FedRAMP

Introduction: FedRAMP in the Cloud Security Assurance Landscape

The Federal Risk and Authorization Management Program (FedRAMP) is the United States government-wide programme that provides a standardised approach to security assessment, authorisation, and continuous monitoring for cloud products and services used by federal agencies. Established formally in 2011 through an Office of Management and Budget (OMB) memorandum and codified in law by the FedRAMP Authorization Act (part of the National Defense Authorization Act for Fiscal Year 2023), FedRAMP embodies a 'do once, use many times' philosophy. Its intent is to reduce duplicative effort, drive consistent security, and accelerate the adoption of secure commercial cloud by federal departments and agencies.

For any Cloud Service Provider (CSP) that wishes to sell Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), or Infrastructure-as-a-Service (IaaS) to the US federal market, a FedRAMP authorisation is effectively a market-entry requirement. For federal agencies, FedRAMP is mandatory whenever they procure or operate a cloud service that processes, stores, or transmits federal information. This guide provides an auditor-grade, end-to-end treatment of FedRAMP: what it is, who must comply, its control structure derived from NIST Special Publication 800-53, a master assessment checklist covering every control family, the phased path to authorisation, the continuous monitoring model, and how FedRAMP maps to adjacent frameworks such as ISO/IEC 27001, SOC 2, StateRAMP, and NIST 800-171.

What is FedRAMP

FedRAMP is a compliance and authorisation programme, not a standalone control catalogue. It layers a federal governance and process wrapper on top of the NIST Risk Management Framework (RMF) and the NIST SP 800-53 control catalogue. In practice, FedRAMP takes the FIPS 199 impact levels (Low, Moderate, High), selects a tailored baseline of NIST 800-53 controls for each level, adds FedRAMP-specific parameters and additional controls, and defines the process by which a CSP is assessed by an independent Third Party Assessment Organisation (3PAO) and then authorised.

There are two principal authorisation paths. The first is the Agency Authorisation path (formerly called Agency ATO), where a specific federal agency reviews the CSP's security package and its Authorising Official (AO) issues an Authority to Operate (ATO), which other agencies may then reuse. The second is the JAB path historically operated by the Joint Authorization Board; under the FedRAMP Authorization Act the JAB has been superseded by a FedRAMP Board, and the programme has moved toward a single authorisation model with agency sponsorship. FedRAMP also defines a lighter-weight FedRAMP Tailored baseline (often called Li-SaaS, Low-impact SaaS) for low-risk, low-impact SaaS applications.

The deliverable at the heart of every FedRAMP engagement is the Security Assessment Package: principally the System Security Plan (SSP) with its attachments, the Security Assessment Plan (SAP), the Security Assessment Report (SAR) produced by the 3PAO, and the Plan of Action and Milestones (POA&M). After authorisation, the CSP must maintain the authorisation through Continuous Monitoring (ConMon), submitting monthly deliverables and undergoing an annual assessment.

Key FedRAMP Terminology

Who Must Comply with FedRAMP

FedRAMP applies to cloud services in the federal ecosystem. Compliance obligations fall on different parties depending on their role. The following table clarifies who is in scope and why.

• Trigger for applicability: the cloud service handles federal information (any data an agency creates, collects, processes, stores, or transmits).
• Impact level drives the baseline: FIPS 199 categorisation of confidentiality, integrity, and availability determines Low, Moderate, or High.
• Most SaaS applications targeting federal buyers pursue the Moderate baseline, as it covers the majority of Controlled Unclassified Information (CUI) use cases.
• High baseline is required for law enforcement, emergency services, financial, and health data where a breach could have severe or catastrophic impact.

Structure of FedRAMP: Impact Levels, Control Families, and Baselines

