FISMA Compliance Checklist: What the Law Actually Requires

FISMA Compliance Checklist: What the Law Actually Requires

A FISMA compliance checklist is a list of what the Federal Information Security Modernization Act requires an agency, or a contractor running a system for an agency, to have in place.

The catch is that NIST, which writes the standards FISMA points to, says plainly that its own publications are "not a 'FISMA Compliance checklist'". FISMA asks for a risk-based security program, and in NIST's words, compliance "is a byproduct" of running one.

So this checklist is built from the law itself. It follows the eight program elements written into 44 U.S.C. 3554(b), the documents a system needs to get an authorization to operate, the reporting duties, and what changed in the FY 2026 and FY 2027 reporting metrics. Every requirement links to or names the source it comes from. All sources were read on 2026-10-26.

What FISMA Is, in Two Paragraphs

FISMA started as the Federal Information Security Management Act of 2002, part of the E-Government Act. It requires each federal agency to "develop, document, and implement an agency-wide program to provide information security" for its information and systems, "including those provided or managed by another agency, contractor, or other sources" (NIST FISMA background).

The Federal Information Security Modernization Act of 2014 amended it. According to CISA, the 2014 law wrote into statute the Department of Homeland Security's job of putting security policy into effect at civilian agencies, and gave it the power to issue binding operational directives. CISA, part of DHS, carries out that role today. The 2014 law also spelled out the oversight role of the Office of Management and Budget (OMB). And it required agencies to tell Congress about major incidents. In day-to-day terms, OMB sets the policy, CISA runs operations and collects the metrics, and NIST writes the technical standards.

Does FISMA Apply to You?

FISMA applies to federal executive agencies and to the systems run for them. The statute's definition of a federal information system reaches "an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency" (NIST, quoting FISMA 2002). Here is how that plays out in common situations.

The contract decides the edge cases. Read the security clauses before you assume you are in or out. For the cloud route, see our FedRAMP authorization guide. For CUI on contractor systems, see the NIST 800-171 compliance guide and the CMMC compliance guide.

The FISMA Compliance Checklist: Eight Program Elements

Section 3554(b) of title 44 lists what every agency security program must include. This is the closest thing to an official FISMA checklist, because it is the statute's own list. Each item below quotes or paraphrases the law and adds what it means in practice.

1. Periodic risk assessments

The law requires "periodic assessments of the risk and magnitude of the harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems" supporting the agency.

• ☐ Every system is categorized as low, moderate, or high impact under FIPS 199, which rates confidentiality, integrity, and availability separately.
• ☐ Risk assessments are dated, repeated on a schedule, and redone after major changes.

2. Risk-based policies and procedures

Policies must be based on those risk assessments, "cost-effectively reduce information security risks to an acceptable level," cover each system's whole life cycle, and ensure compliance with OMB policy and the NIST standards issued under 40 U.S.C. 11331.

• ☐ Each system meets the minimum requirements in FIPS 200 by applying the matching SP 800-53B control baseline.
• ☐ Minimum configuration requirements are defined. The statute names "minimally acceptable system configuration requirements" as something the agency sets.

3. Subordinate plans

The program needs "subordinate plans for providing adequate information security for networks, facilities, and systems or groups of information systems, as appropriate."

• ☐ A system security plan exists for each system and describes how each selected control is implemented.
• ☐ Shared networks and facilities are covered by a plan too, not left out because no single system owns them.

4. Security awareness training

Training must inform personnel, "including contractors," of the risks tied to their work and their duties under agency policy.

• ☐ Contractor staff are in the training records, not only employees.
• ☐ Role-based training covers people with privileged access.

5. Testing at least once a year

Testing is where the statute sets a hard floor: "periodic testing and evaluation" of policies, procedures and practices "with a frequency depending on risk, but no less than annually." That testing must cover the management, operational and technical controls of every system in the agency's inventory, and must include automated tools.

• ☐ Every system in the inventory had at least one control test in the last 12 months.
• ☐ Automated scanning or monitoring is part of the testing, not only document review.

6. Remedial action

Finding problems is not enough. The agency must have "a process for planning, implementing, evaluating, and documenting remedial action" for deficiencies.

• ☐ Each weakness found is tracked to closure with an owner and a date. Agencies track this in a plan of action and milestones (POA&M).

7. Incident detection, reporting, and response

Incident procedures must cover detection, reporting and response, and must line up with the standards and guidelines in 44 U.S.C. 3556(b). The agency must notify and consult the federal information security incident center (which the 2014 Act placed within DHS) and, as the case requires, law enforcement and the relevant Inspector General and General Counsel offices. For a major incident, the agency must notify the relevant congressional committees "not later than 7 days after the date on which there is a reasonable basis to conclude that the major incident has occurred."

• ☐ The incident plan names who reports to CISA, and when.
• ☐ The plan includes the seven-day congressional clock for major incidents.

Our incident response plan guide covers how to write the plan itself.

8. Continuity of operations

