Table Of Contents
-
Parts vs. Systems: FedRAMP Controls vs. 20x KSIs
-
FedRAMP Controls Are the Parts
-
20x KSIs Are the Systems
-
FedRAMP 20s KSIs and The Car Analogy
-
Why Having the Parts Is Not Enough
-
What This Looks Like in a Cloud Environment
-
How Evaluation Changes
-
The Practical Takeaway
-
The Math Behind the Control-to-KSI Mapping
-
What About KSIs Without Specific Control Mappings?
-
Conclusion
Many cloud providers understand FedRAMP as a long list of controls: account management, authentication, encryption, audit logging, configuration management, incident response, and so on.
That view is not wrong: Controls matter and they are still the building blocks of FedRAMP security.
However, controls by themselves do not always show whether a cloud service is secure in practice.
A provider may be able to point to individual controls and say, “Yes, we have that.” The harder and more important question is, Do those controls work together to produce the intended security outcome? That is why the relationship between controls and Key Security Indicators, or KSIs, matters.
FedRAMP describes KSIs as a way to summarize expected security capabilities. In other words, KSIs do not simply repeat every control statement one-for-one. They roll up control intent into higher-level capabilities that can be validated more directly. A simpler way to think about it is this: Controls are the parts. KSIs are the systems.
Learn how to get your FedRAMP ATO.
Parts vs. Systems: FedRAMP Controls vs. 20x KSIs
A car is not roadworthy just because it contains all the right parts. It may have a battery, starter, brake pads, steering column, dashboard sensors, seatbelts, tires, and an engine. Each of those parts can be inspected individually. Each one may pass its individual test. But that still not guarantee that your car will run, much less run safely.
You can apply this same logic to FedRAMP. Individual controls are like the parts of the car. They address specific requirements such as managing accounts, enforcing Multi-Factor Authentication, encrypting data, logging activity, reviewing access, or responding to incidents.
KSIs, on the other hand, are more like the operating systems of the car: braking, steering, ignition, monitoring, safety, and fuel delivery. They look at whether the parts come together to produce a working capability.
That distinction is important because systems can be implemented in different ways. For example, not every car uses the exact same breaking design. A compact car, an electric vehicle, and a heavy truck may all have different braking architectures. What matters is not whether every vehicle uses the same part in the same way. What matters is whether the braking system works.
FedRAMP 20x applies a similar idea. A cloud providers does not necessarily need to rebuild its entire environment to “sell to the government.” But it does need to show how its existing offering addresses the required security capabilities. The question becomes less, “Did you implement this control exactly the way a traditional narrative package expects?” and more, “Can you demonstrate that this security capability is working in your actual system?”
Learn more: FedRAMP 20x in Plain English: What’s New, What’s Next, and Why It Matters
FedRAMP Controls Are the Parts
Each FedRAMP control represents a specific, testable component of an information system’s security architecture.
For example:
- AC-2 addresses account management.
- IA-2 addresses identification and authentication.
- AU-2 addresses event logging.
- CM-2 addresses baseline configuration.
- IR controls address incident response.
Each control can be implemented, documented, tested, and assessed on its own. This is useful. But it is not the whole story.
A cloud service can have account management, MFA, logging, encryption, access reviews, and incident response procedures on paper, and still have weak security outcomes if those components are fragmented, inconsistently applied, or not continuously validated.
20x KSIs Are the Systems
KSIs represent higher-level security capabilities. Instead of asking only whether a specific control exists, KSIs ask whether the relevant security capability is actually functioning.
For example, the Identity and Access Management KSI theme is not just about whether a provider has accounts, passwords, MFA, and access reviews as separate artifacts. It is about whether the system effectively protects user data, controls access, and applies zero trust principles.
The Monitoring, Logging, and Auditing KSI theme is not just about whether logs exist. It is about whether important events, activity, and changes are actually monitored, logged, audited, reviewed, and acted upon.
The Service Configuration KSI theme is not just about whether configuration documents exist. It is about whether the system follows FedRAMP encryption policies, verifies resource integrity, and restricts access to third-party information resources.
That is the shift. KSIs evaluate whether the security outcome is being delivered, not merely whether individual control components are present.
Learn more: The Three Pillars Behind FedRAMP 20x Continuous Validation
FedRAMP 20s KSIs and The Car Analogy
Let’s go back to the car analogy: An automobile is made up of multiple systems:
- Ignition and electrical systems
- Mechanical systems
- Fuel or battery systems
- Braking and steering
- Safety
- Monitoring and dashboard
- Body and structural
Each system is made up of individual parts. A mechanic can inspect a battery, brake pad, spark plug, tire, sensor, or seatbelt latch independently. But no one would certify the car as roadworthy just because every part is present and working independently. The car is only roadworthy if the systems work together.
The same distinction exists between controls and KSIs. In FedRAMP, controls are the parts. KSIs are the systems.
For example: A control like AC-2 may show that account management exists. IA-2 may show that authentication is required. AU-2 may show that logging is defined. But the broader question is whether identity, access, monitoring, and response are operating together in a way that produces a secure, reliable environment.
Talk to one of our FedRAMP experts to learn more about how KSI apply to your environment.
Why Having “the Parts” Is Not Enough
A car can have all the right parts and still fail as a system. The same is true for a cloud environment. A car may have a functioning starter, battery, and ignition switch, but if they are not connected properly, the car will not start.
Similarly, a cloud environment may have identity-related controls documented and partially implemented. But if authentication, authorization, account lifecycle management, MFA, and access review do not operate together effectively, the Identity and Access Management capabilty can still fail.
This is an example of the core point: Controls can pass individually while the system still fails operationally.
Learn more: Is FedRAMP 20x More Secure–or Is It Just More Visible?
What This Looks Like in a Cloud Environment
A provider may pass individual controls such as IA-2, AC-2, and AU-2. But the provider may still have an identity and access problem if:
- Accounts are not deprovisioned promptly.
- MFA is inconsistently enforced.
- Privileged access is not tightly governed.
- Access reviews are performed as paperwork exercises.
- Identity activity is logged out but not meaningfully monitored.
In a traditional control-by-control model, these issues may be scattered across multiple control discussions. In a KSI-based model, they are easier to understand as one broader question: Does the identity and access management capability actually work?
That is the value of the KSI abstraction: It helps connect individual security requirements to the real-world capability they are supposed to produce.
How Evaluation Changes
Controls are often evaluated in isolation: Does this component meet the requirement?
KSIs are evaluated more like operating systems: Does this capability work in practice?
That does not make the underlying controls irrelevant. The controls still matter. They are the pieces that support the capability. But FedRAMP 20x shifts the emphasis from proving every part through a traditional narrative package, to demonstrating that the assembled system produces the intended security outcome.
A mechanic does not certify a car as safe because every part appears in inventory. They evaluate whether the car starts, stops, steers, signals, monitors problems, protects passengers, and performs reliably under real conditions.
FedRAMP 20x is moving in the same direction. It is not only asking whether security controls exist. It is asking whether the system those controls create can be continuously validated.
The Practical Takeaway
The practical takeaway is straightforward: Controls are necessary. KSIs show whether those controls produce a working security capability.
Focusing only on controls is like inventorying car parts. That inventory is necessary, but it does not prove the car can be driven safely.
Focusing on KSIs helps answer the more important question: Does the system actually work as a whole?
The Math Behind the Control-to-KSI Mapping
Based on the current control-to-KSI mapping analysis, the following figures can be used as a working summary:
- 474 total control and control enhancement references
- 257 unique mapped control and control enhancement references
- 147 unique parent control references, excluding control enhancements
The important point is not just the number of mapped controls, but that many FedRAMP Moderate controls are represented through KSIs because they contribute to broader security capabilities.
In other words, 20x does not simply discard the underlying control framework. It reorganizes much of that control intent around security outcomes that can be validated more directly.
What About KSIs Without Specific Control Mappings?
Not every KSI maps cleanly to a specific FedRAMP Moderate control. Some KSIs operate as process, validation, or FedRAMP-specific requirements rather than direct translations of individual controls.
These include:
| KSI | Description |
| KSI-AFR-CCM | Collaborative Continuous Monitoring |
| KSI-AFR-FSI | FedRAMP Security Inbox |
| KSI-AFR-ICP | Incident Communications Procedures |
| KSI-AFR-PVA | Persistent Validation and Assessment |
| KSI-AFR-SCG | Secure Configuration Guide |
| KSI-AFR-UCM | Using Cryptographic Modules |
| KSI-CNA-OFA | Optimizing for Availability |
| KSI-CED-RRT | Reviewing Response and Recovery Training |
| KSI-PIY-RES | Reviewing Executive Support |
These KSIs are still part of the security picture. They reflect the fact that FedRAMP 20x is not merely a remapping exercise. It also introduces expectations around ongoing validation, reporting, communication, and operational readiness.
Find out how FedRAMP 20x applies to your system and how to achieve your ATO.
Conclusion
FedRAMP 20x does not make the FedRAMP Moderate controls irrelevant. It changes how many of those controls are represented, evaluated, and validated.
Instead of requiring cloud service providers to prove compliance through every control as a standalone narrative, the KSI model asks providers to demonstrate the security outcomes those controls are meant to support.
The controls are still the parts. The KSIs show whether the system works.
Get in touch with our FedRAMP experts to learn how to “translate” your existing Rev. 5 controls into 20x KSIs.
About the Author
Table Of Contents
-
Parts vs. Systems: FedRAMP Controls vs. 20x KSIs
-
FedRAMP Controls Are the Parts
-
20x KSIs Are the Systems
-
FedRAMP 20s KSIs and The Car Analogy
-
Why Having the Parts Is Not Enough
-
What This Looks Like in a Cloud Environment
-
How Evaluation Changes
-
The Practical Takeaway
-
The Math Behind the Control-to-KSI Mapping
-
What About KSIs Without Specific Control Mappings?
-
Conclusion
