3.12 CA

718 paragraphs across ten sections. This is the final page of the NIST 800-171 family library. Here is the design rationale and the things about this page that make it structurally different from every other family page.

Why AT-CA is the keystone

Every other family page in this library exists in isolation — AT-AU describes the SIEM, AT-CM describes the baselines, AT-IR describes the incident response plan. AT-CA is the page that makes them a programme rather than a collection of procedures. It does four things no other page does.

It defines the system boundary — the explicit list of what is and is not in CUI scope. Without a defined boundary, every other control's scope is ambiguous. The assessor's first question is always "what is in scope?" and AT-CA must answer it precisely.

It provides the master cross-reference — Section 3C is a 14-row table mapping every control family to its Confluence page, its primary evidence items, and its current SoA implementation status. This is the navigation aid an assessor uses to move from the SSP to any specific control family in under 30 seconds. It is also the CISO's dashboard for the entire programme — one table that shows the compliance posture at a glance.

It holds the POA&M — the register of known deficiencies. An assessor who finds AT-CA's POA&M well-populated and actively managed will have significantly more confidence in the programme than an assessor who finds a zero-item POA&M or one with dormant entries. A functioning POA&M is evidence of a mature compliance programme; its absence is evidence that deficiencies exist but are not being acknowledged.

It documents the continuous monitoring plan — Section 6 maps 18 monitoring activities across all control families, with evidence IDs, frequencies, owners, and what each feeds into. This is what 3.12.3 actually requires: not just that monitoring happens, but that it is planned, assigned, scheduled, and connected to the corrective action process when it detects a problem.

The gold banner at the top of the document — "KEYSTONE DOCUMENT — Read this page before any other family page" — is a deliberate departure from the house style of the other 13 pages. It exists because an assessor who starts with AT-AC (Access Control) rather than AT-CA will struggle to interpret what they see. The system boundary is in AT-CA. The SoA is in AT-CA. The POA&M is in AT-CA. The evidence register structure that all other pages reference is defined here. The keystone banner signals to the CISO preparing for an assessment that this page must be current before anything else matters.

The 30-day update requirement in the banner is the operationally critical commitment: if a new cloud environment is brought into CUI scope, the SSP boundary must be updated within 30 days. If the SIEM is replaced, AT-AU and AT-CA must be updated within 30 days. If a control status changes (a POA&M item is closed), the SoA must be updated within 30 days. The 30-day window is tight enough to keep the SSP current without being so immediate that every routine change triggers a formal document update.

The zero-item POA&M problem

Common finding five directly addresses an assessment pattern that appears counterintuitive: an organisation with zero POA&M items being treated as a red flag rather than a green one. The logic is sound. No organisation implementing 110 controls across complex IT infrastructure has genuinely perfect compliance at any given moment. A configuration drifts. A patch falls behind SLA. A new system is deployed without going through the full JML process.

An organisation that honestly self-assesses will find these gaps and put them in the POA&M. An organisation that either does not self-assess or chooses not to document what it finds will have a zero-item POA&M. The assessor cannot distinguish between the two interpretations just by looking at the POA&M — but when testing begins and findings emerge, the interpretation becomes clear. Proactively putting a small number of well-managed items in the POA&M before an external assessment is the correct approach. It signals a functioning programme.

The SSP-as-Confluence-space architecture

The implementation description for 3.12.4 makes the architecture explicit: the SSP is not a single PDF — it is the Confluence space itself, with the AT-CA page as the master section and the AT-[family] pages as the control implementation sections. This architecture has significant practical advantages over a traditional single-document SSP.

Engineers and system owners can update their sections independently, using Confluence's native version control rather than a document management system. The evidence items are linked directly from the implementation sections. The assessor can navigate from the SoA to any specific control implementation in seconds rather than searching through a 300-page PDF. And critically, it is easier to keep current — updating AT-MA to reflect a new vendor maintenance arrangement is a Confluence page edit, not a Word document revision requiring re-approval.

For external assessments where a PDF is needed, Confluence provides a structured PDF export. The CISO produces the SSP export at assessment time from the current state of the space, meaning the PDF always reflects the live implementation rather than a snapshot taken at a previous point. This export is what becomes EV-E05 for the assessment record.

The continuous monitoring plan as programme architecture

Section 6 (the continuous monitoring plan) is the most architecturally significant table in the document because it is where 3.12.3 is operationalised across all 14 families simultaneously. The 18 monitoring activities are distributed across all control families — EV-F01 through F07 are the SIEM and security operations activities; EV-D01, D02, D05, D06, D07, D20, D23, and D29 are the quarterly technical verifications; and EV-B05 and EV-A04 are the management-level programme activities.

The "Feed into" column is the design detail that turns the table from a schedule into a programme. Each monitoring activity has a documented consequence: if the monthly MFA coverage report (EV-D05) finds an unenrolled account, the consequence is "immediate remediation for admin accounts." If the monthly vulnerability scan (EV-D06) finds scan gaps, the consequence is "POA&M for scan gaps." If the monthly SIEM log review (EV-F01) detects a control gap, the consequence is "POA&M if gap detected." Without this column, monitoring activities are performed but their findings disappear rather than flowing into the corrective action programme.

The complete NIST 800-171 family library

All 14 family pages are now complete. Here is the final library with all outputs in /mnt/user-data/outputs/:

Document	Controls	CMMC L1	Paragraphs
AT-AC · Access Control	22	4	~1,020
AT-AT · Awareness and Training	3	0	~489
AT-AU · Audit and Accountability	9	0	797
AT-CA · Security Assessment	4	0	718
AT-CM · Configuration Management	9	0	1,064
AT-IA · Identification and Authentication	11	2	727
AT-IR · Incident Response	3	0	629
AT-MA · Maintenance	6	0	639
AT-MP · Media Protection	9	1	788
AT-PE · Physical Protection	6	4	735
AT-PS · Personnel Security	2	0	501
AT-RA · Risk Assessment	3	0	635
AT-SC · System and Comms Protection	16	2	~1,256
AT-SI · System and Info Integrity	7	4	730

110 controls · 17 CMMC Level 1 practices · 14 families · complete. Together with the four Excel workbooks produced earlier in this project (cross-framework control mapping, audit evidence register, supplier security pack, and advanced tier control mapping), this Confluence ISMS space provides a complete operational implementation reference for NIST SP 800-171 Rev 2 compliance across ISO 27001:2022 and DEFSTAN 05-138 frameworks.