The last element is "plans and procedures to ensure continuity of operations" for systems that support agency operations.

• ☐ Contingency plans exist per system and have been tested.

The System-Level Checklist: Getting an Authorization to Operate

The eight elements describe the agency program. Each individual system also needs an authorization to operate (ATO). The CISA FISMA metrics define an ATO as "the official management decision given by a senior federal official or officials to authorize operation of an information system and to explicitly accept the risk" to the agency and others (FY 2026 and FY 2027 CIO FISMA Metrics).

NIST's Risk Management Framework (SP 800-37 Rev. 2) is the seven-step process that gets a system there: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. We explain each step in our NIST RMF guide. For a checklist, what matters is the paper trail each step leaves behind:

• ☐ Categorization record: the FIPS 199 impact level, with the reasoning.
• ☐ Control selection: the SP 800-53B baseline plus any tailoring. Use the current catalog, SP 800-53 Rev. 5. NIST issued Release 5.2.0 on August 27, 2025, adding controls such as SA-24. Our NIST 800-53 controls guide walks through the families.
• ☐ System security plan (SSP): how each control is implemented, including controls inherited from a cloud provider or a common control provider.
• ☐ Assessment report: what the independent assessor tested and found.
• ☐ Plan of action and milestones: the open weaknesses and their fix dates.
• ☐ Authorization decision: the signed ATO, with the accepted residual risk stated.
• ☐ Continuous monitoring strategy: how controls are watched after the ATO. NIST's guide is SP 800-137.

OMB Circular A-130 is the policy that makes this binding across agencies. NIST summarizes it as requiring agencies to plan for security, assign security responsibility, periodically review controls, and "authorize system processing prior to operations and, periodically, thereafter."

The Reporting Checklist

FISMA is as much about reporting as about controls. Four reporting duties come straight from the statute and CISA's guidance.

• ☐ Annual agency report. Under 3554(c), each agency reports annually to OMB, DHS, the named congressional committees and the Comptroller General on "the adequacy and effectiveness" of its security policies, procedures and practices, including each major incident.
• ☐ Annual independent evaluation. Under 44 U.S.C. 3555, the agency's Inspector General, or an independent external auditor the IG chooses, evaluates the program every year. Agencies without an IG must hire an external auditor themselves.
• ☐ CIO metrics. Agency Chief Information Officers submit the CIO FISMA Metrics through CyberScope by the deadlines in CISA's metrics document. For the FY 2026 fourth-quarter and annual period, the deadline is October 30, 2026. The FY 2027 deadlines are January 29, April 30, July 30 and October 29, 2027. Non-CFO Act agencies report only for the fourth-quarter and annual periods.
• ☐ Major incident notice. Seven days to Congress, as set out in element 7 above.

The statute also tells the agency CIO to report annually to the agency head on how well the security program works, "including progress of remedial actions." That is where your POA&M data ends up.

What Changed in the FY 2026 and FY 2027 Metrics

CISA and OMB published the FY 2026 and FY 2027 CIO FISMA Metrics on August 3, 2026 and revised them to version 1.1 on September 1, 2026. The metrics are what agencies are actually measured on, so they are a good guide to where scrutiny is moving. Four changes stand out.

1. The ATO process itself is now measured. New questions ask for the average elapsed hours to complete each RMF step from Prepare through Authorize, whether the agency's governance, risk and compliance (GRC) tool can import and export OSCAL (NIST's machine-readable format for security plans and assessments), and what share of authorizations use "significant automation." An agency that still assembles ATO packages by hand will have to report that.

For a system owner, the detail that matters is how CISA counts the hours. Elapsed time for a step runs "from the completion of the preceding step to the completion of the step in question and includes any idle or queue time between steps," counted at 24 hours per calendar day, weekends and holidays included, "not the labor hours expended by any party." Three weeks waiting for an assessor's calendar or an authorizing official's signature shows up in the number exactly like three weeks of work. Shortening the queues between steps is the quickest way to improve it.

2. End-of-support edge devices have deadlines. The metrics track BOD 26-02, a CISA binding operational directive issued February 5, 2026. It covers firewalls, routers, switches, load balancers, wireless access points and similar devices on the network boundary that no longer get vendor security updates.

The directive applies to systems "hosted by third parties on an agency's behalf." It binds agencies, not contractors, but agencies "may need to modify contracts to comply," so contractors running agency networks should expect the requirement to reach them through the contract.

3. Logging maturity has a new yardstick. The logging section now measures progress against OMB Memorandum M-26-14, "Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats." An agency's overall maturity is set by the lowest of the five logging elements, so one weak area caps the score.

4. AI systems get pilot questions. Agencies now report how many systems have large language model or generative AI capabilities in operational use, how many were built with secure-by-design practices, and how many have documented data flows and access boundaries. CISA labels these pilot metrics.

