FISMA: what the law requires and how to automate it

What FISMA is

FISMA started as Title III of the E-Government Act of 2002, establishing the basic requirement that federal agencies run an agency-wide information security program rather than securing systems ad hoc, system by system. The Federal Information Security Modernization Act of 2014 updated the law without replacing its core structure: it reassigned day-to-day operational responsibility, giving the Department of Homeland Security a stronger operational role in overseeing agency implementation, including binding operational directives, while OMB retained overall policy authority, and it pushed the law's emphasis further toward continuous monitoring rather than periodic, paperwork-heavy certification.

FISMA requires an agency-wide program, typically owned by the agency's chief information security officer, that includes periodic risk assessments, documented policies and procedures, security awareness training, an incident response capability, contingency and continuity planning, and configuration management, all backed by an annual independent evaluation.

The law is deliberately technology-agnostic; it tells agencies what outcome to achieve, not which specific control to implement. That gap is filled by NIST: FIPS 199 sets the categorization method, FIPS 200 sets minimum security requirements, and the 800-53 control catalog supplies the actual controls agencies implement through the NIST RMF process.

Who needs FISMA

FISMA is a direct legal obligation on federal agencies, but it reaches further than the agencies themselves.

• Every federal executive branch agency, obligated by statute to run a compliant information security program covering its full system inventory.
• Contractors and cloud service providers operating an information system on an agency's behalf, whose systems fall under the sponsoring agency's own FISMA program through contract terms and agency oversight, even though the contractor is not itself a federal entity.
• Component bureaus and sub-agencies within a larger department, each of which typically operates under the parent agency's overall FISMA program while still owning its own system inventory and reporting.

The trigger is not whether an organization thinks of itself as a federal entity; it is whether a federal information system, or a system operated on an agency's behalf, is involved at all.

FISMA requirements, by program element

The annual reporting cycle produces what the field calls FISMA metrics: a maturity-model scoring, running from ad hoc to optimized, applied by both the agency's own CIO office and, separately, by its Inspector General, so OMB receives two independent views of the same program rather than a single self-reported number. OMB compiles agency-level results into its own annual report to Congress on the state of federal information security government-wide.

The FISMA compliance cycle, step by step

FISMA does not run once; it is a recurring annual cycle layered on top of the continuous work of actually securing systems day to day.

1. Inventory every information system: Build and maintain a complete inventory, including systems operated by contractors on the agency's behalf, since an incomplete inventory undermines everything downstream; ongoing, with an initial pass commonly taking two to six weeks.
2. Categorize each system: Apply FIPS 199 to determine each system's impact level, feeding directly into which control baseline applies.
3. Select, implement, and assess controls through the NIST RMF: Run the systems through the same risk management process described on the NIST RMF page, the largest and longest-running piece of the cycle.
4. Run continuous monitoring throughout the year: Track control effectiveness and system changes on an ongoing basis rather than waiting for the annual review to surface problems.
5. Undergo the annual independent evaluation: The agency Inspector General, or a contracted auditor for agencies without one, independently evaluates the program's maturity; commonly several weeks to a few months of fieldwork depending on agency size.
6. Submit metrics and reports to OMB: File the CIO and IG metrics, historically through CyberScope, within the annual reporting window OMB sets.
7. OMB compiles the government-wide report to Congress: Agency-level results roll up into OMB's annual report on the state of federal information security, and the cycle begins again the following year.

How long does FISMA compliance take and what does it cost?

FISMA is not a project with an end date; it is a standing program, so cost and duration split into two different questions: how long it takes to stand up the program, and what it costs to run every year afterward.

Building a compliant program from close to nothing, inventory, policies, initial categorization, and a functioning risk assessment cycle, commonly takes an agency component four to nine months. Once established, the program repeats annually and does not have a natural end point; the ongoing cost is the more relevant figure for budgeting purposes.

Cost is dominated by internal labor: CISO office staff and ISSOs across the system inventory, which scales with how many systems the agency operates. The annual independent evaluation adds a separate cost, whether performed by an in-house Inspector General staff or a contracted auditor, commonly ranging from the tens of thousands of dollars for a small component to several hundred thousand dollars a year for a large department with a broad system inventory.

ACTA is licensed per environment, and every engagement starts with a conversation. ACTA's contribution is to the assessment and reporting artifacts described below, generated from the live environment; the independent evaluation itself remains a separate, required function ACTA does not replace.

Common failure points

Most FISMA problems are program-management failures, not technical ones.

• An incomplete system inventory that omits contractor-operated systems or shadow IT the agency does not formally track.
• Treating the annual report as the deliverable rather than a snapshot of a program that is supposed to run continuously the rest of the year.
• Miscategorizing systems under FIPS 199, which understates or overstates the controls the agency then implements.
• POA&M items that persist year over year without a credible remediation date attached.
• The CIO office and the Inspector General producing inconsistent maturity ratings because the two offices are not working from the same underlying evidence.
• Confusing FISMA, the law and the underlying program, with FedRAMP, a cloud-specific implementation of similar principles, and gathering the wrong kind of evidence as a result.

How ACTA automates FISMA

ACTA's federal pack library includes FISMA alongside NIST 800-53, the NIST RMF, and FedRAMP, and every pack ships with every license, so an agency component running multiple programs off the same underlying control set is not paying separately for each one. Packs are editable YAML, so control narratives can reflect how a specific system is actually configured.

From a live environment, ACTA generates the System Security Plan, Security Assessment Report, POA&M, Risk Assessment Report, control narratives, and evidence binder, the artifact set an agency can put in front of an Inspector General or contracted auditor when the annual independent evaluation asks how the program is run, rather than a static document written once at the start of the fiscal year.

Deployment matters as much as generation for a federal-agency program: ACTA is a single hardened Docker image under 20 MB running on roughly 100 MB of RAM, fully air-gappable. The standard build phones home only for a license heartbeat; the air-gapped build makes no network callback at all. Evidence never leaves the agency's own boundary, which matters directly for a program where FISMA's reporting expectations sit on top of otherwise sensitive system data.

Because ACTA runs on goRapide, BMD's deterministic causal engine, with no LLMs, no agents, and nothing probabilistic in the compliance path, the same environment run through the same journey twice produces identical scores, so the numbers an agency reports do not drift between the self-assessment and the evidence behind it, with an inspectable causal chain behind every score. Continuous monitoring afterward tracks credential health, evidence freshness, and drift from previously passing controls, refreshing a stale posture in two clicks rather than waiting for next year's reporting cycle to notice it slipped.

FISMA and adjacent frameworks

FISMA sets the legal requirement; NIST 800-53 supplies the technical control catalog agencies actually implement to satisfy it, and the NIST RMF is the process NIST publishes for selecting, implementing, and monitoring those controls over a system's lifecycle.

FISMA versus FedRAMP is a common point of confusion: FISMA is the underlying statute governing federal agency information security broadly, while FedRAMP is a specific program built to satisfy FISMA's requirements for cloud services shared across multiple agencies, using a centralized assessment so each agency does not repeat the same FISMA-driven review of the same cloud product independently.

See the wider compliance framework library for how FISMA's requirements connect to the rest of the federal and defense landscape this corpus covers.