Key Security Indicators (KSIs) are the core of FedRAMP 20x. They are what replace the hundreds of NIST SP 800-53 control narratives that defined the old Rev5 authorization process, and they're what every Cloud Service Provider (CSP) pursuing a federal authorization in 2026 needs to understand deeply.
This guide breaks down what KSIs are, the 11 themes they're organized into, the 3 cross-cutting provider-responsibility rules that sit above them, and how evidence requirements differ between 20x Low and 20x Moderate.
New to FedRAMP 20x? Start with What Is FedRAMP 20x? The 2026 Guide for the program overview, timeline, and differences from Rev5.
What Is a Key Security Indicator (KSI)?
A Key Security Indicator is a short, outcome-oriented statement of a security capability a cloud service offering must achieve. Where Rev5 asked "do you have an access control policy that addresses purpose, scope, roles, and responsibilities?", a KSI asks whether your system actually enforces phishing-resistant MFA — and expects you to prove it through automated, continuously validated evidence.
Three things define the KSI approach:
Outcomes over process
A KSI measures whether security works, not whether a policy document exists describing how it should work.
Automated over manual
KSIs are designed to be validated by machine. The official FedRAMP documentation is published in machine-readable JSON, and evidence is expected to be machine-readable too.
Continuous over point-in-time
Where Rev5 relied on annual assessments and screenshots, KSIs are designed to be validated persistently — ideally on the same cadence your own security tooling runs.
The underlying NIST SP 800-53 controls are still present — each KSI lists its "related" controls as a mapping layer — but they are no longer the primary thing being assessed. The KSI is.
How Many KSIs Are There?
The official FedRAMP machine-readable documentation (FRMR_documentation.json) defines 60 KSIs organized into 11 themes, plus 3 cross-cutting "provider responsibility" rules (the CSX group) that govern how CSPs engage with the KSI framework itself.
If you've seen third-party articles quoting "56" or "61" — those are counting errors that treat the CSX rules inconsistently or reference older Phase 1 drafts. The primary source is 60 KSIs plus 3 CSX rules.
| Theme | Code | KSI Count |
|---|---|---|
| Authorization by FedRAMP | KSI-AFR | 10 |
| Change Management | KSI-CMT | 4 |
| Cloud Native Architecture | KSI-CNA | 8 |
| Cybersecurity Education | KSI-CED | 4 |
| Identity and Access Management | KSI-IAM | 7 |
| Incident Response | KSI-INR | 3 |
| Monitoring, Logging, and Auditing | KSI-MLA | 5 |
| Policy and Inventory | KSI-PIY | 5 |
| Recovery Planning | KSI-RPL | 4 |
| Service Configuration | KSI-SVC | 8 |
| Supply Chain Risk | KSI-SCR | 2 |
| Total KSIs | 60 | |
| Provider Responsibility (cross-cutting) | KSI-CSX | 3 rules |
- Code
- KSI-AFR
- KSI Count
- 10
- Code
- KSI-CMT
- KSI Count
- 4
- Code
- KSI-CNA
- KSI Count
- 8
- Code
- KSI-CED
- KSI Count
- 4
- Code
- KSI-IAM
- KSI Count
- 7
- Code
- KSI-INR
- KSI Count
- 3
- Code
- KSI-MLA
- KSI Count
- 5
- Code
- KSI-PIY
- KSI Count
- 5
- Code
- KSI-RPL
- KSI Count
- 4
- Code
- KSI-SVC
- KSI Count
- 8
- Code
- KSI-SCR
- KSI Count
- 2
- Code
- KSI Count
- 60
- Code
- KSI-CSX
- KSI Count
- 3 rules
The 11 KSI Themes, Explained
A useful way to read the list is as the story of a secure cloud service — from how the provider engages with FedRAMP, through how it builds, runs, monitors, recovers, and sources its system.
1. Authorization by FedRAMP (KSI-AFR) — 10 KSIs
Government-facing process KSIs. This is the theme that's unique to FedRAMP — most commercial providers don't implement these for commercial customers, so it's usually the biggest lift. It covers minimum assessment scope, authorization data sharing, vulnerability detection and response, significant change notifications, collaborative continuous monitoring, the FedRAMP secure inbox, persistent validation, the secure-configuration guide for customers, incident-communication procedures, and the cryptographically-signed authorization package.
2. Change Management (KSI-CMT) — 4 KSIs
Log all changes, prefer redeployment of immutable resources over in-place modifications, automate validation throughout deployment pipelines, and review change procedures regularly. This is where your CI/CD pipeline starts earning its keep.
3. Cloud-Native Architecture (KSI-CNA) — 8 KSIs
Restrict network traffic, minimize attack surface and lateral movement, use logical network segmentation, define functionality and privileges strictly, review DoS protections, optimize for availability, follow host best practices, and enforce intended operational state automatically.
4. Cybersecurity Education (KSI-CED) — 4 KSIs
Persistently review training effectiveness for all staff, high-risk roles (privileged access), developers and engineers, and incident-response and recovery staff. Note the word "persistently" — annual phishing training videos won't cut it.
5. Identity and Access Management (KSI-IAM) — 7 KSIs
Phishing-resistant MFA, passwordless where feasible, secure non-user authentication, just-in-time authorization, least privilege, automated suspicious-activity response, and automated account lifecycle management. This is essentially a zero-trust IAM theme.
6. Incident Response (KSI-INR) — 3 KSIs
Review IR procedures regularly, review past incidents for patterns, and produce after-action reports with documented lessons learned.
7. Monitoring, Logging, and Auditing (KSI-MLA) — 5 KSIs
Operate a tamper-resistant SIEM, persistently review logs, evaluate configurations (especially Infrastructure-as-Code), maintain a list of logged event types, and tightly authorize log access.
8. Policy and Inventory (KSI-PIY) — 5 KSIs
Auto-generate real-time inventories, and review the effectiveness of vulnerability disclosure, secure SDLC alignment with CISA Secure-By-Design, security investments, and executive support.
9. Recovery Planning (KSI-RPL) — 4 KSIs
Persistently review RTO and RPO, recovery plan alignment, backup alignment, and test recovery capabilities.
10. Service Configuration (KSI-SVC) — 8 KSIs
Secure network-traffic encryption, automated configuration management, cryptographic resource-integrity validation, automated secret rotation, persistent security improvements, prevention of residual risk after changes, validation of machine-to-machine communications, and prompt removal of unwanted federal data on request.
11. Supply Chain Risk (KSI-SCR) — 2 KSIs
Persistently identify and mitigate supply chain risk, and automatically monitor third-party software for upstream vulnerabilities.
The 3 Cross-Cutting Provider-Responsibility Rules (KSI-CSX)
Above the 11 themes sit three rules that govern how CSPs approach the KSI framework itself. These aren't about your security capabilities — they're about the contract you're entering with FedRAMP:
KSI-CSX-SUM (Implementation Summaries, MUST)
Providers must maintain simple high-level summaries for every KSI, including goals, pass/fail criteria, the information resources being validated, the machine-based and non-machine-based validation processes, current implementation status, and any clarifications.
KSI-CSX-SCP (Scope, SHOULD)
Providers should apply all KSIs across the entire Minimum Assessment Scope.
KSI-CSX-ORD (Order, MAY)
Providers may follow a recommended order of criticality when assembling an initial authorization package.
Ignore these at your peril — KSI-CSX-SUM in particular is the connective tissue that ties your evidence back to each KSI for the assessor.
FedRAMP 20x Low vs. FedRAMP 20x Moderate
The simplest mental model: 20x Low and 20x Moderate share the same 60 KSIs and the same 11 themes. The capability statements do not change between baselines. What changes is the depth of automation and validation rigor expected to demonstrate the same outcome.
FedRAMP was explicit about this in RFC-0014 (the Phase 2 KSI update): "very few new Key Security Indicators required for Moderate; this is because almost every single Moderate control is already covered by an existing or slightly modified Key Security Indicator." In other words, Moderate does not mean more KSIs — it means better evidence for the KSIs that already exist.
Five KSIs strengthened for Moderate in Phase 2
Five KSIs in particular were added or strengthened during Phase 2 to capture the capabilities that matter most at the Moderate impact level:
- KSI-CNA-EIS (Enforcing Intended State) — Automated, persistent enforcement of intended operational state across machine-based resources.
- KSI-MLA-ALA (Authorizing Log Access) — Just-in-time, role- and attribute-based authorization for access to log data.
- KSI-SVC-PRR (Preventing Residual Risk) — Reviewing for and removing residual risk after changes.
- KSI-SVC-VCM (Validating Communications) — Automated, persistent validation of authenticity and integrity of inter-service communications.
- KSI-SVC-RUD (Removing Unwanted Data) — Prompt removal of federal customer data (including from backups) on agency request.
The automation bar is higher at Moderate
Phase 2 also raised the automation bar across the board. Where Phase 1 accepted written attestations for some KSIs at Low, Phase 2 expects truly automated and opinionated validation for Moderate. For example, KSI-PIY-RIS (Reviewing Investments in Security) expects evidence that a provider has staff and budget for security. At Low, FedRAMP accepted attestation about budget or staffing numbers. At Moderate, FedRAMP expects automated validations demonstrating the actual participation and involvement of security staff in day-to-day operations.
Phase 2 formalized a concrete threshold: automated validation must cover at least 70% of a provider's KSIs.
If you're aiming for Moderate, plan for deeper automation — not just more documentation.
What Good KSI Evidence Looks Like
Assessors aren't reading a Word document. They're looking at machine-readable evidence packages — typically JSON, OSCAL, or equivalent — that tie each KSI to observable proof. A good evidence entry typically includes:
- The KSI ID being addressed
- The validation method (automated / manual / hybrid)
- The tool or system that produced the evidence
- A timestamp
- A pass/fail result
- A pointer to the raw evidence (a policy export, a log query, a configuration snapshot)
- The next scheduled validation
If your current compliance posture is built around PDFs and screenshots, this is the biggest operational shift in 20x. Evidence has to be produced by your actual infrastructure, not manufactured during audit season.
Where to Go Next
Understanding the KSIs is the what. The next question is how — what your 2026 preparation plan should actually look like, which tooling gaps to close first, and where most CSPs go wrong. We've covered that in detail: How to Prepare for FedRAMP 20x in 2026.