Compliance as Code
Compliance as code for FedRAMP 20x means expressing security expectations as machine-checkable Key Security Indicators, storing intended state in version control, and collecting dated evidence from pipelines and live systems — instead of treating a Word SSP as the only proof.
Educational resource only. scm.cc is not a FedRAMP Recognized Independent Assessor (3PAO) and is not FedRAMP-authorized; it grants no authorization, certification, or assessment outcome. FedRAMP.gov is the authoritative source. This is not legal advice.
Technical detail
CR26 does not define a KSI family named 'compliance as code'. The idea is how several families are demonstrated: KSI-CMT (log changes, redeploy from version control, review procedures, automate validation), KSI-MLA-EVC (persistent configuration evaluation), and KSI-SVC-ACM (automated configuration management). The Security Decision Record and Collaborative Continuous Monitoring expect machine-readable, ongoing evidence. Implementation guides (AWS, Azure, GCP, Terraform, Kubernetes, GitHub, GitLab, CI/CD) are maps when they ship; they are not official FedRAMP methods.
How to implement
Start with KSI-CMT and the indicator pages for RMV, VTD, and RVP. Wire CI so every production change is a tagged deploy with tests. Point config-drift collectors at intended state. Use the hub implementation cluster for cloud and IaC notes. Do not invent extra CMT ruleset types. Do not dual-map one pipeline log onto two indicators.
Common mistakes
- Calling a policy PDF 'compliance as code' with no pipeline or intended-state source. - Treating scm.cc as FedRAMP-authorized because it talks about automation. - Stacking extra GitHub org ruleset types onto KSI-CMT-RMV, KSI-CMT-VTD, or KSI-CMT-RVP. - Dual-mapping one CI log onto two KSI indicators.
Automated validation methods (catalog)
- Redeploy from version control (KSI-CMT-RMV)
Change is applied by shipping a versioned artifact, not by editing a live host. Quote the catalog statement on the indicator page.
- Automated validation through deployment (KSI-CMT-VTD)
Tests and policy checks run in the pipeline that produces the artifact. Do not stack extra GitHub ruleset types onto CMT-* for product verification.
- Review of change procedures (KSI-CMT-RVP)
Change procedures exist and are reviewed. Automation does not replace the dated review fact.
- Persistent evaluation of machine configuration (KSI-MLA-EVC)
Intended configuration is compared continuously, not only at a point-in-time scan.
- Automated configuration management (KSI-SVC-ACM)
Service configuration is managed as code or equivalent automation. Class C markers stay catalog facts, not product verification.
Questions teams ask
- Is 'compliance as code' an official FedRAMP 20x KSI family?
- No. It is how several CR26 indicators are demonstrated — especially KSI-CMT, KSI-MLA-EVC, and KSI-SVC-ACM. Quote the catalog; do not invent a KSI-CAC id.
- Does using Terraform or GitHub Actions make a system FedRAMP certified?
- No. Tools produce evidence. Certification is a FedRAMP decision. scm.cc is not an assessor and is not FedRAMP-authorized.
Related hub pages
- ksi/ksi cmt
- ksi/ksi mla
- ksi/ksi svc
- ksi/ksi cmt rmv
- ksi/ksi cmt vtd
- ksi/ksi cmt rvp
- ksi/ksi mla evc
- ksi/ksi svc acm
- ksi
- configuration management
- evidence
- continuous monitoring
- implementation
- implementation/aws
- implementation/azure
- implementation/gcp
- implementation/terraform
- implementation/kubernetes
- implementation/infrastructure as code
- implementation/github
- implementation/gitlab
- implementation/ci cd
- fundamentals
Primary sources
- FedRAMP 20x Key Security Indicators (CR26) (retrieved 2026-09-27)
- FedRAMP 20x overview & Core Principles (retrieved 2026-09-27)
- Collaborative Continuous Monitoring (CCM / Ongoing Certification Report) (retrieved 2026-09-27)
Last verified 2026-09-27. FedRAMP.gov is authoritative.