Compliance & frameworks
FedRAMP
FedRAMP
FedRAMP — the Federal Risk and Authorization Management Program — standardizes how cloud products are security-assessed, authorized, and continuously monitored before US federal agencies are allowed to use them. It is built on the NIST SP 800-53 control baselines (Low, Moderate, and High), assessed by an accredited third-party assessment organization (3PAO), and authorized by a federal agency that accepts the residual risk. For a cloud service provider it is the price of entry to the federal market — and one of the most demanding evidence bars in commercial compliance, because an agency is putting its own authorization on the line to use you.
Who it applies to
FedRAMP applies to cloud products and services — SaaS, PaaS, or IaaS — that a US federal agency uses to store, process, or transmit federal data. The FedRAMP Authorization Act, enacted as part of the FY2023 defense authorization, made that requirement statutory and pushed agencies toward reusing existing authorizations rather than starting over. In practice the pressure arrives one of two ways: a federal agency wants to buy your product and needs it authorized at the impact level the data demands, or a prime contractor or systems integrator needs an already-authorized service to sit inside their own boundary. Moderate and High workloads frequently run in government-community regions such as AWS GovCloud (US) or Azure Government, though commercial regions of all three major providers also carry their own FedRAMP authorizations.
Cloud control themes
What FedRAMP asks of your cloud
- Access control & identification (AC, IA) — least privilege, disciplined account management, and phishing-resistant MFA for privileged and remote access
- Audit & accountability (AU) and continuous monitoring — logging depth, retention, and the recurring ConMon evidence stream authorizing agencies expect after go-live
- Configuration management (CM) — hardened baseline configurations and least functionality maintained consistently across the authorization boundary
- System & communications protection (SC) — boundary protection (SC-7) and FIPS 140-validated encryption for data in transit and at rest
- Authorization boundary & inventory — an accurate, defensible definition of exactly which cloud resources and data flows are in scope, since everything else in the package hangs off it
Domain × framework
Which assessment domains produce FedRAMP evidence
| Assessment domain | How it maps |
|---|---|
| Identity & access | IAM findings map to the Access Control (AC) and Identification & Authentication (IA) families — least privilege (AC-6), account management (AC-2), and phishing-resistant MFA (IA-2) are recurring failure points at Moderate and High. |
| Data security | Encryption and storage-exposure findings evidence the System & Communications Protection and Media Protection families — data at rest (SC-28) and in transit (SC-8/SC-13) must use FIPS 140-validated cryptography. |
| Network exposure | Segmentation and exposed-endpoint findings directly test SC-7 boundary protection — the authorization boundary is the crux of a FedRAMP package, so external connections and management-plane exposure carry outsized weight. |
| Logging & monitoring | Log coverage, retention, and detection findings map to the Audit & Accountability (AU) and System & Information Integrity (SI) families and feed the monthly continuous-monitoring deliverables. |
| Configuration & posture | Baseline-drift findings support the Configuration Management (CM) family — hardened baselines (CM-2) and least functionality (CM-7) measured against the control set for your target impact level. |
| Framework mapping | The crosswalk ties each finding to its 800-53 control and baseline (Low / Moderate / High), producing evidence that lines up with the System Security Plan and turns cleanly into POA&M items. |
What you get
A findings report framed against the NIST 800-53 baseline you are targeting — Low, Moderate, or High — with each cloud gap tied to its control family and ranked by real risk. It is organized to feed the work your 3PAO and your authorizing agency expect: a clearer authorization boundary, technical evidence that supports your System Security Plan, and a remediation order your engineers can convert directly into Plan of Action and Milestones (POA&M) entries — so you enter the formal assessment knowing where you stand rather than discovering it under a clock.
Most relevant to: FinTech, Healthcare
Questions
Do you grant an ATO or act as our 3PAO?
No. A FedRAMP authorization (ATO) is issued by a federal agency that accepts the risk, and the independent security assessment is performed by an accredited third-party assessment organization (3PAO). The health check is cloud-technical readiness — it finds and prioritizes the configuration gaps that would otherwise surface during that formal assessment, so you go in prepared.
Which impact level do you assess against?
We frame findings against the baseline you are pursuing — Low, Moderate, or High — and concentrate on the cloud-configuration controls that level demands. The higher the baseline, the more your identity, boundary, encryption, and logging evidence has to hold up under scrutiny.
Does this cover continuous monitoring?
The check itself is a point-in-time picture, but it is organized around the same control families your monthly ConMon reporting draws on. The logging, configuration, and vulnerability evidence you stand up for the assessment is the same evidence you keep producing after authorization — so the work does not go to waste once you have an ATO.
Framework work in practice
Evidence rooms and compliance tables
Mapping is for auditors and operators — shown in the spaces where evidence is reviewed.
