FedRAMP vs FISMA: How Agency Security Law and Cloud Certification Fit Together

FedRAMP and FISMA are not alternatives: FISMA sets the security obligation every federal agency carries, and FedRAMP is the standardised route for assessing cloud services so that agencies can meet that obligation when they use them. Vendors still ask which one they need, and agency teams still treat a FedRAMP listing as if it were their own authorisation to operate. This guide explains how the statute and the programme connect, who carries which duty, how NIST SP 800-53 baselines and impact levels relate to FedRAMP's 2026 Certification Classes, how agencies reuse a FedRAMP package in their own ATO, and how continuous monitoring splits between provider and agency. It is written for cloud providers selling to US federal agencies, agency security and authorisation staff, and the assessors and advisers between them.

Status as of 14 November 2026: FISMA 2014 is in force as codified at 44 U.S.C. 3551 onwards, with section 3554 last amended in December 2018 according to the code text checked. The FedRAMP Authorization Act (44 U.S.C. 3607 to 3616) and OMB Memorandum M-24-15 govern FedRAMP, and FedRAMP's Consolidated Rules for 2026 take mandatory effect on 1 January 2027, with no new Rev5 applications accepted after 11 June 2027. Dates and programme rules are changing quickly: check fedramp.gov and the official code before acting.

Key takeaways

• One is the law, the other is the cloud route under it. FISMA makes each agency head responsible for protecting agency information and systems, including those run by contractors; FedRAMP standardises the assessment of cloud services used for that purpose.
• The agency ATO never goes away. FedRAMP issues a certification of the cloud service; the agency still categorises its own system, configures the service and issues its own authorisation to operate.
• Reuse is a legal presumption. The FedRAMP Authorization Act says a FedRAMP package is presumed adequate for an agency ATO, while leaving agencies' FISMA duties and their right to demand more for a demonstrable need intact.
• Classes are not impact levels. FedRAMP's Classes A to D describe how much assurance a provider supplies; FIPS 199 impact levels describe the agency's system. Agencies must still decide both.
• Monitoring is split, not shared. The provider keeps its certification current through FedRAMP's ongoing rules; the agency monitors its own system, its configuration of the service and its own controls under its FISMA programme.

The short answer

So a vendor never chooses "FedRAMP or FISMA". It needs FedRAMP when an agency's use of its cloud service is within FedRAMP scope, and it inherits FISMA obligations through contract terms because the agency's FISMA duty extends to systems operated on its behalf. The live FISMA Guide covers the statute's obligations and reporting in depth, and the FedRAMP Guide covers classes, paths and the 2026 rules; this page focuses on how they connect.

FISMA: the statutory obligation

Threat model: FISMA addresses the risk that agency information and systems are compromised through weak governance, untested controls or unreported incidents. Section 3554(a)(1)(A) requires agency heads to provide protections commensurate with the risk and magnitude of harm, explicitly including systems "used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency".

Architecture in words: the agency head owns the duty and delegates it to the CIO, who designates a senior agency information security officer. Section 3554(b) requires an agency-wide programme with eight elements: periodic risk assessment, risk-based policies across the system life cycle, subordinate security plans, awareness training, testing of controls at least annually for every inventoried system, a remediation process, incident detection, reporting and response, and continuity plans. For a major incident, 3554(b)(7) requires notifying the relevant congressional committees within seven days of a reasonable basis to conclude one has occurred. Section 3554(c) requires an annual report on programme effectiveness, including major incidents and breaches of personal information.

How it is applied: agencies implement FISMA through NIST's Risk Management Framework (SP 800-37 Rev. 2, final December 2018), which runs from preparation and FIPS 199 categorisation through control selection from SP 800-53B, implementation, assessment, authorisation by an authorising official and continuous monitoring supporting ongoing authorisation. OMB issues policy and reporting guidance; CISA administers operational directives.

Failure modes: paper authorisations that are never revisited; contractor and cloud systems missing from the system inventory; incident reporting that misses the major incident clock; controls tested once for the ATO and never again.

Worked scenario: a civilian agency runs a grants system on its own infrastructure. No cloud service is involved, so FedRAMP does not apply, but FISMA does in full: the agency categorises the system, selects and tests controls, issues an ATO, and reports on it each year.

