FedRAMP
U.S. General Services Administration · Version Rev 5 Baselines · 2012; NIST 800-53 Rev 5 baselines effective 2023
The US federal authorization program for cloud services used by government agencies.
Overview
The Federal Risk and Authorization Management Program provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by U.S. federal agencies. Any cloud service provider seeking to sell to federal agencies must achieve a FedRAMP Authorization to Operate. The program uses NIST Special Publication 800-53 Revision 5 as its control baseline, with additional FedRAMP-specific parameters and requirements layered on top. Three impact levels exist: Low, Moderate, and High, determined by the sensitivity of the federal data the cloud service will process.
Authorization can be granted through two paths: an Agency Authorization, where a single federal agency sponsors and grants the ATO, or the FedRAMP Board process, formerly the Joint Authorization Board, for cloud services used by multiple agencies. Both paths require assessment by an accredited Third Party Assessment Organization. A3LA ISO/IEC 17020-accredited 3PAOs conduct the assessment against the applicable baseline and produce a Security Assessment Report. The System Security Plan is the primary documentation artifact, typically running hundreds of pages across all required control implementation descriptions. FedRAMP 20x is a modernization initiative launched in 2024 to streamline the authorization process through automation and machine-readable security documentation.
Who Needs This
Cloud service providers seeking to sell IaaS, PaaS, or SaaS solutions to U.S. federal agencies
SaaS companies with existing federal agency customers who need to formalize their authorization
Cloud providers whose services are referenced in federal agency existing authorizations
Technology companies building on FedRAMP-authorized platforms who want to reduce their authorization scope through inheritance
Organizations responding to federal RFPs that specify FedRAMP Moderate or High as a requirement
Structure at a Glance
For cloud services where the loss of confidentiality, integrity, or availability would have a limited adverse effect on agency operations. Approximately 125 controls.
The most common authorization level. For services where a breach would have a serious adverse effect. Approximately 325 controls. Required for most federal agency use cases.
For cloud services processing the most sensitive unclassified federal data, including law enforcement, emergency services, and financial systems. Approximately 421 controls.
A tailored Low baseline for low-impact SaaS services. Approximately 36 controls. Introduced to reduce barriers for commodity SaaS adoption.
AI Prompt Recipes
Copy these prompts directly into Claude or any capable model. Replace the bracketed placeholders with your organization-specific details.
Control Implementation Description
Use this to write SSP implementation descriptions for individual controls.
You are a FedRAMP Moderate SSP author. Write a control implementation description for NIST 800-53 Rev 5 control [CONTROL ID] — [CONTROL NAME]. My system is a [DESCRIBE SYSTEM: IaaS/PaaS/SaaS, technology stack, data types]. The implementation: [DESCRIBE HOW THIS CONTROL IS IMPLEMENTED]. Required format: present tense, active voice, specific to our environment, referencing actual tools and processes by name. Include: what the control does, who is responsible, how often it runs or is reviewed, and what evidence artifact demonstrates it is operating. Note any FedRAMP-specific parameter values that apply to this control.
Customer Responsibility Matrix
Use this to define which controls are inherited, shared, or customer-owned in a SaaS product.
I am building a FedRAMP Customer Responsibility Matrix for our [IaaS/PaaS/SaaS] service. Our infrastructure runs on [UNDERLYING AUTHORIZED PLATFORM, e.g., AWS GovCloud]. For the following control family: [CONTROL FAMILY, e.g., Access Control], analyze each control and assign: Provider responsibility (our system implements fully), Customer responsibility (customer agency must implement), or Shared responsibility (both parties contribute). For shared controls, specify exactly what the provider implements and what the customer must implement. Use FedRAMP CRM template language.
Continuous Monitoring Plan
Use this to draft a ConMon strategy that satisfies FedRAMP monthly reporting requirements.
Draft a FedRAMP continuous monitoring strategy for our [IMPACT LEVEL] authorized system. System description: [BRIEF DESCRIPTION]. Current monitoring tools: [LIST TOOLS]. Draft: (1) a monthly vulnerability scanning schedule compliant with FedRAMP ConMon requirements, (2) a Plan of Action and Milestones (POA&M) management process including SLA timelines for each vulnerability severity, (3) a monthly reporting package outline covering the six required ConMon deliverables, and (4) a process for significant change requests that require re-assessment under FedRAMP.
Boundary Definition
Use this to define and document the system authorization boundary for the SSP.
I need to define the authorization boundary for a FedRAMP [IMPACT LEVEL] System Security Plan. My system: [DESCRIBE SYSTEM COMPONENTS, INFRASTRUCTURE, AND SERVICES]. External services used: [LIST EXTERNAL SERVICES AND APIS]. Agency-provided components: [DESCRIBE IF ANY]. Help me: (1) identify all components that must be included within the authorization boundary, (2) determine which external services qualify as FedRAMP-interconnected external services versus outside the boundary, (3) draft the authorization boundary description for the SSP, and (4) identify what interconnection security agreements or data flow diagrams are needed.
Common Pitfalls
These are the mistakes practitioners see repeatedly in real assessments and implementation projects.
Underestimating SSP scope. A FedRAMP Moderate SSP requires implementation descriptions for approximately 325 controls. Organizations that begin writing without a full system inventory often discover undocumented components during 3PAO review that expand scope significantly.
Control inheritance overclaimed. Just because your infrastructure runs on an authorized platform does not mean all controls are inherited. Each control must be analyzed for what the platform provides versus what you must implement. 3PAOs verify every inheritance claim.
ConMon treated as a deliverable rather than an operational program. FedRAMP requires monthly submission of vulnerability scan results, updated POA&Ms, and change summaries. Agencies revoke ATOs for missed ConMon deliverables.
Significant change process bypassed. Any change to the authorization boundary, architecture, or security posture requires a formal Significant Change Request reviewed by the authorizing agency. Unauthorized changes are a major finding during annual assessments.
Ignoring FedRAMP 20x developments. The GSA began piloting the 20x modernization program in 2024. Cloud providers pursuing new authorizations should monitor 20x guidance because assessment methodologies and documentation formats are expected to change.
Cross-Framework Mapping
NIST CSF 2.0
FedRAMP uses NIST 800-53 as its control baseline, which maps directly to NIST CSF 2.0 subcategories. Organizations with CSF 2.0 programs have a structural head start.
CMMC
Both programs require 3PAO or C3PAO assessments against NIST baselines. FedRAMP uses NIST 800-53, CMMC Level 2 uses NIST 800-171. Organizations serving DoD and civilian agencies often pursue both.
ISO 27001
FedRAMP control descriptions can be mapped to ISO 27001 Annex A. Organizations dual-pursuing ISO 27001 and FedRAMP often consolidate evidence collection for overlapping controls.
All content sourced from official issuing body documentation.
Official source ↗