Cyber Crisis Leadership Training for Executives | DORA, NIS2, UK CAF & ISO 27001

NIS2 Art 20(2); DORA Art 5(4); CAF A2 (Risk Management); ISO 27001 7.2.

Not a threat taxonomy — a translation of the current landscape into board consequences.

Covers:

- AI-accelerated and industrialised ransomware
- Deepfake-enabled fraud and authorised-payment scams 
- Third-party/supply-chain and ICT-provider compromise
- Attacks on backups and on incident responders themselves.

The emphasis throughout: Why the modern cyber crisis is an enterprise business crisis, not a technical failure.

Applied activity: "So what for us?" — in table groups, participants map the top three threats to their own organisation's critical/essential services and name the board decision each would force.

NIS2 Art 20(1)&(2); DORA Art 5(2),(4); CAF A1 (Governance); ISO 27001 5.1 & 7.2.

The heart of the regulatory alignment.
- What "approve," "oversee" and "ultimate responsibility" mean in practice 
- The non-delegable nature of accountability (you can delegate execution to a CISO, never the duty to understand and direct)
- Personal liability in accordance with national implementing law 
- Entity-level fines and management-ban exposure under NIS2/DORA
- CAF's expectation of informed board decision-making
- ISO 27001's demand for demonstrable leadership commitment and competence

Above all: What a supervisor or assessor will actually ask the board to evidence.

Applied activity: The one-page defence. Groups draft the answer they would give a supervisor/assessor who asks, "Show me how this board discharged its duties" — then stress-test whether their real-world evidence trail (board minutes, training records, competence evidence, CAF returns) could produce it today.

NIS2 Art 21(2); DORA Art 5(2); CAF D1 (Response & Recovery); ISO 27001 A.5.24–5.27.

The lifecycle model.

Before: Setting risk appetite, approving plans, assuring readiness, asking the right pre-incident questions.

During: The board's distinct role versus the incident team's — governance, not hands-on response; escalation triggers; the crisis-governance structure and who holds which decision.

After: Recovery oversight, lessons-learned, remediation accountability and reporting to the regulator and market.

The Crisis Cadence — running the board through a long incident. Real ransomware recoveries routinely run for weeks or months; the board's role is sustained oversight, not a single crisis meeting.

This segment sets the board's rhythm for a live incident: meeting frequency, duration and a standing agenda; the upward information flow — what the incident team reports, in what format, how often; the decision log as a governance artefact — who keeps it, what it must capture, and why it becomes the board's defence file; and endurance — deputies, succession when key people are unavailable, and managing fatigue across a multi-week incident.

Applied activity: Escalation mapping. Participants build their own escalation and decision-rights map — who convenes the board, at what threshold, with what authority — and identify where it currently breaks. Each group then drafts the standing agenda and reporting cadence for "day 5" of a live incident and nominates who keeps the decision log.

Duties served: DORA Art 5(2) (risk tolerance) & Arts 28–30 (ICT third-party risk); NIS2 Art 20 (oversight judgement) & Art 21(2)(d) (supply-chain security); CAF A1 (decision-making) & A4 (Supply Chain).

The core executive skill a crisis demands: making consequential, often irreversible decisions on incomplete and contradictory information, against a running clock.

Frameworks for triage under ambiguity, avoiding both paralysis and premature certainty, separating the reversible from the irreversible, and knowing which decisions are the board's to make versus the executive's.

Not Our Breach, Still Our Problem — the supplier-side incident. A distinct decision problem arises when the incident is at a third party: limited information rights, reliance on the supplier's timeline — yet the reporting duties remain yours.

DORA's ICT third-party provisions and NIS2 Article 21(2)(d) place supply-chain security and incident obligations on the entity, not the supplier. The segment covers the contractual levers the board should already have demanded: notification clauses, audit rights and step-in rights.

Applied activity: Inject drills. Short, escalating injects (a single odd login → media rumour → confirmation that regulated data is affected → attacker contacts board members directly). Groups must decide and justify with the information they have — then see how new information reframes the last call. The culminating supplier inject: "Your critical SaaS provider has confirmed a breach but will say nothing further for 48 hours. The DORA clock question: has your incident started?"

Duties served: NIS2 Art 23; DORA Arts 17–23 & RTS 2025/301; UK NIS Regulations; CAF D1 & sector reporting; GDPR Arts 33–34; UK MAR (listed entities).

The reporting timelines rehearsed as board decisions, not compliance trivia.

- DORA's initial notification — one report, two clocks: due within 4 hours of classifying the incident as major, and no later than 24 hours from becoming aware of it; the intermediate report follows within 72 hours of the initial notification and the final report within one month.

- NIS2's 24h/72h/1-month cadence. The UK NIS Regulations' statutory 72-hour notification for operators of essential services — and the direction of travel:

-The Cyber Security and Resilience Bill now before Parliament proposes a two-stage UK regime with an initial notification within 24 hours to both the sector regulator and the NCSC, a full report within 72 hours, direct customer notification, and penalties of up to £17m or 4% of global turnover — so boards should rehearse to the tighter cadence now. Plus the hard legal calls boards actually face: ransom-payment decisions and sanctions exposure, preserving legal privilege over investigations, disclosure obligations, and the interaction with insurers.

The Second Clock — market disclosure for listed entities. For listed companies, a cyber incident can constitute inside information under the UK Market Abuse Regulation, triggering an obligation to disclose to the market as soon as possible unless the strict conditions for delaying disclosure are met.

This clock runs independently of, and often faster than, DORA/NIS2/GDPR notifications, and directors of listed companies carry personal exposure for disclosure failures. (Delivered for listed cohorts; contextualised out for private companies.)

Calling the Cavalry — law enforcement, the NCSC and who can actually help. When and why to engage the NCSC, Action Fraud and the NCA — and what each can and cannot do. The critical fact boards get wrong: NCSC engagement is voluntary and advisory; it is not a regulatory notification and discharges no reporting duty. The segment also covers how law-enforcement engagement interacts with insurers, legal privilege and disclosure — the reason it sits in this module.

Applied activity: Beat the clock. Against a live scenario timeline, groups decide what must be notified, to whom, and by when — including, for listed cohorts, the MAR question "is this inside information yet?" — and draft the two-line "what we know / what we don't" statement for the first regulatory contact.

Duties served: NIS2 Art 21(2) & Art 23; CAF D1; ISO 27001 7.4 (communication).

What each audience expects and how those expectations conflict: staff, customers, regulators, media, investors, partners and the attacker.

Sequencing and consistency across channels; the risks of saying too much, too little, or too soon; spokesperson discipline; and the reputational half-life of the first 24 hours.

Applied activity: The holding statement & the hostile question. Groups draft a customer holding statement, then face rapid-fire media/regulator questions from the facilitator — experiencing how wording written for one audience is read by all of them.

Duties served: All of the above — the synthesis module (maps to CAF A1/D2 and ISO 27001 9.3/10 continual improvement).

The recurring, avoidable failure patterns: treating cyber as "the IT team's problem," freezing on decisions, over- or under-communicating, unclear decision rights, no pre-agreed escalation, untested plans, and confusing activity with control.

Set against the positive standard: what genuine board-level cyber resilience looks like — clear roles and risk appetite, rehearsed escalation, decisive-but-humble decision-making, coordinated response, and a defensible evidence trail.

Applied activity: Failure-to-standard. Each group takes one classic failure mode and defines the specific practice, artefact or behaviour that would prevent it in their organisation, feeding directly into the action commitments at close.

Duties served: DORA Art 5(4), NIS2 Art 20(2), CAF B6 & D2, ISO 27001 7.2 (applied, evidenced training/competence).

A consolidated mini-drill that runs the full arc — detection, escalation, decision, reporting, communication — at pace, so participants apply every module together.

This is the on-ramp: it establishes the shared vocabulary, roles and expectations participants need to step into a full cyber crisis simulation / tabletop wargame ready to perform rather than learn the format cold.

Outcome statement: Participants understand their role in a cyber crisis and are ready to apply that knowledge in a realistic exercise.

It is a one-day, application-level executive workshop that prepares boards and senior leadership teams to lead through a cyber crisis. Rather than raising awareness, it rehearses the actual decisions, escalations, regulatory notifications and communications leaders must make during a cyber incident, aligned to DORA, NIS2, the UK Cyber Assessment Framework (CAF) and ISO 27001.

For many organisations, yes. NIS2 Article 20(2) requires members of the management body of essential and important entities to follow cybersecurity training. DORA Article 5(4) requires financial-entity board members to keep their ICT-risk knowledge and skills up to date through specific, regular training. The UK CAF and the UK Cyber Governance Code of Practice expect boards to build cyber literacy, and ISO 27001 requires demonstrable leadership competence with retained evidence. 

Board members and non-executive directors, the CEO, CFO, COO and wider C-suite, General Counsel and the Company Secretary, Chief Risk and Compliance Officers, communications leaders, and business-unit leaders with crisis roles. It is written for the people who must decide, disclose and defend during an incident — not the technical team.

No. The workshop is designed specifically for senior, non-technical decision-makers. All content is expressed in the language of governance, risk, liability, decisions and communication. CISOs and CIOs are welcome as participants or observers.

Awareness training explains what cyber risk is; this workshop rehearses what leaders personally do, decide and say when an incident happens. It operates at the “apply and evaluate” level — using decision drills, injects, mock regulator and media exchanges, and board-pack critique — and it produces documented training evidence that awareness sessions typically do not.

Four regimes are mapped module by module: the EU NIS2 Directive (including Article 20 duties, liability and sanctions), DORA for financial entities (including Article 5 governance and the incident-reporting RTS), the UK NCSC Cyber Assessment Framework (CAF) used in GovAssure and NIS Regulations oversight, and ISO/IEC 27001:2022 leadership, competence and incident-management requirements. It also covers GDPR breach notification, the UK Cyber Security and Resilience Bill and, for listed companies, UK Market Abuse Regulation disclosure. 

Under NIS2: an early warning within 24 hours of awareness, an incident notification within 72 hours and a final report within one month. Under DORA: an initial notification within 4 hours of classifying an incident as major (no later than 24 hours from awareness), an intermediate report within 72 hours and a final report within one month. GDPR requires notifying the ICO or data-protection authority within 72 hours where personal data is involved, and listed companies may need to disclose to the market as soon as possible under MAR. The workshop rehearses decisions against all of these clocks.

Each engagement generates a training attendance and completion attestation for every participant, a board action log, a facilitator observations summary and a readiness statement. Together these support NIS2 and DORA supervisory reviews, CAF/GovAssure returns and ISO 27001 Clause 7.2 competence evidence — helping the board answer “show me how you discharged your duties” on a single defensible page.

A cyber crisis simulation (or tabletop exercise / executive wargame) is a facilitated, scenario-driven rehearsal in which the leadership team responds to an unfolding incident under realistic pressure. This workshop is the purpose-built first half of that engagement: it establishes the duties, decision frameworks, escalation model and shared vocabulary so the simulation tests judgement rather than orientation. It can also be delivered standalone.

At least annually. DORA requires “regular” training proportionate to ICT risk, NIS2 expects ongoing board competence, and the UK Cyber Governance Code of Practice directs boards to exercise incident-response plans at least once a year. Annual delivery — ideally paired with a live simulation — keeps the evidence trail current and captures regulatory change.

NIS2 provides fines of up to €10 million or 2% of worldwide annual turnover for essential entities (€7 million or 1.4% for important entities), plus personal liability for management-body members and possible temporary management bans under national implementing law. The UK Cyber Security and Resilience Bill proposes penalties of up to £17 million or 4% of global turnover. Beyond fines, boards face regulatory scrutiny, disclosure exposure, insurance consequences and reputational damage.

No — unlike NIS2 and DORA, PCI DSS contains no explicit board-training mandate. It does, however, require formally assigned executive accountability for information security (Requirement 12.1.3–12.1.4), annual security awareness training for all personnel (Requirement 12.6), and annual testing of the incident response plan with trained response personnel (Requirement 12.10). A payment-card breach is exactly the kind of enterprise crisis this workshop rehearses — running the acquirer, card-brand, forensic-investigator and GDPR clocks in parallel — and the workshop’s documented evidence pack supports those PCI DSS executive-accountability and response-testing requirements, even though the standard itself does not mandate board training.

Yes. It is delivered as a private, single-organisation cohort (typically 8–16 leaders), in person or live-online, with scenarios and regulatory scope contextualised to the entity: DORA-led for financial services, NIS2-led for EU essential and important entities, CAF/GovAssure-led for UK operators of essential services, central government and the NHS, and framed to generate Clause 5.1/7.2/7.3 evidence for ISO 27001-certified organisations.