99.1 Governance Wrapper
This is one of the most useful conceptual framings in compliance architecture, and it is frequently missed by organisations that implement ISO 27001 and NIST 800-171 as separate programmes running in parallel rather than as a single integrated system.
The fundamental distinction: clauses vs Annex A
ISO 27001 has two distinct parts that serve entirely different purposes, and conflating them is the source of most audit failures.
Annex A (the 93 controls in the 2022 edition) is the control catalogue — the list of technical and procedural safeguards. This is where the NIST 800-171 mapping lives, where AT-AC through AT-CA sit, where the SIEM and the baseline configurations and the media sanitisation procedures all reside. Annex A answers the question "what security controls do you have?"
Clauses 4 through 10 are the management system requirements — the organisational governance structure that decides which Annex A controls are needed, verifies they are working, and drives improvement when they are not. Clauses 4 through 10 answer the question "how do you know your security controls are appropriate and effective?"
The key insight is that you can implement every single one of the 93 Annex A controls and still fail an ISO 27001 audit if clauses 4 through 10 are not functioning. Conversely, an organisation with a genuinely functioning management system (clauses 4 through 10) that honestly identifies gaps will get further in an audit than an organisation with technically complete controls but no governance around them. The management system is the engine; Annex A is the output.
Clause 4 — Context of the organisation
Clause 4 establishes why the ISMS exists and for whom. It has three operational components.
4.1 — Understanding the organisation and its context requires identifying the internal and external factors that affect the ability to achieve the intended outcomes of the ISMS. For a UK defence supplier, the internal factors include the organisation's risk appetite, IT maturity, staff capability, and the existing control landscape. The external factors include the regulatory environment (UK GDPR, DFARS, DEFSTAN), the threat landscape (NCSC reporting, CISA KEV), customer and contracting authority expectations, and the supply chain risks introduced by third parties. This is where the threat intelligence input to the AT-RA risk assessment formally begins — 4.1 is the mandate for AT-RA 3.11.1 to use current threat intelligence.
4.2 — Understanding the needs and expectations of interested parties identifies who has a stake in the ISMS and what they require from it. For a multi-framework organisation the interested parties include the MOD contracting authority (DEFSTAN requirements), US government customers (DFARS/CMMC), the ICO (UK GDPR), the NCSC (cyber resilience expectations), the board (risk governance), insurance underwriters (cyber policy conditions), and customers who share CUI. Documenting these stakeholders and their requirements is what gives you the evidence base for why your ISMS has the scope it has, and why you maintain certain controls that might otherwise appear disproportionate to your size.
4.3 — Determining the scope defines the boundary of the ISMS — which organisational units, locations, systems, and processes are covered. This is the direct precursor to the SSP system boundary description in AT-CA Section 3B. In practice, 4.3 and the SSP boundary should be the same document, or at minimum should be consistent. An ISO 27001 auditor who finds the ISMS scope excludes systems that are clearly CUI-scope will raise a finding. The scope must be honest and complete.
4.4 — ISMS simply requires that the organisation establishes, implements, maintains, and continually improves an ISMS in accordance with the standard. This is the commitment clause — it is what the certification body is certifying. Everything else in clauses 4 through 10 elaborates on what "establishes, implements, maintains, and continually improves" means in practice.
The connection to NIST 800-171 is that clause 4 provides the justification layer that NIST lacks. NIST 800-171 tells you what controls to implement. Clause 4 tells you why those specific controls are appropriate for your specific context — your business, your threats, your stakeholders, your boundary. When a C3PAO asks "why do you have this control?" the answer lives in clause 4.
Clause 5 — Leadership
Clause 5 addresses the single most common root cause of ISMS failure: leadership treating information security as an IT department problem rather than an organisational governance matter.
5.1 — Leadership and commitment requires that top management demonstrates active engagement with the ISMS — not delegation. Specifically: ensuring the ISMS objectives are aligned with the organisational strategic direction; ensuring adequate resources are available; communicating the importance of information security; supporting other managers in demonstrating leadership in their areas; and promoting continual improvement. The evidence an auditor looks for is management review minutes (EV-A01) showing board-level engagement with security findings, resource decisions in response to assessment findings, and strategic direction statements that connect business objectives to security requirements.
The practical implication for a CMMC-preparing organisation is that the CISO cannot be the only person who understands why the controls exist. The CEO must understand that DFARS requires 72-hour reporting and that the organisation is contractually obligated to meet it. The CFO must understand that POA&M remediation items require budget. The HR Director must understand that the leaver de-provisioning checklist (AT-PS Section 4) is a compliance requirement, not an IT nicety.
5.2 — Policy requires that top management establishes an information security policy that sets direction, includes commitments to satisfy applicable requirements and to continual improvement, and is communicated within the organisation. The policy is the governance document that sits above all the operational procedures — AT-AC, AT-MA, AT-PS, and every other family page is implementing the policy. If the policy does not exist, nothing below it has a governance anchor.
5.3 — Organisational roles, responsibilities, and authorities requires that responsibilities for ISMS roles are assigned and communicated. This is the mandate for the named CISO, the IT Manager role, the HR Manager's role in AT-PS, the Facilities Manager's role in AT-PE, and the Security Analyst role in AT-AU and AT-RA. DEFSTAN requires a named CISO explicitly. NIST 800-171 implies role clarity through the "personnel with [responsibility] responsibilities" language in every 800-171A assessment procedure. Clause 5.3 is where that role structure is formally documented and owned.
Clause 6 — Planning
Clause 6 is the risk-intelligence layer — it is where the risk assessment methodology connects to the control selection process.
6.1 — Actions to address risks and opportunities has two sub-clauses that are the most important planning activities in the entire standard.
6.1.2 (risk assessment process) requires a documented, repeatable risk assessment methodology that identifies and analyses risks and determines risk levels. This is not advisory — it is mandatory. An organisation that selects security controls without a documented risk assessment methodology cannot claim ISO 27001 conformity, regardless of how good its controls are. The AT-RA page satisfies 6.1.2: the 5×5 likelihood × impact matrix, the nine-phase annual assessment procedure, the risk register structure, and the threat intelligence requirement are the clause 6.1.2 risk assessment process.
6.1.3 (risk treatment) requires that risk treatment options are selected, the Annex A controls needed are determined (referencing a Statement of Applicability), a risk treatment plan is produced, and residual risk is accepted by risk owners. This is the formal mandate for the Statement of Applicability (EV-E01 in AT-CA). The SoA is not a NIST 800-171 requirement — it is an ISO 27001 clause 6.1.3 requirement. Its value is that it forces the organisation to make an explicit, documented decision about every Annex A control: why is it included, or why is it excluded? Controls that are excluded without justification are a finding.
The connection to CMMC is that the CMMC SoA (which covers 110 NIST controls) and the ISO 27001 SoA (which covers 93 Annex A controls) should be read together. Where the control sets overlap — and they overlap substantially for the 13 families outside CA — a single SoA entry can satisfy both frameworks simultaneously.
6.2 — Information security objectives requires that measurable objectives are established, that plans exist to achieve them, and that those plans are reviewed. This is where the security metrics programme (EV-F02) gets its governance mandate: the metrics must connect to defined objectives. "Patch all Critical vulnerabilities within 7 days" is a security objective. The patch compliance rate in the monthly metrics report is the measurement of whether it is being achieved. The organisation cannot claim clause 6.2 conformity if it produces metrics that do not connect to stated objectives.
Clause 7 — Support
Clause 7 is the enablement layer — the resources, competence, awareness, communication, and documentation that make the ISMS function.
7.1 — Resources requires that the organisation determines and provides the resources needed for the ISMS. This is the budget clause. It gives the CISO the governance basis to request the vulnerability scanner, the PAM platform, the SIEM, the pen test budget, the staff training budget, and the CMMC certification fees. Without clause 7.1, resource requests can be treated as discretionary IT spending. With it, they are obligations flowing from a management commitment.
7.2 — Competence requires that personnel doing ISMS-relevant work are competent — and that competence is evidenced. This is EV-A08 (ISMS role competency records in AT-CA). For the CISO it means evidencing appropriate security qualifications (CISSP, CISM, ISO 27001 Lead Auditor, or equivalent experience). For IT Operations engineers maintaining the baselines, it means evidencing training on the specific platforms. For the HR Manager executing the leaver checklist, it means evidencing awareness training that includes the security obligations of the process.
7.3 — Awareness requires that people working under the organisation's control are aware of: the information security policy; their contribution to ISMS effectiveness; and the implications of non-conformity. This is where AT-AT (Awareness and Training) sits — 3.2.1 through 3.2.3 are the NIST implementation of clause 7.3. The annual security awareness training (EV-B05), the role-specific training (EV-B06), and the phishing simulation programme (EV-B07) are all clause 7.3 evidence artefacts.
7.4 — Communication requires that the organisation determines what, when, with whom, and how to communicate on ISMS matters. For a CMMC-scope organisation this includes the internal communication of the AUP to all staff, the external communication of security requirements to suppliers (the supplier security pack), and the regulatory communication to the ICO and contracting authorities when an incident occurs. AT-IR Section 4 (external reporting procedures) is the clause 7.4 external communication plan for incident scenarios.
7.5 — Documented information is the documentation management clause. It requires that the ISMS documentation is created, controlled, and maintained — that it exists in a defined location, is accessible to those who need it, is protected from inappropriate modification, and is retained for defined periods. This entire Confluence ISMS space is the documented information system for clause 7.5. The version history on each AT-[family] page, the SCM audience variants, and the evidence filing structure (EV-A through EV-F) are all clause 7.5 controls.
Clause 8 — Operation
Clause 8 is the execution layer — where the planning from clause 6 becomes operational reality.
8.1 — Operational planning and control requires that the processes needed to meet ISMS requirements are planned, implemented, controlled, and reviewed. It also requires control of planned changes and review of the consequences of unintended changes. This is the mandate for the change management process in AT-CM 3.4.3 and 3.4.4 — the requirement to track and approve changes to CUI-scope systems, to assess security impact before implementation, and to review the consequences of unintended changes (including the SIEM alert for unexpected configuration changes).
8.2 — Information security risk assessments requires that risk assessments are performed at planned intervals and when significant changes occur. This is the AT-RA 3.11.1 annual assessment requirement with its update triggers — the 'periodically' in 3.11.1 is clause 8.2's planned intervals; the 'when new vulnerabilities are identified' is clause 8.2's significant changes. The two requirements are satisfied by the same process.
8.3 — Information security risk treatment requires that the risk treatment plan is implemented. This is the POA&M in AT-CA Section 4 — the mechanism by which risk treatment decisions translate into tracked corrective actions with owners and due dates.
Clause 8 is where the rubber meets the road. The risk assessment was planned in clause 6. The resources were secured in clause 7. Clause 8 is where the risk assessment actually happens, the vulnerability scanner actually runs, the patch gets applied within SLA, and the incident response team actually responds. Every AT-[family] page is a clause 8 operational control.
Clause 9 — Performance evaluation
Clause 9 is the measurement and review layer — the feedback loop that tells the organisation whether what it is doing in clause 8 is working.
9.1 — Monitoring, measurement, analysis, and evaluation requires that the organisation determines what needs to be monitored, what methods will be used, when analysis and evaluation will occur, and who will do it. This is the continuous monitoring plan in AT-CA Section 6 — 18 monitoring activities mapped to evidence items, frequencies, and owners. The monthly security metrics report (EV-F02) is the clause 9.1 monitoring output. The metrics must connect to objectives (clause 6.2) — the patch compliance rate connects to the patching SLA objective; the MFA coverage rate connects to the MFA deployment objective.
9.2 — Internal audit requires that internal audits are conducted at planned intervals to provide information on whether the ISMS conforms to requirements and is effectively implemented. The annual internal security control assessment programme (AT-CA Section 5) is the ISO 27001 internal audit programme. The assessment methodology — Examine, Interview, Test — mirrors exactly what ISO 27001 expects from an internal audit. The audit report (EV-A02) is the clause 9.2 output.
The distinction between clause 9.1 (monitoring) and clause 9.2 (audit) is worth making explicit because they serve different purposes. Monitoring is continuous and automated — the SIEM, the MDM compliance dashboard, the vulnerability scanner. Audit is periodic and independent — a structured review by someone assessing whether the controls are effective, not just running. AT-CA 3.12.3 maps to clause 9.1; AT-CA 3.12.1 maps to clause 9.2.
9.3 — Management review requires that top management reviews the ISMS at planned intervals — considering the results of monitoring, audits, risk assessments, and progress on objectives — and makes decisions. The management review (EV-A01) is the formal annual governance checkpoint. ISO 27001 specifies the minimum inputs and outputs. Inputs must include: the status of actions from previous reviews; changes in external and internal issues; feedback on security performance (from monitoring and audit); the extent to which objectives have been met; nonconformities and corrective actions; results of risk assessments; audit findings; and opportunities for improvement. Outputs must include decisions on improvement opportunities and resource needs. A management review that consists of a five-minute agenda item with no documented decisions does not satisfy clause 9.3.
Clause 10 — Improvement
Clause 10 is the adaptation layer — what changes when the evaluation in clause 9 reveals that something is not working.
10.1 — Continual improvement requires that the organisation continually improves the suitability, adequacy, and effectiveness of the ISMS. This is the meta-requirement — it is why the clauses form a cycle (Plan in 4-6, Do in 7-8, Check in 9, Act in 10) rather than a one-time implementation. An ISMS that is static — where the same controls are implemented year after year without review or improvement despite changes in the threat landscape, technology, or business — does not satisfy clause 10.1, even if it technically satisfies every Annex A control.
10.2 — Nonconformity and corrective action requires that when a nonconformity occurs, the organisation reacts to it, investigates the cause, determines whether similar nonconformities could occur elsewhere, takes action to eliminate the cause, reviews the effectiveness of that action, and updates risk information if necessary. This is the corrective action register (EV-A03 and EV-A04 in AT-CA). Every POA&M item is a documented nonconformity with a root cause and a corrective action. Every post-incident review (EV-D13 in AT-IR) is a clause 10.2 root cause analysis for a security incident. The lesson learned in the exercise report (EV-D15) that triggers an IRP update is clause 10.2's effectiveness review.
How the clauses wrap the other frameworks
The governance wrapper function works in both directions.
Downward — clauses mandate that controls exist. The risk assessment (clauses 6.1.2, 8.2) drives which Annex A and NIST controls are implemented. The resource provision (clause 7.1) ensures the controls are funded. The competence requirement (clause 7.2) ensures the people operating controls are qualified. The operational control (clause 8.1) ensures the controls run. Without clauses 4 through 10, Annex A is a shopping list without a reason to buy any particular item.
Upward — controls provide evidence for the clauses. The SIEM (AT-AU) provides the clause 9.1 monitoring output. The vulnerability scan (AT-RA) feeds the clause 8.2 risk assessment input. The leaver checklist (AT-PS) provides the clause 8.1 operational control evidence. The management review (clause 9.3) consumes outputs from EV-F02 (security metrics), EV-C02 (risk assessment), EV-A02 (audit findings), and EV-C04 (treatment actions). Without the AT-[family] pages and their evidence items, the management review has nothing to review.
The most elegant consequence of this architecture is that compliance with NIST 800-171, CMMC Level 2, and DEFSTAN Profile 2 all feed into the same clause 9.3 management review. The CISO presents the NIST control implementation status, the CMMC POA&M, and the DEFSTAN assessment findings at a single annual review. Leadership makes resource decisions that apply across all three frameworks simultaneously. The corrective action from an incident review (AT-IR) improves the IR playbook (Annex A 5.26), feeds the POA&M (CMMC 3.12.2), and updates the risk register (AT-RA 3.11.1) — one corrective action, three framework obligations satisfied.
This is why the Confluence architecture built across this project is structured the way it is. Each AT-[family] page is simultaneously an ISO 27001 Annex A control implementation, a NIST 800-171 control implementation procedure, a DEFSTAN evidence document, and an input to the management system clauses. The evidence items (EV-A through EV-F) are the structured evidence for both the control families and the management system. The AT-CA page is where the management system clauses come to life operationally — it is the plan (clause 6), the audit (clause 9.2), the monitoring framework (clause 9.1), the nonconformity tracking (clause 10.2), and the SSP (NIST 3.12.4) all in one document.