Index
Management's relationship with the ISMS is fundamentally different from every other audience. They are not consumers of security guidance — they are accountable for it. Their Confluence content must support three things ISO 27001 clause 5.1 explicitly requires of top management: demonstrating commitment, allocating resources, and participating in governance. Everything they see should be oriented toward decisions, not procedures.---
SCM variant configuration for isms-management
The isms-management group is configured differently from isms-it-staff. Where IT staff need to see all-staff content plus technical depth, managers need to see all-staff content plus governance context — but explicitly without operational procedure detail. The SCM macro pattern on shared pages therefore has a management block that is distinct from the IT-staff block, sitting alongside it rather than nesting within it:
{scroll-content-variant: isms-all-staff}
[Behavioural guidance — everyone]
{scroll-content-variant}
{scroll-content-variant: isms-it-staff}
[Technical procedure — IT staff only]
{scroll-content-variant}
{scroll-content-variant: isms-management}
[Governance context and management obligations — managers only]
{scroll-content-variant}
{scroll-content-variant: isms-security}
[Evidence checklist and framework refs — security team only]
{scroll-content-variant}
The Confluence group isms-management should include: CEO, COO, CFO, CTO, CISO (as they have a governance role, not just a technical one), and line managers who have specific ISMS obligations (approving access requests, signing off on leavers, enforcing the AUP within their teams). Do not include all senior staff by default — a senior engineer with no governance obligations belongs in isms-it-staff, not isms-management.
isms-security should be configured as a superset of both isms-management and isms-it-staff — the security team needs to see all governance content to audit it, all IT procedures to assess them, and the additional evidence layer on top. The cleanest group hierarchy in Confluence: isms-all-staff → isms-it-staff → isms-security, with isms-management as a sibling of isms-it-staff. SCM then renders the correct blocks for each group's intersection.
Governance dashboard — management addition to the home page
The home page is the single most important page for management. Their SCM block on the home page is a self-contained governance cockpit — everything they need to know about the current state of the ISMS without navigating elsewhere. It sits directly below the all-staff welcome block, before any other content.
Certification and compliance status panel. A simple coloured status table — not a traffic-light chart (those require ongoing maintenance to keep meaningful), but a factual status table with five columns: Framework, Status, Certificate/Assessment Date, Expiry/Renewal Due, and Owner. Rows for ISO 27001, Cyber Essentials, Cyber Essentials Plus (if held), CMMC (self-attestation date and SPRS score), and DEFSTAN 05-138 (last assessment and next obligation date). This table is updated by the CISO monthly. Management can see at a glance whether any certification is lapsing, without needing to read the underlying documentation.
The key discipline here is that certification expiry is a board-level risk, not just an IT inconvenience. A lapsed Cyber Essentials certificate can trigger a breach of DEFSTAN contract conditions within 30 days. A lapsed ISO 27001 certification can affect enterprise sales. Include a simple note below the table: "Certificate renewals require management sign-off on the compliance budget. Renewal processes should begin 90 days before expiry." This surfaces the budget decision before it becomes urgent.
Information security objectives performance panel. The IS objectives you set under ISO 27001 clause 6.2 must be measurable and monitored. Management sees a condensed version of the full objectives dashboard here — one row per objective, showing the target, the current value, the trend (up/down arrow), and the RAG status. Five to seven objectives is the right number — enough to be comprehensive, few enough to be readable. Example objectives a management audience can evaluate:
Patch compliance rate — percentage of critical vulnerabilities remediated within 14 days. Target 95%. If current is 87% and trending down, that is a resourcing or tooling decision, not just an IT operations matter.
Security awareness training completion — percentage of in-scope staff with current annual training completed. Target 100%. If current is 76% in September, line managers need to chase their direct reports — this metric gives them the prompt.
Mean time to close high-severity corrective actions — days from finding to closure for any CA rated high severity. Target 30 days. If the current figure is 64 days, there is a resourcing or prioritisation failure that management must address.
Incident response time — percentage of significant incidents where initial response was within the defined SLA (typically two hours). Target 95%. A drop in this metric signals either an under-resourced security team or a process failure.
Supplier assurance coverage — percentage of critical suppliers with a current security assessment on file. Target 100%. If this is below target, management needs to understand which critical suppliers have not been assessed and why.
Open risk summary panel. A three-row summary table — not the full risk register, which is too granular for a governance dashboard. Three rows only: number of high/critical risks currently open on the register; number with treatment actions overdue; number that have been escalated for board-level risk acceptance decision. Link from this table to the full management risk posture page (described below). This panel exists to answer one question: does management need to make a risk decision right now? If there are overdue treatment actions or risks awaiting board acceptance, the answer is yes.
Upcoming governance actions panel. A short list of the next five governance obligations with due dates: next management review date, next internal audit start date, next Cyber Essentials renewal deadline, next ISO 27001 surveillance audit, and any CMMC re-attestation or DEFSTAN assessment due within the next six months. This is the content that prevents the CISO from being the only person in the organisation who knows that the ISO 27001 audit is in three weeks.
Management risk posture — additive block on 05 · Risk Register
The full risk register page is visible to the security team and management both, but management need a different entry point to it. The isms-management SCM block on the risk register page presents an executive summary that management can read and act on, before the detailed register content that the security team works with operationally.
Executive risk summary. Three paragraphs maximum. Current risk landscape: how many risks are on the register, how many are high or critical, how that compares to the previous quarter. Top three risks in plain language — not control reference codes, but a sentence describing the actual risk to the business: "Our legacy manufacturing system runs an unsupported operating system and cannot be patched, creating a significant ransomware exposure. The treatment plan (system replacement) is in progress with a target completion date of Q2." Management's role in relation to this risk is explicit: they must have approved the investment, understand the timeline, and be briefed if the timeline slips.
Risk appetite statement (management-facing). The risk appetite statement lives in the Risk Management Policy and is also presented here in plain language. It must answer four practical questions for a management audience: what level of risk are we willing to accept before we must invest in mitigation? Who has authority to formally accept a risk at each score band? What triggers an escalation to board level? What is the cost implication of our current risk appetite (i.e., what residual risk are we carrying and what would it cost to reduce it further)?
Most risk appetite statements are written for auditors. This one is written for a CFO making a budget decision or a CEO deciding whether to pursue a contract that increases the organisation's attack surface. The language should be: "We accept residual risks scoring 1–4 without further escalation. Risks scoring 5–9 require a documented treatment plan approved by the CISO. Risks scoring 10 or above require formal board acknowledgement. We currently carry two risks in the 10+ band — details below."
Risk treatment investment decisions outstanding. A short table listing any risks where the treatment plan requires a budget or resource decision from management. Columns: risk ID and plain-language description, treatment action required, estimated cost or resource, decision needed by, decision owner. This is the only content in the risk register section that management is expected to act on directly, rather than just read for awareness. Keeping this decision table current is the CISO's responsibility — it should never have more than five rows before becoming a management review agenda item.
How to read the full risk register. A brief orientation note, visible only to management, explaining the structure of the detailed register below: what the likelihood and impact scores mean in practical terms (not just "1-5 scale" but "5 on impact means this risk could cause us to lose a defence contract or suffer a regulatory fine exceeding £100,000"), and what the treatment status categories mean (accepted, in treatment, completed). This single paragraph stops the management review from stalling because someone does not know what a risk score of 12 actually implies.
Policy accountability — management addition to 01 · Policies
On each of the twelve policy pages, the isms-management SCM block adds a governance context section that sits below the all-staff summary. Its purpose is to surface two things: what management must do to fulfil their obligations under the policy, and what evidence the auditor will test for management's role.
The structure is consistent across all twelve policies. For the Information Security Policy: management obligation is to attend the annual management review and sign the policy document. Auditor test: the policy carries a named executive signature and a dated approval. For the Access Control Policy: line managers must respond to provisioning and de-provisioning requests within one working day, and must notify IT of their direct reports' role changes or departures on or before the effective date. Auditor test: JML log entries show manager approval for each provisioning event.
For the Risk Management Policy: management must formally accept or reject each risk escalated to their level, and must attend the risk review component of the management review meeting. Auditor test: risk acceptance records carry management sign-off, and management review minutes reference the risk register review. For the Supplier Security Policy: management must approve the engagement of any critical supplier, must be aware of the security obligations in each critical contract, and must authorise the annual assurance review budget. Auditor test: supplier register shows management approval for critical supplier engagements.
The management block on the Information Security Policy page specifically is where the board-level commitment statement lives in its authoritative form. The home page carries an excerpt — the policy page carries the full statement with the executive signature. ISO 27001 auditors check this page early in a stage-one audit. If the executive signature is absent, generic, or undated, it is a finding against clause 5.1 before any technical control has been assessed.
Line manager checklist — management-specific page. Create a dedicated page under 01 · Policies visible only to isms-management and isms-security, titled "Line manager security obligations". This page consolidates all the security actions that line managers own across all policies into a single checklist format: before a new starter's first day (notify IT at least two working days in advance; confirm role and required access; ensure AUP sign-off is on the onboarding checklist); when a team member changes role (notify IT on the effective date; confirm new access requirements; review and de-provision previous access within five working days); when a team member leaves (notify IT and HR no later than the last working day; confirm equipment return on the leaver's checklist; do not wait to see if IT notices the departure); annually (confirm all direct reports have completed security awareness training; review and sign off annual access rights review for their team; review their team's compliance with clear desk and screen lock requirements). This page is the practical operationalisation of ISO 27001 clause 7.3 (awareness), 5.4 (management responsibilities), and CMMC AC.L1-3.1.1 for line managers who are not security professionals but nonetheless have a direct compliance role.
Compliance status and certification roadmap — dedicated management page
This is a standalone page within section 07 · Reference Library or as a child of the home page, visible to isms-management and isms-security only. It exists to give management the full forward-looking compliance picture in one place — not what we are certified to today, but what decisions we need to make over the next 18 months to maintain and extend our compliance posture.
Current certification posture. A one-page summary of every active certification and assessment obligation: the framework, the certification body or assessment route, the current certificate or attestation reference, the valid from and valid to dates, the scope covered, and the annual cost of maintaining it. Management should be able to see in one table that ISO 27001 surveillance audit costs approximately £3,000–5,000 annually, that Cyber Essentials Plus costs £3,000–8,000 depending on scope, and that CMMC Level 2 third-party assessment (if required) costs £30,000–80,000 for a first assessment. These are budget inputs that belong in front of management, not buried in procurement records.
Upcoming renewal and assessment calendar. A 24-month forward calendar showing every certification renewal, surveillance audit, assessment obligation, and internal review milestone. Management need to see not just when events occur but when budget commitments must be made (typically 90 days before a certification body engagement), when internal preparation must begin (typically 60 days for a surveillance audit, 120 days for a recertification), and when management participation is required (management review meeting must occur before the surveillance audit in most ISO 27001 certification body requirements). A Gantt-style table works better than a calendar view for this — rows for each framework, columns for each month, cells showing what is happening.
CMMC contract obligations tracker. For organisations with US defence contracts under DFARS 252.204-7012, this section is particularly important. List each active contract that carries CMMC or NIST 800-171 obligations: contract number, contracting agency, CMMC level required, current assessment status, SPRS score, and the contract renewal date (the renewal date is when non-compliance becomes a contract termination risk). Management should understand that CMMC self-attestation is a legal declaration — the executive who signs the self-attestation is personally attesting to the accuracy of the SPRS score. If the score is inaccurate and there is a breach, that individual has potential personal liability under the False Claims Act. This is a management-level risk, not an IT-level risk, and it belongs in front of them explicitly.
Investment decisions outstanding. A short table listing any compliance investments that require management approval: capital expenditure for a new security tool, resource allocation for a penetration test, budget for an external audit, headcount for a security role. Each row: investment description, amount, which compliance obligation it supports, deadline by which the decision is needed, and the consequence of not investing (e.g., "Without a penetration test by Q3, we cannot renew Cyber Essentials Plus, which would breach the security schedule on our MOD framework agreement"). Management should be making these decisions proactively, not being surprised by compliance gaps when contracts are at risk.
Management review pack — management addition to 06 · EV-A
ISO 27001 clause 9.3 is unambiguous: management review must happen at planned intervals, it must cover a defined set of inputs, and the outputs must include decisions on resources, policy changes, and continual improvement. The management review pack in Confluence is what makes this happen systematically rather than being a once-a-year document-production exercise.
Agenda template. Create a standard agenda as a Confluence page template that is copied for each management review meeting. The ISO 27001 clause 9.3 required inputs map directly to agenda items: status of actions from previous review (5 minutes); changes in external and internal context relevant to the ISMS (10 minutes — this covers regulatory changes, new contracts, organisational changes, new threats identified through threat intelligence); IS objectives performance against targets (10 minutes — use the dashboard panel from the home page); risk register review and treatment status (15 minutes); audit findings (internal audit results, any surveillance audit findings, corrective action status) (15 minutes); incident summary and trend analysis (10 minutes); supplier security status (5 minutes); and opportunities for continual improvement (10 minutes). Total: 80 minutes. Management review should be a standing meeting on the executive calendar, not an ad-hoc event convened when the auditor asks for evidence of it.
Required inputs checklist. Before each management review, the CISO prepares a pack containing: updated IS objectives dashboard; risk register summary with any changes since last review; internal audit report or audit schedule status; corrective action register with open items highlighted; incident summary report; training completion rates; supplier assurance review summary; and any external changes (new regulations, threat intelligence, certification body communications). The management page includes a checklist confirming each input has been prepared and reviewed by the CISO before the meeting — this checklist itself is evidence of the clause 9.3 input requirements being met.
Decisions management must make at each review. Clause 9.3 requires documented outputs, not just minutes. The management review must produce: a decision on whether IS objectives need to be revised; a decision on resource allocation for the ISMS (budget confirmation); a decision on any policy changes required; a formal closure or extension of overdue corrective actions; risk acceptance decisions for any risks escalated for board-level consideration; and a decision on any opportunities for continual improvement raised. The minutes template in Confluence is structured around these required outputs — blank fields that must be completed during the meeting, not retrospectively.
Minutes template. Provide a Confluence page template for management review minutes. Structure: date, attendees (with roles), apologies, items reviewed (one section per agenda item with a brief summary of the discussion), decisions made (numbered decision log at the end — clear subject, decision, and owner), and actions arising (action, owner, due date). The decisions log is what ISO 27001 auditors look for to verify that management review is substantive governance, not a rubber-stamp meeting. If the decisions log is empty or identical across multiple reviews, it suggests the review is not genuinely engaging with the ISMS.
Supplier governance and BCM — management content
Critical supplier governance summary. On the supplier management section of the EV-D evidence pages, the isms-management SCM block adds a one-page supplier governance summary. This is not the full supplier register (which the security team maintains operationally) — it is a risk-tiered summary showing: how many critical suppliers are in the register; which ones have upcoming contract renewals within 12 months; which ones have open security assessment findings; and which ones are currently rated as high-risk and why. Management's role in supplier governance is to approve the engagement of critical suppliers, to be aware of high-risk supplier relationships, and to ensure that the security obligations in contracts are commercially viable to enforce.
The most important management decision in supplier governance is one that is often made without security input: the decision to engage a new critical supplier or to renew a contract with a high-risk supplier. The management SCM block on the supplier pages includes a simple prompt: "Any supplier engagement requiring access to Restricted data, CUI, or production systems must be approved by the CISO before the contract is signed. Use the supplier security assessment request process to initiate this review." This instruction, visible only to management, is the organisational control that prevents the CISO from discovering a new critical supplier relationship six months after it began.
BIA executive summary. The Business Impact Analysis is a detailed technical document — recovery time objectives, recovery point objectives, dependency mapping, and impact modelling across multiple scenarios. The management SCM block on the BIA page presents an executive summary: which systems are classified as critical (any system whose failure would cause more than four hours of business disruption or more than £X of financial impact); what the board-approved RTO and RPO targets are for each; whether current backup and recovery capability meets those targets (yes/no, with the gap if no); and the cost and timeline to close any gap. The executive summary ends with a clear statement of the management decision required: "The current DR capability for System X has a tested RTO of 12 hours against a board-approved target of 4 hours. Closing this gap requires [investment]. Approval is required by [date] to include this in the next BCM testing cycle."
BCM governance obligations. Management's role in business continuity is governance, not operation. The management page on BCM covers three things: their obligation to set and approve RTO/RPO targets annually (the BIA outputs must be endorsed by management, not just produced by IT); their obligation to participate in or receive the results of annual BCM exercises (the post-exercise report is a management review input); and their obligation to act on BCM investment decisions within the timeline required by the testing schedule. A BCM programme that produces findings that are never remediated because management has not allocated the budget is a liability — this section makes the connection between governance decisions and operational resilience explicit.
What management does not see — and why this matters
Management not seeing the 03 · Advanced Controls section is deliberate and important. The 110 NIST 800-171 control specifications, DEFSTAN Profile 2 technical procedures, and ISO 27001 Annex A 8.x technical controls have no decision value for a management audience. Surfacing them creates two problems: it dilutes the governance content that management actually needs to act on, and it creates a false sense that reading the control documentation is the same as governing the control programme. Management governs through metrics, decisions, and accountability — not by reading technical procedures.
Management not seeing the full 06 · Audit & Evidence section is similarly deliberate. The detailed evidence register, individual scan reports, JML log entries, and corrective action records are operational documents that the security team manages and the auditor reviews. What management sees is a summary view: the governance dashboard on the home page, the IS objectives performance table, and the management review inputs prepared by the CISO. The distinction between governing the ISMS and operating it must be maintained in the Confluence architecture — not because management cannot understand the detail, but because their governance role is to hold the CISO accountable for the operational detail, not to be burdened with it directly.
The single exception: management should be able to see the corrective action register summary — specifically any corrective actions rated as high severity with overdue target dates. Create a filtered view of the corrective action register (a Confluence macro or a linked filtered table) visible to isms-management showing only high-severity open items with their owners and due dates. This is the one operational document that has direct governance accountability attached — a CISO who is not closing high-severity corrective actions on time is a management performance matter, and management cannot hold them accountable for it without visibility of it.