Index
The advanced tier is where the three frameworks converge most densely — and where the mapping work pays off most. Every page you build here serves three simultaneous purposes: NIST 800-171 SSP content, ISO 27001 Annex A implementation evidence, and DEFSTAN Profile 2 technical compliance. Build it once, reference it everywhere.
Let me start with an interactive family-by-family breakdown you can navigate, then give you the complete Confluence page architecture.
Click any family card to see its controls, ISO 27001 Annex A mappings, DEFSTAN profile assignment, and CMMC Level 1 indicators. The "Build Confluence page" button on each card will generate the full procedure content for that family. Below is the complete architecture for how to structure section 03 in Confluence.
How the three frameworks align — the structural logic
Before building pages, it helps to understand the mapping geometry. NIST 800-171 and ISO 27001 Annex A are not parallel lists — they overlap heavily in the technological and organisational control groups but diverge significantly in scope and intent. DEFSTAN 05-138 is a third overlay that draws from both.
NIST 800-171 is purpose-built for CUI protection in non-federal systems. Its 110 controls across 14 families are all mandatory — there is no applicability decision. Every control either applies to your system or requires a compensating control documented in the SSP. ISO 27001 Annex A is broader and more flexible — 93 controls across four groups, but only the ones you declare applicable in the SoA need to be implemented. DEFSTAN 05-138 Profile 2 sits closest to NIST 800-171 in technical depth, drawing on the same underlying NCSC and NIST guidance, which is why the cross-mapping between them is tighter than the mapping between DEFSTAN and ISO 27001.
The practical implication for Confluence: each family page must carry all three framework perspectives simultaneously, because a C3PAO assessor reading it for CMMC, an ISO 27001 auditor reading it for Annex A, and a DEFSTAN assessor reading it for Profile 2 compliance will all reach the same page and need to see what they are looking for without navigating elsewhere.
Section 03 · Advanced controls — the complete Confluence page architecture
The section sits under a parent page restricted to isms-it-staff and isms-security via Confluence page-level restrictions (not SCM macros — see the IT staff content response for why this matters). The parent page contains the navigation structure and the System Security Plan.
03 · Advanced controls
│
├── AT-SSP · System Security Plan (master document)
├── AT-SoA · Statement of Applicability cross-reference
├── AT-MAP · Three-way control mapping (NIST ↔ ISO 27001 ↔ DEFSTAN)
│
├── AT-AC · Access Control [22 controls]
├── AT-AT · Awareness and Training [3 controls]
├── AT-AU · Audit and Accountability [9 controls]
├── AT-CM · Configuration Management [9 controls]
├── AT-IA · Identification and Auth [11 controls]
├── AT-IR · Incident Response [3 controls]
├── AT-MA · Maintenance [6 controls]
├── AT-MP · Media Protection [9 controls]
├── AT-PE · Physical Protection [6 controls]
├── AT-PS · Personnel Security [2 controls]
├── AT-RA · Risk Assessment [3 controls]
├── AT-CA · Security Assessment [4 controls]
├── AT-SC · Sys & Comms Protection [16 controls]
│ ├── AT-SC-BDY · Boundary protection
│ ├── AT-SC-ENC · Encryption and key management
│ └── AT-SC-ARC · Architecture and design
└── AT-SI · Sys & Info Integrity [7 controls]
The AT-SC family is the only one that warrants sub-pages — at 16 controls covering network architecture, encryption, key management, DLP, and mobile code, a single page becomes unmanageable. Split it into three focused sub-pages and keep the parent as a summary and navigation index.
The standard page template for every family
Every family page follows the same seven-section structure. This consistency is what allows an assessor to navigate the space without a guide, and what allows the CISO to maintain it without relearning the layout each time.
Section 1 — Family summary table. A properties table at the top: NIST family abbreviation, full name, control count, CMMC Level 1 practices in this family (linked), ISO 27001 Annex A controls implemented here (linked), DEFSTAN 05-138 profile (P1 or P2 or both), Confluence page owner (role), last reviewed date, next review date. This table is what populates the SSP's system description section — it is the navigational metadata.
Section 2 — Control implementation summary. A master table with one row per control: control ID, control title (verbatim from NIST SP 800-171 Rev 2), implementation status (Implemented / Partially Implemented / Planned — the three statuses used in the SSP), ISO 27001 Annex A cross-reference, DEFSTAN reference, and a link to the evidence record in section 06. This table is the SSP content for this family. The CISO and assessor use this table; the engineer reads section 3 for the procedure.
Section 3 — Technical implementation procedure. The operational procedure for each control, written for the engineer who has to implement it. Organised by control ID, each entry contains: what the control requires (the assessment objective from NIST SP 800-171A — the companion assessment procedures document); how your organisation implements it (the specific technology, configuration, and process — this is the SSP implementation description); configuration settings where applicable (specific values, not general descriptions — "BitLocker with AES-256, TPM 2.0 required, recovery key escrowed to Azure AD" not "encrypt hard drives"); and the NIST SP 800-171A assessment method (examine, interview, or test — this tells the engineer exactly what a C3PAO assessor will do to verify compliance).
Section 4 — ISO 27001 Annex A implementation notes. For each ISO 27001 Annex A control mapped to this family, a brief note confirming how the NIST implementation satisfies the Annex A requirement, and whether any additional Annex A-specific action is needed beyond what NIST requires. In most cases the NIST implementation is more prescriptive than Annex A — implementing NIST satisfies the equivalent Annex A control automatically. Where ISO 27001 requires something NIST does not (typically in the organisational and people control groups), flag it explicitly so the Annex A auditor can find the supplementary evidence.
Section 5 — DEFSTAN 05-138 mapping. A brief section indicating whether this family maps to Profile 1, Profile 2, or both. For Profile 1 controls, confirm that the Fundamental tier page (FC-01 through FC-07) carries the all-staff visible implementation — the Advanced tier page carries the technical procedure that makes it work. For Profile 2 controls, note any DEFSTAN-specific nuances where the standard diverges from NIST 800-171 (typically around approved cryptographic algorithms, personnel clearance levels, or incident notification obligations to the MOD).
Section 6 — Evidence requirements. A table listing every evidence item this family generates: evidence ID (cross-referenced to the main audit evidence register), evidence type, required frequency, Confluence location, and the name of the person responsible for generating it. This is the operational link between the control specification and the evidence register — it tells the engineer not just what to implement but what records to produce.
Section 7 — Assessment checklist. A short checklist derived from NIST SP 800-171A's examine, interview, and test objectives. Framed as "what a C3PAO assessor will check" — this is the most valuable section for audit preparation. For each control, three to five bullet points describing what the assessor will look at, who they will ask, and what they will test. Engineers who have read this section before an assessment know exactly what to prepare and can brief their colleagues accordingly.
DEFSTAN 05-138 Profile 1 vs Profile 2 — the precise boundary
The distinction between Profile 1 and Profile 2 in DEFSTAN 05-138 maps closely but not perfectly to the Fundamental/Advanced tier split in your Confluence space. Understanding the boundary prevents both over-engineering (building Profile 2 controls into your Fundamental tier pages) and under-engineering (assuming Profile 1 is just Cyber Essentials).
Profile 1 is the DEFSTAN minimum. It requires: Cyber Essentials (all five domains, self-assessed); a documented information security policy signed by senior management; a named security point of contact; an incident reporting procedure with notification to the MOD/NCSC; and basic personnel security (BPSS or equivalent for personnel with access to OFFICIAL information). Everything in your Fundamental tier (FC-01 through FC-07) satisfies Profile 1. The policies in section 01 and the governance records in section 06 complete it.
Profile 2 is where DEFSTAN aligns with NIST 800-171. It requires: Cyber Essentials Plus (independently assessed); a full risk assessment process; technical security architecture documentation; privileged access management; audit logging and monitoring; network segmentation; encrypted communications for sensitive data; supply chain security controls; business continuity planning; and personnel security commensurate with the data sensitivity (which for SECRET-adjacent information may require SC or DV clearance levels, not just BPSS). This is the content that lives in section 03 of your Confluence space.
The nuances where DEFSTAN Profile 2 diverges from NIST 800-171 are worth flagging explicitly on the relevant family pages:
On the AT-SC page: DEFSTAN specifies NCSC-approved cryptographic products for certain defence applications — not just FIPS-validated, but products on the NCSC Commercial Product Assurance (CPA) or CAPS approved product list. For CUI under US contracts, FIPS 140-2/3 is sufficient. For UK OFFICIAL-SENSITIVE under DEFSTAN, confirm with your MOD point of contact whether CPA-approved products are required for your specific application.
On the AT-AU page: DEFSTAN Profile 2 expects audit log retention aligned to the sensitivity of the data — for OFFICIAL-SENSITIVE, the NCSC guidance suggests a minimum of 12 months online and 3 years archived. The NIST 800-171 requirement does not specify a retention period, leaving it to the system security plan. Set your Confluence policy to the more demanding DEFSTAN guidance.
On the AT-IR page: DEFSTAN contracts typically include a specific incident notification obligation to the contracting authority (the MOD or prime contractor) within 24 hours of discovery, alongside the NCSC notification. NIST 800-171 3.6.2 requires incident reporting but targets the organisational reporting chain. The DEFSTAN obligation is an external reporting requirement to a government customer — document it explicitly in the IR procedure so it is not missed in the 72-hour pressure of an actual incident.
The System Security Plan — the master document
The SSP at AT-SSP is the document that a CMMC Level 2 C3PAO assessor reads before doing anything else. It is not a policy document — it is a technical description of your information system, its CUI flows, and how every one of the 110 NIST controls is implemented. The Confluence page architecture you are building is the source material that populates the SSP — which is why the family pages must be kept current.
The SSP Confluence page should contain or link to: system name and purpose; system boundary description (what is in scope, what is explicitly out of scope); network architecture overview (a diagram showing the system boundary, CUI flows, external connections, and key components — this is one of the few cases where a network diagram belongs in the ISMS documentation); CUI categories processed by the system (from the National Archives CUI Registry — specific category codes, not generic descriptions); user population description; interconnected systems and agreements; and the implementation status table for all 110 controls (which is assembled from the individual family pages).
The POA&M lives as a child page of AT-CA (Security Assessment, control 3.12.2). Every control that is "Partially Implemented" or "Planned" in the SSP must have a corresponding POA&M entry. A clean SSP with accurate implementation statuses and a current POA&M showing active remediation is the single most effective preparation for a CMMC Level 2 assessment.
Build order — which family pages to prioritise
Not all 14 families are equally urgent to build. The priority order is determined by three factors: control count (more controls = more SSP content needed), CMMC Level 1 presence (these are already partially documented in the Fundamental tier and must be extended, not duplicated), and assessment frequency (families that assessors spend the most time on).
Build in this sequence:
AT-AC first — 22 controls, 4 CMMC Level 1 practices, highest evidence burden, first thing a C3PAO assessor examines. The access control family establishes whether the organisation has a coherent identity and access model. Without it the rest of the SSP lacks a foundation.
AT-SC second — 16 controls including the FIPS encryption requirements and network architecture. The boundary protection and encryption controls are the technical backbone of CUI protection. Split into the three sub-pages from the start.
AT-AU third — 9 controls covering logging and monitoring. This family is consistently weak in first-time assessments because organisations have SIEM tools but insufficient evidence that the tools are actively monitored. The monthly log review records are the gap that AT-AU closes.
AT-CM fourth — 9 controls. Baseline configuration and change management. The hardened baselines (already documented in FC-02 for the Fundamental tier) need to be extended here with the full NIST 3.4.x compliance specifications.
AT-SI fifth — 7 controls, 4 CMMC Level 1 practices. The SI family bridges the Fundamental and Advanced tiers — the Level 1 practices (AV and patching) already have Fundamental tier pages, but the advanced controls (IDS/IPS monitoring at 3.14.6, anomalous usage detection at 3.14.7) require additional infrastructure and evidence that the Fundamental tier does not address.
AT-IA sixth — 11 controls covering authentication. MFA configuration for privileged accounts (3.5.3) and FIPS-validated cryptographic modules for authentication (3.5.10) are the two controls most commonly cited in CMMC findings. Build this page before your first external assessment.
The remaining eight families (AT-AT, AT-IR, AT-MA, AT-MP, AT-PE, AT-PS, AT-RA, AT-CA) can be built in any order after the first six. They are operationally important but are less frequently the source of major findings in first-time CMMC assessments, largely because their evidence requirements are more straightforward (training records, physical access logs, destruction certificates, risk assessment reports).
Now let me produce the downloadable advanced tier mapping workbook — the authoritative cross-reference for all 110 controls.The workbook has four sheets, colour-coded by control family throughout:
Advanced Tier Mapping — all 110 NIST SP 800-171 Rev 2 controls in family order, each with CMMC Level 1 indicator (teal), ISO 27001:2022 Annex A cross-reference (blue), DEFSTAN 05-138 profile (P1/P2), Confluence page assignment, current implementation status (green/amber/red), evidence IDs from the audit evidence register, and assessor focus notes drawn from NIST SP 800-171A.
Family Summary — one row per family with control counts, CMMC Level 1 practice list, key Annex A controls, DEFSTAN profile, Confluence page name, and the recommended build priority (AC first, SC second, AU third — as argued above).
SSP Status Tracker — the operational view for maintaining your System Security Plan. Each of the 110 controls has an implementation status you update as work progresses, a POA&M flag (automatically Y for anything not fully implemented), and the NIST SP 800-171A assessment method (Examine, Interview, or Test) so engineers know exactly how a C3PAO assessor will verify each control.
How to Use — including a note on NIST SP 800-171 Rev 3 (published May 2024, which restructures some controls) — worth checking against your specific contract requirements to confirm whether Rev 2 or Rev 3 applies.
The one mapping insight that saves the most assessment time
Across all 110 controls and three frameworks, the single most useful pattern to communicate to your technical team is this: where NIST 800-171 has a control, implementing it correctly almost always satisfies the corresponding ISO 27001 Annex A control simultaneously. The reverse is not true — ISO 27001 Annex A is applicability-based and does not require the level of technical specificity that NIST demands.
This means your engineers only need to ask one question when building a procedure: "does this satisfy the NIST 800-171 assessment objective?" If the answer is yes, the Annex A control is covered as a consequence. The only exception is the ISO 27001 organisational and people control groups (Annex A 5.x and 6.x) — these have governance and HR obligations that NIST does not address as prescriptively. For those, the policy pages in section 01 and the HR security content in the all-staff and management variants carry the weight.