FedRAMP: the standardised cloud route

Threat model: FedRAMP addresses duplicated, inconsistent assessment of the same cloud services by many agencies, which wastes effort and leaves gaps. Section 3609 directs GSA to run a process supporting agency review, reuse and standardisation of cloud security assessments, including oversight of continuous monitoring.

Architecture in words: a provider earns a FedRAMP Certification for a defined cloud service offering. Under the 2026 rules there are two programme types, Rev5 (tailored SP 800-53 baselines) and 20x (Key Security Indicators with automated validation), and four Certification Classes, A to D. FedRAMP deliberately calls its result a "certification" so it is not confused with an agency ATO, which has its own meaning under OMB Circular A-130. The provider publishes a certification package and keeps it current through ongoing certification requirements. See FedRAMP 20x and FedRAMP 20x vs FedRAMP Rev 5 for choosing between the programme types.

Scope: OMB M-24-15 scopes FedRAMP to cloud products and services (IaaS, PaaS, SaaS) that create, collect, process, store or maintain federal information on behalf of an agency. It lists categories outside scope, including systems used only for one agency's operations and not offered as a shared service, social media and communications platforms used under agency policy, search engines, widely available services providing commercial information without collecting federal information, and ancillary services whose compromise poses negligible risk. FedRAMP stresses that only the agency can decide whether its use case is in scope: the same service can be in scope for one use and out for another.

Failure modes: treating the listing as covering features or regions outside the certification boundary; agencies using the commercial version instead of the certified one; providers losing certification by neglecting ongoing requirements.

Worked scenario: a SaaS case management product is wanted by three agencies. Its provider obtains one FedRAMP Certification; each agency then authorises its own use of the product, reusing the same package rather than running three separate assessments.

Where they meet: the agency ATO and the presumption of adequacy

The connection between the two is written into the FedRAMP Authorization Act. Section 3613 requires each agency head to check whether a FedRAMP authorisation already exists before starting its own, and to use existing FedRAMP assessments and materials to the extent practicable. Section 3613(e) makes the assessment in a FedRAMP package "presumed adequate" for use in an agency ATO, and then states that this presumption does not modify an agency's responsibility to comply with subchapter II of chapter 35, which is FISMA, or its authority to require more where it has a demonstrable need.

If an agency finds the package wholly or substantially deficient, section 3613(b) requires it to document why in the resulting package, and M-24-15 says it should inform the FedRAMP office. M-24-15 also ties the presumption to the certification being actively maintained through continuous monitoring, and to use at or below the authorised level.

Baselines, impact levels and Certification Classes

Both regimes rest on NIST, but they now describe different things. FISMA, through FIPS 199 and FIPS 200, requires the agency to categorise each information system and select a baseline. FedRAMP's 2026 Certification Classes describe the depth and frequency of assurance information a provider commits to supply, and FedRAMP warns that they indicate "the level of assurance provided, not the level of security".

FedRAMP's agency guidance gives a broad reading: Class A suits pilots and negligible-risk uses; Class B most low impact systems and some higher ones with compensating controls; Class C most low or moderate impact systems; Class D most systems regardless of impact level. It also says agencies should not authorise a Class A service for more than 12 months unless the provider is pursuing a higher class. The point for both sides is that a class never replaces the agency's own categorisation.

Decision guidance: who needs what

• Cloud provider selling to agencies, use in scope: you need a FedRAMP Certification at the class your customers' uses demand, plus contract terms that flow down agency FISMA requirements such as incident reporting. Start with the route analysis in the FedRAMP Guide.
• Cloud provider whose use is out of scope: for example a single-agency system not offered as a shared service. FedRAMP is not required, but the agency must still authorise the system under FISMA, often against the same SP 800-53 controls.
• Contractor operating a system for an agency, not cloud: FedRAMP does not apply; FISMA applies through the agency, which includes contractor-operated systems in its programme.
• Agency adopting a certified service: reuse the package, do the agency-side work, issue the ATO. Do not start a parallel full assessment unless you can document a demonstrable need or a deficiency.
• Agency with a unique requirement: add the extra requirement under the demonstrable need provision, record why, and expect FedRAMP to decide whether the package itself should change.
• Small provider: the class choice drives cost because higher classes commit to more frequent, more detailed assurance data. FedRAMP describes Class A as the entry point since FedRAMP Ready went legacy on 28 July 2026.

