FISMA is a US federal law that requires agencies, and the contractors and other organizations that run systems on their behalf, to protect information with a documented, risk-based security program. Compliance means following NIST standards, authorizing each system to operate, and monitoring it over time. It is not a certificate you buy.
What does FISMA actually say?
The Federal Information Security Management Act passed in 2002 as part of the E-Government Act. It told every federal agency to build, document and run an agency-wide information security program. That program covers the agency's own systems and also those managed by another agency, a contractor or another source.
In 2014 Congress passed the Federal Information Security Modernization Act, which amended the 2002 law. According to CISA, it codified the Department of Homeland Security's role in administering security policy for civilian executive branch systems, clarified the Office of Management and Budget's oversight, and cut wasteful reporting while adding reporting for major incidents. Agencies now report major incidents and data breaches to Congress.
Both versions keep the same short name, which is why people write "FISMA and FISMA compliance" as if they were two things. They are one law and its later update.
Who has to comply?
NIST states that FISMA applies to federal agencies and to contractors or other sources that provide information security for information and systems supporting an agency's operations and assets. A federal information system includes one operated by an agency or by a contractor on the agency's behalf.
Here is a constructed example. A small company hosts a case-tracking application for a civilian agency. The agency owns the data, the company runs the servers. The system is a federal information system for FISMA purposes, so the agency will expect the company to meet the same control baseline it would apply to its own data center.
A company that sells software to the public, with no agency system involved, is not subject to FISMA directly. It may still meet FISMA-derived requirements through a contract.
How does the NIST process work?
NIST is blunt that its standards are not a "FISMA compliance checklist." The goal is managing risk, and compliance follows from doing that well. The Risk Management Framework gives a repeatable seven-step path:
- Prepare the organization and its risk management roles.
- Categorize the system and its information by impact.
- Select a set of SP 800-53 controls based on that impact and on risk assessment.
- Implement the controls and document how.
- Assess whether they are in place, working as intended and producing the desired results.
- Authorize the system to operate, by a senior official who accepts the residual risk.
- Monitor control implementation and changes in risk on an ongoing basis.
The authorizing official reads the documentation that comes out of these steps and decides whether to accept the remaining risk.
What changed with the 2014 update?
Three things matter to practitioners. Reporting became less about paperwork and more about incidents. Continuous monitoring got more weight, so a point-in-time audit is not enough. And agencies gained clearer access to DHS technical help. CISA also publishes yearly FISMA reporting metrics for chief information officers, inspectors general and senior agency officials for privacy, which show what agencies are measured on.
What are the common mistakes?
Treating authorization as a one-time event. Authorization is a decision with an expiry in practice, because the monitoring step keeps feeding new risk information back to the authorizing official.
Confusing the law with a checklist. The law sets the duty. The NIST publications explain how to meet it, and agencies add their own requirements through contracts.
Skipping inventory. You cannot categorize or monitor a system whose components you cannot list. Software bills of materials and dependency inventories help here, because a vulnerable library inside an application is part of the system's risk.
What to do
- Find out whether your system is a federal information system, by asking the contracting officer or reading the contract clauses.
- Get the system's impact categorization from the agency before selecting controls.
- Map your existing controls to the SP 800-53 baseline and list the gaps.
- Write down how each control is implemented, in your security documentation.
- Set up continuous monitoring: vulnerability scans, configuration checks and inventory reviews on a schedule.
- Track every open weakness with an owner and a date.
Safeguard can help with the dependency and vulnerability side of that list, through SBOM and dependency scanning and compliance automation. It does not certify you or authorize a system. That decision stays with the agency.
Quick check
Is there an official FISMA certification?
No. NIST describes the process as risk management, and the authorizing official at the agency makes the decision to operate a system. Third parties can assess controls, but no one certifies a company as "FISMA compliant" in a way that replaces that decision.
Does FISMA apply to private companies?
Only when they operate or support a federal information system for an agency. A private company with no agency system is not covered directly.
Sources
Last reviewed: 18 October 2026.
