ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
FedRAMP 20x KSI, short for Key Security Indicators, is the mechanism the programme uses to replace long control narratives with evidence that a specific security outcome is true, and ideally proven by data your systems already produce. If you are planning a first certification, or moving from the older Rev5 path, understanding the indicators is the fastest way to see what an assessment will look like.
This guide explains what the indicators are, the themes they are grouped under, how validation is expected to work, and how to prepare. The programme has changed quickly and continues to change, so treat the details here as a starting point and check the FedRAMP site before you commit to a plan. For the wider process, see our FedRAMP authorization guide.
Free gap assessment
Are you working to the 2026 FedRAMP rules or the old ones?
Score the Key Security Indicators and the CR26 obligations, free, including the Security Decision Record that replaced the SSP.
Run the free FedRAMP gap assessment → or View premium report sample
FedRAMP describes 20x as a new approach that moves beyond traditional compliance toward the security decisions that matter most, with continuous evaluation and assessment of the effectiveness of those decisions in place of a checklist audit. In Phase 1, the programme focused almost entirely on Key Security Indicators as a proof of concept for automation-based validation. Phase 2 examined the depth and width of each indicator for its effectiveness and its burden at the Moderate level, and the first pilot authorizations followed in March 2026, with more granted by late April, according to the FedRAMP Phase 2 page.
In practice, a KSI is a statement of a security outcome, for example that all user authentication uses phishing-resistant multi-factor authentication, that changes are made by redeploying immutable components, or that logs are centralised and tamper-resistant. Rather than describing how you satisfy hundreds of NIST SP 800-53 controls in prose, you show that each outcome holds, using machine-readable evidence.
Public summaries group the indicators into eleven themes. Because the list has been revised, check the current version on the FedRAMP site.
| Theme | What it covers |
|---|---|
| Cloud Native Architecture | Cloud-native design, minimised attack surface, immutable infrastructure |
| Service Configuration | Encryption, key management, risk-informed patching |
| Identity and Access Management | Zero trust practices, phishing-resistant MFA |
| Monitoring, Logging and Auditing | Centralised, tamper-resistant logging and a SIEM |
| Change Management | Automated testing and validation before deployment |
| Policy and Inventory | Asset inventories and security staffing suited to the service |
| Recovery Planning | Tested backup and contingency arrangements |
| Incident Response | Detection and post-incident review |
| Cybersecurity Education | Continuous training with regular testing |
| Third-Party Information Resources | Supply chain items such as software bills of materials and verification of subservice providers |
| Authorization by FedRAMP | How the provider works with FedRAMP itself |
Counts of individual indicators differ between sources and versions, so this guide does not quote a number. Ask your assessor which version applies to your certification class.
Summaries of the programme describe three ways to show an indicator is met. Automated validation resolves an indicator to true or false from the state of your infrastructure. Documented validation uses human-attested policies and procedures. Hybrid validation combines both. The stated preference is machine-readable evidence that is supported by proof and validated automatically wherever possible, and the expectation of automation rises with the certification class. FedRAMP’s rules now describe Classes A to D in place of the older impact levels, a shift covered in our FedRAMP ATO guide.
A useful test for any indicator is whether a script could answer it. If the outcome is that no user can authenticate without phishing-resistant MFA, the identity provider’s configuration export can show it. If it is that logs cannot be altered, the storage policy and the write-once settings can show it. If the answer is only a policy PDF, that is a documented indicator, and it will carry less weight than telemetry that shows the control operating.
The choice depends on where you are today. Providers already in a Rev5 process, with an agency sponsor and a documented package, may prefer to stay the course while the legacy path remains open. Providers starting from scratch, with a modern cloud stack and good telemetry, are the natural candidates for 20x. Secondary sources give dates for the last new Rev5 applications and the end of legacy certifications, but the dates have moved before, so take them from FedRAMP directly. Our guide to the NIST RMF vs FedRAMP explains the wider landscape, and our note on GovRAMP vs FedRAMP covers state and local use.
Someone must own each theme. Platform engineering usually owns architecture, configuration and change, the identity team owns access, security operations owns logging and incident response, and the compliance lead ties the evidence together and manages the relationship with FedRAMP and the assessor. Choose tooling that can export configuration and log data in structured form, and keep the evidence store under change control, because an assessor will want to see how the data was produced and that it has not been edited.
The independent assessor’s role is to judge whether your evidence really shows the outcome, and to check the effectiveness of your security decisions, not to tick items on a list. Involve the assessor early, ask how they will test each theme, and agree what a sample of the evidence should look like. A short pilot run against two or three themes will reveal formatting and coverage problems long before the formal submission for FedRAMP 20x KSI validation.
A small SaaS provider that hosts a case management tool for federal agencies runs on a major public cloud with infrastructure as code. It maps its environment to the indicator themes and finds it can evidence most of them from configuration exports and logs. Two gaps appear: some administrators still use one-time passcodes instead of phishing-resistant authenticators, and its inventory of third-party components is incomplete. It rolls out hardware keys, generates software bills of materials in the build pipeline and adds a nightly job that exports the evidence in the required format. It then approaches an assessor with a package built around what its systems demonstrate, not around a stack of narratives. The example is illustrative only.
Certification is the start of a continuous cycle. Indicators can turn false the day a configuration drifts, a new service is added to the boundary or an engineer disables a control during an incident. Set alerts on the checks that back each indicator, review failures at a fixed cadence and record the cause and the fix. Report significant changes to FedRAMP as its rules require, and keep a change log that links each boundary or architecture change to the indicators it touches. A provider that can show a quick, recorded response to a failed indicator is in a much stronger position than one that finds drift at the annual review.
The supporting records are consistent across paths: a boundary description, a system inventory, policies, an evidence register, a continuous monitoring plan and a corrective action process. The FedRAMP Toolkit includes templates for these, which you can adapt to your service. For the programme’s own description, see the FedRAMP 20x page, and confirm the current indicator list and rules there before you rely on any summary.
Key Security Indicators, which are security outcomes that a provider demonstrates with machine-readable evidence rather than narrative descriptions.
They act as an abstraction layer that is simpler to approach and assess, so providers on the 20x path demonstrate indicator outcomes instead of writing a narrative for every control.
The stated expectation is automated validation wherever possible, with human attestation used where automation is not feasible, and the expectation increases with the certification class.
On the FedRAMP website, which publishes the current rules and schemas. Secondary summaries, including this one, may lag behind.
September 30, 2026