FedRAMP inherits the structure of NIST SP 800-53. Controls are organised into control families (each identified by a two-letter code such as AC for Access Control). FedRAMP defines security control baselines — pre-selected and parameterised sets of controls — for each FIPS 199 impact level. The number of controls grows with impact level. The FedRAMP baselines are periodically re-baselined as NIST revises SP 800-53 (the current baselines are aligned to NIST SP 800-53 Revision 5).

FedRAMP Impact Levels and Baseline Sizes

The NIST SP 800-53 Control Families Adopted by FedRAMP

FedRAMP baselines draw from the twenty control families below. Rev 5 introduced Supply Chain Risk Management (SR) and PII Processing and Transparency (PT). Not every family is fully populated at every impact level, but all are represented at Moderate and High.

Master Assessment Checklist: Every Control Family

This is the operational core of the guide. For each NIST 800-53 control family adopted by FedRAMP, the tables below enumerate what an assessor (3PAO) verifies and the typical evidence a CSP must produce. Findings feed the Security Assessment Report and any residual weaknesses feed the POA&M. Control identifiers (e.g., AC-2) reference the NIST catalogue as implemented by the FedRAMP baseline; parameter values (frequencies, thresholds) are set by FedRAMP-specific assignments.

AC — Access Control

AT — Awareness and Training

AU — Audit and Accountability

CA — Assessment, Authorisation, and Monitoring

CM — Configuration Management

CP — Contingency Planning

IA — Identification and Authentication

IR — Incident Response

MA — Maintenance

MP — Media Protection

PE — Physical and Environmental Protection

PL — Planning

PS — Personnel Security

PT — PII Processing and Transparency

RA — Risk Assessment

SA — System and Services Acquisition

SC — System and Communications Protection

SI — System and Information Integrity

SR — Supply Chain Risk Management

PM — Program Management (Organisation-Level)

Scoping the Authorisation Boundary

Correct scoping is the single most consequential decision in a FedRAMP engagement. The authorisation boundary defines everything that is assessed and authorised: the applications, infrastructure, data stores, supporting services, external connections, and the human and physical elements that process federal data. An overly broad boundary inflates cost and control burden; an overly narrow boundary risks a rejected package or an under-protected system.

• Define the Cloud Service Offering precisely: which application, tiers, and functionality are being authorised.
• Establish the FIPS 199 impact level first — it dictates the baseline and therefore the entire scope of controls.
• Draw the authorisation boundary diagram showing all components, data flows, and every crossing of the boundary (ingress/egress).
• Identify leveraged authorisations: the underlying IaaS/PaaS must itself be FedRAMP-authorised so the CSP can inherit those controls.
• Document the shared responsibility model — which controls the CSP implements, which are inherited from the platform, which are customer responsibility, and which are hybrid.
• Include all external services and interconnections (email, identity, monitoring, ticketing) and confirm each is authorised, in-scope, or covered by a signed agreement.
• Explicitly list what is out of scope and justify exclusions; corporate/back-office systems must be excluded through segmentation, not by assertion.
• Account for the full data lifecycle within the boundary: collection, processing, storage, transmission, backup, and disposal of federal data.

Implementation Approach: Phased Roadmap to Authorisation

A realistic FedRAMP journey for a Moderate SaaS typically spans nine to eighteen months. The following phased approach sequences the work so that expensive assessment activity is not wasted on an immature control environment.

Phase 1 — Readiness and Gap Assessment

• Activities: secure federal agency sponsorship or plan the agency-authorisation path; perform FIPS 199 categorisation; conduct a gap assessment against the target baseline; optionally complete a FedRAMP Readiness Assessment Report (RAR) with a 3PAO.
• Deliverables: impact-level determination, gap analysis report, remediation roadmap, RAR (for Marketplace 'In Process — Ready' designation).

Phase 2 — Boundary Definition and Architecture

• Activities: finalise the authorisation boundary and data flow diagrams; select a FedRAMP-authorised underlying platform; design segmentation, encryption (FIPS 140-validated), and identity architecture; define the shared responsibility matrix.
• Deliverables: authorisation boundary diagram, network and data flow diagrams, shared responsibility matrix, architecture decision records.

