FedRAMP Key Security Indicators (KSI) Course — RMF Coach

Lesson 1 — What a KSI Is (~9 min)

Start here: the one idea 20x is built on — capabilities you can verify, not paperwork you can read.

Define a Key Security Indicator and explain why FedRAMP 20x is built on them.

Mara Lindqvist runs security at Northwind Files, a cloud document service chasing federal customers. In the traditional path she'd spend months writing a System Security Plan — hundreds of pages narrating how every control is met — and an assessor would check that snapshot once a year.

Her agency contact, Ray, asks a different question: "Don't send me the document. Can you show me — right now — that only the right people can access the service, that changes are tested before they ship, and that you'd notice an attack?"

That question is the whole idea behind Key Security Indicators. FedRAMP 20x replaces most of the narrative package with a defined set of security capabilities a provider must have and continuously demonstrate, not merely describe.

A Key Security Indicator (KSI) is a concise statement of a security capability — something the provider's people and machines actually do — backed by automation that persistently monitors, enforces, and reports the security state.

Three properties make KSIs different from a narrative control description:

They are few and fixed. FedRAMP publishes the set — currently 46 KSIs in 10 categories — in a machine-readable rules source, so every provider answers the same questions.

They are stated as outcomes. A KSI says what must be true ("logs are persistently reviewed and audited"), not what document must exist.

They are validated continuously. Evidence is generated by automation and checked on an ongoing basis, not at an annual point in time.

Because the set is canonical and versioned, when FedRAMP updates a KSI, everyone — providers, assessors, agencies, and tools — updates from the same source.

Put the two models side by side:

Narrative model: the provider describes each control → an assessor reads and samples → the result is a signed snapshot that starts drifting the day it's issued.

KSI model: the provider builds each capability → automation emits evidence continuously → the assessor validates the evidence stream → agencies see current state, not last year's state.

Notice what did not change: the security engineering underneath. Least privilege, logging, incident response, recovery, supply chain care — the substance is the same substance the SP 800-53 catalog organizes. What changed is the form of proof. That's why practitioners who know RMF and the catalog pick up KSIs quickly: the capabilities are familiar; the demonstration is new.

Lesson 2 — Anatomy of a KSI (~9 min)

Learn to read one KSI precisely, and you can read all 46.

Decompose any KSI into its ID, category, name, and statement, and interpret its 'persistently' language.

Every KSI has four parts:

ID — KSI-<CATEGORY>-<ABBR>, e.g. KSI-IAM-ELP. The middle token is the category (Identity and Access Management); the last token abbreviates the capability (Ensuring Least Privilege).

Name — a short verb phrase: Ensuring Least Privilege.

Statement — the normative sentence: "Identity and access management measures are used and persistently reviewed to ensure each user or device can only access the resources they need."

Category — one of ten groups that organize the set, the way families organize the SP 800-53 catalog.

The statement is the requirement. The name is a handle. The ID is how machines — schemas, evidence, dashboards — refer to it.

The 46 KSIs are organized into 10 categories:

CED — Cybersecurity Education (1 KSI): training that is reviewed for effectiveness.

CMT — Change Management (4): changes are logged, redeployed rather than hand-edited, validated through deployment.

CNA — Cloud Native Architecture (8): strictly defined privileges, enforced intended state, minimal attack surface, traffic controls.

IAM — Identity and Access Management (6): automated account lifecycle, passwordless/phishing-resistant auth, least privilege, just-in-time authorization.

INR — Incident Response (3): after-action reports, reviewed procedures, pattern analysis of past incidents.

MLA — Monitoring, Logging, and Auditing (5): SIEM, defined event types, reviewed logs, controlled log access.

PIY — Policy and Inventory (5): real-time inventories, executive support, security investment, secure SDLC, vulnerability disclosure.

RPL — Recovery Planning (4): RTO/RPO defined, backups and plans aligned, recovery tested.

SCR — Supply Chain Risk (2): supply chain risks mitigated and third-party software monitored.

SVC — Service Configuration (8): automated configuration and secret management, encryption, integrity validation, data removal.

Count them: 1 + 4 + 8 + 6 + 3 + 5 + 5 + 4 + 2 + 8 = 46.

Read a handful of KSI statements and one word repeats: persistently. Logs are persistently reviewed. Least privilege is persistently reviewed. Recovery is persistently tested.

That word is the difference between the old world and this one. An annual access review satisfied a point-in-time assessment; it does not satisfy "persistently reviewed." The intent is a capability that runs as part of operations — usually automated, always repeatable, and producing evidence as it runs.

When Sofia, Northwind's platform engineer, plans a KSI implementation, her first question is never "what document do we need?" It's "what runs, how often, and what evidence does it emit?" That question is the correct reading of 'persistently'.

