Most cyber resilience training still teaches resilience as a technical and procedural discipline: how to detect faster, contain more cleanly, restore systems, and run a tighter incident review.
All of that matters. None of it, on its own, tells a responder whether the incident they're managing has just started a legally binding clock, which authority needs to hear from them and by when, or what specific artefact a regulator will ask to see six months later.
That gap — between operational competence and regulatory competence — is where otherwise well-run incidents turn into avoidable compliance failures. A resilience programme that doesn't teach PCI DSS, DORA, the UK CAF and NIS2 as first-class subject matter, rather than an appendix to "real" cyber incident response training, is teaching half the discipline.
Ask most incident response teams to run a cyber tabletop exercise and they'll handle detection, triage, containment and recovery with genuine competence. Ask the same team, mid-exercise, which specific regulatory clock just started running, what threshold just got crossed, and which authority needs to hear from them in the next four hours rather than the next four days — and the confidence usually drops sharply. That gap isn't a training failure in the conventional sense. It's evidence that most cyber resilience training treats regulation as background context rather than as one of the disciplines a responder actually needs to master.
This matters more now than at any point in the last decade, because four major frameworks — PCI DSS, DORA, the UK Cyber Assessment Framework (CAF), and NIS2 — have converged on a shared underlying idea: an organisation's technical response to an incident and its regulatory response to that same incident are no longer separable activities.
They happen in the same room, on the same clock, often executed by the same people. Training that keeps them in separate silos is training people for a version of incident response that no longer exists.
The starkest argument for regulatory literacy is arithmetic, not philosophy. Each of these frameworks attaches a specific, unforgiving timeline to specific decisions:
A team that understands containment brilliantly but has never internalised that DORA's 4-hour window starts at classification, not at detection, will burn most of that window arguing about whether the incident even qualifies as major. The technical response and the regulatory response are not sequential; they are concurrent, and a team trained only in the first is, by definition, only half-prepared for the second.
Every one of these frameworks turns on a judgment call made early and under pressure: is this incident significant enough to trigger reporting? Each framework answers that question differently, and the differences are exactly the kind of detail generic incident response training glosses over:
A responder trained to recognise "this is bad" has learned something useful but incomplete. A responder trained to recognise "this meets DORA's Article 18 test but not NIS2's Article 23(3) test, and here's why the difference matters for which authority gets called" has learned the actual skill these frameworks are testing for.
That distinction is not pedantry — it's the difference between a defensible regulatory position and a retrospective justification built after the fact, which regulators can and do tell apart.
A second reason regulatory study belongs inside resilience training, not beside it: these frameworks don't treat documentation as an administrative afterthought to incident response. They treat it as a structural precondition for a response to count as adequate at all.
Look at the shape of a complete incident response documentation set under any of these regimes and a pattern emerges.
NIS2's incident response documentation runs to 146 documents across 13 categories, of which 15 are explicitly mandatory.
DORA's equivalent set is also 146 documents across 13 categories, each mapped to a specific DORA article, RTS or ITS.
PCI DSS Requirement 12.10 alone — a single requirement number — decomposes into seven sub-requirements, each needing distinct evidence, drawing in supporting requirements from logging (Requirement 10), intrusion detection (Requirement 11), anti-malware and patching (Requirements 5 and 6), and third-party risk (12.8 and 12.9).
The UK CAF's incident response documentation, mapped against its own Indicators of Good Practice, splits into Core evidence (the artefacts an assessor expects to see directly) and Supporting evidence (everything that strengthens the picture without being the primary proof).
None of that volume is bureaucratic bloat. Each document exists because a specific decision, communication, or piece of evidence needs to be reconstructable after the fact — who classified the incident and when, what was communicated to which authority, what evidence supports the root cause finding, what changed in the plan as a result.
A responder who understands why the documentation exists, not just that a form needs completing, produces better evidence under pressure, because they understand what that evidence is actually for. Training that treats documentation as a separate compliance module, disconnected from the incident response skills being taught, produces people who can run an exercise cleanly and then fail the paperwork trail that same exercise was supposed to generate.
Perhaps the most underappreciated argument for studying these frameworks together, rather than one at a time, is that they don't agree on some fundamental questions, and understanding where they diverge teaches something generic "best practice" training can't.
Take board-level accountability. NIS2's Article 20(2) and DORA's Article 5(4) both explicitly require every individual member of the management body to undertake training, framed as a personal, ongoing obligation tied to real legal liability.
The UK CAF never uses the word "mandate" for board training at all. It's an outcome-based framework, and its Board Direction indicator (A1.a) simply cannot be satisfied without board-level competence, so the training obligation arrives implied rather than stated. The Cyber Governance Code of Practice then makes explicit what CAF leaves as an inference.
PCI DSS goes a third direction entirely: it names no board training obligation whatsoever, restricts its closest governance clause (Requirement 12.4.1) to service providers only, and directs its one genuine training requirement (12.10.4) downward toward operational incident responders rather than upward toward governance.
Three regulatory philosophies, three different structural choices, applied to the exact same underlying risk. A team trained on only one framework tends to assume its structure is simply "how cybersecurity governance works" and then misapplies that assumption the moment they operate under a different regime, or worse, under several at once.
An organisation subject to PCI DSS and NIS2 simultaneously cannot treat PCI's silence on board training as license to under-invest in the governance training NIS2 separately and explicitly requires. Recognising that these frameworks encode different regulatory philosophies — statutory governance mandate versus outcome-based assessment versus contractual operational standard — is itself a resilience skill, because most real organisations sit inside more than one regime at once and have to reconcile them without contradicting any single one.
Generic incident response training tends to reward speed and calm under pressure, both genuinely necessary, neither sufficient on its own. Regulatory frameworks add a dimension generic training doesn't naturally cover: precision under time constraint, where being close is functionally the same as being wrong.
A responder who classifies a DORA incident as major twenty minutes after the actual classification moment hasn't lost twenty minutes — they've compressed the 4-hour notification window by that same twenty minutes, on a clock with no extensions. A team that escalates a NIS2 incident based on operational disruption to the entity, but never separately assesses whether the incident also meets the "considerable damage to other persons" test, has applied half of Article 23(3)'s alternative-conditions structure and may have missed a reportable incident entirely, believing they'd correctly judged it as non-reportable. These aren't hypothetical training gaps — they are the exact failure modes that show up in post-incident and regulatory reviews, and they are specifically the kind of error that only gets caught by someone who has studied the regulatory text closely enough to know it isn't just a stricter version of common sense.
The practical implication isn't that every responder needs to become a compliance lawyer. It's that regulatory literacy needs to sit inside the same training curriculum as technical incident response, tested under the same pressure, rather than delivered as a separate module read once and filed away:
This is precisely the design philosophy behind NCSC Assured Cyber Security Training Courses and the Cyber Incident Planning & Response Course — building the operational and regulatory judgment together rather than as separate tracks, because that's how the decision actually gets made during a real incident. For the governance layer specifically, Cybersecurity Training for Executives and the Board Cyber Crisis Programme exist to close the exact gap this piece has been describing — leadership that can engage with the regulatory substance of a decision, not just receive a briefing about it after the fact.
Studying a regulation in the abstract only goes so far. The real test of literacy is whether an organisation's actual incident response documentation reflects the framework it's built against. This is where structured, framework-specific document libraries earn their place in a resilience programme, not as a shortcut around understanding the regulation, but as the concrete expression of having understood it.
The NIS2 Incident Response Document Library and its accompanying Master Document Register, the DORA Incident Response Document Library and DORA Master Document Register, and the PCI DSS Incident Response Document Library each map a specific regulatory text onto a specific, maintainable set of artefacts — turning the reading of a directive or standard into something a compliance and response team can actually build, own, and rehearse against.
1. Why isn't technical incident response training enough on its own for cyber resilience?
Technical skill determines how well an organisation detects, contains and recovers from an incident, but regulatory frameworks like DORA, NIS2, PCI DSS and the UK CAF attach specific classification judgments, reporting deadlines and documentation obligations to that same incident. A team that can't correctly classify an incident or recognise which regulatory clock has started is only prepared for half of what a real incident demands.
2. How do the reporting deadlines under DORA and NIS2 actually compare?
DORA requires an initial notification within 4 hours of classifying an incident as major, and no later than 24 hours from detection, followed by a 72-hour intermediate report and a one-month final report. NIS2 requires a 24-hour early warning, a 72-hour incident notification, and a one-month final report. The starting trigger differs: DORA's clock is anchored to classification, NIS2's to awareness of significance.
3. Does PCI DSS have the same kind of reporting clock as DORA or NIS2?
No. PCI DSS sets no fixed external reporting clock of its own; notification to payment brands and acquirers follows the payment brands' own contractual programmes and applicable law, rather than a statutory hour count written into the standard.
4. Why does the UK CAF not explicitly mandate training the way NIS2 and DORA do?
The UK CAF is an outcome-based assessment framework rather than a prescriptive statute, so it defines what a good governance outcome looks like (through Indicators of Good Practice) rather than instructing specific actions. Its Board Direction indicator cannot be satisfied without board-level training, making the requirement implied rather than explicitly stated, with the Cyber Governance Code of Practice spelling out the training expectation directly.
5. Why do these frameworks classify incidents differently instead of using one shared standard?
Each framework was built for a different regulatory purpose and scope. DORA's classification test is quantitative because it applies to a defined financial-services population where specific materiality thresholds make sense. NIS2's test is qualitative because it spans a much broader range of sectors and entity sizes, where a single numeric threshold would be either too strict or meaningless depending on the entity.
6. What happens if an organisation is subject to more than one of these frameworks at once?
The organisation has to satisfy each framework's obligations independently, since none of them defer to or replace the others. This means training and governance need to reflect the specific accountability structure of every applicable framework, since an obligation under one, such as NIS2's board training requirement, isn't satisfied simply because a different framework, such as PCI DSS, doesn't impose an equivalent obligation.
7. Why does documentation matter as much as the technical response during an incident?
Regulatory frameworks treat documentation as evidence of an adequate response, not as an administrative afterthought. NIS2 and DORA each require around 146 documents across 13 categories to fully evidence incident response, and PCI DSS's single Requirement 12.10 decomposes into seven sub-requirements needing distinct evidence, meaning a technically excellent response that isn't documented correctly can still fail a regulatory review.
8. How often should regulatory literacy in cyber resilience training be refreshed?
Given that DORA and NIS2's supporting technical standards and national guidance continue to evolve, and that annual incident plan exercising is an explicit expectation under the UK CAF's Cyber Governance Code of Practice, regulatory literacy should be refreshed at least annually and revisited immediately after any relevant regulatory update or real incident that tests the organisation's classification and reporting judgment.