Phase 3 — Control Implementation and Documentation

• Activities: implement or configure every applicable control; harden systems to CIS/DISA STIG benchmarks; stand up logging, vulnerability scanning, and continuous monitoring tooling; author the SSP with per-control implementation statements and all attachments (policies, IR plan, contingency plan, configuration management plan, incident response plan, rules of behaviour, PIA).
• Deliverables: complete System Security Plan and all attachments, policies and procedures for every control family, evidence repository.

Phase 4 — Independent Assessment (3PAO)

• Activities: engage an accredited 3PAO; the 3PAO produces a Security Assessment Plan; conduct control testing, vulnerability scanning validation, and penetration testing across the six required attack vectors; produce the Security Assessment Report.
• Deliverables: Security Assessment Plan, penetration test report, Security Assessment Report, initial POA&M from findings.

Phase 5 — Authorisation Decision

• Activities: assemble the full Security Assessment Package; the sponsoring agency's Authorising Official reviews the SSP, SAR, and POA&M and evaluates residual risk; remediate blocking findings; obtain the ATO and request Marketplace listing.
• Deliverables: complete security authorisation package, signed ATO letter, FedRAMP Marketplace 'Authorised' designation.

Phase 6 — Continuous Monitoring and Sustainment

• Activities: submit monthly ConMon deliverables (updated POA&M, vulnerability scan results, inventory); operate change control and significant-change requests; conduct the annual assessment; remediate vulnerabilities within FedRAMP timelines.
• Deliverables: monthly ConMon packages, annual assessment report, deviation requests, updated SSP reflecting significant changes.

Continuous Monitoring Maturity / Capability Model

FedRAMP does not define a formal five-level maturity model in the way CMMC does; however, the continuous monitoring programme establishes an escalating expectation of capability. The following model expresses practical capability levels a CSP progresses through, useful for internal readiness scoring.

Assessment and Audit Approach

The FedRAMP assessment is executed by an independent 3PAO following NIST SP 800-53A assessment procedures and FedRAMP-specific test cases. The steps below describe the end-to-end assessment lifecycle.

1. Categorise the system using FIPS 199 to confirm the impact level and applicable baseline.
2. Confirm 3PAO independence and accreditation (A2LA against ISO/IEC 17020 and FedRAMP requirements).
3. Review the System Security Plan and all attachments for completeness and accuracy against the boundary.
4. Develop the Security Assessment Plan defining scope, test cases, sampling, and the assessment schedule.
5. Perform control testing using examine, interview, and test methods for each in-scope control.
6. Conduct authenticated vulnerability scanning of operating systems, web applications, and databases; validate results.
7. Perform penetration testing across the six mandatory attack vectors (external, internal, web application, network, social engineering, and mobile/API as applicable).
8. Document findings, risk-rate each weakness, and record false positives, operational requirements, and risk adjustments.
9. Produce the Security Assessment Report with the Risk Exposure Table and recommendations.
10. Populate the initial POA&M with all open weaknesses, remediation plans, and milestones.
11. Submit the complete package to the Authorising Official for the authorisation decision.
12. Transition into continuous monitoring: monthly deliverables, annual assessment, and significant-change reviews.

Evidence Request List

The following categorised list represents the evidence a 3PAO and Authorising Official expect. Maintaining this in a living evidence repository dramatically reduces assessment friction.