Lesson 3 — KSIs and the Control Catalog (~8 min)

KSIs don't replace what you know — they repackage it for continuous proof.

Relate KSIs to SP 800-53 controls and explain where each model applies.

If you know the catalog, the KSI set reads like familiar country:

KSI-IAM-AAM (automated account lifecycle) walks the same ground as AC-2, Account Management — but demands automation, not description.

KSI-MLA-RVL (logs persistently reviewed) is AU-6, Audit Record Review territory, made continuous.

KSI-CMT-LMC (changes logged and monitored) lives where CM-3, Configuration Change Control lives.

KSI-INR-AAR (after-action reports, lessons incorporated) matches the spirit of IR-4, Incident Handling.

The mapping is thematic, not one-to-one — a KSI often condenses several controls into one demonstrable outcome, and the catalog covers ground (like physical security detail) the KSI set handles differently. But the skill transfers: if you can implement and assess the family, you can build and evidence the KSI.

The Consolidated Rules scale how hard each KSI must be proven by certification class. At Class A — the low-barrier on-ramp — automated verification is optional and attestation carries more weight. Moving up through Classes B, C, and D (aligned to Low, Moderate, and High expectations), more of the KSI set must be verified and validated by automation, with machine-readable evidence an assessor can independently check.

For Northwind's Class C pursuit, that means Sofia's automation isn't a nice-to-have — most KSIs need machine-generated evidence on a continuous cadence, and Devin, the Recognized assessor, validates the stream rather than sampling documents.

One set of statements, one dial: class sets the burden of proof, not the list of capabilities.

Lesson 1 — Identity & Access (IAM) (~11 min)

Six KSIs about the oldest question in security: who can touch what, and who's checking?

Apply the six IAM KSIs to account, authentication, and authorization decisions.

Four IAM KSIs govern accounts and privilege:

KSI-IAM-AAM — Automating Account Management. "The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation." Joiners, movers, leavers — handled by machinery, not tickets someone forgets.

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."

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." Standing admin access gives way to access granted when needed, expiring when done.

KSI-IAM-SNU — Securing Non-User Authentication. "Appropriately secure authentication methods are used and persistently reviewed for non-user accounts and services." Service accounts and API keys get the same discipline humans do.

At Northwind, Sofia wires the HR system to the identity provider so departures deprovision within minutes — that single integration carries AAM, and its logs are the evidence.

Two more IAM KSIs finish the picture:

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." Passkeys and hardware-backed credentials first; where passwords survive, they're paired with phishing-resistant MFA.

KSI-IAM-SUS — Responding to Suspicious Activity. "Accounts with privileged access are disabled or otherwise secured in response to suspicious activity." Not investigated eventually — secured in response. The reflex is automated: impossible-travel login on an admin account → the account is contained first, questions asked second.

Together the six IAM KSIs describe an identity system that runs itself: provisioned by automation, scoped tight, strongly authenticated, and quick to slam the door.

Lesson 2 — Cloud Native Architecture (CNA) (~12 min)

Eight KSIs that make the platform itself the first line of defense.

Apply the eight CNA KSIs to architecture, network, and availability decisions.

Four CNA KSIs are about what the platform is:

KSI-CNA-DFP — Defining Functionality and Privileges. "The functionality and privileges for infrastructure and services are strictly defined." Every service does exactly what it's declared to do — nothing runs 'because it was there'.

KSI-CNA-EIS — Enforcing Intended State. "Automated services are used to persistently assess the security of all machine-based information resources and automatically enforce their intended operational state." Drift isn't reported to a human — it's reverted by machinery.

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."

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." If you run someone's database engine, you run it the way its maker says to.

Note the pattern: these aren't requests for diagrams. They're requests for a platform that continuously knows and enforces its own shape.

Four more CNA KSIs face the network and the users depending on it:

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." Egress matters as much as ingress.

KSI-CNA-ULN — Using Logical Networking. "Logical networking and related capabilities are used and persistently reviewed to enforce traffic flow controls." Segmentation by software-defined boundaries, reviewed as they evolve.

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-OFA — Optimizing for Availability. "Machine-based information resources are persistently reviewed to ensure they are appropriately optimized for high availability and rapid recovery."

Boundary protection veterans will recognize SC-7 country — with the same 20x twist: the review never stops.

Lesson 3 — Service Configuration & Data (SVC) (~12 min)

Eight KSIs about the state of the machine and the safety of the customer's data.

Apply the eight SVC KSIs to configuration, cryptography, and data-handling decisions.

Four SVC KSIs govern the machine's state:

KSI-SVC-ACM — Automating Configuration Management. "The configuration of machine-based information resources is managed using automation and persistently reviewed for drift."

KSI-SVC-ASM — Automating Secret Management. "Management, protection, and regular rotation of digital keys, certificates, and other secrets is automated and persistently reviewed." No spreadsheet of API keys survives contact with this statement.

