In the first three days of a serious cyber incident, boards are briefed too often with too little structure, and the decisions only they can take get buried in technical detail. This template gives the crisis lead a fixed format for board updates during a live incident: a one-page standing update, what the 24, 48 and 72 hour briefings must contain, how to put a decision to directors, and a tracker for the regulatory and disclosure clocks that are running. It is for chief information security officers, general counsel, company secretaries and crisis leads who brief a board or its delegated committee. It assumes the incident response plan is already running; it covers the board conversation, not the technical response.
How to use this template
- Adapt before you need it: replace bracketed text such as [Organisation], [Crisis lead] and [Board crisis committee] with your names, and agree the format with the chair and company secretary in peacetime.
- Use section 4 every time: the standing update is the same shape at hour 4 and hour 70, so directors learn where to look. Sections 5 to 7 list what must be added at each milestone.
- Separate facts from assessments: every statement is marked Confirmed, Assessed or Unknown. Early updates are mostly Assessed and Unknown; that is normal and should be said plainly.
- Keep it short: two pages at most, plus a decision paper where one is needed. Technical detail goes in an annex or the incident log.
- Related templates: record decisions in the Incident Log and Decision Record Template, draft notices with the Regulator Notification Template Pack, and set channels with the Out-of-Band Communications Plan Template.
1. Purpose and triggers
This template sets how [Organisation] keeps its board informed and able to decide during a cyber crisis. The UK NCSC's Board Toolkit states that the board, as the governing body, is ultimately responsible for any cyber security incident, and that directors need what they require to make decisions out of hours and under time pressure. This template is the mechanism for that.
Use it when any of these apply:
- The incident is rated [Severity 1 or 2] in the Incident Severity Classification Matrix Template.
- A decision is likely that sits with the board or [Board crisis committee]: taking critical services offline for an extended period, ransom or extortion engagement, public disclosure, or spending above [delegated limit].
- A regulatory or market disclosure clock may have started (section 9).
- Media, customer or regulator attention is likely within [24 hours].
2. Roles and distribution
| Role | Named person and deputy | Responsibility for board updates |
|---|---|---|
| Crisis lead (gold) | [Name] / [Deputy] | Owns the update, presents it, states decisions required |
| Incident response lead | [Name] / [Deputy] | Supplies technical facts and confidence levels; does not brief the board directly unless asked |
| General counsel | [Name] / [Deputy] | Reviews every update before issue; advises on privilege, disclosure and sanctions |
| Company secretary | [Name] / [Deputy] | Convenes the board or committee, checks quorum, records minutes and resolutions |
| Communications lead | [Name] / [Deputy] | Aligns board messages with external statements |
| Board point of contact | [Director name] | Single director channel between meetings, agreed in advance |
Distribution list: [Chair], [Board crisis committee members], [Chief executive], [General counsel]. Wider board distribution at the chair's discretion. See the Crisis Management Guide for the gold, silver and bronze structure.
3. Handling rules
- Channel: send and discuss updates only on [out-of-band channel], never on corporate email or collaboration tools until the incident response lead confirms they are not compromised.
- Marking: mark every update [Confidential, prepared at the request of counsel] where counsel advises; whether legal privilege applies depends on jurisdiction and facts, so take advice rather than assume it.
- Versioning: number each update (BU-01, BU-02) with the date and time issued in [time zone].
- No speculation on attribution: name a threat actor only when assessed with stated confidence by the response team or a law enforcement partner.
- Record decisions off affected systems: NCSC guidance on ransomware payment decisions advises keeping a careful record of decisions and recording them offline or on systems the attack has not affected.
4. Standing board update (use every time)
| Field | Content |
|---|---|
| Update number and time | [BU-nn], [date, time, time zone]. Next update: [time] |
| Status in one sentence | [What happened, what is affected, whether it is contained] |
| Severity and trend | [Severity], [worsening / stable / improving] since last update |
| Business impact | Services down or degraded, customers affected, revenue or safety impact. Mark each Confirmed, Assessed or Unknown |
| Data impact | Whether data has been accessed or taken, what categories, how many people or records. Confirmed, Assessed or Unknown |
| Containment status | Contained / partly contained / not contained; key actions since last update |
| Identity and access status | Whether privileged, service and machine credentials have been reset or revoked, and what remains. See the Enterprise Credential Reset Runbook Template |
| Recovery outlook | Expected restoration of critical services with confidence level; dependencies |
| External engagement | Regulators, law enforcement, insurer, incident response firm, key customers and suppliers contacted, with times |
| Clocks running | Summary from section 9: next deadline and owner |
| Decisions required | Numbered list, each with a decision paper (section 8) and the latest time it can be taken |
| Decisions taken since last update | By whom, under what authority, recorded in the decision log |
| Key unknowns | The three questions that most affect the next decisions, and when answers are expected |
5. 24-hour briefing
The first formal briefing. Its job is orientation and authority, not answers. Add to the standing update:
- How it was found: date and time of detection, and the time [Organisation] became aware for regulatory purposes as advised by counsel.
- Command in place: who is leading, which outside help is engaged (incident response firm, insurer's panel, legal counsel), and confirmation that the insurer has been notified where cover exists. NCSC guidance advises reporting the attack to your insurer or broker.
- Delegations confirmed: which decisions the board delegates to [Board crisis committee] or the chief executive for the duration, with limits.
- Early notifications: any early warnings or reports already due or made (section 9).
- Holding statements: approved external and internal holding lines, and who may speak.
- Decision on next meeting: confirm cadence (suggested: every [6 to 12] hours while not contained).
6. 48-hour briefing
By now the scope should be clearer. Add:
- Scope assessment: systems, business units, subsidiaries and jurisdictions affected, with confidence levels.
- Root cause hypothesis: initial access route as currently assessed, including whether stolen credentials, a supplier or a third-party integration were involved. See the SaaS Integration Token Breach Response Guide where an integration is implicated.
- Recovery plan options: two or three options with time to restore, cost, residual risk and dependencies.
- Extortion position (if applicable): facts only, with legal and sanctions advice. NCSC guidance states that payment may be unlawful where the recipient is linked to a sanctioned entity, that payment does not guarantee recovery, and that paying does not meet regulatory obligations.
- Stakeholder plan: which customers, partners and staff are told what and when.
- Materiality and disclosure view: counsel's current assessment, and when a determination will be made.
7. 72-hour briefing
The 72-hour mark coincides with several notification deadlines and is when boards usually move from crisis to recovery governance. Add:
- Notifications made: list with times, reference numbers and next reports due.
- Containment confirmation: what evidence supports "contained", including credential resets completed, and what would cause re-entry.
- Recovery timeline: chosen option, milestones and the date for return to normal operations, with confidence.
- Financial view: costs incurred and forecast, insurance position, and any market disclosure considerations.
- Cadence change: proposal to move to daily updates and then to the standing committee, with criteria for stepping down.
- Review commitment: date for the post-incident review and who leads it. See the Post-Incident Review and Root Cause Analysis Template.
8. Decision paper format
Every decision the board is asked to take uses this format, on one page:
| Heading | Content |
|---|---|
| Decision required | [One sentence, framed as a question with a yes or no or a choice of options] |
| Latest time to decide | [Date and time] and what happens if no decision is taken |
| Options | [Option A, B, C], each with impact, cost, risk and reversibility |
| Recommendation | [Option] from [Crisis lead], with reasoning |
| Advice received | Legal, insurer, incident response firm, regulator or law enforcement input, with any dissent |
| Evidence quality | Confirmed facts relied on, and the assumptions that would change the recommendation |
| Authority | Whether this is within the delegation in section 5 or needs full board resolution |
The NCSC Board Toolkit names taking systems offline, including out of hours, as a decision that needs clear authority agreed in advance. Directors should not see a decision for the first time at the moment it must be made.
9. Regulatory and disclosure clock tracker
Keep this table in every update. The regimes below are examples; [General counsel] lists those that apply to [Organisation]. Deadlines are summarised from the Regulator Notification Template Pack; confirm against the official text before relying on them.
| Regime | Trigger | Deadline | Owner | Status |
|---|---|---|---|---|
| UK GDPR and EU GDPR personal data breach | Awareness of a personal data breach, unless it is unlikely to result in a risk to individuals | Without undue delay, and where feasible within 72 hours of awareness | [DPO] | [Not started / drafted / sent] |
| NIS2 (EU) | Significant incident | Early warning within 24 hours of awareness; incident notification within 72 hours of awareness; final report within one month of the incident notification (Article 23(4)) | [Name] | [ ] |
| DORA (EU financial entities) | Major ICT-related incident | As set in the DORA reporting rules; see the pack | [Name] | [ ] |
| US SEC Form 8-K Item 1.05 | Determination that an incident is material | Generally four business days after the materiality determination | [General counsel] | [ ] |
| Contractual notices | As defined in customer and supplier contracts | [Per contract] | [Name] | [ ] |
| Cyber insurance | As defined in the policy | [Per policy] | [Name] | [ ] |
| Law enforcement | Criminal activity | As soon as practical; in the UK, gov.uk/report-cyber shows who to notify | [Name] | [ ] |
The SEC's 2023 rules allow the Form 8-K filing to be delayed only where the US Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety. For the board's continuing oversight duties, see the Board and Director Cyber Liability Guide.
10. Cadence after 72 hours and closure
- Daily: standing update (section 4) until critical services are restored and containment is confirmed.
- Weekly: to [Board crisis committee] until recovery milestones are met and outstanding regulatory reports are filed.
- Closure: a final update recording what happened, decisions taken, notifications made, total cost, and lessons with owners and dates. The NCSC Board Toolkit suggests boards ask what improvements have been made since a significant incident, so the closure update should state them.
- Into the regular report: fold lessons and follow-up actions into the next quarterly Board Cyber Report Template.
Implementation guidance
- Agree it in peacetime: take this template to the board or audit and risk committee with the delegations in section 5 pre-drafted, so they are confirmed rather than invented at hour 20. See the Cyber Incident Readiness Executive Briefing.
- Pre-fill the static parts: roles, distribution, out-of-band channel, regimes in section 9 and contracts with notification clauses.
- Exercise it: run one tabletop a year in which directors receive BU-01 to BU-04 and take at least two decisions from decision papers. The NCSC Board Toolkit encourages board participation in exercises. Record findings in the Tabletop After-Action Report Template.
- Measure it: after each exercise or incident, check time from severity rating to first board update, whether every decision had a paper before its deadline, and whether every regulatory clock was met.
- Review yearly: update section 9 when laws change and section 2 when people change.
Where this sits in common frameworks (our mapping):
| Framework | Reference | How this template supports it |
|---|---|---|
| NIST CSF 2.0 | RS.CO-02, RS.CO-03 | Stakeholders notified and information shared during the incident |
| NIST CSF 2.0 | GV.RR-02 | Roles and authorities established and enforced |
| NIST SP 800-53 Rev 5 | IR-4, IR-6 | Incident handling and incident reporting |
| NIST SP 800-61 Rev 3 | CSF 2.0 Community Profile for incident response | Places incident response inside overall cyber risk management |
Standards and references
- NCSC: Board Toolkit, Planning your response to cyber incidents
- NCSC: Guidance for organisations considering payment in ransomware incidents
- NIST: SP 800-61 Rev 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- US SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure rules
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 33
- legislation.gov.uk: UK GDPR Article 33
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Crisis Management Guide · Incident Log and Decision Record Template · Regulator Notification Template Pack · Board Cyber Risk Reporting Guide