Module 12 Lesson 3 of 6 🕑 ~40 min

> cat module-12-3-lessons-metrics-communications.md

Lessons Learned, Metrics & Communications

An incident isn't finished when systems return to production. This lesson covers what a mature organisation does next: learning from the incident without hunting for someone to blame, measuring performance honestly, and communicating clearly while everything is still on fire.

1 The Post-Incident Review

Once systems are back up, the organisation still has to ask: what can we learn from this? Different companies call it a Post-Incident Review (PIR), Post-Mortem, Root Cause Analysis, or After Action Review — the substance is the same. Useful questions span the whole lifecycle:

Before the incident
Why was the organisation vulnerable? Was the vulnerability known? Were controls missing? Were patches available? Was MFA enabled? Were administrators properly protected?
During detection
Which control detected the attack? How long had the attacker already been present? Which controls failed to catch them? Were alerts ignored?
During response
Was escalation fast enough? Did the right teams get involved? Were responsibilities clear? Could responders access the logs they needed? Were emergency contacts correct? Did containment actually work?
During recovery
Were backups available? Were restoration procedures documented? Did recovery meet RTO/RPO targets? Were dependencies actually understood?

2 Blameless Reviews

A mature organisation tries to understand failures rather than find someone to blame. Instead of "why did John click the phishing email?", ask "why did one successful phishing email allow enterprise compromise?"

🔮 Think it through

Reframe these into blameless, systems-level questions: (1) John clicked a phishing link. (2) The compromised account had domain admin rights. (3) The password hadn't changed in two years.

Reveal reframed questions

Why did the phishing message bypass controls in the first place? Why could this user's endpoint reach privileged systems at all? Why were credentials reusable for that long, and why wasn't rotation enforced? None of these blame John — they ask why the architecture let one human mistake cascade into an enterprise incident. Human mistakes happen constantly and are largely unavoidable; security architecture's job is to make sure one of them never becomes a global incident on its own.

3 Corrective Actions

Lessons learned should produce measurable actions, not vague aspirations. Compare:

BAD:  Improve security.

GOOD: Require phishing-resistant MFA for all privileged administrators
      by 30 November.
      Owner: IAM Team | Status: Open | Priority: Critical

GOOD: Deploy EDR to remaining 430 unmanaged Windows servers.
      Owner: Endpoint Security | Deadline: 15 December

A good corrective action has an owner, a deadline, and a way to verify it's actually done — and it gets tracked to completion, not filed away in a report nobody reopens.

4 Incident Response Metrics

MTTD
Mean Time To Detect — how long did it take to discover the compromise?
MTTA
Mean Time To Acknowledge — how long before someone started handling the alert?
MTTC
Mean Time To Contain — how long before the organisation stopped the attacker causing more damage?
MTTR
Mean Time To Recover (or Respond, depending on the organisation) — how long until services were restored?

Other useful measurements: number of affected systems/identities, amount of data affected, downtime, revenue impact, recovery cost, number of customers affected, incident recurrence, detection source, and initial access vector. Use metrics to improve security, not to pressure analysts into closing incidents prematurely — a team that hits great MTTR numbers by rushing containment before scoping is complete is optimising the wrong thing.

5 Internal Communication Structure

Communication is one of the most underestimated parts of incident response. During a major incident, hundreds of people may be asking what happened, are we compromised, when will systems return, was customer data stolen, should employees disconnect laptops, can customers use the service, should we contact regulators or law enforcement? Incorrect information spreading through the organisation can cause panic or create real legal exposure.

Major incidents normally run a dedicated communication structure with clearly separated layers:

Technical bridge     SOC + IR + Infrastructure + Cloud
Management bridge    Incident Commander + CISO + CIO
Executive updates    CEO + Board + Legal
External comms       PR + Legal + Customer Communications

Technical investigators should never individually give speculative explanations directly to executives or customers — information gets consolidated and verified through the structure first, exactly so one person's guess doesn't become the organisation's official position.

6 Out-of-Band Communications

If attackers control corporate systems, they may be able to read email, Teams, Slack, internal tickets and shared documents — the very channels the response team would normally use to coordinate. Serious incident plans therefore include an independent communication method: emergency phones, a separate collaboration tenant, a pre-created external conferencing service, or paper emergency contact lists. CISA specifically recommends considering out-of-band communications during ransomware response, precisely because attackers may be monitoring the organisation's normal channels while the response is being planned inside them.

7 Situation Reports

Major incidents run on regular situation reports (sitreps) — a consistent format that gives management reliable information without drowning them in forensic detail:

INCIDENT: Enterprise Ransomware
SEVERITY: SEV1
STATUS: Containment

KNOWN IMPACT:
  137 endpoints, 12 servers
  Finance file share unavailable

CURRENT FINDINGS:
  Initial access likely VPN account compromise.
  Evidence of lateral movement under investigation.

ACTIONS COMPLETED:
  Compromised VPN account disabled.
  Affected hosts isolated.
  Firewall IOCs blocked.
  Backups isolated.

NEXT ACTIONS:
  Determine Domain Controller impact.
  Validate backup environment.
  Continue threat hunting.

NEXT UPDATE: 14:00 UTC

Notice what it deliberately leaves out: no PowerShell command lines, no MITRE technique IDs, no raw log excerpts. It's built for a management audience, on a predictable cadence, with a clear "next update" time so people aren't left refreshing their inbox wondering if anyone's still working the problem.

Lesson Outcome

You should now be able to run a blameless post-incident review, write a corrective action that's actually trackable, explain MTTD/MTTA/MTTC/MTTR and why metrics can be misused, describe the layered communication structure a major incident needs, explain why out-of-band communications matter, and write a situation report a CISO could actually use. Lesson 4 zooms out further — regulatory reporting obligations, what a mature IR architecture actually looks like, and the incident types beyond ransomware.