FISMA binds federal agencies — and, through contracts, the organisations that operate systems on their behalf. Many contractors first encounter it as a set of clauses requiring an authorisation package for a system they built, with a timeline attached.
The framework underneath
FISMA is implemented through the NIST Risk Management Framework, which runs in defined steps:
- Categorise the system by the impact of a confidentiality, integrity or availability failure — low, moderate or high. This single decision drives the size of everything that follows.
- Select a control baseline from NIST SP 800-53 matching that categorisation, then tailor it with documented justification.
- Implement the controls.
- Assess them, typically by an independent assessor producing a security assessment report.
- Authorise — an authorising official accepts the residual risk and grants an Authority to Operate.
- Monitor continuously, because the ATO is conditional on the system remaining in a known state.
Categorisation is where cost is decided. Moving from moderate to high materially expands the control baseline, so the categorisation decision deserves genuine analysis rather than defaulting upward out of caution.
The artefacts
The authorisation package centres on a System Security Plan describing the boundary and how each selected control is implemented, a security assessment report from the assessor, and a POA&M for anything unmet. The SSP is the document everything is judged against — a vague boundary definition causes more difficulty than any individual control gap.
Track control implementation and evidence in one place
GRC Copilot maps control baselines to your evidence and shows what is unmet, which is what an authorisation package depends on.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
How contractors are bound
Not usually by FISMA directly, but by contract clauses requiring compliance with agency security requirements for systems operated on the agency's behalf. That typically means producing the same artefacts, submitting to assessment, and supporting continuous monitoring reporting.
Two things surprise contractors. The boundary often extends further than expected — into supporting infrastructure, identity services and the corporate systems administrators use to reach the environment. And continuous monitoring is a recurring obligation, not a post-award formality: an ATO can be withdrawn.
FISMA, FedRAMP and CMMC
All three sit on NIST control catalogues and are frequently confused:
- FISMA — agencies and systems operated for them, authorised per system by the agency.
- FedRAMP — cloud services sold to agencies, with a standardised authorisation reusable across agencies.
- CMMC / 800-171 — protection of controlled unclassified information in the defence supply chain.
If you provide a cloud service to agencies, FedRAMP is the route. If you operate a system for one agency, FISMA authorisation is. If you hold CUI under defence contracts, 800-171 applies.
Frequently asked questions
Does FISMA apply to us as a contractor?
Through your contract, if you operate a system on an agency's behalf. Read the clauses — the obligation is contractual rather than statutory for you.
How long does an ATO take?
Months, driven by categorisation, assessment scheduling and remediation. The assessor's availability is frequently the constraint rather than your readiness.
Is an ATO permanent?
No. It is conditional on continuous monitoring and can be withdrawn if the system's security posture degrades.
Can we reuse a FedRAMP authorisation?
For a cloud service, that is precisely its purpose — a FedRAMP authorisation is designed to be reused across agencies rather than re-earned.
Key takeaways
- Categorisation decides the baseline and therefore the cost.
- Contractors are bound by clauses, not by the statute directly.
- The boundary usually extends further than teams expect.
- An ATO is conditional and can be withdrawn.