Lesson Overview
The service is back. The compromised account is locked, the credentials are rotated, the clean backup is restored and validated, and the screens are green again. For a tired team it is tempting to treat that moment as the end. It is not. The most valuable part of a cyber incident is what happens after the danger has passed, when a calm team works out honestly what occurred and changes something so the same gap does not open twice. An incident the Principality merely survives teaches nothing. An incident it learns from makes it permanently harder to harm.
This lesson closes the loop the whole course has been building. Lesson 01 prepared for the bad day; Lesson 02 detected and analysed the event; Lesson 03 contained, eradicated, and recovered; Lesson 04 gave you defensive playbooks; Lesson 05 kept the essential functions running through the disruption. Now you learn the final phase of the incident lifecycle: post-incident activity. You will run a blameless lessons-learned review, turn its findings into real changes to controls, policies, and playbooks, feed those lessons back into the framework functions so the gap is closed at the root, and make the honest disclosures and reports that duty and law require. Through all of it runs one cultural point on which everything else depends: in this speciality, reporting a mistake is help, not failure.
This is the knowledge layer. The judgement here, what counts as a real fix, when a disclosure is required, how to set an honest tone in a review, is learned by doing, and the practical parts (running a review after a tabletop exercise, drafting a post-incident report, walking a finding back into a hardened control) are practised and signed off in person where supervision allows. By the end you will be able to explain why the post-incident phase is part of the response and not an optional extra, run a blameless lessons-learned review that produces specific owned changes, update controls and policies and playbooks so a lesson sticks, feed lessons back into the Govern, Identify, and Protect work of the framework so the same weakness does not recur, make responsible and honest disclosures and reports where they are required, and explain and uphold the no-blame culture that makes early honest reporting the Principality's first and best defence.
Key Terms
- Post-incident activity: the final phase of the incident lifecycle, in which the team reviews what happened, learns from it, and improves, so the response is not finished when the service is restored but when the lessons are captured and applied.
- Lessons-learned review: the structured meeting, held soon after an incident closes, that asks what happened, what worked, and what to fix, and turns the answers into changes. Often called a post-incident review or, in operational language, a post-mortem.
- Blameless: attacking the weakness in the system and the process, not the person who tripped over it, so people speak openly and the real cause is found. Blameless is not consequence-free for genuine negligence or dishonesty, which are matters of discipline handled elsewhere.
- Root cause: the underlying weakness that allowed the incident, found by asking "why" past the first easy answer, as distinct from the surface event or the person nearest to it.
- Corrective action: a specific, owned, recorded change made because of a finding. A finding without a corrective action has been noticed, not learned.
- Playbook: the written step-by-step drill for handling a given type of incident (the kind built in Lesson 04). Playbooks are living documents, updated after every incident that tests them.
- Responsible disclosure: telling those who have a right or need to know, the affected people, the proper authority, and any partner whose systems are touched, in an honest, timely, and measured way, neither hiding the harm nor causing further harm by how it is told.
- Govern, Identify, Protect: three of the six functions of the recognised cybersecurity framework. Govern sets strategy, policy, roles, and oversight; Identify knows the assets and risks; Protect puts the safeguards in place. These are the functions a post-incident lesson usually flows back into.
- No-blame culture: the climate, set above all by leaders, in which a member who has made a mistake or fallen for a lure reports it at once because they know they will be helped, not punished, for the honest early report.
Why the response is not over when the service is back
Picture two small forces, each hit by the same kind of incident: a member fell for a convincing phishing message, an account was taken over, and a handful of records were exposed before the takeover was spotted and stopped. Both forces respond competently. Both contain the compromise, rotate the credentials, restore from a clean backup, and bring the service back the same day. To an outside eye they look identical, and on the day they were.
A year later they are not. The first force treated the restored service as the finish line, stood down, and moved on. It never asked why the lure worked, why the takeover ran undetected, or whether the same trick would work again, so all three weaknesses stayed in place, and over the year the same kind of incident happened twice more, each time paid for in full. The second force treated the restored service as the start of the most important phase. It sat down within days and found that the lure worked because the member had no quick way to report a suspicious message, that the takeover ran undetected because no alert was set on logins from new locations, and that the records were reachable because an everyday account had standing access it did not need. It fixed all three. The same trick, tried again three months later, was reported in two minutes, flagged by an alert, and reached nothing of value. The second force did not have better luck. It had the discipline to learn.
WHY THE POST-INCIDENT PHASE IS PART OF THE RESPONSE
Restored service is the MIDDLE of the work, not the end.
recognise -> report -> contain -> eradicate -> recover -> | LEARN |
(service (close
back) the loop)
Without the last step: With it:
same lure works again root cause fixed
same blind spot stays detection improved
same weak access remains least privilege tightened
| |
incident repeats, paid in full the gap does not recur
| |
no stronger in a year permanently harder to harm
An incident survived teaches nothing. An incident learned from
makes the Principality stronger than it was before the bad day.
For a small humanitarian home-defence force serving a digital state, this is not a refinement, it is a necessity. The Army is young and has no long history of incidents whose lessons an earlier generation already paid for. Almost everything this speciality will know, it will learn from its own events, most of them small. A force that learns honestly and quickly from small incidents will be ready for a large one; a force that only survives its incidents will meet each one as if for the first time, forever. The post-incident phase is where survival is converted into strength, and it is part of the response, not an afterthought to it.
The blameless lessons-learned review
The engine of the post-incident phase is a single meeting, held soon after the incident closes, while memory is fresh and before the team scatters. It is the incident-response cousin of the after-action review taught in Junior Leadership, and it runs on the same honesty. Its job is to answer three plain questions for everyone in the room, then turn the answers into change:
THE LESSONS-LEARNED REVIEW: THREE QUESTIONS, THEN ACTION
WHAT HAPPENED? <-- one agreed, factual timeline of the
| incident, plainly, with no blame yet
| (when detected, when contained, what
v was touched, what we did and when)
WHAT WORKED? <-- name what to KEEP: the alert that fired,
| the backup that restored, the fast report
| (a review that only finds faults wears
v the team down and misses what saved you)
WHAT TO FIX? <-- the gaps, traced to ROOT CAUSE, not to
| the nearest person; the surface answer
| is rarely the real one
v
CORRECTIVE ACTIONS <-- each fix made SPECIFIC, OWNED, RECORDED,
and given a date; this is the whole point
Hold it soon, and prepare it. Hold the review within days of closing the incident, while the timeline is fresh and the excuses have not yet hardened. Someone, usually the member who kept the incident record through the response, brings the facts: the timeline built in Lesson 02, the actions logged with their times, what was affected, and how it ended. The review examines a shared account, not competing memories.
Build one honest account first. Agree what happened in plain facts, with no judgement and no causes yet. When was the event first detected, and by what? When was it contained? What was touched, which accounts, which records, whose data? What did the team do, and when? Agree this before anyone reaches for a "why," because the moment blame enters, the facts bend to fit whoever is defending themselves.
Name what worked. A review that only hunts for faults teaches the team to dread it and misses half the lesson. Name what to keep: the alert that fired, the offline backup that restored cleanly, the member who reported in two minutes, the playbook step that held under pressure. The team needs to know what saved it as much as what failed it, and naming the wins keeps the review safe to be honest in.
Find the real cause, not the nearest person. This is the heart of the review and the step most often botched, because people stop at the first answer. "The account was taken over because Private B clicked the link" is an answer, but it is the surface, and a person, not a problem. Keep asking. Why did the link work? The message looked like a genuine internal notice and there was no fast way to check it. Why did the takeover run undetected? No alert was set on logins from new locations. Why did it reach records? An everyday account carried standing access it did not need. Now you have causes worth fixing, and not one is "Private B is careless." They sit with the controls, the detection, and the access design, which is to say with the system, which is to say with us.
Turn each fix into a corrective action. The review earns its keep here or not at all. Every fix becomes a corrective action that is specific enough to do, owned by a named person, recorded where it will be seen again, and given a date. "Be more careful" changes nothing. "Add a one-click report-phishing path and brief it to all members by the end of the month, owned by the section's systems assistant" changes behaviour. A review that ends in a shared nod, then nothing, has failed however honest it was. The point is not insight, it is change.
Updating controls, policies, and playbooks
A corrective action is a promise. It becomes real only when it is built into the way the force actually works, and there are three places a lesson lands.
WHERE A LESSON LANDS (so it cannot leak away)
CONTROLS the technical safeguards: an alert added, an access
right removed, MFA made phishing-resistant, a patch
applied, a backup schedule tightened and its restore
re-tested. The fix that stops the cause directly.
POLICIES the written rules and standards: who may hold what
access, how fast a lost device is reported, what an
everyday account is allowed to reach. The rule that
keeps the control in place after attention moves on.
PLAYBOOKS the response drills (Lesson 04): a missing step added,
a slow step reordered, a contact list corrected, a
decision made clearer. The next response goes faster
because this one taught it how.
Controls are the technical safeguards, and the most direct place a fix lands. The takeover that ran undetected becomes an alert on logins from new locations. The everyday account with standing access becomes least privilege properly applied (the rule from CIS 220 and the specialities framework: access follows appointment, and an account gets only what its role needs). The lure that worked becomes phishing-resistant MFA where it can be deployed, so a stolen password alone is not enough. The hole that was used becomes a patch applied and a configuration corrected. If the incident exposed a backup that could not be restored cleanly, the control is a tested restore, because an untested backup is a hope, not a control.
Policies are the written rules that keep a control in place after the incident fades from memory. A control applied once decays; a policy makes it the standard. If a lost device took too long to report, the policy sets the standard plainly: report a lost or stolen device at once so its access and certificates can be revoked. If an account held access it should not have, the policy restates who may hold what, and access reviews check it stays true. Policies are how the Principality stops relying on everyone remembering and starts relying on a standard that is written, briefed, and enforced.
Playbooks are the response drills built in Lesson 04, and they are living documents. Every real incident tests the playbook that covers it, and the review is where it is corrected: a missing step added, a slow step reordered, a wrong contact list put right, a decision point made clearer so the next responder does not hesitate where this one did. A force that updates its playbooks after every incident gets faster and surer over time; one that leaves them static repeats the same fumbles. The same discipline reaches the rehearsals: a tabletop exercise (Lesson 01) is run again with the new scenario so the lesson is drilled before the next real test, not after it.
Feeding the lesson back into Govern, Identify, and Protect
The deepest fixes do not stop at one control or one playbook. They flow back into the framework functions that shape the whole posture, so the gap is closed at the root rather than patched at the surface. The lifecycle you have followed is itself mapped onto these functions: when the Respond and Recover work is done, the lessons feed back into Govern, Identify, and Protect, which is what turns a one-off response into a permanent improvement.
THE LEARN-AND-IMPROVE LOOP, BACK INTO THE FRAMEWORK
+-----------------------------------------------+
| |
v |
GOVERN ----> IDENTIFY ----> PROTECT ----> DETECT |
(strategy, (assets, (safeguards, (spot it) |
policy, data, MFA, access, | |
roles, risks) training) v |
oversight) RESPOND |
^ (act) |
| | |
| v |
| RECOVER |
| (restore) |
| | |
| <----- LESSONS LEARNED <-------------+-------+
| (post-incident activity)
|
A lesson does not stop at the fix. It flows back:
-> GOVERN : the takeover showed a role and decision were unclear,
so update policy, roles, and oversight.
-> IDENTIFY : the incident reached an asset nobody had inventoried,
so update the asset and risk picture.
-> PROTECT : the lure worked and access was too broad, so harden
MFA, access control, and awareness training.
Same gap cannot recur, because the function that owns it has changed.
Govern owns strategy, policy, roles, and oversight. If the incident showed that nobody was sure who decides to take a service offline, or that a policy was silent where it should have spoken, the lesson belongs here: the role is clarified, the policy written or corrected, and oversight set so the change is checked. Govern is where "this kept being unclear" becomes "this is now decided and written down."
Identify owns the knowledge of assets, data, and risks. Incidents have a way of reaching things nobody had listed: a service not on the inventory, records whose sensitivity was underrated, a dependency nobody had mapped. The lesson updates the picture, so the next risk assessment is honest about what exists and what it would cost to lose.
Protect owns the safeguards, and it is where most technical lessons land for good: access control tightened to least privilege, MFA moved toward phishing-resistant methods, secure configuration corrected, and, crucially, awareness training improved. If a lure worked, the training gains that real example (anonymised, never to shame the member who reported it) so the whole force can recognise the next one. A lesson fed into Protect is a lesson made into a standing defence.
Feeding lessons back into these three functions closes the gap at the level that owns it, so the same weakness cannot recur. A patch on one host fixes one host; a Govern, Identify, or Protect change fixes the class of problem across the force. This is the loop that makes the whole cycle, preparation, response, continuity, and learning, into one continuous process rather than a series of separate fire-fights. Some lessons are bigger than one section and must be passed up the chain so the whole speciality learns once instead of every section learning the hard way, exactly the staff discipline of honest review that runs through the Army's resilience work.
Honest disclosure and reporting
Some incidents carry a duty that reaches beyond fixing our own systems: a duty to tell others who have a right or need to know. This is responsible disclosure, and it is a matter of honesty and law, not of public relations. It is also strictly defensive: disclosure tells and warns, it never retaliates.
Who must be told depends on what happened. Where personal data has been exposed, the affected people and the proper authority must be told as duty requires, honestly and in good time, so they can protect themselves; this is the data-breach playbook's notify step (Lesson 04), and it is not optional because it is uncomfortable. Where a partner's systems or a shared service are touched, that partner is told so they can defend themselves too. Where an incident is or may be a crime, ransomware almost always is, the proper authorities are involved; the team preserves evidence and does not take matters into its own hands. And inside the force, the incident is reported up the chain through the proper channel, because the Principality cannot govern a risk it has not been told about.
RESPONSIBLE DISCLOSURE: TELL, HONESTLY AND IN GOOD TIME
WHO WHY TONE
affected people they can protect themselves honest, plain,
(their data) (change passwords, watch no spin, no
for misuse) minimising
proper authority duty and law require it; factual, timely,
(breach / crime) they may need to act complete
partner / shared their systems may be at risk prompt, candid,
service what they need
up the chain the force must govern the full, with the
(own command) risk it cannot see timeline and facts
NEVER hide it, delay to look better, or downplay the harm.
NEVER "hack back," name-and-shame, or retaliate. Disclosure
warns and informs; it does not strike. Defensive and lawful only.
The tone of disclosure matters as much as the fact of it. Tell the truth plainly: what happened, what data or systems were affected, what the force has done, and what the person or partner should do. Do not spin it, delay it to soften it, or minimise harm that is real, because a dishonest disclosure compounds the original failure with a second, worse one, a breach of trust. Equally, do not cause fresh harm by how you tell it. The Principality discloses to inform and to warn, never to retaliate. There is no "hacking back," no naming and shaming, no striking at a supposed attacker; the speciality is defensive and lawful, and that line holds firmly through the post-incident phase as through every other.
The no-blame culture
Everything in this lesson rests on one foundation, and without it the rest collapses: a member who has made a mistake, fallen for a lure, lost a device, clicked the link, must report it at once, and will do so only if they are sure they will be helped and not punished for the honest early report. This is the no-blame culture, and in this speciality it is not a kindness, it is a defence.
The reasoning is exact. The greatest danger in any incident is the time between the mistake and the report, because that is the window in which the attacker works unopposed. A member who clicks a link and reports it in two minutes hands the team a fighting start: revoke the session, reset the credential, contain the harm before it spreads. A member who hides the same click for fear of trouble hands the attacker an hour, a day, a week, and a small mistake becomes a large breach. The single most expensive thing a force can do to its own security is to make people afraid to report, because fear does not prevent mistakes, everybody makes them, it only delays the reports, which is the one thing that actually matters. So the rule is firm: reporting a mistake is help, not failure. The member who reports a clicked link has not failed the team; they have given it the early warning that is the alert human's whole value, the first and best line of defence.
Blameless does not mean consequence-free, or it curdles into "nobody is responsible for anything." Genuine negligence, dishonesty, hiding an incident, or a wilful refusal to meet a known standard are matters of discipline and conduct, dealt with properly and usually in private, as Military Customs, Discipline, and Conduct teaches. But the ordinary honest mistake, the convincing lure, the device left on a train, the click that looked safe at the time, is exactly what the no-blame culture protects, because punishing those teaches only concealment, and concealment is what kills. The tone is set by leaders before any incident occurs: a leader who attacks the weakness in the system rather than the person nearest to it, and who thanks the member who reported rather than rebuking the member who erred, builds a force that reports early and learns fast. A leader who hunts for someone to blame builds a force that hides, and a force that hides cannot be defended.
In Practice: The Review After the Account Takeover
A small RKA section's systems assistant, a corporal in the Information Systems and Cyber Security speciality, has just closed an incident. A private fell for a convincing message that looked like an internal notice, entered their single sign-on credentials on a fake page, and the account was taken over. A login alert eventually fired, the corporal revoked the active sessions, reset the password, confirmed MFA, checked for sneaky changes (a mail-forwarding rule had been added, and was removed), and notified up the chain. A small number of records had been viewable for about forty minutes. The service is back and the account is secure. The corporal knows the work is not finished.
Within two days the corporal runs a blameless lessons-learned review. The private is in the room, and the corporal opens by making it safe: "This is not about whose fault it was. You reported it the moment you doubted it, and that fast report is why we contained this in minutes instead of days. Thank you. We are here to find what let it happen and fix it." They build one honest timeline, name what worked (the alert fired, the offline backup was sound, the report was fast), then push the why past the easy answer. The lure worked because there was no quick way to check or report a suspicious message. The takeover ran undetected because the alert was set only on failed logins, not on a successful login from a new location. The records were reachable because the everyday account carried standing access it did not need.
THE ACCOUNT-TAKEOVER REVIEW, AND WHERE EACH LESSON LANDS
WHAT WORKED fast report; login alert; clean offline backup -> KEEP
ROOT CAUSES CORRECTIVE ACTION LANDS IN
----------- ----------------- --------
no fast way to check/ one-click report path, PROTECT
report a suspect message briefed to all members (awareness +
(corporal, this month) control)
alert only on failed add alert on login from PROTECT /
logins, not new-location a new location DETECT control
success (corporal, this week)
everyday account had apply least privilege; PROTECT +
standing record access access follows POLICY
it did not need appointment (this month) (access rule)
policy silent on who clarify role and write GOVERN
may hold record access it into standard (policy/roles)
-> playbook updated: add "check for added forwarding rules" as a
standing step. -> data-breach disclosure made to the affected
people and the proper authority, honestly and in good time.
Each fix becomes a corrective action that is specific, owned, recorded, and dated. The corporal takes the one-click report path and the new-location alert; least privilege is applied to the account and written into policy so it stays applied; the gap in who may hold record access goes up to Govern as a policy and role clarification. The phishing playbook gains a standing step to check for added forwarding rules, because this incident showed why it matters. Because real records were exposed, the corporal makes the honest disclosure the data-breach playbook requires: the affected people are told plainly what happened and what to do, and the proper authority is informed, in good time and without spin. None of it retaliates against anyone; all of it makes the section permanently harder to harm. And the private, far from being punished, becomes the section's best example of the thing that worked, the fast honest report, told anonymously in the next awareness brief so the whole force learns the lesson without anyone being shamed for it.
Check Your Understanding
- Explain why the response to a cyber incident is not over when the service is restored, using the two-forces comparison from the start of the lesson. What does the post-incident phase convert survival into, and why does this matter especially for a young force with little incident history of its own?
- A lessons-learned review must find the root cause, not the nearest person. Take the account takeover where a member clicked a link, and show the difference between stopping at "the member clicked" and pushing the "why" to its real causes. Where do those causes then land, controls, policies, playbooks, and which framework functions (Govern, Identify, Protect) do the deepest lessons feed back into, and why does feeding them back close the gap so it cannot recur?
- The no-blame culture holds that reporting a mistake is help, not failure. Explain the exact reasoning: why is the time between a mistake and its report the dangerous window, why does punishing honest mistakes make a force less secure rather than more, and what does "blameless is not consequence-free" mean in practice? Separately, state who must be told when an incident exposes personal data, and why responsible disclosure is honest and defensive but never retaliation.
Reflection (write a short paragraph): This lesson argues that an incident the Principality merely survives teaches nothing, while one it learns from makes it permanently stronger, and that the whole of this learning depends on people being willing to report their mistakes honestly and early. Think of a time, in the Army or out of it, when you or a group either learned honestly from something that went wrong or failed to. Work through what happened, what worked, and what should have been fixed, and ask where the real cause lay, in a person or in the system around them. Then ask the harder question of yourself: when you make a mistake that could expose a problem, what is your honest first instinct, to report it at once or to hope it goes unnoticed, and what would a force have to be like for the early honest report to feel like the help this lesson says it is rather than the confession it can feel like?
Summary
- The response is not over when the service is back. Post-incident activity, the final phase of the incident lifecycle, is where survival is converted into strength; an incident merely survived teaches nothing, while one learned from makes the Principality permanently harder to harm. This matters most for a young force learning almost everything from its own events.
- The engine is the blameless lessons-learned review, held soon after the incident closes: build one honest timeline (what happened), name what to keep (what worked), trace gaps to root cause not the nearest person (what to fix), and turn every fix into a corrective action that is specific, owned, recorded, and dated.
- Lessons land in three places: controls (the technical safeguard that stops the cause), policies (the written rule that keeps the control in place), and playbooks (the Lesson 04 drills, kept living and updated after every incident, with rehearsals re-run).
- The deepest lessons feed back into the framework's Govern (strategy, policy, roles, oversight), Identify (assets, data, risks), and Protect (access control, MFA, awareness training) functions, which closes the gap at the level that owns it so the same weakness cannot recur, and makes preparation, response, continuity, and learning one continuous cycle rather than separate fire-fights.
- Make honest, responsible disclosures where duty and law require: tell the affected people and the proper authority when data is exposed, the partner when shared systems are touched, the authorities when an incident is a crime, and the chain of command always. Tell it plainly and in good time, never hidden, spun, or used to retaliate. Strictly defensive and lawful: no "hacking back."
- All of it rests on the no-blame culture: reporting a mistake is help, not failure, because the dangerous window is the time between the mistake and the report, and a force that punishes honest mistakes only teaches concealment. Blameless is not consequence-free; genuine negligence and dishonesty remain matters of discipline. This builds on the after-action review of Junior Leadership and on the honest review used in HCR 220, and it draws on the disciplined mindset of SIG 220 and the reporting discipline of PME 210.
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia