Federal Modernization Workbook · Book 14 · How
Chapter 12 — The Series as a Map: Which Volume and Book Closes Each Control
The compliance series and the workbook books are two views of one program; the map tells a reader where each control is closed, where its proof is built, and what will still be open when everything on the map is done.
How the Federal Compliance series is organized, and why its volumes and the workbook’s books don’t line up one to one. A volume-by-volume map: what each volume covers, which book carries it now, which control families it claims closure for, and where the full volume still lives. What an agency’s first assessment can be expected to find before the program. And the residual compliance risk that remains even when every volume on the map is built, which only the authorizing official can accept.
The Federal Compliance series grew as eleven volumes written for one purpose: to show, control by control, how a moderate-impact agency implements the NIST SP 800-53 controls in its baseline across its estate and proves it. The workbook books reorganize the same material by topic. A reader who starts from a control, a volume or a book needs to know where the other two are. This chapter is that map.
The two organizations differ for a reason. The series is arranged by layer: the naming and identity floor, then the data tier, then security operations, then the governance artifacts, then the volumes that teach, deploy, automate and operate it. The books are arranged by the question a reader brings: why does identity matter, why does DNS matter, why does compliance decay. Most volumes therefore feed more than one book, and most books draw on more than one volume. Where a book has absorbed a volume’s argument, the book is the place to read it. Where a volume’s depth (its runbooks, scripts and long control tables) didn’t fit a book, the volume stays in the repository, and this chapter links it there.
How to read the map
Three conventions apply to everything below.
- “Closes” means the series’ claim, under this book’s rule. A volume claims a control closed when it specifies the mechanism that supports it and the evidence that proves it. Under Chapter 04’s rule, a control closes only when the mechanism exists in the estate and its proof is recorded. The map shows where each claim is made, not that the agency has met it.
- Families, not counts. The volumes carried their own control counts, which were internal and dated. The map lists the control families each volume works in, with representative controls. The per-control index is Appendix A.
- Two volumes are this book. The executive summary, questionnaire and crosswalk volume, and the governance and assurance volume, are this book’s sources. Their content is in Chapters 01 to 11 and the appendices; they aren’t linked separately.
The map, volume by volume
| Volume | What it covers | Carried now by | Control families it claims closure for |
|---|---|---|---|
| Executive summary, questionnaire and crosswalk | The program’s thesis, the federal clock, the closure rule, the product inventory questionnaire and the control crosswalk | This book: Chapters 01–04, Appendix A, Appendix B | None directly; it indexes the rest |
| I. Foundation and transport | Naming and addressing, device and cryptographic identity, the HR source of truth, cloud identity and Zero Trust network access, telecommunications and edge enforcement | Books 02, 03, 04, 07, 08, 09, 10 | SC (SC-7, SC-8, SC-12, SC-17, SC-20 to SC-22), IA (IA-2 to IA-5, IA-9), AC (AC-2 to AC-4, AC-17, AC-19), CM (CM-2, CM-6, CM-8), AU (AU-2, AU-12), PS (PS-4, PS-5), SI (SI-3, SI-4, SI-12), with SA-9, PL-8 and CA-7 |
| II. Data platform | Database authentication without stored credentials, the implementation runbooks, and consolidation limits set by network physics | Book 06 | IA and AC extended to the database tier; SC-5, SC-8, SC-28; AU-9; CP-9, CP-10; CA-3; SA-8 (the volume’s CP-9 and CP-10 claims were not carried into Book 06; Appendix A shows both open) |
| III. Security operations | Privileged access, vulnerability and patch management, cloud-native posture, data protection, detection, and the multi-cloud evidence fabric | Book 12; privileged access in Book 04 | AC-5, AC-6 and enhancements, AC-11, AC-12, IA-11; RA-5, SI-2, SI-5, CM-7; MP-2 to MP-5, SC-12, SC-13, SC-28, AU-10; AU-6 to AU-8, AU-11, SI-4, IR-4, IR-6, IR-8 |
| IV. Governance and assurance | Contingency, supply chain, program management, privacy, training, and the authorization package | This book: Chapters 05–11 | CP, SR, PM, PT, AT; CA-2, CA-5, CA-6, CA-7; RA-3 |
| V. Training and certification | The academy: a compliance track and an implementation track over the same material, rubrics, certification and labs | Book 16, People: Training & Education; the training controls are Chapter 09 | No new closures; it produces the training evidence AT-2 and AT-3 rely on |
| VI. Implementation | The architecture as code: landing zone and network, identity and access, detection, response, data protection, baselines, the evidence pipeline and test harnesses | Book 10 (landing zone as code), Book 04 (access as code), Book 12 (detection, response, data protection, baselines), Book 15 (evidence pipeline and test harnesses) | No new closures; it deploys the mechanisms the architecture volumes claim (CM-2, CM-3, CM-6, CM-7, AC, IA, AU-6, SI-4, IR-4, CA-5, CA-7) |
| VII. Automation | The coordination layer: drift routed to an owner, change gated by approval, evidence rolled into the package, across Microsoft 365, Azure, AWS and VMware | Book 15, Compliance Automation & Day-2 Operations; Microsoft 365 automation in Book 15, Chapter 08; attestation and native access governance in Book 04 | No new closures; it operates CM-3, CM-6, CM-8, AC-2, RA-5, SI-2, CA-2, CA-5, CA-7 |
| VIII. Multi-cloud DNS, DHCP and IPAM | The naming plane built cloud by cloud, with a governed front door for change | Book 08 | SC-20, SC-22, CM-8, CM-3, AU-2, and CM-5 for separation of duties over naming changes |
| IX. Day-2 operations | The governed catalog: help desk requests, the landing zone front door, application registration, telephony, SaaS integration and identity governance | Book 15; front door in Book 10; application registration and identity governance in Book 04 | No new closures; it re-expresses AC-2, AC-5, AC-6, IA-4, IA-5, CM-2, CM-3, CM-8, SA-9, CA-3, AU-2 as governed requests |
| X. Governance platform integration | How the series’ evidence lands on a governance platform, and why that binding is optional | Book 13 | No new closures; it routes and explains |
Book 17, AI Identity Governance, and Book 18, Application Modernization, have no volume behind them; their material is new.
Where the full volumes still are
Some of the volumes outside this book stay in the repository as files. Each of those is a complete document with its own control tables, runbooks and scripts, written before the books were built; where a book and a volume disagree, the book is the later, footnoted text. Links to the repository go to those files. The rest, all of Volume V and parts of Volumes VI, VII and IX, were replaced by chapters of Books 15 and 16, and their links go to the chapters.
The repository volumes predate the re-verification the books went through, and some of their dates and directive descriptions are stale. Two examples matter for compliance. They describe the agency’s evidence as feeding “the FedRAMP 20x KSI pipeline,” but FedRAMP’s 2026 Key Security Indicators bind cloud providers, not agencies (Book 13, Chapter 11). And some describe BOD 26-04 as an SBOM directive, which it isn’t (Chapter 11). Read a volume for its depth; check its federal facts against the book that carries it.
What the volumes depend on
The order a reader meets the volumes isn’t the order the estate needs them. The series makes two dependency claims, both the program’s design, that explain most of the map.
The naming and identity floor comes first. The foundation volume’s argument is that “you cannot inventory what you cannot name, authorize what you cannot identify,” and that without that floor the controls claimed in later volumes don’t degrade, they become impossible to evaluate. Authoritative asset identity from the naming plane is the join key the evidence contract runs on (Book 12, Chapter 02); the HR source of truth is what every account decision asserts (Book 03). The multi-cloud naming volume is read last only because it is the deepest implementation detail; in dependency order it sits near the root (Book 08).
Assurance comes last, and depends on everything. The governance and assurance volume, this book, turns technical evidence into an authorization. Its recurring point is that a well-configured control that can’t produce a signed, tested, machine-readable artifact is, from the assessor’s chair, an open finding. The package in Chapter 11 can only report what the earlier volumes made observable.
The build-and-run volumes sit across the others. Implementation deploys what the architecture volumes specify, automation operates it, day-2 operations governs the routine changes that otherwise erode it, and training makes people able to do all three. The series is explicit that these four volumes mostly re-express controls the architecture already closes rather than closing new ones; their necessity is that a closure nobody deploys, operates or evidences isn’t assessable.
What the first assessment will find
Before the program, the series expected an assessor to document a recognizable set of findings at a moderate-impact agency still running a perimeter-era estate. These are the program’s expectations from its own analysis, not a published audit list, and an agency’s own assessment will differ. They are worth knowing because each points at the book that closes it. Where a row names a book that differs from Appendix A, the row is the finding’s home and the appendix is the control’s: the finding is closed where its condition is fixed, and the control is closed where the appendix lists it.
| Expected finding | The condition behind it | Closed in |
|---|---|---|
| CM-8: component inventory incomplete | Inventory assembled per environment, by hand or by periodic scan; new workloads missed until the next scan | Book 08 for the naming and addressing records; Book 12, Chapter 02; the control as a whole is closed in Books 10 and 12 (Appendix A) |
| SC-20, SC-21: secure name resolution incomplete | Internal zones unsigned; no consistent validation across environments | Book 08 |
| SC-7: no DNS-layer boundary control | Command-and-control and exfiltration domains resolvable through the standard resolver | Book 08 for the DNS-layer control; the control as a whole is closed in Books 09 and 12 (Appendix A) |
| AU-2, AU-12: naming and addressing events not in the SIEM | DNS and DHCP logs per environment, in different formats, or not collected | Books 08 and 12 |
| IA-9, SC-8: certificate-to-host binding undocumented | Workload certificates issued by hand and not tied to the inventory | Book 07 for the certificate binding; Appendix A lists IA-9 in Book 06, where it is partly closed, and SC-8 in Book 09, where it is closed (Appendix A) |
| SC-8: no network-layer encryption on direct internet circuits | Confidentiality depends on each application negotiating TLS | Book 09 |
| AC-4, SC-7, SI-3: no application-layer inspection on direct internet paths | Traffic controlled by address and port only | Book 09 |
| AU-12: session records incomplete | Flow logs without user, device, application or action | Book 09 |
| IA-2: legacy authentication events hard to attribute | NTLM fallback that doesn’t produce attributable, queryable sign-in records | Books 02 and 06 |
| IA-5, CM-8: database credentials and estate undocumented | Stored SQL logins, no central rotation, instances not fully enumerated | Book 06 |
The source added that under FedRAMP’s 2026 rules an open finding would no longer carry a remediation deadline but a continuous-evidence requirement. That is wrong for an agency. FedRAMP’s rules bind providers; the agency’s plan of action and milestones is governed by CA-5, with milestones and scheduled completion dates, and its remediation clocks for known exploited vulnerabilities come from BOD 26-04 (Chapter 11; Book 12, Chapter 06). What is true is that continuous evidence is how the agency shows a finding stayed closed.
The residual risk after the whole program
Build every volume on the map and the agency still carries risk. The series is candid about this, and so is this book. The authorizing official needs to see the remainder, because they are the only person who can accept it: SP 800-37 says the explicit acceptance of risk “cannot be delegated.”1
The remainder falls into six kinds.
- Self-assessment until it is independently assessed. The program’s automated verdicts are the system’s own team grading its own work. CA-2(1) and CA-7(1), both in the NIST Moderate baseline, ask for independent assessors.2 Until an independent assessment confirms them, every verdict is advisory, however reproducible (Chapter 11).
- What automation can’t see. SP 800-37 notes that automated tools may “not generate information for every control or every part of a control,” and that manual assessments then fill the gaps at frequencies the organization sets.3 Policies, plans, training effectiveness and physical protections are in this category. The program’s coverage report separates proven claims from asserted ones so the gap is visible (Book 13, Chapter 12).
- Risk inherited from providers. Where the system runs on a certified cloud service, controls such as physical and environmental protection are the provider’s, and the agency’s assurance is the provider’s certification plus the agency’s review of each quarterly report. FedRAMP requires agencies to review each Ongoing Certification Report and to notify FedRAMP when one raises a concern serious enough that the authorizing official would likely rescind the authorization.45 Where a cloud capability the design assumed isn’t in the authorized boundary, the gap is the agency’s (Book 10). On premises, the agency owns the physical controls itself.
- Evidence that stops arriving. A mechanism that emits nothing is invisible, and the package reflects only the evidence present (Book 12, Chapter 12). The program treats a silent required source as a monitoring failure, not a pass, but a source nobody knew to require is still a blind spot.
- Risks outside control evaluation. The source volume named four: mission risk from a system’s failure; insider threat, which needs HR and behavioral programs as well as technical controls; physical security; and supply chain risk beyond what a software inventory can show, such as a supplier’s ownership or location. A control set that passes assessment doesn’t measure any of them. The agency’s risk management strategy and its supply chain program (Chapter 07) do.
- Design not yet built, and vendor features not yet delivered. Parts of the program are designed but not built: governance across agencies’ own estates, and generating complete OSCAL security plans for every consuming agency of a shared service (Book 13, Chapter 11). And a vendor roadmap is not a commitment: a control that depends on a feature the vendor has announced but not shipped in the authorized boundary is open until the feature is there (Chapter 04).
Two more belong to the people rather than the technology. The program’s own rule set covers only part of FedRAMP’s indicator surface, so a clean run against it is a statement about the rule set, not about full coverage. And every mechanism on the map depends on people who can build, run and evidence it; that is the subject of Book 16, and of Chapter 09 for the controls.
None of this argues against the program. It argues for writing the remainder down. A package that lists what is proven, what is asserted, what is inherited and what is accepted gives the authorizing official a risk they can see. A package that reports a single green score hides the same risk and makes it theirs anyway.
What changes, in one table
| Old habit | What replaces it |
|---|---|
| Eleven volumes read front to back | A map from each control and volume to the book that carries it now |
| A volume’s control count stands for coverage | Families per volume, with the per-control index in Appendix A and closure judged by Chapter 04’s rule |
| The volumes are the current word on federal facts | The books are; the volumes keep their depth but some of their dates and directive descriptions are stale |
| Volumes read in reading order | The naming and identity floor first; assurance last; build-and-run across all of them |
| A clean self-assessment means the risk is gone | Six kinds of residual risk remain, written down for the authorizing official to accept or not |
National Institute of Standards and Technology, SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, December 2018, Task R-4 (risk acceptance can’t be delegated) and Appendix F (ongoing authorization, limits of automated tools), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf (accessed Oct 21, 2026).↩︎
National Institute of Standards and Technology, SP 800-53 Rev. 5, controls CA-2(1) and CA-7(1), read from the release 5.2.0 OSCAL catalog, https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json; baseline membership from the release 5.2.0 SP 800-53B Moderate baseline profile, https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_MODERATE-baseline_profile.json (both accessed Oct 21, 2026).↩︎
National Institute of Standards and Technology, SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, December 2018, Task R-4 (risk acceptance can’t be delegated) and Appendix F (ongoing authorization, limits of automated tools), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf (accessed Oct 21, 2026).↩︎
FedRAMP, “Collaborative Continuous Monitoring,” FedRAMP Consolidated Rules for 2026, rules CCM-AGM-ROR and CCM-OCR-AVL, https://www.fedramp.gov/2026/reference/collaborative-continuous-monitoring/ (accessed Oct 21, 2026).↩︎
FedRAMP, “Agency Use” rules, FedRAMP Consolidated Rules for 2026, rule AGU-USE-NFC (Notify FedRAMP of Monitoring Concerns), https://www.fedramp.gov/2026/agencies/rules/agency-use/ (accessed Oct 21, 2026).↩︎