Learning from Exercises
How learning from exercises becomes real change, through honest debriefs, owned actions, retesting and sharing lessons without blame or softening findings.
The short answer
Learning from an exercise means turning what happened during the rehearsal into changes that can be seen in the plan, the procedure, the contacts, or the service itself. An exercise that ends with a report that nobody acts on has produced a document, not learning. Learning requires honesty about what went wrong, ownership of each change, and a later check that the change works. It also requires a culture in which admitting a gap is treated as useful, because teams that fear blame will soften their findings and the firm will keep rehearsing the same flaws. The measure of learning is not the quality of the report, but the difference between the next exercise and the last one.
What makes a debrief honest?
A debrief is honest when it separates description from judgement and when it welcomes disagreement. Description states what happened, in what order, and what was decided. Judgement then asks whether those decisions were sound, given the information available at the time, rather than with hindsight. A useful debrief invites participants to name what confused them, what information they lacked, and what they would do differently, without fear that candour will be held against them. Observers contribute evidence from their notes, which helps prevent the debrief from becoming a contest of memory. The facilitator should also ask what was not tested, so that gaps in the exercise itself are recorded rather than mistaken for strengths.
How are actions owned and tracked?
Actions from an exercise should be specific, owned by a named person or role, and tied to a weakness found during the exercise. A vague action such as improving communication is unlikely to lead to change, while a specific action such as updating a contact route, revising a customer message template, or clarifying who can pause a service can be checked. Tracking should show whether each action has been completed, and should keep overdue actions visible rather than allowing them to fade. Actions that are repeatedly deferred deserve attention, because deferral may signal that the action was unrealistic, that ownership was unclear, or that the underlying problem is harder than the exercise suggested. In each case, the tracking record should say so plainly.
Why does learning require retesting?
Learning requires retesting because a change that has not been tested is only a hypothesis. If an exercise found that a workaround failed, the revised workaround should be tested in a later exercise, under conditions similar enough to be meaningful. If a contact route was updated, the next exercise should require participants to use it. Retesting closes the loop and gives participants a reason to take actions seriously, since they know the change will be examined again. It also reveals whether a change created a new problem, such as a revised procedure that is clearer on paper but slower in practice. A firm that retests shows that it treats exercises as part of a cycle, not as isolated events.
How should lessons be shared?
Lessons should be shared with the teams that need them, in a form they can use, without turning the exercise into a story about individual failure. A lessons note might describe the gap, the change made, and the retest result, so that another service facing a similar risk can learn without repeating the exercise. Sharing should respect confidentiality where needed, but it should not hide the gap itself, since a lesson that omits the problem teaches nothing. Cross service sharing is particularly valuable for common weaknesses, such as outdated contacts, unclear authority, or workarounds that depend on one person. When sharing works, a lesson learned in one service prevents a failure in another, which is a strong return on the time spent exercising.
What does false learning look like?
False learning looks like activity without change. It includes reports that praise teamwork while omitting gaps, actions that are marked complete when only a document was updated, and retests that avoid the original weakness. It also includes learning that is recorded but never reaches the people who would act on it, such as a front line team that still uses an old procedure because nobody told them it changed. The antidote is evidence: a changed plan that can be shown, a contact that can be dialled, a workaround that can be demonstrated, or a decision rule that can be quoted. If learning cannot be shown in that concrete way, it should be treated as incomplete, however good the exercise felt at the time.
Primary sources on the record
- Financial Conduct Authority, operational resilience: the UK regime, labelled separately from DORA.
- European Union Agency for Cybersecurity, ENISA: incident response and resilience practice, cited as practice, not law.
- National Institute of Standards and Technology, Computer Security Resource Center: resilience and incident guidance, cited as practice, not law.
Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.