Skip to content
Close
SEARCH
Contact Us
Contact Us
High-end managed detection and response center, realistic futuristic SOC environment, modern security operations center with multiple monitors displaying threat intelligence, cybersecurity analysts at workstations, real-time threat detection das...-2

Key Security Indicators (KSIs)

Key Security Indicators are the unit of compliance under FedRAMP 20x. Each KSI is a specific, measurable security outcome a cloud system has or does not have, validated automatically against the running infrastructure rather than asserted in a written narrative. This page covers what KSIs are, the four primary clusters, the evidence-emission model, and how cloud providers operationalize KSI validation.
From narrative to verifiable evidence

What a KSI Actually Is

A KSI is a specific, machine-verifiable security capability that a cloud service either has or does not have at any given moment, validated automatically against the running infrastructure rather than asserted through a written narrative. The KSI model inverts the Rev5 compliance question. Under Rev5, an assessor asked, describe how you enforce multi-factor authentication. Under 20x, the KSI asks, produce telemetry showing MFA is enforced for 100 percent of privileged users right now. The provider does not write a paragraph; the provider emits structured evidence from the underlying systems.
The FedRAMP PMO published the initial Key Security Indicators standard on May 30, 2025, in support of the Phase 1 Low pilot. The Low baseline KSI set includes 56 indicators. The Phase 2 Moderate pilot expanded the set to 61 indicators to cover the additional Moderate control surface. The KSI structure continues to refine under CR26 and is expected to expand as the program matures into Phase 3 and beyond. The full KSI set covers identity, system protection, cloud-native architecture, monitoring and logging, incident response, vulnerability management, data protection, and supply chain.
Identity, protection, architecture, monitoring

The Four Core KSI Clusters

KSIs are grouped into clusters aligned to security domains. Each cluster covers a specific set of capabilities that engineering teams can instrument. The four clusters below are the foundation of the 20x evidence model.
1
KSI-IAM (Identity and Access Management)
Phishing-resistant multi-factor authentication, privileged access controls, federated identity, session management, and credential lifecycle. KSI-IAM is the cluster that translates the broad concept of strong identity into specific, verifiable claims. Example indicator: every privileged session in the last 24 hours used a phishing-resistant authenticator.
2
KSI-SC (System and Communications Protection)
Centralized configuration management, encryption in transit and at rest, cryptographic key management, and boundary protections. KSI-SC covers the cluster of controls that ensure the system's communications and configurations remain trusted and consistent. Example indicator: every customer data store is encrypted at rest with keys managed in an authorized key management system.
3
KSI-CNA (Cloud Native Architecture)
Immutable infrastructure, distributed denial of service protection, container and serverless security, and the cloud-native operational posture that the 20x program assumes as baseline. KSI-CNA is where 20x is most opinionated about how modern cloud services should be architected. Example indicator: production deployments are reproducible from declarative configuration with no mutable host state.
4
KSI-MLA (Monitoring, Logging, and Auditing)
Security Information and Event Management deployment, centralized log collection, log retention, and continuous security event analysis. KSI-MLA is the cluster where managed detection and response platforms make the most direct contribution. Example indicator: 100 percent of in-scope hosts emitted logs to the SIEM in the last hour.
5
Supporting Clusters
Additional clusters cover incident response, vulnerability management, data protection, supply chain security, and personnel security. Each supporting cluster contains indicators specific to its domain, mapped to the corresponding NIST SP 800-53 Rev 5 control families.
6
How Clusters Map to Controls
Each KSI cluster maps to multiple NIST SP 800-53 Rev 5 control families. KSI-IAM covers controls from the Access Control (AC) and Identification and Authentication (IA) families. KSI-SC covers System and Communications Protection (SC) and Configuration Management (CM). KSI-MLA covers Audit and Accountability (AU) and System and Information Integrity (SI). The KSI structure groups related controls into clusters that engineering teams can instrument together.
From source-of-truth systems to OSCAL evidence

How KSI Validation Works in Practice

A KSI is validated when a continuous validation pipeline emits structured evidence that the indicator's expected state holds. For an MFA KSI, the evidence might be a query result against the identity provider showing every privileged session in the last 24 hours used a phishing-resistant authenticator. For a logging KSI, the evidence might be a SIEM health check showing 100 percent of in-scope hosts emitted logs in the expected window. For an encryption KSI, the evidence might be an inventory of all data stores annotated with their encryption status and key management posture. The Phase 1 Low pilot required at least 70 percent of evidence to be automated for pilot participants. The long-term 20x target is 80 percent or higher continuous automated validation across the control set. The remaining percentage covers controls whose evidence is inherently periodic or manual, such as personnel screening, physical security inspections, and contractual review cycles. The KSI evidence is structured into the OSCAL package as part of the System Security Plan and the Assessment Results. Each KSI references the underlying NIST SP 800-53 control it satisfies, the evidence source, and the validation method. The OSCAL package becomes the system of record for which KSIs are validated, which are pending, and which are not currently met. This structure is what enables the continuous-collaboration model with 3PAOs that 20x assumes. The assessor does not wait for an annual audit window; the assessor subscribes to KSI validation events through the OSCAL package and reviews them continuously. The assessor's role shifts from periodic auditor to ongoing reviewer.
MDR vs EDR vs SIEM vs MSSP vs XDR comparison
The operational shift