KSI-SVC-PRR — Preventing Residual Risk. "Plans, procedures, and the state of information resources are persistently reviewed after making changes to limit and remove unwanted residual elements that would likely negatively affect the confidentiality, integrity, or availability of federal customer data." After the change ships, what got left behind?

KSI-SVC-EIS — Evaluating and Improving Security. "Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made." Not just hold the line — move it.

Note SVC-EIS shares an abbreviation with CNA-EIS but is a different KSI: CNA-EIS enforces intended state; SVC-EIS improves it.

Four SVC KSIs face the data:

KSI-SVC-SIN — Securing Information. "Information is encrypted or otherwise secured from unwanted access or modification."

KSI-SVC-VCM — Validating Communications. "The authenticity and integrity of communications between machine-based information resources is persistently validated using automation." Mutual TLS between services is the everyday face of this.

KSI-SVC-VRI — Validating Resource Integrity. "Use cryptographic methods to validate the integrity of machine-based information resources." Signed images, verified artifacts.

KSI-SVC-RUD — Removing Unwanted Data. "Unwanted federal customer data is removed promptly when requested by an agency in alignment with customer agreements, including from backups if appropriate…" — the spill-response and offboarding KSI. When Ray's agency asks Northwind to purge a spilled file, this statement is why 'we can't reach the backups' is not an acceptable answer.

Lesson 4 — Change, Monitoring & Logging (CMT + MLA) (~12 min)

Nine KSIs: ship changes safely, and see everything that happens.

Apply the four CMT and five MLA KSIs to deployment and observability decisions.

The four CMT KSIs:

KSI-CMT-LMC — Logging Changes. "Modifications to the cloud service offering are logged and monitored."

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." No SSH-and-edit in production — rebuild from source and redeploy, so every change has a commit behind it.

KSI-CMT-VTD — Validating Throughout Deployment. "Persistent testing and validation of changes throughout deployment is automated." The pipeline tests on the way out, not just before merge.

KSI-CMT-RVP — Reviewing Change Procedures. "The effectiveness of documented change management procedures is persistently reviewed." The process itself is a resource under review.

RMV is the culture-changer: infrastructure as code stops being a preference and becomes the compliance path.

The five MLA KSIs form a chain:

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." Decide what to see — then verify you're seeing it.

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."

KSI-MLA-RVL — Reviewing Logs. "Logs are persistently reviewed and audited." The shortest KSI statement in the set — and one of the hardest to fake, because review leaves its own evidence.

KSI-MLA-ALA — Authorizing Log Access. "A least-privileged, role and attribute-based, and just-in-time access authorization model is used and persistently reviewed for access to log data based on organizationally defined data sensitivity." Logs are sensitive data too.

KSI-MLA-EVC — Evaluating Configurations. "The configuration of machine-based information resources, especially infrastructure as code, is persistently evaluated and tested." Your IaC is code — test it like code.

Chain complete: decide (LET) → collect tamper-resistant (OSM) → review (RVL) → protect access (ALA) → test the configs feeding it all (EVC).

Lesson 5 — Incidents & Recovery (INR + RPL) (~10 min)

Seven KSIs for the bad day: respond, learn, and get back up — provably.

Apply the three INR and four RPL KSIs to incident response and recovery planning.

The three INR KSIs all point at the same target: institutional learning.

KSI-INR-AAR — Generating After Action Reports. "Incident after action reports are generated and lessons learned are persistently incorporated." The report isn't the deliverable — the incorporated lesson is.

KSI-INR-RIR — Reviewing Incident Response Procedures. "The effectiveness of documented incident response procedures is persistently reviewed." Tabletops, drills, and post-incident critiques feed procedure updates.

KSI-INR-RPI — Reviewing Past Incidents. "Past incidents are persistently reviewed for patterns or vulnerabilities that were not previously apparent or identified." Last quarter's minor events, re-read together, often spell out this quarter's major one.

Notice there's no KSI that says 'have an incident response plan.' The set assumes the plan and demands proof the loop — respond, write, learn, improve — actually turns.

The four RPL KSIs form a loop around two numbers:

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." First, declare how fast (RTO) and how much loss (RPO) is acceptable.

KSI-RPL-ARP — Aligning Recovery Plan. "The alignment of recovery plans with defined recovery objectives is persistently reviewed." The plan must actually achieve the declared numbers.

KSI-RPL-ABO — Aligning Backups with Objectives. "The alignment of machine-based information resource backups with defined recovery objectives is persistently reviewed." Backup frequency and scope derive from RPO, not from default settings.

KSI-RPL-TRC — Testing Recovery Capabilities. "The capability to recover from incidents and contingencies aligned with defined recovery objectives is persistently tested." Restore drills prove the whole chain.