Continuous monitoring: who watches what

FISMA requires agencies to test controls at least annually and to detect, report and respond to incidents. FedRAMP now calls the provider-side obligation "ongoing certification" and reserves "continuous monitoring" for collaborative monitoring with agencies, noting that agencies must still perform continuous monitoring under Circular A-130. In practice:

• Provider side: vulnerability detection and response, significant change notification, incident communication and refreshed assessment evidence, per the FedRAMP rules for its programme type and class. Missing them can cost the certification.
• Agency side: the agency's tenant configuration, its identity integration, its logging, its users and data, and the residual risks it accepted at ATO, reviewed through its own ongoing authorisation.
• Join point: agencies consume the provider's ongoing certification data and act on it; providers need agency points of contact who will read it.

Where identity fits

The split shows clearly in identity. The provider's certification covers how it controls its own administrators, service accounts and secrets; 20x Key Security Indicators include phishing-resistant MFA and just-in-time access for user and non-user accounts. The agency's ATO covers its own side: federating its identity provider, restricting tenant administrators, and governing the API keys, service principals and integration tokens its staff and AI agents create inside the service. Those agency-created non-human identities are outside the provider's certification boundary and inside the agency's FISMA programme. See the Non-Human Identity (NHI) Guide.

Common failure patterns

• "We are FedRAMP, so the agency is covered": a certification does not authorise any agency's use; each agency still issues its own ATO.
• Agencies re-assessing from scratch: ignoring the presumption of adequacy wastes time and runs against section 3613 unless the agency documents a demonstrable need or deficiency.
• Reading Class as impact level: picking a service by class alone, without categorising the agency system, leaves gaps in agency-side controls.
• Boundary drift: staff use features, regions or integrations outside the certified boundary, or the commercial edition rather than the certified one.
• Agency-side credentials ignored: integration tokens and service accounts created by the agency inside a certified SaaS are left out of the agency's inventory. A single stolen SaaS API key can be enough to trigger the major incident clock under section 3554(b)(7).
• Monitoring nobody reads: providers deliver ongoing certification data that agency teams never review, so the presumption rests on evidence nobody checks.

Detection and measurement

• Cloud inventory coverage: percentage of cloud services in use that appear in the agency system inventory with a scope decision recorded.
• Reuse rate: share of cloud ATOs issued by reusing a FedRAMP package rather than a full independent assessment.
• Certified edition use: number of in-scope services used outside their certified edition or boundary (target zero).
• Time to ATO: median days from package review to agency ATO for certified services.
• Ongoing data review: percentage of provider ongoing certification reports reviewed by the agency within its defined window.
• Agency-side NHI coverage: percentage of agency-created API keys and service accounts in certified services that have an owner and review date.

Framework mapping

Practitioner checklist

• State in contracts and proposals that FedRAMP certification supports, but does not replace, the agency ATO.
• Record a FedRAMP scope decision for every cloud service the agency uses, made by the agency.
• Categorise the agency system under FIPS 199 before comparing Certification Classes.
• Reuse FedRAMP packages by default; document any demonstrable need or deficiency in writing.
• Confirm users are on the certified edition and within the certified boundary.
• Write the agency system security plan around agency-side controls, not a copy of the provider's package.
• Assign named agency reviewers for the provider's ongoing certification data.
• Inventory agency-created service accounts, API keys and integrations inside each certified service.
• Recheck fedramp.gov dates before each milestone while the 2026 rules bed in.

Standards and references

• Cornell LII: 44 U.S.C. 3554, Federal agency responsibilities
• Cornell LII: 44 U.S.C. 3552, Definitions
• FedRAMP: Consolidated Rules for 2026 and FedRAMP Authorization Act text (official repository)
• FedRAMP: fedramp.gov
• NIST: SP 800-37 Rev. 2, Risk Management Framework
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• OMB: Memoranda index

Related NHI Mgmt Group resources: FISMA Guide · FedRAMP Guide · FedRAMP 20x · FedRAMP 20x vs FedRAMP Rev 5. This guide summarises FISMA and the FedRAMP programme and is not legal advice.