What Cloud Providers Must Do to Emit KSI Evidence

The KSI model assumes a cloud-native operating posture. To produce KSI evidence at the cadence 20x expects, a cloud service needs specific infrastructure capabilities. Services architected around annual paper assessments will not produce KSI evidence at the required frequency without significant re-engineering. The list below covers what cloud providers should have in place to operate under the KSI model.
1
Centralized Identity
A single identity provider (or federated identity system) covering all human and service accounts in the authorization boundary. KSI-IAM evidence requires querying the identity provider for session data, authentication strength, and access patterns. Distributed identity systems make KSI-IAM evidence harder to produce and validate.
2
Infrastructure as Code
Production infrastructure deployed from declarative configuration, version-controlled and reproducible. KSI-CNA evidence depends on the ability to demonstrate that deployments match their declared configuration and that mutable host state is minimized. Manual or click-ops infrastructure makes KSI-CNA evidence inconsistent.
3
Centralized Logging
All in-scope systems emit security-relevant logs to a centralized collection point with sufficient retention. KSI-MLA evidence depends on the completeness of log emission and the integrity of the collection pipeline. Gaps in log emission produce gaps in KSI-MLA evidence.
4
SIEM Deployment
A Security Information and Event Management platform with continuous correlation and analysis. KSI-MLA includes indicators specifically about SIEM coverage and analysis quality. Logging without analysis is not sufficient under the KSI model.
5
Automated Configuration Management
Configuration drift detection and automated remediation for systems in the authorization boundary. KSI-SC and KSI-CNA both depend on the ability to demonstrate that the actual configuration matches the declared baseline.
6
Evidence Structuring
The underlying evidence is necessary but not sufficient. The evidence must be structured into the OSCAL package with references to the corresponding KSI, the underlying control, and the validation method. NISTCompliance.AI handles the evidence structuring layer, ingesting evidence from underlying systems and producing the OSCAL artifacts the program requires.
Evidence production and OSCAL structuring

How Cybertorch and NISTCompliance.AI Cover the KSI Stack

The KSI model has two operational halves: producing evidence at the required cadence, and structuring evidence into the OSCAL package. Cybertorch covers the first half by emitting telemetry as a byproduct of normal SOC operations. NISTCompliance.AI covers the second half by ingesting that evidence and producing the OSCAL artifacts. Together they close the KSI loop without requiring the cloud provider to build a separate compliance pipeline.
Cybertorch as a KSI-MLA Evidence Source Cybertorch is a FedRAMP Certified Class D MDR platform built on Azure Government with SIEM, centralized log collection, log retention, and continuous security event analysis. The platform emits the telemetry that KSI-MLA requires as a byproduct of normal SOC operations. Cloud providers that inherit Cybertorch controls inherit a continuous-validation telemetry surface that emits KSI evidence without separate instrumentation work.
Cybertorch's Overlap With KSI-IAM and KSI-SC Beyond KSI-MLA, Cybertorch's telemetry overlaps meaningfully with KSI-IAM and KSI-SC. The SOC monitors authentication events, privileged session activity, and configuration drift across protected systems. Cloud providers can use Cybertorch's continuous monitoring as a contributor to KSI-IAM and KSI-SC evidence in addition to KSI-MLA.
24/7 U.S.-Citizen SOC Cybertorch's analyst team is 100 percent U.S.-citizen, satisfying the citizenship requirements that federal agencies and DIB contractors increasingly require. ITAR-compliant operations. Continuous incident response capability that supports the KSI-IR cluster evidence.
NISTCompliance.AI as the OSCAL Production Pipeline NISTCompliance.AI ingests evidence from underlying control implementations across 800-plus NIST SP 800-53 Rev 5 controls and generates the complete OSCAL package as an output. SSPs are produced from control evidence rather than written by hand. POA&Ms are maintained continuously as findings open and close. Component Definitions document inherited controls from underlying platforms. Assessment artifacts are exportable for 3PAO review.
Cross-Framework Mapping NISTCompliance.AI maps KSI evidence to multiple frameworks from a single evidence base. The same evidence that satisfies a FedRAMP KSI under 20x also satisfies the equivalent CMMC Level 2 practice and the equivalent FISMA Moderate control. This is operationally significant for cloud providers serving both federal civilian and DoD markets.
Auditor Co-Pilot NISTCompliance.AI includes an Auditor Co-Pilot capability that lets 3PAOs and C3PAOs query the OSCAL package and the underlying evidence in natural language. The Auditor Co-Pilot accelerates the assessment review cycle, which is increasingly important as the 3PAO relationship shifts from annual audit to continuous review under 20x.
The Combined Position Quzara is the only firm that operates both a FedRAMP Certified Class D platform that emits KSI evidence and the AI compliance platform that structures that evidence into OSCAL packages. The two products together close the gap between continuous-validation telemetry and program-required submission artifacts.
Quzara Cybertorch federal MDR

