AD6.10 Post-Incident Review and Improvement

Conducting the review

Schedule the post-incident review within 1 week of the incident — while the details are fresh. For a solo IT administrator, this is a 30-minute self-review using the incident report (AD6.9) as the source material. For teams, it's a 30-minute meeting with anyone involved in the response.

Question 1: How did we detect it?

Best case: your Monday review or alert notification caught it — the monitoring system worked as designed. Measure the time from compromise to detection (dwell time). If the compromise happened Saturday night and you detected it Monday morning, dwell time is ~36 hours. That's good for a weekly review cadence but could be improved with real-time notifications for this alert type.

Worst case: the incident was discovered by accident — a user noticed suspicious emails, a vendor called about a strange payment request, or the managed SOC found it during unrelated investigation. Accidental discovery means your monitoring missed it. Why? Was the sign-in anomaly not flagged by Entra ID Protection? Did the inbox rule creation not trigger a Defender alert? Was the alert generated but not configured for notification? Each miss is a specific monitoring gap to close.

Question 2: What could have prevented it?

Map the attack chain to your controls. For an AiTM → BEC attack: Did Safe Links catch the phishing URL? (If not: review Safe Links policies.) Did CA003 block the token replay? (If not: was the attacker's device compliant, or did they use a browser session that CA003 doesn't cover?) Did MFA registration require additional verification? (Entra ID can require users to re-authenticate with a strong method before registering new MFA devices — if the attacker registered an MFA method after compromise, this control was missing.)

Common prevention improvements: restrict MFA method registration (require re-authentication before adding new methods), implement conditional access token protection (preview feature that binds tokens to specific devices), add named location conditions to CA policies (block sign-ins from countries where you have no employees), and deploy phishing-resistant MFA for high-value accounts (FIDO2 security keys, which can't be phished via AiTM).

Question 3: What would we do differently?

Review the response timeline: was containment fast enough? Did you preserve evidence before acting? Did you notify the right people at the right time? Was the managed SOC coordination smooth?

Common response improvements: pre-build the PowerShell commands (don't type them during the incident), practice the procedure on a test account quarterly, improve the escalation contact sheet (add backup contacts), and refine the incident report template (add sections that were missing).

Turning findings into actions

Each post-incident review finding becomes a specific action item:

Add these action items to your quarterly report under "Improvements" — each completed action demonstrates that your security program learns from incidents and continuously improves.

After 4 incidents across a year, your post-incident findings reveal patterns: "3 of 4 incidents involved AiTM phishing → phishing-resistant MFA for executives is the highest-impact prevention measure." These patterns drive strategic security investments that are justified by incident data, not by vendor marketing.

Common improvements by incident type

After handling each incident type several times, you'll converge on these improvements:

After repeated AiTM compromises: Deploy phishing-resistant MFA (FIDO2 security keys or Windows Hello for Business) for executive accounts. These methods can't be phished via AiTM because the authentication happens on the physical device — there's no password or code for the proxy to capture. Cost: £25-50 per FIDO2 key. Impact: eliminates AiTM risk for protected accounts. This is the single highest-value improvement after your first AiTM incident.

Configure conditional access token protection (if available in your tenant). Token protection binds the access token to the specific device that authenticated — a stolen token can't be replayed from a different device. Navigate to entra.microsoft.com → Protection → Conditional Access → create a new policy → Session controls → "Require token protection for sign-in sessions." Note: this feature may still be in preview and has compatibility limitations with some client applications.

After repeated phishing clicks: Implement a phishing simulation program. Microsoft 365 E3 doesn't include Attack Simulation Training (requires E5 add-on), but third-party tools like KnowBe4, Proofpoint Security Awareness, or free tools like GoPhish can run simulated phishing campaigns. Track which users click simulated phishing links. Users who click repeatedly get additional training — not punishment. The goal is measurement and education, not enforcement.

After repeated BEC attempts: Implement a payment verification procedure with the finance team: any payment change, new vendor, or bank detail update received via email must be verified by phone using a known contact number (not the number in the email). This procedural control costs nothing and prevents the financial fraud that BEC is designed to achieve.

After any incident with delayed detection: Add or refine the specific alert notification that should have caught it earlier. If an inbox rule creation didn't generate a notification, configure a notification for "Suspicious inbox manipulation rule" alerts. If a sign-in from an unusual country didn't trigger an alert, review your Entra ID Protection risk detection settings.

Tracking improvements across quarters

Create a simple improvement tracker that persists across quarters:

=== IMPROVEMENT TRACKER ===

Q1 2026:
- [x] Configure MFA registration policy (from AiTM incident Jan)
- [x] Add inbox rule notification (from BEC incident Feb)
- [ ] Deploy FIDO2 keys for executives (procurement pending)

Q2 2026:
- [x] Implement payment verification procedure (from BEC incident Apr)
- [ ] Evaluate phishing simulation tool (from repeated clicks Q1)
- [ ] Add named location CA policy (block sign-ins from non-business countries)

Include this tracker in your quarterly report under "Security Improvements." Each completed item demonstrates continuous improvement driven by real incident data. Each pending item is a documented risk with a timeline — management can see what's done, what's planned, and what needs budget.

The improvement tracker is the connection between individual incidents and strategic security investment. Without it, each incident is an isolated event. With it, incidents are data points that build the case for specific improvements — each justified by a real event in your environment, not by a vendor's marketing claim.

Integrating findings into the quarterly report

Your quarterly management report (established in AD3.10 and expanded in AD4.10) gains a new section from AD6: Incident Summary.

"This quarter: [X] security incidents handled. [Y] compromised accounts contained (average containment time: [Z] minutes). [W] phishing campaigns scoped and purged. [V] improvement actions implemented. Key improvement: MFA registration policy added after Q1 AiTM incident — no repeat AiTM compromises since implementation."

The incident count, containment time, and improvement actions are concrete metrics that demonstrate operational security capability. Management sees: incidents happen (realistic), they're contained quickly (capability), and each one leads to improvements (maturity). This is more compelling than "no incidents" — which either means excellent prevention or poor detection.

Building the improvement backlog

After 2-3 incidents, you'll have more improvement actions than you can implement immediately. Create a simple improvement backlog:

Review the backlog quarterly. High-priority items should be completed within 2 weeks. Medium within 1 month. Low items are documented risks for future planning. The backlog demonstrates continuous improvement to auditors and management — each row is a specific, incident-driven security improvement.