The statute, and what it actually says
FISMA is the Federal Information Security Modernization Act of 2014, Pub. L. 113-283, which rewrote the 2002 Federal Information Security Management Act passed as Title III of the E-Government Act. It lives in the U.S. Code at 44 U.S.C. §§ 3551–3558. Read it once and a useful thing becomes obvious: almost every sentence is addressed to an agency head, a Chief Information Officer, or the Director of OMB. No sentence is addressed to a vendor. That is why so many software companies get surprised by it. FISMA does not knock on your door. It arrives inside a contract.
The reach comes from one clause. Under 44 U.S.C. § 3554(a)(1)(A), each agency head must provide information security protections for information collected or maintained by or on behalf of the agency, and for "information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency." Those last nine words are the whole story for a software vendor. If your system is used or operated on the agency's behalf, the agency's statutory duty runs through you, and the agency has no choice but to push the obligation into your contract. OMB Circular A-130, revised in July 2016, says so plainly: agencies must include FISMA requirements in the terms and conditions of contracts and other agreements with external providers.
The second half of the statute is the program. Section 3554(b) lists what the agency's security program must contain, and every item lands on the vendor operating the system: periodic risk assessments, risk-based policies and procedures, security awareness training, periodic testing of control effectiveness at a frequency based on risk "but no less than annually," a documented process for remedial action, incident detection and reporting procedures, and plans for continuity of operations. Section 3555 adds an annual independent evaluation, usually performed by the agency Inspector General or an external auditor working for them. Section 3556 makes CISA the federal incident center. That is the machine you are joining.
Who it applies to, and the test that decides
The question that settles a vendor's obligations is not "do we touch federal data." It is whether the system is operated on behalf of an agency. Three fact patterns come up constantly.
You operate a system for the agency. A case-management application you host, a data pipeline you run in your own cloud account, an analytics service the agency's staff log into for official work. This is squarely inside FISMA. The agency's Authorizing Official signs an Authorization to Operate covering your system, and NIST SP 800-53 controls apply at the baseline the agency's categorization requires.
You sell a commercial cloud service to agencies. FISMA still governs, and the path through it is FedRAMP, which the FedRAMP Authorization Act codified at 44 U.S.C. § 3607 et seq. as part of the FY2023 NDAA. The distinction between the two instruments deserves its own treatment, and we wrote one: FISMA vs FedRAMP, which and when.
You hold agency information on your own corporate systems. Delivering source code, holding Controlled Unclassified Information in your repository, receiving a data extract for model training. Here the governing set is usually NIST SP 800-171 rather than the full 800-53 catalog, carried by DFARS 252.204-7012 in defense work and by the CUI program rule at 32 CFR part 2002 governmentwide. FAR Case 2017-016 proposed a governmentwide CUI clause in January 2025 at 90 FR 4278; read the clause list in the solicitation in front of you rather than assuming what has been finalized.
Where first-time vendors lose the most schedule
Editorial weighting from public guidance and assessment practice — illustrative, not a measured statistic.
Where FISMA enters your contract
FISMA obligations arrive as clauses and as a statement of work, and they are rarely labeled "FISMA." FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems, sets fifteen baseline requirements and appears in solicitations whenever a contractor may have Federal contract information on its systems. In defense work, DFARS 252.204-7012 requires adequate security under NIST SP 800-171 and imposes the 72-hour cyber incident report to DIBNet, 90-day media preservation, and flowdown to subcontractors. DFARS 252.204-7019 and -7020 drive the Supplier Performance Risk System self-assessment score. The CMMC program rule at 32 CFR part 170 took effect on December 16, 2024, and DoD's acquisition rule carrying CMMC into DFARS clauses followed in 2025, which means the score you post can become a certification you have to hold.
Then come the software supply-chain requirements that now travel with any federal software delivery. OMB M-22-18, issued September 14, 2022, and updated by M-23-16 on June 9, 2023, requires agencies to obtain a self-attestation that the producer follows the secure software development practices in NIST SP 800-218, the Secure Software Development Framework. CISA published the common attestation form in March 2024. Executive Order 14028 § 4 put software bills of materials into the same conversation, and NTIA's minimum-elements guidance from July 2021 remains the reference for what an SBOM has to contain. Civilian agencies add their own supplements on top; the GSA acquisition manual, for example, carries GSAM 552.239-71 for security requirements on unclassified IT.
The practical instruction is short. Before you price the work, pull the clause list out of Section I, read the security section of the statement of work, and find the sentence that names a NIST publication or an impact level. That sentence is your cost driver.
What the impact level actually changes
Categorization is the agency's call, not yours. Under FIPS 199 and NIST SP 800-60, the agency's system owner assigns a potential-impact rating of low, moderate, or high across confidentiality, integrity, and availability, then takes the high-water mark. FIPS 200 makes the minimum control requirement compulsory, and NIST SP 800-53B publishes the baselines. What changes with the level is not only how many controls apply but how much evidence each one demands and how deeply an assessor tests it.
| Categorization | Typical trigger | Approximate 800-53B baseline | What it means in practice |
|---|---|---|---|
| Low | Public data, no PII, limited adverse effect if lost | ~150 controls | Documented practice plus basic scanning; assessment is largely examine and interview |
| Moderate | PII, CUI, most agency business systems | ~290 controls | The common case. Independent assessment, penetration testing, formal contingency and incident testing |
| High | Law enforcement, health, financial, mission-essential systems | ~370 controls | Enhanced separation of duties, stricter media and personnel controls, deeper technical testing |
| National security system | Intelligence, military command and control, classified processing | CNSSI 1253 overlays | Outside the ordinary FISMA path; the categorization method and the authorizing chain both change |
Two implications matter for pricing. First, a moderate system on a FedRAMP-authorized infrastructure inherits a large share of the physical, environmental, and infrastructure controls from the provider, which is why the Customer Responsibility Matrix from your hosting provider is one of the first documents to obtain. Second, control counts understate the work. The labor sits in producing repeatable evidence for the controls you own, not in reading the catalog.
The artifacts that must exist
An authorization package is a defined set of documents. An assessor will ask for them by name, and an Inspector General will ask again a year later. NIST SP 800-37 Rev. 2 organizes the work into seven Risk Management Framework steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. The artifacts map onto those steps.
- FIPS 199 categorization memo naming the information types from SP 800-60 and the resulting impact level
- System Security Plan written to NIST SP 800-18, with an implementation statement for every applicable control and a boundary diagram showing every data flow that crosses it
- Risk assessment per NIST SP 800-30, refreshed on a stated cadence rather than once at authorization
- Security Assessment Plan and Security Assessment Report produced against the procedures in NIST SP 800-53A Rev. 5 by an assessor independent of the development team
- Plan of Action and Milestones (POA&M) with a responsible party, resources, and a real completion date on every open weakness
- Contingency plan and test record per NIST SP 800-34, and an incident response plan and test record per NIST SP 800-61
- Configuration management plan and baselines per NIST SP 800-128, tied to a named benchmark such as a DISA STIG or a CIS benchmark
- Continuous monitoring strategy per NIST SP 800-137, stating scan frequency, metrics, reporting path, and the change threshold that forces reassessment
- Privacy documentation: a Privacy Threshold Analysis, a Privacy Impact Assessment under § 208 of the E-Government Act of 2002, and a System of Records Notice under the Privacy Act, 5 U.S.C. § 552a, where the system retrieves records by personal identifier
- Supply-chain package: the SP 800-218 secure development attestation, an SBOM, and evidence that cryptographic modules appear on the NIST Cryptographic Module Validation Program list under FIPS 140-3
The Authorizing Official signs the ATO letter on the strength of that package. Since the 2016 revision of Circular A-130, agencies may run ongoing authorization driven by continuous monitoring instead of a fixed three-year reauthorization clock, which shifts effort from a periodic scramble into steady operations.
Findings that come back every time
Assessment findings are unusually predictable. The same handful accounts for most of what lands in a first Security Assessment Report, and every one of them is a documentation-and-discipline problem rather than a technical mystery.
- The SSP describes a different system. The plan was written before the architecture settled and never re-baselined, so the diagram omits a queue, a cache, or an entire second region
- POA&M items past due with no revised milestone, which reads to an assessor as an unmanaged risk register rather than a slipped date
- Unauthenticated vulnerability scans submitted as evidence, which show the perimeter and miss the host
- Audit logging short of OMB M-21-31, which set event-logging maturity tiers and a retention expectation of twelve months in active storage plus eighteen months in cold storage
- No test record for contingency or incident response; the plans exist, the annual exercise never happened, and controls CP-4 and IR-3 fail on evidence
- Shared administrator accounts and CI/CD pipelines where one engineer can commit, approve, and deploy, which defeats separation of duties
- Cryptography that is strong but unvalidated, because the library is not a module on the CMVP validated list
- Undocumented interconnections to a partner API or a corporate identity provider that never made it into an agreement per NIST SP 800-47
- Training and Rules of Behavior records that cannot be produced per person per year for everyone with system access
The Inspector General evaluation under § 3555 grades on a five-level maturity model, where Level 4, Managed and Measurable, is the bar for an "effective" rating. Repeat findings are what keep programs below it. GAO has kept federal information security on its High-Risk List since 1997, and the themes in its reporting are the themes above.
The reporting clocks
Three clocks matter, and they run at different speeds. CISA's federal incident notification guidelines direct agencies to report confirmed incidents within one hour of identification, which means your contractual notification to the agency has to be faster than that or the agency cannot comply. FISMA itself requires the agency to notify Congress of a major incident within seven days of the date it reasonably believes one occurred, under 44 U.S.C. § 3554(b)(7)(C)(iii)(III); OMB's annual FISMA guidance, most recently in the M-24-04 series, defines what counts as major. In defense contracts, DFARS 252.204-7012 sets its own 72-hour report to DIBNet, preservation of affected media for at least 90 days, and submission of malicious software to the DoD Cyber Crime Center.
Write those clocks into your own runbook with names and phone numbers attached, and rehearse them. An incident is a terrible time to discover that the notification path in your plan points at a person who left last year.
What it costs to get wrong
FISMA carries no civil penalty aimed at a vendor. The consequences arrive through the contract and through the False Claims Act, and they have grown teeth. The Department of Justice announced its Civil Cyber-Fraud Initiative on October 6, 2021, to pursue contractors that misrepresent cybersecurity practices or fail to report incidents. Aerojet Rocketdyne settled for $9 million in July 2022. Verizon paid $4,091,317 in September 2023 over a service delivered to federal agencies. MORSECORP agreed to $4.6 million in March 2025 for representations about its NIST SP 800-171 posture. Raytheon entities and Nightwing agreed to $8.4 million in May 2025 over cybersecurity requirements on defense contracts.
Under 31 U.S.C. § 3729, False Claims Act liability runs to treble damages plus per-claim civil penalties that adjust annually for inflation, and 31 U.S.C. § 3730(d) pays a relator between 15 and 30 percent of the recovery. That relator share is why these cases surface: the person most likely to file is an engineer who watched a self-assessment score get rounded up. Short of litigation, the ordinary consequences are still expensive. A cure notice, a corrective action request, a negative CPARS entry that follows you into every future source selection, withheld payments, an ATO that lapses and takes the system offline, termination for default, and suspension or debarment under FAR subpart 9.4.
The other cost is the quiet one. Agencies do not award new work to vendors whose last authorization package took eleven months and arrived with sixty open POA&M items. Security performance is procurement performance.
A practical sequence for the first time
The sequence below is the order that avoids rework. The most common mistake is writing the System Security Plan first, before the boundary and the inherited controls are settled, which guarantees a rewrite. The second most common is treating assessment as the finish line rather than the start of monitoring.
First authorization: working sequence
Six to twelve months is an honest range for a first moderate-baseline authorization, and the variance is driven almost entirely by step 3. Teams that already run configuration as code, centralized logs, and reviewed pull requests find that most of the technical evidence exists and only needs to be pointed at. Teams that have to build all of it during the authorization take the long end.
How we work this
Our engineers build production AI, ML, data, and cloud systems for federal customers, and we treat the security package as part of the build rather than as a document produced afterward by someone who was not in the room. That means the boundary diagram comes out of the same repository as the infrastructure code, the control implementation statements name the actual Terraform module or pipeline stage that satisfies them, and the evidence an assessor will ask for is generated on a schedule instead of assembled under pressure. Our bench includes named engineers, licensed professional engineers, and domain specialists, and we work as prime or as a subcontractor to an integrator that needs the security package and the software delivered by the same team.
Bottom line
FISMA is a statute about agencies that becomes an obligation for you the moment your software is used or operated on an agency's behalf. The requirements themselves are stable and published: categorize under FIPS 199, select and implement controls from NIST SP 800-53, assess independently, document in an SSP and a POA&M, get an ATO, and monitor continuously with annual testing. The difficulty is never in finding the rule. It is in producing evidence, on a schedule, that the controls you wrote down are the controls you run. Build that habit first and the paperwork follows quickly.
Common questions on scope and limits
Does FISMA apply to a company that only writes code and never hosts anything?
Usually not as a system authorization. If you develop software the agency deploys and operates, the agency authorizes its own system. Your obligations are contractual and supply-chain: the SP 800-218 secure development attestation, an SBOM, protection of any Federal contract information or CUI on your corporate systems under FAR 52.204-21 or DFARS 252.204-7012, and cooperation with the agency's assessment of the delivered product.
Can an authorization from one agency be reused by another?
For cloud services, that is exactly what FedRAMP is for, and the FedRAMP Authorization Act at 44 U.S.C. § 3607 et seq. gives an existing FedRAMP authorization a presumption of adequacy for other agencies. Outside FedRAMP, reciprocity is discretionary. An Authorizing Official may accept another agency's package as the basis for a decision, and often will if the boundary and categorization match, but nothing compels it.
Is there such a thing as a "FISMA certified" product?
No. FISMA authorization attaches to a system operating in a defined boundary for a specific agency, not to a product on a shelf. A vendor claiming FISMA certification is describing something the statute does not create. The things that do exist as portable credentials are a FedRAMP authorization listed in the marketplace, a FIPS 140-3 validated cryptographic module on the CMVP list, and a CMMC certification at a given level.
What happens if an open POA&M item cannot be closed on time?
Revise the milestone before the date passes, state the reason and the compensating control, and route it to the Authorizing Official. A tracked and re-planned item is a managed risk. A silently expired item is a finding, and repeated silent expirations are what move an Inspector General toward an ineffective rating for the program.
Frequently asked questions
The Federal Information Security Modernization Act of 2014, Pub. L. 113-283, codified at 44 U.S.C. §§ 3551–3558. It replaced the 2002 Act of nearly the same name. Agency responsibilities, including the clause covering systems operated by a contractor on an agency's behalf, sit at § 3554.
It depends on the FIPS 199 impact level the agency assigns. The SP 800-53B baselines run roughly 150 controls at low, 290 at moderate, and 370 at high, before agency-specific overlays. A large share of infrastructure controls are inherited if you host on a FedRAMP-authorized platform, which is why the provider's Customer Responsibility Matrix is an early document to obtain.
Six to twelve months is realistic for a moderate-baseline system. The variance comes from operational evidence: configuration baselines, authenticated scanning, centralized logging with the retention OMB M-21-31 expects, and training and approval records. Teams with those already running move through assessment far faster than teams building them during the process.
FISMA imposes no direct fine on a contractor. Exposure runs through the contract and through the False Claims Act, 31 U.S.C. §§ 3729–3733. Settlements under the Justice Department's Civil Cyber-Fraud Initiative include $9 million from Aerojet Rocketdyne in 2022, $4,091,317 from Verizon in 2023, $4.6 million from MORSECORP in 2025, and $8.4 million from Raytheon entities and Nightwing in 2025. Contract-level consequences include cure notices, negative CPARS ratings, a lapsed ATO, termination, and suspension or debarment.
Not necessarily. The 2016 revision of OMB Circular A-130 moved federal practice toward ongoing authorization supported by continuous monitoring, so many systems no longer face a fixed three-year reauthorization. The monitoring program, the annual control testing required by 44 U.S.C. § 3554(b)(5), and a defined significant-change trigger replace it.