KSI Tracking¶

FedRAMP 20x replaces control-by-control narrative with Key Security Indicators: outcome statements you evidence continuously rather than describe once. GRC-ITSM tracks each indicator as a three-level structure -- the indicator itself, the individual checks that evidence it, and the dated record of every time a check ran. This page explains that structure so you can tell which level to look at when a KSI is not Satisfied.

The three levels¶

flowchart TD
    A["<b>Parent KSI ticket</b> (ID ends -P)<br/>KSI-SVC-VRI - Validating Resource Integrity<br/>Partially Satisfied"]
    B["<b>Child check ticket</b><br/>KSI-SVC-VRI.11 [AWS]<br/>EC2 instances run approved trusted AMI images<br/>Satisfied"]
    C["<b>Child check ticket</b><br/>KSI-SVC-VRI.12 [AWS]<br/>Critical buckets have object lock protection for integrity<br/>Not Satisfied"]
    D["<b>Validations tab</b><br/>definition + one row per run<br/>Pass Count / Fail Count / Status / Date"]
    E["<b>Validations tab</b><br/>definition + one row per run<br/>Pass Count / Fail Count / Status / Date"]
    F["<b>Implemented Requirement asset</b><br/>the SSP's record of this indicator"]
    A --> B
    A --> C
    B --> D
    C --> E
    A -.->|"linked asset"| F

Each level answers a different question.

Both levels are ticket type Validation under category Validation>KSI, owned by the Governance, Risk and Compliance team on the Class C Validation SLA, and both carry a Priority of Machine when the evidence comes from a scan. Expand a parent row in the validations list to see its children inline.

The parent also links to its Implemented Requirement asset -- the SSP's record of the indicator. That link is what lets the same evidence serve both continuous monitoring and the System Security Plan without maintaining the story twice.

The child ticket summary is the fastest way to orient yourself: it names the check ID you need for an exemption tag, the cloud in brackets, and what the check actually tests, without opening anything.

Reading a check ID¶

Every automated check carries an ID derived from its indicator, with a numeric suffix:

KSI-RPL-ABO.11
└──┬───┘ └┬┘ └┬┘
   │      │   └── check number; the range identifies the cloud provider
   │      └────── indicator within the family
   └───────────── KSI family

The suffix range is the provider:

So KSI-IAM-APM.11 and KSI-IAM-APM.21 evidence the same indicator on two different providers, and the numbers never collide across providers. When you read a failure, the suffix tells you which cloud to go look at before you open anything -- and the child ticket states the provider in brackets alongside it.

The same ID appears as the Validation ID on the child ticket's Validations tab, and in the compliance mod that produces the results. It is the join between a ticket in the platform, a check in the scanner, and an exemption tag on a cloud resource.

The ten KSI families:

What a check ticket holds¶

Open a child ticket and go to its Validations tab. Two things live there: the check's definition, stated once for the ticket, and the run history, one row per run.

The definition¶

These fields describe what the check tests and how. They belong to the ticket, so they read the same no matter which run you are looking at.

The Validation Test is worth reading before you act on a failure. It states the actual assertion, including the cases where an empty result set is the pass condition, or where the check cannot fully evaluate what its indicator implies.

The run history¶

Below the definition sits the Validations table. Each row is one run:

Note the two status vocabularies, which are easy to conflate: a run is Pass or Fail, while a ticket is Satisfied, Partially Satisfied, or Not Satisfied. A ticket can sit at Partially Satisfied while its newest run says Pass, because the ticket's status accounts for cadence and coverage, not just the last result.

Because rows accumulate rather than overwrite, the table is the evidence an assessor asks for: not "this control is implemented" but "this check ran on these dates, against this many resources, with these results". The trend matters as much as the current state -- a check that went from 3 failures to 1 to 0 across four days shows remediation happening, which a single snapshot cannot.

How statuses roll up¶

Parent and child tickets share one status vocabulary, so you read a child the same way you read its parent:

A parent KSI is only as good as its children. A parent showing Partially Satisfied means at least one of its checks is not clean -- expand it and the offending child is visible immediately, since the children carry the same three statuses. Fix the failing check and the indicator follows; there is no separate attestation step for machine-based indicators.

A Not Satisfied validation enters the vulnerability workflow and is tracked to closure like any other finding. See Vulnerability Detection & Response for the remediation timelines that apply.

SLA timers¶

Every validation ticket carries a Respond By Date and an SLA Time Left countdown under the Class C Validation SLA. A negative, red timer means the validation is past its respond-by date: the evidence is stale, not necessarily failing. Treat an overdue Satisfied validation as seriously as a failing one, because an assessor looking at your evidence cadence sees the same thing you do.

Machine-based and non-machine-based¶

Most indicators are evidenced by scans. Three are not:

These carry manual validation records with a Validation Method other than Automated, and they need someone to produce and refresh the evidence on a cadence. The remaining 43 indicators update themselves as long as the scanner runs.

Scan-backed validations carry a Priority of Machine, so you can tell at a glance which rows update themselves and which are waiting on a person.

Automated coverage by provider:

Rule validations use the same structure¶

KSIs are not the only thing validated on a cadence. FedRAMP rules are tracked the same way, under category Validation>Rule, and they appear alongside KSIs in the All Open Validations list. The difference is which framework field the ticket populates:

Everything else is identical: the same statuses, the same Machine priority on scan-backed rows, the same Class C Validation SLA, and the same Validations table underneath. Rule families you will see include VER (vulnerability evaluation) and VDR (vulnerability detection and response); see Vulnerability Detection & Response for what those rules require.

When a check has exceptions¶

Some resources will legitimately fail a check -- a test environment inside the boundary, a resource whose risk you have formally accepted. Rather than let those failures sit and erode the signal, you can tag the resource in your cloud environment so the scan reports it as skipped instead of failing, with the justification travelling alongside the result.

Skipped resources land in neither the Pass Count nor the Fail Count, so an exemption narrows what a check measures. That makes it a governance decision, not a cleanup step. See Compliance Exemptions for how to tag resources, which checks support it, and the review discipline that keeps exemptions from becoming permanent.

Verify your setup¶

1. Open Compliance > KSIs and confirm all 46 parent tickets exist for your system, each with a -P ticket ID.
2. Expand a parent in the list and confirm its child check tickets appear, carrying their own statuses and a provider bracket matching the clouds you actually run.
3. Open a child, go to its Validations tab, and confirm the definition fields are populated and the run history has rows with recent dates. An empty run history means the scan is not reaching the platform -- start with the Steampipe/Powerpipe Stack verification steps.
4. Check the SLA Time Left column for negative timers. Overdue validations mean the cadence has slipped even where the status is Satisfied.
5. Confirm the three non-machine-based indicators have an owner and a cadence, since nothing will populate them automatically.