Vol VII Book 04 — Federal Compliance — Control Attestation, Evidence & KSI
From tracked task to assessed control: IRM/GRC control tests, POA&M, and the OSCAL/KSI feed into the authorization package
0.1 Draft Proposal — Subject to Review
Developed by the CSI Team (Cloud Services Infrastructure); not yet reviewed or approved by the Agency CIO Office, OIS, or leadership. Date Code: 2026-07-21 07:38 ET
Series Context — Volume VII Book 04. The output stage of the coordination layer. Books 02 and 03 turn M365 and Azure control state into tracked work; this book turns the rolled-up result of that work into assessed control state — the ServiceNow IRM/GRC control tests, POA&M items, and the OSCAL/KSI evidence feed that Vol IV Book 06 (Authorization Package & ConMon) and Vol VI Book 07 (Evidence & ConMon Pipeline) carry into the ATO package.
1 What This Document Addresses
A closed remediation task is operational hygiene; an assessed control is what an authorizing official signs. Between the two sits attestation: the periodic control test, the evidence that the test passed, the POA&M for what did not, and the machine-readable roll-up that lets a continuous authorization run instead of a once-a-year scramble.
This book covers how ServiceNow’s IRM/GRC surface consumes the tracked-work stream from Books 01–03 and produces the three artifacts the authorization package needs: assessed control state (CA-2), a plan of action and milestones for gaps (CA-5), and a continuous-monitoring roll-up emitted as OSCAL and FedRAMP 20x KSI evidence (CA-7). It is the join between the coordination layer and the series’ existing evidence spine — it does not replace that spine, it feeds it.
2 The Attestation Model — Task Stream to Assessed Control
Control state arrives as work; attestation lifts it to evidence in four steps:
| Step | Input | ServiceNow surface | Output |
|---|---|---|---|
| 1. Map | Control → the M365/Azure tests and tasks that evidence it (the compliance spine binding) | IRM control map | Each control knows which tests attest it |
| 2. Test | Scheduled control test reads the current posture roll-up (Books 02/03) + spot evidence | IRM control test / indicator | Pass / fail / partial per control, with evidence attached |
| 3. Gap | Any fail/partial | IRM issue → POA&M | Owned POA&M item: milestone, owner, closure evidence (CA-5) |
| 4. Emit | Assessed control state + POA&M | Evidence export | OSCAL component/assessment + KSI evidence into the ConMon package |
The compliance spine is the SSOT for the control-to-evidence binding. Which controls this volume attests, and which slot/KSI each maps to, is defined in federal-compliance-compliance-spine.yml — the same generated spine that renders every book’s “Authorities Closed Here” table. ServiceNow’s IRM control map is a projection of that binding, not an independent authority. If the two disagree, the spine wins and the IRM map is out of date — the identical truth-vs-projection discipline the CMDB follows toward IPAM/DDI.
3 Assessed Control State (CA-2)
The IRM control test is the attestation primitive. Each control this volume covers carries a test that reads the rolled-up posture from Books 02/03 (SCuBA pass rate, CA-exception review currency, Azure Policy compliance, Defender open-finding age, patch SLA conformance) and renders a pass/fail/partial with the underlying evidence attached. Because the test reads actioned posture — drift that became a task that became closure — a passing control is backed by an owned, evidenced trail, not a point-in-time screenshot. That is the difference between CA-2 as an annual event and CA-2 as a standing indicator.
4 Plan of Action & Milestones (CA-5)
Every fail or partial becomes a POA&M item with a single owner, a milestone date, and a required closure evidence type. POA&M items are ServiceNow IRM issues, so they inherit the same SLA, approval, and audit-trail machinery as remediation tasks — and they link back to the Books 02/03 tasks that will close them, so the POA&M is never a parallel spreadsheet that drifts from the operational work. A POA&M whose linked remediation task closes with passing re-test evidence closes automatically; one whose milestone slips escalates. This is CA-5 as a living record joined to the work, not a quarterly reconciliation.
5 The OSCAL / KSI Emit (CA-7)
The roll-up is emitted in the two machine-readable forms the series already consumes:
- OSCAL — assessed control state and POA&M are exported as OSCAL assessment-results / POA&M models into the authorization package that Vol IV Book 06 owns. This keeps the ATO package generated, not hand-assembled, and diffable release to release.
- FedRAMP 20x KSI evidence — each attested control’s result is mapped to its KSI theme (per the spine’s
ksibindings) and emitted as KSI evidence into the pipeline Vol VI Book 07 and the Multi-Cloud Evidence Fabric (Vol III Book 07) carry to CDM and the KSI scorer.
ServiceNow is the workflow hub, not the evidence lake. The telemetry lake and the KSI scorer live in the evidence fabric (Vol III Book 07); ServiceNow contributes the workflow-and-attestation record — the owned test, the approval trail, the POA&M — into that fabric via the same evidence contract every native stack emits to. Coordination plane feeds truth plane; it does not become it.
6 One Pipeline, Every Estate — the Phase 5 Seam
The attestation loop this book defines is estate-agnostic by construction, and Phase 5 makes that concrete: the RedHat-on-AWS estate’s control state enters this same pipeline, not a parallel one. The Patch & Systems Management book’s Phase 5 emission contract delivers AWS remediation records into the same SI-2 task stream this book attests over; the AWS assessment feed ranks in the same RA-5 queue; Security Hub and GuardDuty telemetry lands in the same Evidence Fabric the KSI emit reads. An assessed control is assessed over the whole estate keyed to the one CM-8 join key — there is no AWS attestation narrative, no second scorecard, and no per-cloud OSCAL package. That is the epic’s closing invariant, and this book is where it holds.
7 Closure Necessity
7.1 Closure Provenance — the doctrine this pipeline enforces
Book 00’s Closure Provenance Doctrine is the law this book mechanizes: no closure counts unless it carries its proof. Every stage of the pipeline above is a provenance stage — the control test attaches the posture evidence it read; the POA&M item closes only on passing re-test evidence; the emit step publishes machine-readable results, not summaries. The task streams this book reads (Books 02/03 and the day-2 catalog lanes) honor the same rule at the task level: a closing update carries its verification payload, and human-only closures are flagged and counted separately — an attestation over unverified closures would attest fiction, and a report that cannot be regenerated from the closure stream is an artifact of effort, not of state. The day-2 scoped app implements the closure rules (see servicenow-day2/README.md).
7.2 Closure Necessity — an unattested control is a claim, not a control
Books 02 and 03 make M365 and Azure controls operate; this book makes them assessable. Without the attestation stage, the authorization package is a static document that describes controls no one has tested against live posture, and the FedRAMP 20x KSI feed has no workflow-attested input. CA-2, CA-5, and CA-7 are not closed by a dashboard — they are closed by an owned test, an owned gap, and a machine-readable emit that an authorizing official and a KSI scorer can both consume. Remove this book and the coordination layer produces tidy tasks that never reach the AO.
9 Honest Limits
- An attestation is only as strong as the test behind it; a control test that reads a shallow posture signal attests shallowly. Test depth is co-owned with Vol VI Book 08 (validation harnesses) — the attestation inherits that book’s coverage, good or bad.
- ServiceNow IRM produces the workflow-attested record; the authoritative OSCAL SSP and the KSI score live downstream (Vol IV Book 06, Vol VI Book 07). This book emits into them, and must not fork a second authorization narrative.
- Continuous authorization is a discipline, not a feature: the emit is only continuous if the tests run on cadence and the POA&M is worked. An idle IRM module produces a stale attestation that reads worse than an honest annual one.
10 Cross-References
federal-compliance-compliance-spine.yml— the SSOT control-to-evidence binding the IRM control map projects.- Vol IV Book 06 (Authorization Package & ConMon) — the OSCAL package this book emits into.
- Vol VI Book 07 (Evidence & ConMon Pipeline) and Vol III Book 07 (Evidence Fabric) — the KSI/CDM pipeline this book’s attestations feed.
- Vol VII Book 02 / 03 — the M365 and Azure task streams this book attests over.
- Vol III Book 03 (Patch & Systems Management), Phase 5 — the RedHat-on-AWS emission contract and assessment feed whose records this book attests alongside the M365/Azure streams.
11 Provenance
Draft. ServiceNow IRM/GRC, OSCAL, and the FedRAMP 20x KSI pipeline are deployed examples of the attestation-and-emit mechanism; the spine-as-SSOT and coordination-feeds-truth disciplines are the invariants. Vendor-source citations for the ServiceNow IRM/GRC capability claims are pending, and once added remain dated, not permanent — see the Vendor Currency Doctrine; FedRAMP 20x tooling in particular (e.g. ServiceNow-native KSI products) is moving fast enough that this book’s own claims should be re-verified before use in a Project Plan. The attestation-pipeline figure is authored as committed house-style SVG (rasterized to PNG).