Instrumenting Your KSI Evidence Pipeline?

Cybertorch produces the continuous-validation telemetry KSI-MLA, IAM, and SC require, as a byproduct of normal SOC operations. NISTCompliance.AI ingests that evidence and generates the OSCAL package the program requires. Request a consultation to map your KSI evidence sources to the program baseline.
Schedule a FREE Consultation

Common Questions About Key Security Indicators

What does KSI stand for? Key Security Indicator. Each KSI is a specific, measurable security outcome that a cloud system has or does not have, validated automatically against the running infrastructure rather than asserted through a written narrative.
How many KSIs are there? The Phase 1 Low baseline KSI set includes 56 indicators. The Phase 2 Moderate set expanded to 61 indicators. The KSI set continues to refine under CR26 and is expected to expand as the program matures.
What are the main KSI clusters? The four primary clusters are KSI-IAM (Identity and Access Management), KSI-SC (System and Communications Protection), KSI-CNA (Cloud Native Architecture), and KSI-MLA (Monitoring, Logging, and Auditing). Supporting clusters cover incident response, vulnerability management, data protection, and supply chain.
How is a KSI different from a NIST SP 800-53 control? A KSI is a higher-level summary capability, validated through automation. A NIST SP 800-53 control is a specific requirement, typically validated through evidence collection. Each KSI maps to multiple NIST controls; the KSI is the abstraction layer that groups related controls into capabilities engineering teams can instrument together. The 20x model uses KSIs for summary validation while preserving the NIST control catalog underneath.
How are KSIs validated? A KSI is validated when a continuous validation pipeline emits structured evidence that the indicator's expected state holds in production. For an MFA KSI, the evidence might be a query against the identity provider showing every privileged session in the last 24 hours used a phishing-resistant authenticator. For a logging KSI, the evidence might be a SIEM health check showing 100 percent of in-scope hosts emitted logs in the expected window.
What evidence automation percentage does 20x require? The Phase 1 pilot required at least 70 percent of evidence to be automated. The long-term 20x target is 80 percent or higher continuous automated validation across the control set. The remaining percentage covers controls whose evidence is inherently periodic or manual.
Do KSIs apply to all FedRAMP baselines? Currently KSIs apply to the 20x Low and Moderate baselines (Classes B and C under CR26). Class D (the former High baseline) has no 20x path defined and remains on Rev5. The KSI set is expected to expand as the program adds additional baselines and authorities.
Can a service emit KSI evidence with manual processes? Some KSIs are inherently periodic or manual (personnel screening, contractual review). Most are automated. A cloud service operating primarily on manual processes will not produce KSI evidence at the cadence 20x expects. The KSI model assumes a cloud-native operating posture with centralized identity, infrastructure-as-code, centralized logging, a SIEM, and automated configuration management.
How do KSIs interact with Significant Change Notices? A change that affects a KSI's validation state triggers updates to both the KSI evidence stream and the OSCAL package, with a Significant Change Notice if the change is material. The continuous-validation pipeline detects the change, the OSCAL SSP is updated, the affected KSIs are re-validated, and the SCN becomes a notification pointer into the updated artifacts. The model is integrated, not sequential.
What is the role of the 3PAO under the KSI model? 3PAOs validate that the KSI evidence pipeline is operating correctly and that the emitted evidence actually demonstrates the indicator's expected state. Under 20x, the 3PAO transitions from annual auditor to continuous collaborator, reviewing KSI evidence as it is emitted rather than waiting for an annual assessment window.
How does Cybertorch emit KSI evidence? Cybertorch is a FedRAMP Certified Class D MDR platform with SIEM, centralized log collection, log retention, continuous security event analysis, and 24/7 U.S.-citizen SOC operations. The platform emits the telemetry that KSI-MLA requires as a byproduct of normal SOC operations. Telemetry overlaps with KSI-IAM and KSI-SC where the SOC monitors authentication events and configuration baselines. Cloud providers inheriting Cybertorch controls inherit a continuous-validation telemetry surface that contributes to KSI evidence across multiple clusters.
How does NISTCompliance.AI structure KSI evidence? NISTCompliance.AI ingests KSI evidence from underlying telemetry sources and produces the OSCAL package that links each KSI to its evidence, the corresponding NIST SP 800-53 Rev 5 control, and the FedRAMP profile. The platform handles cross-framework mapping so KSI evidence collected once satisfies FedRAMP, CMMC Level 2, FISMA Moderate, and the underlying NIST catalog from a single evidence base.