One section carries over from the FY 2025 metrics and still deserves a line on your checklist: phishing-resistant MFA is counted system by system. Agencies report how many systems enforce a phishing-resistant credential "(e.g., FIDO2, PIV)" and how many still accept phishable ones such as push notifications, one-time codes, SMS or voice. A system does not count as MFA-enabled unless every application inside its boundary is. Our NIST MFA standards guide explains what makes a method phishing-resistant.

The interconnection questions also cite OMB M-22-09, the federal zero trust strategy. If your agency is still early on that path, our NIST 800-207 zero trust guide is a plain starting point.

A Contractor's FISMA Checklist

If you operate a system for an agency, FISMA reaches you through the agency and the contract. The agency owns the ATO and the reporting. You supply the evidence. In practice, that means:

1. Find the security clauses first. The contract tells you which baseline, which reporting timelines, and which agency policies apply.
2. Confirm the impact level. Ask the agency for the FIPS 199 categorization. Everything else scales from it.
3. Write or update the SSP for the system boundary you run, and mark which controls you inherit from a cloud provider.
4. Put your staff through the agency's awareness training. The statute names contractors explicitly.
5. Agree incident reporting in writing: who you call at the agency, how fast, and what you send. The agency's seven-day clock for major incidents runs from the date there is "a reasonable basis to conclude" one occurred, so slow reporting from you shortens its window.
6. Feed the POA&M. Report weaknesses and fix dates in the format the agency uses.
7. Inventory your edge devices against CISA's end-of-support list if you run network gear on the agency's behalf.
8. Plan for continuous monitoring, not a one-time audit. Ask what the agency expects monthly, quarterly and annually.

Common FISMA Compliance Mistakes

• Treating SP 800-53 as the whole job. Controls are element 2 of eight. Risk assessment, training records, annual testing, remediation tracking, incident procedures and contingency plans all need their own evidence.
• Leaving contractors out of training records. Section 3554(b)(4) names contractors.
• Testing "annually" by reviewing documents only. The law asks for testing of management, operational and technical controls, and for automated tools.
• Forgetting the seven-day congressional notice for major incidents.
• Counting a system as MFA-enabled when one application inside the boundary still takes a password alone.
• Ignoring old edge devices because they still work. Under BOD 26-02, still working does not matter if the vendor no longer issues security updates.

Frequently Asked Questions

Is there an official FISMA compliance checklist?

No. NIST states that its risk management standards are "not a 'FISMA Compliance checklist.'" The nearest official list is the eight program elements in 44 U.S.C. 3554(b), which this guide follows, plus the questions in CISA's annual CIO FISMA Metrics.

What are the FISMA requirements in short?

An agency-wide security program with eight elements: risk assessments, risk-based policies, system security plans, awareness training, annual testing, remediation tracking, incident procedures, and continuity plans. Each system also needs an authorization to operate, and the agency reports every year and gets an independent evaluation.

What is the difference between FISMA and NIST 800-53?

FISMA is the law. SP 800-53 is the NIST control catalog that agencies use to meet it. Under FISMA, agencies must comply with the NIST standards issued under 40 U.S.C. 11331, such as FIPS 199 and FIPS 200, and FIPS 200 points to SP 800-53 for the controls.

Do private companies need to be FISMA compliant?

Only when they operate an information system for a federal agency, or sell a cloud service agencies authorize through FedRAMP. A private company holding federal CUI on its own systems usually follows NIST SP 800-171 instead.

How often is FISMA compliance evaluated?

At least once a year. Agencies must test controls no less than annually, report annually, and receive an annual independent evaluation from their Inspector General or an outside auditor. CFO Act agencies also report CIO metrics during the year through CyberScope.

What happened to the 2002 FISMA?

The Federal Information Security Modernization Act of 2014 amended the 2002 Act rather than replacing it. People still say "FISMA" for both; the current text is in 44 U.S.C. chapter 35, subchapter II.

Sources Used

1. NIST, FISMA Background, accessed 2026-10-26
2. 44 U.S.C. 3554, Federal agency responsibilities, govinfo, accessed 2026-10-26
3. 44 U.S.C. 3555, Annual independent evaluation, govinfo, accessed 2026-10-26
4. Public Law 113-283, Federal Information Security Modernization Act of 2014, accessed 2026-10-26
5. CISA, Federal Information Security Modernization Act, accessed 2026-10-26
6. CISA and OMB, FY 2026 and FY 2027 CIO FISMA Metrics, version 1.1, September 1, 2026
7. CISA, BOD 26-02: Mitigating Risk From End-of-Support Edge Devices, accessed 2026-10-26
8. OMB Circular A-130, accessed 2026-10-26
9. OMB M-26-14 and OMB M-22-09, accessed 2026-10-26
10. FIPS 199, FIPS 200, SP 800-37 Rev. 2, SP 800-53 Rev. 5, SP 800-53B, SP 800-137, NIST CSRC, accessed 2026-10-26
11. 44 U.S.C. 3556, Federal information security incident center, govinfo, accessed 2026-10-26

Last reviewed: 2026-10-26. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.