Two vocabularies, one join
NIST 800-53 controls and FedRAMP Key Security Indicators are different objects that join. Walk the join in both directions before anything else, because every later claim traverses it.
A control is a requirement written for an organisation: account management, boundary protection, developer testing. A Key Security Indicator is an outcome statement written for continuous proof: “modifications to the cloud service offering are logged and monitored.” They are different objects, in different documents, with different grammars — and they join.
The join reads in one direction: an indicator names the controls it is evidence for. Prove the indicator continuously and you are contributing evidence toward each control it names. Read it backwards — “this control is covered because an indicator mentions it” — and you have claimed more than the join says, which is the over-claim step 5 exists to train out.
Below is the whole graph, one theme at a time. Open your team’s nearest theme first — the architecture one if you build infrastructure, change management if you own the pipeline. Every id is a page; this walk is how the rest of the site is addressed.
CED — Cybersecurity Education
1 indicators
KSI-CED-RAT Reviewing All Training
The effectiveness of relevant cybersecurity education and training is persistently reviewed, including at least general training for all employees, role-specific training for employees in high risk roles, training for development and engineering staff on secure software delivery, and training for staff involved with incident response or disaster recovery.
evidence for: cp-3, ir-2, ps-6, at-2, at-2.2, at-2.3, at-3.5, at-4, ir-2.3, at-3, sr-11.1
CMT — Change Management
4 indicators
KSI-CMT-LMC Logging Changes
Modifications to the cloud service offering are logged and monitored.
evidence for: au-2, cm-3, cm-3.2, cm-4.2, cm-6, cm-8.3, ma-2
KSI-CMT-RMV Redeploying vs Modifying
Changes to machine-based information resources are executed through the redeployment of version controlled resources rather than direct modification wherever reasonable.
KSI-CMT-RVP Reviewing Change Procedures
The effectiveness of documented change management procedures is persistently reviewed.
KSI-CMT-VTD Validating Throughout Deployment
Persistent testing and validation of changes throughout deployment is automated.
CNA — Cloud Native Architecture
8 indicators
KSI-CNA-DFP Defining Functionality and Privileges
The functionality and privileges for infrastructure and services are strictly defined.
KSI-CNA-EIS Enforcing Intended State
States nothing at some classes — an indicator can simply stop, and the schema allows it.
KSI-CNA-IBP Implementing Best Practices
The use and configuration of third-party machine-based information resources is persistently compared against the original provider's best practices and guidance.
KSI-CNA-MAT Minimizing Attack Surface
Machine-based information resources are persistently reviewed to ensure they have a minimal attack surface and that lateral movement is minimized if compromised.
evidence for: ac-17.3, ac-18.1, ac-18.3, ac-20.1, ca-9, sc-7.3, sc-7.4, sc-7.5, sc-7.8, sc-8, sc-10, si-10, si-11, si-16
KSI-CNA-OFA Optimizing for Availability
Machine-based information resources are persistently reviewed to ensure they are appropriately optimized for high availability and rapid recovery.
reaches no controls
KSI-CNA-RNT Restricting Network Traffic
Machine-based information resources are persistently reviewed to ensure they are appropriately configured to limit inbound and outbound network traffic.
KSI-CNA-RVP Reviewing Protections
The effectiveness of protection against denial of service attacks and other unwanted activity for machine-based information resources is persistently reviewed.
KSI-CNA-ULN Using Logical Networking
Logical networking and related capabilities are used and persistently reviewed to enforce traffic flow controls.
evidence for: ac-12, ac-17.3, ca-9, sc-4, sc-7, sc-7.7, sc-8, sc-10
IAM — Identity and Access Management
6 indicators
KSI-IAM-AAM Automating Account Management
The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation.
evidence for: ac-2.2, ac-2.3, ac-2.13, ac-6.7, ia-4.4, ia-12, ia-12.2, ia-12.3, ia-12.5
KSI-IAM-APM Adopting Passwordless Methods
Secure passwordless methods are used for user authentication and authorization when feasible, otherwise strong passwords with phishing-resistant MFA is used.
evidence for: ac-3, ia-5.1, ia-5.2, ia-5.6, ia-6, ac-2, ia-2, ia-2.1, ia-2.2, ia-2.8, ia-5, ia-8, sc-23
KSI-IAM-ELP Ensuring Least Privilege
Identity and access management measures are used and persistently reviewed to ensure each user or device can only access the resources they need.
evidence for: ac-2.5, ac-2.6, ac-3, ac-4, ac-6, ac-12, ac-14, ac-17, ac-17.1, ac-17.2, ac-17.3, ac-20, ac-20.1, cm-2.7, cm-9, ia-2, ia-3, ia-4, ia-4.4, ia-5.2, ia-5.6, ia-11, ps-2, ps-3, ps-4, ps-5, ps-6, sc-4, sc-20, sc-21, sc-22, sc-23, sc-39, si-3
KSI-IAM-JIT Authorizing Just-in-Time
A least-privileged, role and attribute-based, and just-in-time security authorization model is used and persistently reviewed for all user and non-user accounts and services.
evidence for: ac-2, ac-2.1, ac-2.2, ac-2.3, ac-2.4, ac-2.6, ac-3, ac-4, ac-5, ac-6, ac-6.1, ac-6.2, ac-6.5, ac-6.7, ac-6.9, ac-6.10, ac-7, ac-20.1, ac-17, au-9.4, cm-5, cm-7, cm-7.2, cm-7.5, cm-9, ia-4, ia-4.4, ia-7, ps-2, ps-3, ps-4, ps-5, ps-6, ps-9, ra-5.5, sc-2, sc-23, sc-39
KSI-IAM-SNU Securing Non-User Authentication
Appropriately secure authentication methods are used and persistently reviewed for non-user accounts and services.
evidence for: ac-2, ac-2.2, ac-4, ac-6.5, ia-3, ia-5.2, ra-5.5
KSI-IAM-SUS Responding to Suspicious Activity
Accounts with privileged access are disabled or otherwise secured in response to suspicious activity.
evidence for: ac-2, ac-2.1, ac-2.3, ac-2.13, ac-7, ps-4, ps-8
INR — Incident Response
3 indicators
KSI-INR-AAR Generating After Action Reports
Incident after action reports are generated and lessons learned are persistently incorporated.
KSI-INR-RIR Reviewing Incident Response Procedures
The effectiveness of documented incident response procedures is persistently reviewed.
evidence for: ir-4, ir-4.1, ir-6, ir-6.1, ir-6.3, ir-7, ir-7.1, ir-8, ir-8.1, si-4.5
KSI-INR-RPI Reviewing Past Incidents
Past incidents are persistently reviewed for patterns or vulnerabilities that were not previously apparent or identified.
MLA — Monitoring, Logging, and Auditing
5 indicators
KSI-MLA-ALA Authorizing Log Access
States nothing at some classes — an indicator can simply stop, and the schema allows it.
evidence for: si-11
KSI-MLA-EVC Evaluating Configurations
The configuration of machine-based information resources, especially infrastructure as code, is persistently evaluated and tested.
KSI-MLA-LET Logging Event Types
A list of information resources and event types that will be logged, monitored, and audited is maintained and persistently reviewed to ensure these activities occur.
evidence for: ac-2.4, ac-6.9, ac-17.1, ac-20.1, au-2, au-7.1, au-12, si-4.4, si-4.5, si-7.7
KSI-MLA-OSM Operating SIEM Capability
A Security Information and Event Management (SIEM) or similar system(s) is used and persistently reviewed for centralized, tamper-resistant logging of events, activities, and changes.
evidence for: ac-17.1, ac-20.1, au-2, au-3, au-3.1, au-4, au-5, au-6.1, au-6.3, au-7, au-7.1, au-8, au-9, au-11, ir-4.1, si-4.2, si-4.4, si-7.7
KSI-MLA-RVL Reviewing Logs
Logs are persistently reviewed and audited.
evidence for: ac-2.4, ac-6.9, au-2, au-6, au-6.1, si-4, si-4.4
PIY — Policy and Inventory
5 indicators
KSI-PIY-GIV Generating Inventories
Authoritative sources are used to automatically generate real-time inventories of all information resources when needed.
evidence for: cm-2.2, cm-7.5, cm-8, cm-8.1, cm-12, cm-12.1, cp-2.8
KSI-PIY-RES Reviewing Executive Support
Executive support for achieving the provider's security goals is persistently reviewed and demonstrated.
reaches no controls
KSI-PIY-RIS Reviewing Investments in Security
The effectiveness of the provider's investments in achieving security goals is persistently reviewed.
evidence for: ac-5, ca-2, cp-2.1, cp-4.1, ir-3.2, pm-3, sa-2, sa-3, sr-2.1
KSI-PIY-RSD Reviewing Security in the SDLC
The effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles is persistently reviewed.
evidence for: ac-5, au-3.3, cm-3.4, pl-8, pm-7, sa-3, sa-8, sc-4, sc-18, si-10, si-11, si-16
KSI-PIY-RVD Reviewing Vulnerability Disclosures
The effectiveness of the provider's vulnerability disclosure program is persistently reviewed.
evidence for: ra-5.11
RPL — Recovery Planning
4 indicators
KSI-RPL-ABO Aligning Backups with Objectives
The alignment of machine-based information resource backups with defined recovery objectives is persistently reviewed.
KSI-RPL-ARP Aligning Recovery Plan
The alignment of recovery plans with defined recovery objectives is persistently reviewed.
evidence for: cp-2, cp-2.1, cp-2.3, cp-4.1, cp-6, cp-6.1, cp-6.3, cp-7, cp-7.1, cp-7.2, cp-7.3, cp-8, cp-8.1, cp-8.2, cp-10, cp-10.2
KSI-RPL-RRO Reviewing Recovery Objectives
The desired Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined and persistently reviewed for alignment with the provider's business needs and capabilities.
KSI-RPL-TRC Testing Recovery Capabilities
The capability to recover from incidents and contingencies aligned with defined recovery objectives is persistently tested.
evidence for: cp-2.1, cp-2.3, cp-4, cp-4.1, cp-6, cp-6.1, cp-9.1, cp-10, ir-3, ir-3.2
SCR — Supply Chain Risk
2 indicators
KSI-SCR-MIT Mitigating Supply Chain Risk
Persistently identify, review, and mitigate potential supply chain risks.
evidence for: ac-20, ra-3.1, sa-9, sa-10, sa-11, sa-15.3, sa-22, si-7.1, sr-5, sr-6, ca-7.4, sc-18
KSI-SCR-MON Monitoring Supply Chain Risk
Third party software information resources are automatically monitored for upstream vulnerabilities using mechanisms that may include contractual notification requirements or active monitoring services.
evidence for: ac-20, ca-3, ir-6.3, ps-7, ra-5, sa-9, si-5, sr-5, sr-6, sr-8
SVC — Service Configuration
8 indicators
KSI-SVC-ACM Automating Configuration Management
The configuration of machine-based information resources is managed using automation and persistently reviewed for drift.
evidence for: ac-2.4, cm-2, cm-2.2, cm-2.3, cm-6, cm-7.1, pl-9, pl-10, sa-5, si-5, sr-10
KSI-SVC-ASM Automating Secret Management
Management, protection, and regular rotation of digital keys, certificates, and other secrets is automated and persistently reviewed.
KSI-SVC-EIS Evaluating and Improving Security
Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made.
evidence for: cm-7.1, cm-12.1, ma-2, pl-8, sc-7, sc-39, si-2.2, si-4, sr-10
KSI-SVC-PRR Preventing Residual Risk
States nothing at some classes — an indicator can simply stop, and the schema allows it.
evidence for: sc-4
KSI-SVC-RUD Removing Unwanted Data
States nothing at some classes — an indicator can simply stop, and the schema allows it.
KSI-SVC-SIN Securing Information
Information is encrypted or otherwise secured from unwanted access or modification.
evidence for: ac-1, ac-17.2, cp-9.8, sc-8, sc-8.1, sc-13, sc-20, sc-21, sc-22, sc-23, sc-28, sc-28.1
KSI-SVC-VCM Validating Communications
States nothing at some classes — an indicator can simply stop, and the schema allows it.
KSI-SVC-VRI Validating Resource Integrity
Use cryptographic methods to validate the integrity of machine-based information resources.
evidence for: cm-2.2, cm-8.3, sc-13, sc-23, si-7, si-7.1, sr-10
Exit check — a colleague says “AC-2 maps to a KSI, so it’s handled.” What did they get backwards?
The direction, and with it the claim. The indicator is evidence towardthe controls it names — proving it contributes; it does not discharge a control by itself, and one control is usually named by several indicators, each covering a different slice. “Handled” is a verdict about the control’s whole requirement, and the join alone never supports it. The two-way instrument for checking any specific edge is /crosswalk.