Define the objectives, align the plan, align the backups, test the capability. If the test misses the RTO, one of the first three links needs work — and the evidence trail shows which.

Lesson 6 — Program, People & Supply Chain (PIY + CED + SCR) (~11 min)

Eight KSIs proving the security program itself is real — funded, supported, taught, and supplier-aware.

Apply the five PIY, one CED, and two SCR KSIs to program governance and supply chain decisions.

The five PIY KSIs audit the program:

KSI-PIY-GIV — Generating Inventories. "Authoritative sources are used to automatically generate real-time inventories of all information resources when needed." Not a spreadsheet updated quarterly — a query answered from live sources.

KSI-PIY-RES — Reviewing Executive Support. "Executive support for achieving the provider's security goals is persistently reviewed and demonstrated." Leadership backing is a reviewable claim.

KSI-PIY-RIS — Reviewing Investments in Security. "The effectiveness of the provider's investments in achieving security goals is persistently reviewed." Is the money moving the needle?

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."

KSI-PIY-RVD — Reviewing Vulnerability Disclosures. "The effectiveness of the provider's vulnerability disclosure program is persistently reviewed." Outsiders can report a hole, and the reports go somewhere.

An assessor reading PIY evidence learns something no scan reveals: whether security is resourced and led, or a heroic side project.

Three KSIs complete the set:

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." One KSI, four named audiences — and it measures effectiveness, not attendance.

KSI-SCR-MIT — Mitigating Supply Chain Risk. "Persistently identify, review, and mitigate potential supply chain risks."

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." When a dependency announces a CVE, the provider hears about it from tooling — not from the news.

That's all 46. You now hold the complete set: 6 IAM, 8 CNA, 8 SVC, 4 CMT, 5 MLA, 3 INR, 4 RPL, 5 PIY, 1 CED, 2 SCR.

Lesson 1 — Evidence, the Package & Ongoing Reporting (~10 min)

A KSI you can't evidence is a KSI you don't have.

Trace a KSI from implementation to machine-readable evidence to certification and ongoing reporting.

For each KSI, the provider maintains three things:

1. The implementation — the automation and process that make the statement true.

2. The evidence — machine-generated output showing it operating: IdP lifecycle logs for KSI-IAM-AAM, pipeline run records for KSI-CMT-VTD, restore-drill results for KSI-RPL-TRC.

3. The determination — the provider's own true/false assertion that the KSI is met, which the Recognized assessor independently validates.

Good evidence has two properties. It's machine-readable — structured data a tool can check, not a screenshot. And it's regenerable — run the query again tomorrow and get tomorrow's truth. Sofia's rule of thumb at Northwind: if producing the evidence requires a human to remember, the implementation isn't done.

KSI results appear twice in a service's life:

At certification — the machine-readable certification package carries the KSI determinations and supporting evidence. Devin, the Recognized assessor, validates them; agencies reviewing Northwind read results, not three hundred pages of narrative.

Forever after — recurring ongoing certification reporting keeps the picture current. The CR26 document set defines machine-readable records for this — the same schema-driven discipline as the rest of the package, so agency tooling can consume updates automatically.

This is the payoff of the whole model: because evidence is structured and continuous, an agency's trust doesn't age. Ray checks Northwind's current KSI state the way he'd check a status dashboard — which is exactly what it is.

Lesson 2 — When Things Change (~10 min)

The KSI model is built for change — degradation, drift, and redesign all have a lane.

Handle a degraded KSI and a significant change the way the 20x model expects.

Tuesday morning, Northwind's dashboard flips KSI-SVC-ASM red: a certificate in a legacy subsystem was rotated by hand last week — outside the automated secret manager. The automation noticed, because noticing is its job.

This is the model working, not failing. Under continuous validation the provider's own machinery catches degradation before the assessor or agency does. The expected sequence: contain (bring the stray secret back under automated management), correct the cause (the legacy subsystem gets wired into the secret manager), and let the reporting show it — the ongoing evidence stream records both the dip and the recovery.

What providers must not do is quietly patch the evidence. The value of the entire certification rests on the stream being trustworthy; a provider caught curating its evidence has a much bigger problem than one red KSI.

Most change is routine and already governed by the CMT KSIs: version-controlled, redeployed, validated through the pipeline, logged and monitored. The KSI evidence stream simply keeps reporting through it.

Some change is significant — a new data center region, a re-architected authentication system, a new major subservice. The CR26 document set defines significant change notifications as machine-readable records, so providers notify in structured form and agencies consume the notification with tooling, evaluating impact against current KSI results rather than waiting for a re-assessment cycle.

The habit to build: when planning any change, ask which KSIs does this touch, and will their evidence stay green through the transition? A re-architected auth system touches most of IAM; planning the evidence continuity is part of planning the change.