After an incident, organizations often collect a long list of lessons learned and congratulate themselves on restoring service. Yet the revised contact list may never reach the night shift, or the failed supplier assumption may remain embedded in next year’s recovery plan. The real issue is the difference between recording an observation and changing a capability. A disciplined after-action process preserves the factual timeline, identifies material failure mechanisms and tracks improvements into operational evidence. It must treat an exercise and a real incident consistently enough to learn from both, while respecting the different reliability of their evidence.
01Secure the event record before memories diverge
Collect incident or exercise logs, communications, system timestamps, customer updates, workarounds and decisions as soon as it is safe. Staff recollections can be valuable but should be labeled and reconciled against primary records. Separate the time an incident was noticed, when a response was authorized and when useful service resumed; these are not interchangeable measures. Preserve evidence under the relevant data-retention and confidentiality rules.
Identify the operating scope and effects before judging individual choices. An actual flood may create conflicting safety and access obligations, while a tabletop cannot reproduce the physical limits of a damaged site. Ask observers to record uncertainties, omitted events and simulated intervals. This prevents a confident but unreliable narrative from becoming the official explanation for why recovery worked or failed.
Event integrity. Preserve distinct time markers for detection, activation, service restoration and stabilized operation. A recovered service may still have an unresolved backlog or a security limitation. Keeping that distinction prevents later reviews from turning a partial result into an unsupported success narrative.
Technical context: ISO 22301:2019 — Business continuity management systems — Requirements (with Amd 1:2024) is one verified source for the concepts discussed here.
02Distinguish symptoms from failed assumptions
A failed recovery contact is a symptom. The underlying problem may be missing ownership for updates, an inaccessible directory during an outage or an untested dependency on a mobile operator. The solution differs for each cause. Separate problems in plan design, strategy capacity, competence, governance, supplier agreements and technology; do not assume that rewriting procedure wording is a sufficient response to every finding.
Test each candidate cause against available evidence and alternative explanations. If an alternate workspace was unusable, was it because space was unavailable, credentials were invalid, necessary records were missing, or the building could not lawfully host the activity? Ask the affected process owner and a competent technical specialist to validate the conclusion. Document uncertainty rather than presenting an untested cause as fact.
Cause verification. If the team attributes failure to a late supplier response, examine whether the request reached the correct contracted emergency channel. A poorly designed internal authorization process can resemble external supplier unreliability; selecting the wrong root cause will produce ineffective procurement actions.
03Identify what was adaptive and worth keeping
Not every departure from the plan was a failure. Teams sometimes discover a safer sequencing decision or a more resilient communication path that the plan had not anticipated. Evaluate adaptations against legal requirements, customer commitments, data integrity and workforce safety. An improvised workaround may deserve formalization, but only after its risks and control needs are assessed.
Preserve the conditions under which the adaptation helped. A manual routing process that succeeds for ten urgent transactions may not scale to normal throughput. Record its capacity, authorized users, exception handling and reconciliation method. Without this context, a temporary success can be copied into the plan as an unrestricted alternative that later creates a different operational failure.
Adaptive practice. Capture why a workaround was safe under the actual conditions and what made it effective. A one-time manual approval can be controlled through a specialist’s oversight but unsafe without that specialist. Do not automatically promote every successful improvisation into a general permanent procedure.
04Prioritize corrective actions by consequence
Develop actions that change a particular capability: obtain dual-channel emergency contacts, contract for tested alternate capacity, create a delegated approval role or safeguard an offline data extract. A due date and owner are necessary but not sufficient. Describe the acceptance evidence that would demonstrate the corrected failure route. Avoid creating dozens of low-value editing tasks that obscure a few serious strategic defects.
If immediate exposure remains, implement temporary safeguards while a durable improvement is developed. For example, a manually checked contact cascade may be necessary until a new alerting service is proven. Record the residual risk and the authority accepting it. This keeps leadership aware that the team is operating under a provisional control rather than assuming a closed action means a solved risk.
Priority register. Separate critical recovery strategy failures from documentation tidy-up tasks. Escalate any weakness affecting life safety, legal duties or irreversible customer harm. Where a durable fix is delayed, define temporary safeguards and record who accepts the residual exposure.
05Update every artefact affected by the cause
One weakness may span the BIA, response roles, supplier continuity agreement, application recovery procedure, contact list and training materials. Map the correction across the connected documents and systems. A revised BCP that conflicts with an unchanged IT restoration runbook is not an improvement. Use controlled change management to make sure staff see the current instruction and obsolete copies are retired.
Include plan activation criteria, minimum service definitions and customer messages where the issue changed an important operating assumption. The approving authority should understand the operational consequences of the revision, not merely the changed text. Communicate targeted changes to the people who must use them at the point of disruption, and request acknowledgment where the change affects safety or critical authorization.
Change completeness. Trace the correction through contact lists, delegated authority records, provider agreements and affected training. A revised BCP that sends responders to an obsolete runbook is not a controlled improvement. Verify that the current version is available where users must act.
06Verify effectiveness with a focused re-test
A completed training slide or newly signed procedure is only implementation evidence. If the incident exposed an unreachable deputy, repeat a contact test without reliance on the original person. If data restoration produced inconsistent transactions, test a controlled recovery and reconciliation using realistic cases. Set the retest scope to the failed mechanism, avoiding the expense of repeating an entire exercise when it adds no diagnostic value.
Record expected criteria, what was tested, actual outcome and residual limitations. If the retest fails, reopen the action and reconsider its underlying cause. If it passes, review whether the new control has created a transfer of risk—for example, broader access rights that increase information security exposure. Effectiveness is the change in working capability, not the action tracker’s status field.
Effectiveness proof. Test the failed mechanism in a representative transaction or exercise, including the previously missing dependency. Report the test conditions and any residual limits. Closing an action after a training attendance record is insufficient where the original failure was an inaccessible system.
| Decision domain | Owner or objective | Observable evidence |
|---|---|---|
| Observation | Customer contact failure | Call attempt and timestamp |
| Cause | Unowned priority list | Version history and owner |
| Action | Validated supplier access | Approved change and access test |
| Effectiveness | Re-run contact scenario | Successful cascade with evidence |
07Use management review to identify repeating patterns
Aggregate findings by failure mechanism, critical service, location and change type, rather than only counting exercises completed. Trends may show repeated issues with external communications, alternate access rights or unowned dependencies. Management review should address whether selected recovery strategies remain credible, whether resources are sufficient and whether corrective actions have meaningfully reduced exposure.
Keep the record proportionate. A concise after-action narrative linked to an action register and evidence can be more useful than a long report with no closure mechanism. ISO 22301 sets BCMS requirements, while ISO 22313 and ISO 22398 give relevant application and exercise guidance; the organization selects a learning method appropriate to its disruption risk and operating complexity.
Governance signal. Repeated findings about emergency access may reveal a design or resource problem across the BCMS, not numerous unrelated employee errors. Management review should challenge strategy assumptions and fund the changes that frontline teams cannot authorize by themselves.
Practical Review Questions
- Can the team distinguish actual observations from recollections and simulated timestamps?
- Which failed assumption—not merely visible symptom—must change?
- Does the correction update every connected recovery instruction?
- What focused demonstration will close the effectiveness check?
Close the Learning Loop Before Declaring the Lesson Learned
Build a concise evidence chain that begins with a reliable event observation and ends with a verified capability change. The event owner should preserve the chronology and describe the consequences, while the control owner examines the causal mechanism. For each important finding, document the proposed correction, connected procedures and systems, temporary safeguards, decision authority and the evidence that will demonstrate effective implementation. Avoid using the same report to conceal unresolved safety, data or customer issues behind a generally positive restoration narrative.
Use a focused retest to decide whether the change works under conditions resembling the original failure. If a supplier escalation failed because of an obsolete authorization route, have a deputy activate the current route without help from the original contact. Review results at the BCMS management forum and keep actions open when their effectiveness remains unproven, even if the procedure itself has been updated.
Closing Perspective
Continuity plans improve when evidence from an event changes a defined operating control and a re-test demonstrates the improvement under the conditions that previously failed.
References & Further Reading
Official ISO publications informing the continuity method discussed above. Guidance publications provide recommendations; ISO 22301 contains BCMS requirements. The organization must validate any sector-specific legal duties separately.