Most board cyber reports are long lists of security activity that leave directors unable to say whether the organisation is inside its risk appetite or what they are being asked to decide. This template gives you a standing quarterly board report with a fixed structure: a one-page summary, risk posture against appetite, a short set of metrics with agreed tolerances (including non-human identity and third-party risk), material incidents, and an explicit list of decisions needed. Sections 1 to 7 are written as a reporting standard you can adopt as is, so the report means the same thing every quarter. It is built around the UK Cyber Governance Code of Practice and the NCSC Cyber Security Toolkit for Boards, with notes for SEC registrants. It is for CISOs, risk and GRC leads, company secretaries and the directors who receive the report.
How to use this template
- Replace text in square brackets, such as [Organisation], [Risk committee] and [X days], with your own terms. Values in brackets are illustrative starting points, not requirements from any standard.
- "Must" indicates a mandatory requirement of this reporting standard; "should" indicates recommended practice.
- Agree the metric set and tolerances with the board once (section 4.3), then keep them stable for at least four quarters so trends are comparable. The Cyber Governance Code of Practice action E2 asks boards to require formal reporting at least quarterly, set suitable metrics and agree tolerances for each.
- Start from an agreed appetite statement. If you do not have one, use the Cyber Risk Appetite Statement Template first. For the wider reasoning behind board reporting, see the Board Cyber Risk Reporting Guide.
1. Purpose
This standard sets the content, cadence and ownership of cyber security reporting to the [Board] and [Risk committee] of [Organisation], so that directors can: judge whether cyber risk is within the agreed appetite; see whether the cyber strategy is being delivered; understand material incidents and the obligations they trigger; and take the decisions only they can take, with a clear record of each decision.
2. Scope
This standard applies to:
- Reports covered: the quarterly board cyber report, the annual cyber posture review, and out-of-cycle incident briefings.
- Risks covered: all cyber risks in the [enterprise risk register], including risks arising from suppliers, partners and subsidiaries, and from the human and non-human identities (service accounts, API keys, tokens, certificates, workload identities and AI agents) that access [Organisation] systems.
- Entities covered: [Organisation] and [list subsidiaries / all group entities].
Operational reporting to management is out of scope, but board metrics must trace to it.
3. Roles and responsibilities
| Role | Responsibilities |
|---|---|
| [Board] | Approves the cyber risk appetite, metric set and tolerances; records decisions taken on the report; receives the report at least quarterly. |
| [Risk committee / Audit committee] | Reviews the full report before the board; challenges metrics outside tolerance; oversees assurance (internal audit, external testing). |
| [Non-executive director with cyber oversight] | Holds regular two-way dialogue with the CISO between meetings; sponsors decisions in section 4.7. |
| [Executive owner of cyber risk, e.g. COO or CIO] | Accountable for the report; confirms that risk owners agree the posture shown. |
| [Chief Information Security Officer] | Prepares the report, owns metric definitions and data quality, presents in person. |
| Risk owners | Confirm the current rating and treatment status of their cyber risks each quarter. |
| [Company secretary] | Schedules the report, minutes decisions and actions, and tracks them to closure. |
| [General counsel] | Confirms regulatory reporting obligations and disclosure positions for incidents in section 4.4. |
4. Policy statements
4.0 Every quarterly report must contain sections 4.1 to 4.7 in this order. The body must not exceed [8] pages, excluding appendices. Each section gives required content, then template text.
4.1 One-page summary
4.1.1 Page one must be readable alone and must answer four questions: are we within appetite, what changed, what happened, and what do we need from the board.
| Item | Template text |
|---|---|
| Overall position | [Within / Partly outside / Outside] appetite. [X] of [Y] board metrics within tolerance (last quarter: [X] of [Y]). |
| Top three risks | [Risk name]: [rating], [trend up / flat / down], owner [name]. |
| What changed | [New threat, new system, acquisition, regulation, supplier change] and its effect on risk. |
| Material incidents | [Number] incidents rated [severity 1-2]; [none / one] met a regulatory reporting threshold. |
| Strategy delivery | [X]% of cyber strategy milestones on track; [named milestone] at risk because [reason]. |
| Decisions needed | [Number] decisions, listed in section 4.7, each with a recommended option. |
4.2 Risk posture against appetite
4.2.1 Each principal cyber risk must be shown with its owner, current rating, target rating, appetite threshold, trend and treatment status, using the same scale as the [enterprise risk register].
4.2.2 Risks outside appetite must state the treatment plan, the date it will return within appetite, and the cost or trade-off of closing the gap. The NCSC board toolkit suggests the number of risks within the agreed threshold, and the cost of high-priority risks outside it, as a useful indicator.
4.2.3 The report must flag any risk that has been accepted rather than treated, with the accepting executive and expiry date.
| Risk | Owner | Current | Target | Appetite | Trend | Treatment and date |
|---|---|---|---|---|---|---|
| [Ransomware disrupting [critical service]] | [COO] | [High] | [Medium] | [Low-Medium] | [Flat] | [Immutable backups for tier 1 by [date]] |
| [Compromise of machine credentials or tokens] | [CIO] | [High] | [Medium] | [Medium] | [Up] | [Secrets rotation and owner assignment by [date]] |
| [Critical supplier compromise or outage] | [CPO] | [Medium] | [Medium] | [Medium] | [Up] | [Exit plans for top [10] suppliers by [date]] |
4.2.4 The report must note cumulative risk where several risks could crystallise at once, for example during [year-end reporting], as the NCSC toolkit recommends.
4.3 Key metrics and tolerances
4.3.1 The board metric set must contain [8 to 12] metrics, each with a definition, data source, owner, tolerance (green, amber, red) and four-quarter trend. Every metric must trace to a risk in 4.2 or a strategy objective.
4.3.2 Metrics must measure outcomes or exposure, not activity. "Number of phishing emails blocked" is not a board metric; "time to detect and recover from an incident affecting [critical service]" is (the NCSC toolkit's own example).
| Area | Metric | Tolerance (illustrative) |
|---|---|---|
| Resilience | Tier 1 services with a recovery test in the last [12] months, and achieved vs target recovery time | Green 100%; red below [90]% |
| Detection and response | Median time to detect and to contain severity 1-2 incidents | Green under [24] h to contain |
| Exposure | Known exploited vulnerabilities on internet-facing systems past [14]-day SLA | Green 0; red above [5] |
| Human identity | Privileged and remote access protected by phishing-resistant MFA | Green 100%; any exception named |
| Non-human identity | Service accounts, API keys and tokens with a named owner; credentials older than [90] days; privileged NHIs without rotation | Green above [95]% owned; red any unowned privileged NHI |
| Third-party risk | Critical suppliers assessed in the last [12] months; open high-severity supplier issues; suppliers with standing access to production | Green 100% assessed; red any overdue critical supplier |
| People | Completion and effect of training (for example phishing-report rate) for [high-risk roles] | Green above [90]% |
| Strategy delivery | Cyber strategy milestones on track and budget spent against plan | Green above [85]% on track |
| Assurance | Overdue audit and test findings rated high | Green 0 overdue more than [90] days |
4.3.3 The non-human identity line is mandatory, because service accounts, keys and tokens are often missing from board reporting entirely. Cloudflare's 2023 breach came from four credentials, out of thousands exposed in the Okta support breach, that were not rotated because they were wrongly believed to be unused (see the Cloudflare Thanksgiving Breach). For metric definitions, see the Identity Security Metrics Guide.
4.3.4 The third-party line should follow the NCSC supply chain module: share of suppliers assessed, when each was last assessed, share compliant with required policy, and high-severity issues. See the Third-Party Risk Management Guide.
4.3.5 Any change to a metric definition must be shown in the report, with the old and new values for one quarter.
4.4 Incidents and near misses
4.4.1 The report must list every incident rated [severity 1 or 2] in the period, with: date detected, business impact, root cause (or "under investigation"), status, cost to date, regulatory notifications made or assessed, and lessons with owners.
4.4.2 Incidents at suppliers that affected [Organisation] must be included.
4.4.3 Where a control failure caused the incident, the report must say whether that control was reported as effective in earlier quarters. Change Healthcare's 2024 breach began at a remote-access portal that, in the CEO's written testimony, did not have multifactor authentication (see the Change Healthcare Breach 2024).
4.4.4 The report must include the date and outcome of the last incident exercise. Code action D2 expects exercising of the incident plan at least annually, with lessons fed back into the plan and risk assessments.
4.5 Regulatory and assurance position
4.5.1 The report must summarise upcoming obligations and owners, such as [NIS2 / DORA / SEC rules / sector regulator requirements], and the status of external assurance (certifications, penetration tests, CAF or Cyber Essentials assessments).
4.5.2 For SEC registrants: Item 106(c) of Regulation S-K requires a description of the board's oversight of cybersecurity risk, any responsible committee and how it is informed, and whether management reports to the board. This report and its minutes are the evidence for that disclosure. Material incidents are disclosed on Form 8-K Item 1.05 within four business days of the materiality determination, so the report must show who determines materiality and how fast. See the SEC Cybersecurity Disclosure Rules Guide.
4.6 Strategy and investment
4.6.1 The report must show progress against the cyber strategy, and where investment would most reduce risk outside appetite, in line with Code actions B3 and B4.
4.7 Decisions needed
4.7.1 Each decision must be stated as a question with options, a recommendation, cost, the risk effect of each option, and the date by which it is needed. Items for noting go elsewhere.
| # | Decision | Options | Recommendation | Risk effect | Needed by |
|---|---|---|---|---|---|
| 1 | [Approve funding to retire legacy remote access] | [A: fund now, [cost]; B: defer to [year]] | [A] | [Returns risk R2 within appetite by [date]] | [Date] |
| 2 | [Accept risk of [supplier] without exit plan for [6] months] | [Accept with expiry / Require exit plan] | [Accept to [date]] | [R3 stays at appetite limit] | [Date] |
| 3 | [Pre-approve authority to take [service] offline in an incident] | [Delegate to [CEO + CISO] / Board only] | [Delegate] | [Shortens containment] | [Date] |
4.7.2 Incident authorities the NCSC toolkit highlights, such as taking systems offline, should be pre-agreed here.
5. Exceptions
5.1 A section of the report may be omitted only with the approval of the [Risk committee chair], and the omission must be stated on page one.
5.2 A metric that cannot be produced must be reported as "not available", with the reason and the date it will be available. It must not be removed or replaced with an estimate without saying so.
5.3 Highly sensitive detail (active investigations, unpatched exposures) may be moved to a restricted appendix with controlled distribution, but the summary must still show its effect on posture.
6. Compliance and monitoring
- Cadence: the report must reach the [Risk committee] at least quarterly and the [Board] at least [quarterly / twice a year], with an annual posture review. The NCSC toolkit expects a broader posture review at least every 12 months.
- Out of cycle: the CISO must brief the [Chair and committee chair] within [24] hours of a severity 1 incident or of any incident that may require regulatory notification.
- Data quality: metric data must come from systems of record, not manual estimates; [Internal audit] must review the metric set and its sources at least [annually].
- Decision tracking: the company secretary must report the status of every previous decision and action at the start of section 4.7.
- Evidence: reports, minutes and decision logs must be retained for [X years], as they support governance disclosures and regulator enquiries. On personal accountability, see the CISO Personal Liability Guide.
7. Review and approval
7.1 This standard is owned by [CISO] and approved by the [Board]. It must be reviewed at least annually, after a severity 1 incident, and when the risk appetite, regulations or strategy change materially.
| Version | Date | Author | Approved by | Changes |
|---|---|---|---|---|
| [1.0] | [Date] | [CISO] | [Board, minute ref] | [Initial version] |
Implementation guidance
Rolling it out
- Agree appetite first: confirm the cyber risk appetite with the board (Code action A3). Without it, section 4.2 has nothing to measure against.
- Draft the metric set: pick [8 to 12] metrics that trace to principal risks; test that each can be produced from a system of record. Expect the NHI and supplier metrics to be the hardest.
- Dry run: produce one shadow quarter and fix definitions with the committee chair.
- Agree tolerances: the board approves tolerances once; changes after that go through section 4.3.5.
- Run four quarters: keep the structure fixed; adjust only via the annual review.
- Roll back: if a metric proves unreliable, mark it "not available" under 5.2 rather than dropping it silently, and replace it at the next review.
Small and large organisations
A small organisation can merge the committee and board steps, use [6] metrics and a two-page report. A listed group should add an entity view to 4.2 and have internal audit sign off metric sources, since the report evidences disclosures.
Framework mapping
| Report section | UK Cyber Governance Code | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 4.2 Risk posture vs appetite | A2, A3, A5 | GV.RM-02 | PM-9 |
| 4.3 Metrics and tolerances | E2, C4 | GV.OV-03 | PM-6 |
| 4.3 Third-party line | A4 | GV.SC-07 | SR-6 |
| 4.4 Incidents and exercises | D1, D2, D4 | ID.IM-01 | IR-3 |
| 4.6 Strategy and investment | B1 to B4 | GV.OV-01 | PM-9 |
| 3 Roles | E1, E3 | GV.RR-01 | PM-9 |
See the UK Cyber Governance Code of Practice Guide for the full set of actions.
Standards and references
- DSIT and NCSC: Cyber Governance Code of Practice
- NCSC: Cyber Security Toolkit for Boards
- NCSC: Risk management for cyber security (Board Toolkit)
- NCSC: Implementing effective cyber security measures (Board Toolkit)
- NCSC: Collaborating with your supply chain and partners (Board Toolkit)
- US CFR: 17 CFR 229.106, Regulation S-K Item 106 Cybersecurity
- SEC: Cybersecurity Risk Management, Strategy, Governance and Incident Disclosure, fact sheet
- NIST: Cybersecurity Framework 2.0
This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Board Cyber Risk Reporting Guide · UK Cyber Governance Code of Practice Guide · Cyber Risk Appetite Statement Template · Identity Security Metrics Guide · Incident Response Plan Template