Skip to content

Security & Compliance Frameworks

What this section covers

A plain-language explanation of each major government and industry security framework — what it is, who it applies to, how it’s structured, and how the frameworks relate to one another. Plus a decision guide: which framework you actually need, based on the data you hold and who you sell to.

Who it’s for

Engineering leads, founders, and program staff deciding how to make a platform compliant — and what “compliant” even means for their data. No prior compliance background assumed; jargon is explained on first use.

Disclaimer. Not legal or compliance advice. Frameworks, control counts, and timelines change. Every figure here is dated and cited; verify against the authoritative source before relying on it. When stakes are high, engage a qualified assessor (3PAO / C3PAO / QSA / ISO auditor).

Figures verified 2026-05-29.


The one-sentence version

Build to FedRAMP High / NIST 800-53, and almost everything else becomes a mapping exercise. FedRAMP High is built on the most rigorous NIST control baseline; SOC 2, ISO 27001, StateRAMP, and CMMC Level 2 are largely subsets you can satisfy with the same controls and evidence. That’s why this platform’s security FRD targets FedRAMP and treats every control as an à-la-carte module.

This is a deliberate strategy, not a claim that FedRAMP is literally “required” everywhere. See Choosing your framework below for the honest nuance — purely commercial buyers usually ask for SOC 2 or ISO 27001, not FedRAMP.


The frameworks at a glance

FrameworkWho requires itWhat it protectsBuilt onThis doc
FedRAMPUS federal agencies buying cloud servicesFederal data in cloud (SaaS/IaaS/PaaS)NIST 800-53 Rev 5FedRAMP
FISMAUS federal agencies & their systemsAll federal information systemsNIST 800-53 / RMFFISMA
NIST SP 800-53(the control catalog itself)Confidentiality, integrity, availabilityNIST 800-53
NIST SP 800-63(the identity standard itself)Identity proofing, authentication, federationNIST 800-63 (IAL/AAL/FAL)
NIST 800-171 / CMMCDoD contractors handling CUIControlled Unclassified InformationNIST 800-171 / -172NIST 800-171 & CMMC
DoD Impact Levels / StateRAMPDoD (IL2–6) / US state & local govtsDefense / state-government cloud dataFedRAMP + extrasStateRAMP & DoD ILs
ISO/IEC 27001Commercial & international buyersInformation Security Mgmt System (ISMS)ISO 27001
SOC 2Commercial B2B / SaaS buyersTrust over a service org’s controlsAICPA TSCSOC 2
HIPAAAnyone handling US health data (PHI)Protected Health InformationHIPAA
PCI DSSAnyone storing/processing card dataCardholder dataPCI DSS

Choosing your framework (by data and buyer)

The framework you need is driven by two questions: what data do you hold, and who buys from you? Walk the table top to bottom — the first row that matches your situation usually governs.

If you handle……and sell to…You almost certainly needNotes
Classified national-security dataDefense/IC(Beyond this guide — air-gapped, IL6+)Out of scope here.
Controlled Unclassified Information (CUI)DoD / defense supply chainCMMC Level 2 (= NIST 800-171)Self-assessment or C3PAO assessment by contract phase.
Federal agency data, in the cloudUS federal agenciesFedRAMP (Low / Moderate / High)Impact level set by FIPS 199 categorization of the data.
Federal agency data, on-prem / non-cloudUS federal agenciesFISMA (NIST RMF + 800-53)FedRAMP is the cloud-specific flavor of FISMA.
US state / local government dataState & local agenciesStateRAMP / GovRAMPThe state-level analog of FedRAMP; reuses FedRAMP work.
Protected Health Information (PHI)Healthcare / payersHIPAA (+ usually SOC 2/HITRUST)Sign a BAA; HIPAA is law, not a certification.
Payment card data (PAN)Anyone taking cardsPCI DSSBest avoided by never touching PAN — use a tokenizing gateway.
General customer/business dataCommercial enterprises (US)SOC 2 Type IIThe default ask in US B2B SaaS sales.
General customer/business dataInternational / EU enterprisesISO/IEC 27001The global standard; often paired with SOC 2.
EU residents’ personal dataAnyone in the EU marketGDPR (regulation, not a cert)Layer on top of your security framework.

How they nest

Most of these frameworks share DNA. Roughly, from broadest controls to narrowest:

NIST 800-53 (full control catalog)
└─ FedRAMP High (410 controls) ← strictest cloud baseline
└─ FedRAMP Moderate (323)
└─ FedRAMP Low / Li-SaaS (156)
≈ maps down to ISO 27001, SOC 2, StateRAMP, CMMC L2

If you implement and evidence a FedRAMP Moderate/High control set, a SOC 2 or ISO 27001 audit is largely re-using the same controls with different paperwork. That is the whole reason the platform builds to FedRAMP first and maps down — do the hard one once.

The honest caveat: FedRAMP authorization itself is only meaningful for selling cloud services to US federal agencies (it requires an agency sponsor). A purely commercial company cannot “get FedRAMP” without a federal customer, and commercial buyers won’t ask for it — they ask for SOC 2 / ISO 27001. So: build to the FedRAMP control baseline from day one (cheap insurance, maps everywhere), but certify against whatever your actual buyers require.


How this maps to building software

The frameworks above are what to comply with. For how to implement the controls in a real platform — identity (IAL/AAL/FAL), encryption (FIPS 140-3), audit logging, continuous monitoring, boundary protection, and the rest — as independently-deployable modules, see:


  • Security Guidance (app-level) — XSS, CSP, sanitization, log redaction (guide pending)
  • Procurement — Overview — buying compliant tools (FedRAMP/StateRAMP as a procurement gate)
  • STANDARDS.md

Sources (verified 2026-05-29)

ClaimSource
FedRAMP is built on NIST 800-53 Rev 5; baseline structurefedramp.gov
NIST control catalogNIST SP 800-53 Rev 5
Digital identity (IAL/AAL/FAL)NIST SP 800-63-4
CMMC = NIST 800-171DoD CMMC
SOC 2 Trust Services CriteriaAICPA
ISO/IEC 27001:2022ISO