• Governance and documentation: System Security Plan, all attachments, policies and procedures for every control family, rules of behaviour, Privacy Impact Assessment.
• Boundary and architecture: authorisation boundary diagram, network diagram, data flow diagrams, shared responsibility matrix, leveraged authorisation documentation.
• Access control: account inventory, privileged account list, RBAC/permission matrices, account review records, MFA configuration.
• Logging and monitoring: audit event definitions, sample logs, SIEM rules, log retention configuration, monitoring/IDS architecture.
• Vulnerability and patch: monthly authenticated scan reports (OS/web/DB), remediation tracking, patch deployment logs, penetration test report.
• Configuration management: hardening baselines, benchmark scan results, change tickets, CAB records, component inventory/CMDB.
• Contingency and resilience: contingency plan, backup logs, restoration test results, DR exercise reports, RTO/RPO documentation.
• Incident response: IR plan, incident register, US-CERT/CISA reporting procedure, tabletop exercise results.
• Personnel and training: screening records (redacted), onboarding/offboarding logs, signed access agreements, training completion reports.
• Cryptography and data protection: FIPS 140-validation certificates, TLS/cipher configuration, encryption-at-rest and key management evidence.
• Supply chain and third parties: SCRM plan, vendor risk assessments, interconnection agreements, external service SLAs.
• Continuous monitoring: ConMon plan, monthly deliverable submissions, POA&M history, deviation requests, significant-change request records.

Roles and Responsibilities

KPIs to Track

• Percentage of applicable controls fully implemented versus planned/partial.
• Number of open POA&M items by severity (High/Moderate/Low) and ageing beyond remediation timelines.
• Mean time to remediate vulnerabilities against FedRAMP SLAs (High 30 / Moderate 90 / Low 180 days).
• On-time submission rate for monthly continuous monitoring deliverables.
• Vulnerability scan coverage — percentage of in-scope assets scanned (authenticated) each cycle.
• Percentage of assets deviating from the approved hardening baseline (configuration drift).
• Incident detection and response metrics: mean time to detect and mean time to respond; reporting within required timeframes.
• Privileged access review completion rate and count of stale/orphaned accounts.
• Change management: percentage of changes following approved change control; significant-change requests submitted on time.
• Annual assessment findings trend versus prior year (net-new versus recurring weaknesses).

Readiness Checklist

• FIPS 199 categorisation completed and impact level (Low/Moderate/High) confirmed.
• Agency sponsorship secured or agency-authorisation path defined.
• Authorisation boundary and data flow diagrams finalised and validated.
• Underlying platform confirmed FedRAMP-authorised and leveraged controls documented.
• Shared responsibility matrix completed for all applicable controls.
• System Security Plan and every attachment drafted with per-control implementation statements.
• Policies and procedures exist for all in-scope control families.
• FIPS 140-validated cryptography in use for data in transit and at rest.
• Multi-factor authentication enforced for all privileged and non-privileged access.
• Authenticated vulnerability scanning operational for OS, web, and database.
• Centralised logging, SIEM monitoring, and required log retention configured.
• Contingency plan and backups tested with documented restoration.
• Incident response plan tested and US-CERT/CISA reporting procedure defined.
• Accredited 3PAO engaged and Security Assessment Plan agreed.
• POA&M process and continuous monitoring tooling stood up ahead of authorisation.

Common Gaps

• Authorisation boundary omits supporting services (logging, secrets, CI/CD, bastion) that can access federal data.
• Use of non-FIPS 140-validated cryptographic modules for encryption in transit or at rest.
• Incomplete or inconsistent SSP control implementation statements that do not match the actual configuration.
• Vulnerability remediation exceeding FedRAMP timelines with weak POA&M justification.
• Authenticated scanning gaps — unauthenticated scans or assets excluded from scan scope.
• Weak least-privilege enforcement and stale privileged accounts.
• Inherited controls asserted without evidence or a signed shared responsibility matrix.
• Continuous monitoring deliverables submitted late or incomplete after authorisation.
• Significant changes deployed without a significant-change request or re-assessment.
• Inadequate penetration testing that does not cover all six required attack vectors.
• Contingency and incident response plans documented but never exercised.
• Supply chain risk management (SR family) treated superficially with no supplier assessments.

FedRAMP Mapped to Other Frameworks

Frequently asked questions

Need help with FedRAMP?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.