FISMA vs FedRAMP: which applies when

Two instruments, different scopes

FISMA (Federal Information Security Modernization Act of 2014, amending the 2002 original) is a federal law. It requires every federal agency to inventory its information systems, categorize each under FIPS 199, implement NIST 800-53 controls at the appropriate baseline, and maintain an ATO for each system. FISMA applies to systems the agency operates or that are operated on the agency's behalf.

FedRAMP is not a law; it is a government-wide program managed by GSA with oversight from the Joint Authorization Board and the FedRAMP PMO. Its purpose is narrower: standardize the security assessment, authorization, and continuous monitoring for cloud products and services that agencies procure. FedRAMP authorization is reusable across agencies.

Where the line sits

The control crosswalk

Both instruments sit on the same underlying control catalog: NIST 800-53 Rev 5. FedRAMP defines specific baseline selections (Low, Moderate, High, Li-SaaS). FISMA points agencies to the same 800-53 baselines via FIPS 200. The overlap is nearly total at the control level. The difference is who does the assessment and for whose benefit.

• A FedRAMP-authorized cloud service comes with an assessed body of evidence against 800-53 controls.
• An agency building a system on top of that service inherits a large fraction of those controls into its FISMA ATO package.
• The agency still has to assess and document the application-layer controls it added on top.
• The FedRAMP package is reusable; the agency's application-layer ATO is not (each agency does its own application ATO for each system).

Three common cases

flowchart TD
    A([Your federal AI engagement]) --> B{Are you selling a\nmulti-agency SaaS product?}
    B -->|Yes| C[FedRAMP Authorization required\nBefore any agency can procure at scale]
    B -->|No — delivery or consulting| D{Operating inside an\nagency-authorized boundary?}
    D -->|Yes — SBIR, task order,\nagency-hosted system| E[FISMA via agency ATO\nAsk the CO where the boundary sits]
    D -->|No — hosting your own system| F{FAR or DFARS\ncontract clause flows 800-53?}
    F -->|Yes| G[800-53 or 800-171 compliance\nAgency runs ATO against your impl]
    F -->|No clause yet| H[Clarify boundary before\nyou architect — saves weeks of rework]
    C --> I[FedRAMP path:\nSponsor agency, 3PAO, JAB or agency ATO]
    style C fill:#dc2626,color:#fff,stroke:#dc2626
    style E fill:#3b82f6,color:#fff,stroke:#3b82f6
    style G fill:#7c3aed,color:#fff,stroke:#7c3aed
    style H fill:#d97706,color:#fff,stroke:#d97706
    style I fill:#0d9488,color:#fff,stroke:#0d9488
        

Case 1: You are a SaaS vendor selling to agencies

You need FedRAMP authorization. Without it, the agency cannot procure you at scale. FISMA obligations are the agency's at the system level; your FedRAMP package is what they rely on to discharge the cloud-service portion of their FISMA duty.

Case 2: You are an agency building a new system on a FedRAMP-authorized IaaS

Your system is FISMA-in-scope. You categorize under FIPS 199, select the 800-53 baseline, and run an agency ATO. You inherit the IaaS controls from the FedRAMP package. You are responsible for everything you added on top — application code, data model, RAG stores, prompt handling.

Case 3: You are a contractor operating a system on the agency's behalf

The agency's FISMA obligation runs to the system you operate. If the system lives in a cloud, the cloud is FedRAMP. If you host it yourself, the contract clause in DFARS or FAR flows 800-171 or 800-53 down to you, and the agency runs ATO against your implementation.

The reporting layer

FISMA requires annual agency reporting to OMB and DHS CISA. The reporting covers system inventory, risk posture, significant incidents, and plans for remediation. FedRAMP continuous monitoring feeds the cloud-service portion of that reporting. Agency-level FISMA reporting is broader: it also covers on-prem systems, user-behavior analytics, phishing metrics, and more. A FedRAMP authorization is a necessary-but-not-sufficient input to an agency's FISMA posture.

What this means for small AI firms

If you are a small AI firm delivering a SaaS to federal customers, plan for FedRAMP. The path is long and expensive (see our ATO timeline post), but it is the only door for cross-agency SaaS.

If you are delivering a prototype that will run inside an agency's already-authorized environment (SBIR Phase I or II, for example), you are typically operating under the sponsoring agency's ATO and your FedRAMP work is not yet relevant. Ask the contracting officer where the authorization boundary sits before you architect. This question saves weeks of re-work.

Bottom line

FISMA is the law that obligates agencies to authorize their systems. FedRAMP is the program that standardizes cloud-service authorization so agencies do not each do their own. They share the NIST 800-53 catalog. An agency ATO for a system built on a FedRAMP-authorized service inherits the cloud-layer controls and adds the application-layer ones. If you are selling SaaS to federal, you need FedRAMP. If you are operating inside an agency boundary, you are under FISMA via the agency's ATO.

Frequently asked questions