AWS Public Sector Blog

Deep dive into FedRAMP 20x Key Security Indicators: Decoding the 63 KSIs

Deep dive into FedRAMP 20x Key Security Indicators: Decoding the 63 KSIs

The Federal Risk and Authorization Management Program (FedRAMP) 20x program replaces hundreds of narrative control descriptions with Key Security Indicators (KSIs) organized across 12 themes.

In this post, we break down every KSI theme, categorize each indicator by validation approach, and provide a practical gap analysis framework so you can begin preparing your cloud service offering (CSO) for FedRAMP 20x authorization on Amazon Web Services (AWS).

What are Key Security Indicators?

In our first blog post, we introduced FedRAMP 20x and its shift from static documentation to automated evidence. KSIs are the building blocks of that shift. Each KSI represents a measurable, concrete security outcome, which cloud service providers (CSPs) must demonstrate through automated validation, documented processes, or both.

The Phase 2 pilot completeness requirements set a clear bar: Automated validation must cover at least 70% of KSIs, every KSI must be addressed, and evidence must be available in both human-readable and machine-readable formats. Understanding what each KSI requires is the first step toward meeting that bar.

The 12 KSI themes at a glance

The following table summarizes all 12 KSI themes, their associated KSI counts, and primary focus areas to help you quickly assess where your organization stands:

Theme Name KSI count Focus area
CSX Cross-Cutting 3 Implementation summaries, Minimum Assessment Standard (MAS) scope, priority ordering
AFR Authorization by FedRAMP 10 MAS, vulnerability disclosure, scanning/remediation, Plan of Action and Milestones (POA&M), significant change notification (SCN), authorization data, persistent validation, continuous monitoring
CNA Cloud Native Architecture 8 Network segmentation, attack surface minimization, distributed denial of service (DDoS) protection, API security, automated posture enforcement
CMT Change Management 4 Change control, immutable infrastructure, deployment validation
IAM Identity and Access Management 7 Phishing-resistant multi-factor authentication (MFA), authentication without passwords, least privilege, just-in-time (JIT) access
MLA Monitoring, Logging, and Auditing 5 Audit log generation, security information and event management (SIEM) integration, configuration evaluation
SVC Service Configuration 8 Encryption at rest and in transit, Federal Information Processing Standards (FIPS) cryptography, secrets management, secure defaults
RPL Recovery Planning 4 Recovery time objective (RTO), recovery point objective (RPO), backup procedures, recovery testing
PIY Policy and Inventory 5 Asset inventory, software inventory, executive support, software development lifecycle (SDLC) security
INR Incident Response 3 Incident response plan, procedures, post-incident review
CED Cybersecurity Education 4 General training, role-specific training, developer training, response/recovery training
SCR Supply Chain Risk 2 Supply chain risk assessment, third-party monitoring

Table 1: The 12 KSI themes at a glance

Categorizing KSIs: Automate, document, or both

Not every KSI can be validated by a machine. Some require documented processes, executive attestations, or human judgment. We categorize each KSI into one of three buckets to help you plan your implementation approach:

  1. Fully automatable KSIs can be validated entirely through automated tooling, such as AWS Config rules, AWS Security Hub checks, or infrastructure as code (IaC) scanning. Examples include KSI-SVC-SNT (encrypt network traffic), KSI-CNA-RNT (restrict network traffic), and KSI-IAM-MFA (enforce phishing-resistant MFA).
  2. Process and documentation KSIs require written policies, procedures, or human review cycles. Examples include KSI-INR-AAR (after-action reports), KSI-PIY-RES (executive support review), and KSI-CED-RGT (general training review).
  3. Both KSIs have an automated component and a documented process component. For example, KSI-AFR-VDR (vulnerability detection and response) requires automated scanning tools and a documented methodology with defined service-level agreement (SLA) timelines.

The following figure illustrates how KSIs are distributed across these three categories and the validation lifecycle from preventive controls through runtime monitoring:

Diagram showing the FedRAMP 20x validation lifecycle on AWS across four stages: preventive, pre-deploy, runtime, and threat detection.

Figure 1: FedRAMP 20x KSI validation lifecycle showing the distribution of KSIs across automated, documented, and hybrid categories, with AWS services mapped to each validation stage

Theme-by-theme breakdown

In this section, we explore the areas relevant to each KSI theme and the AWS services related to that theme.

Authorization by FedRAMP (AFR), 10 KSIs

This is the most complex theme because each KSI ties to a FedRAMP-specific standard. KSI-AFR-MAS requires you to identify every information resource in scope, including people, budgets, and systems. KSI-AFR-VDR requires a complete vulnerability detection and response methodology with N1 through N5 severity ratings and defined remediation timelines. KSI-AFR-SCN requires classifying changes as routine, adaptive, or transformative, each with different notification timelines.

On AWS, services such as Amazon Inspector and AWS Security Hub can help address KSI-AFR-VDR. AWS CloudTrail and Amazon EventBridge support KSI-AFR-SCN by detecting and classifying infrastructure changes.

Cloud Native Architecture (CNA), 8 KSIs

These KSIs focus on network segmentation, attack surface minimization, and automated posture enforcement. KSI-CNA-MAT (minimize attack surface) and KSI-CNA-RNT (restrict network traffic) are strong candidates for automated validation using Amazon Virtual Private Cloud (Amazon VPC) security groups, network access control lists (ACLs), and AWS Network Firewall. KSI-CNA-EIS (enforce intended state) maps directly to AWS Config rules that detect drift from your desired configuration.

Identity and Access Management (IAM), 7 KSIs

KSI-IAM-MFA (phishing-resistant MFA) and KSI-IAM-ELP (least privilege) are foundational. AWS IAM Identity Center supports phishing-resistant MFA with FIDO2 security keys. AWS IAM Access Analyzer helps validate least privilege by identifying unused permissions. KSI-IAM-JIT (just-in-time access) can be addressed through temporary role assumption with time-bounded sessions.

Service Configuration (SVC), 8 KSIs

Encryption is the main idea of this theme. KSI-SVC-SNT (secure network traffic) and KSI-SVC-VRI (validate resource integrity) require FIPS 140-2 validated cryptographic modules. AWS Key Management Service (AWS KMS) provides FIPS-validated key management, and AWS Certificate Manager (ACM) automates Transport Layer Security (TLS) certificate provisioning. KSI-SVC-ACM (automate configuration management) aligns with IaC practices using AWS CloudFormation or Terraform.

Monitoring, Logging, and Auditing (MLA), 5 KSIs

KSI-MLA-OSM (operate SIEM capability) requires centralized, tamper-resistant logging. AWS CloudTrail with organization-level trails, Amazon CloudWatch logs, and AWS Security Hub provide the foundation. KSI-MLA-EVC (evaluate configurations) maps to AWS Config conformance packs that persistently evaluate resource configurations.

Change Management (CMT) 4 KSIs, Recovery Planning (RPL) 4 KSIs, Incident Response (INR) 3 KSIs, and remaining themes

The remaining themes align well with established cloud-based practices and are summarized here at a higher level. CMT KSIs favor immutable infrastructure patterns (KSI-CMT-RMV) where changes are deployed through redeployment rather than in-place modification, a natural fit for IaC workflows.

RPL KSIs require documented and tested recovery objectives. INR KSIs require both documented procedures and evidence of post-incident reviews. CED KSIs are entirely process-based, requiring evidence of training programs. SCR KSIs require supply chain risk assessments and automated monitoring of third-party dependencies.

Understanding persistent validation

A critical concept in FedRAMP 20x is the word persistent. FedRAMP defines it as “occurring in a firm, steady way that is repeated over a long period of time.” For moderate impact systems, machine-based KSI validation must run at least every 3 days. Non-machine KSIs must be validated at least every 3 months.

This means your validation infrastructure must be always-on, not a point-in-time assessment. On AWS, this translates to Amazon EventBridge scheduled rules triggering AWS Step Functions workflows that collect evidence from AWS Config, AWS Security Hub, Amazon Inspector, and other services on a recurring cadence.

Conducting your KSI gap analysis

Start your gap analysis with these steps:

  1. Assess your current state. For each of the 63 KSIs, document whether you have full coverage, partial coverage, or no coverage today. If you’re running the Landing Zone Accelerator on AWS (LZA) with the Universal Configuration, many CNA, MLA, and IAM KSIs already have partial coverage through AWS Security Hub, Amazon GuardDuty, AWS Config, and AWS CloudTrail.
  2. Identify automation candidates. Flag every KSI where AWS provides a service or feature that can produce machine-readable evidence. Target the 70% automated validation threshold.
  3. Catalog documentation gaps. For process-based KSIs, determine whether you have existing policies that can be adapted or whether new documentation is needed.
  4. Prioritize by theme. Follow the recommended priority order: AFR KSIs first (they define the framework), then CNA and IAM (foundational security posture), then SVC and MLA (operational security), and finally the remaining themes.
  5. Plan your evidence pipeline. Every KSI needs evidence in both human-readable clear summaries with context, timestamps, and plain-language explanations of what was verified, and machine-readable formats. Plan how each piece of evidence will be generated, stored, and published.

What comes next

With your gap analysis complete, the next step is implementing preventive controls that prohibit noncompliant configurations before they reach your environment. In our next blog, we cover how AWS Organizations service control policies (SCPs) enforce KSIs at the organizational level, reducing both your compliance burden and your assessment surface.

Next steps and resources

Paul Keastead

Paul Keastead

Paul Keastead is an Assurance Consultant with AWS Security Assurance Services (SAS) and a Lead Cybersecurity Maturity Model Certification (CMMC) Certified Assessor. He helps organizations achieve and maintain their compliance objectives in the cloud. Leveraging his experience as a FedRAMP Assessor and over a decade of expertise in national security and public sector technology compliance, Paul works closely with customers, partners, and AWS teams to align security and compliance requirements with business objectives.

Dr. Tommy Kromer

Dr. Tommy Kromer

Dr. Tommy Kromer is a Practice Manager with AWS Security Assurance Services (SAS), focusing on public sector compliance and security operations. He has spent his career helping government contractors navigate complex regulatory landscapes, from the early days of DIACAP through some of the first RMF accreditations to today's CMMC requirements. Leveraging his experience across the Department of Defense and intelligence community, along with expertise in security operations center management and threat hunting, Tommy works closely with customers to align security and compliance as complementary forces that achieve mission-critical objectives.