In this module

AD6.9 Documenting the Incident

5-6 hours · Module 6 · Free

Operational Objective

Every incident needs documentation — for your manager (what happened and what was the impact), for compliance (GDPR assessment, regulatory notification), for your quarterly report (incident metrics), and for future reference (what did we learn). Incident documentation written during the response is accurate. Documentation reconstructed from memory weeks later is incomplete and unreliable. This subsection provides the incident report template — a structured format you fill in during and immediately after the response, covering the timeline, the impact assessment, the containment actions, the data exposure assessment (for GDPR), and the improvement recommendations.

Deliverable: An incident report template with specific sections for timeline, impact, containment, data exposure, and recommendations — plus a GDPR assessment framework for determining whether the incident triggers notification obligations.

Estimated completion: 25 minutes

Figure AD6.9 — The 6-section incident report. Each section serves a different audience: summary for everyone, timeline for technical review, impact for management, containment for audit, GDPR for legal, improvements for future prevention. Fill in each section during and immediately after the response.

The incident report template

Save this template as C:\SecurityScripts\IncidentReportTemplate.md. Copy it for each new incident:

# Incident Report — [Incident Type]
## Date: [Date]   |   Reference: [Defender Incident ID]

### 1. Summary
- **Incident type:** [Compromised account / Phishing / BEC / Other]
- **Affected user(s):** [UPN]
- **Discovery method:** [Monday review / Alert notification / User report]
- **Current status:** [Contained / Under investigation / Resolved]

### 2. Timeline
| Time (UTC) | Event |
|---|---|
| [timestamp] | Initial compromise (phishing email delivered) |
| [timestamp] | Attacker sign-in from [IP] ([location]) |
| [timestamp] | Attacker activity (inbox rules, email reads) |
| [timestamp] | Incident discovered by [method] |
| [timestamp] | Sessions revoked |
| [timestamp] | Password reset |
| [timestamp] | MFA methods reviewed — [suspicious method removed] |
| [timestamp] | Inbox rules removed — [rule details] |
| [timestamp] | Investigation complete |

### 3. Impact Assessment
- **Emails accessed:** [count] emails read during compromise period
- **Emails forwarded externally:** [count] to [external address]
- **Files accessed:** [description or "None identified"]
- **Financial exposure:** [description or "None identified"]
- **Business disruption:** [user locked out for X hours]

### 4. Containment Actions
- [ ] Sessions revoked (Revoke-MgUserSignInSession)
- [ ] Password reset (force change)
- [ ] MFA methods cleaned ([details of removed methods])
- [ ] Inbox rules removed ([rule names and destinations])
- [ ] OAuth consents reviewed ([findings])
- [ ] Mailbox delegates reviewed ([findings])
- [ ] Evidence preserved to [evidence directory path]

### 5. GDPR Assessment
- **Personal data accessed?** [Yes/No — describe what personal data]
- **Personal data exfiltrated?** [Yes/No — describe what was forwarded]
- **Notification required?** [Assessment based on GDPR Article 33]
- **Data subjects to notify?** [If Article 34 applies — which individuals]
- **72-hour clock started:** [timestamp of when you became aware]

### 6. Improvement Recommendations
- **Root cause:** [How the compromise occurred]
- **Prevention:** [What control would have prevented it]
- **Detection improvement:** [Was detection fast enough?]
- **Procedure update:** [Any changes needed to the response procedure]

UK GDPR Article 33 requires notification to the ICO within 72 hours of becoming AWARE of a personal data breach. Not 72 hours from the compromise — 72 hours from when you discovered it.

Three questions determine whether notification is required:

1. Was personal data accessed? If the attacker read emails containing employee NINOs, client addresses, or health information — personal data was accessed. If the attacker only read emails about project schedules and meeting agendas — no personal data was accessed.

2. Is there a risk to individuals? If personal data was forwarded to an external address (the attacker has it), there's a risk to the individuals whose data was exposed. If personal data was read but not exfiltrated (the attacker saw it but didn't copy it), the risk is lower but still exists.

3. Does the risk require notification? The ICO guidance states that notification is required unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons." In practice: if financial data (bank details, credit card numbers) or identity data (NINOs, passport numbers) was exfiltrated, notification is almost certainly required. If internal-only data (employee names and job titles) was accessed but not exfiltrated, notification may not be required.

Your role: Complete Section 5 of the incident report with your assessment. Forward it to your DPO or legal counsel for the notification decision. You identify the data exposure; they make the legal determination. Don't make the notification decision yourself — that's a legal judgment, not a technical one.

The 72-hour clock creates urgency. Here's the practical timeline for an incident discovered Monday at 09:15:

Hour 0 (Monday 09:15): Incident discovered during Monday review. Clock starts.

Hours 0-1 (09:15-10:15): Execute AD6.2 (containment). Begin filling in the incident report template. By 10:15: account contained, initial timeline documented, basic impact assessment started.

Hours 1-4 (10:15-13:15): Complete impact assessment. Determine: what personal data was accessed? Was it exfiltrated? Who was affected? Complete Section 5 (GDPR assessment) of the incident report.

Hours 4-8 (13:15-17:15): Forward the incident report to your DPO or legal counsel. They assess the notification requirement. If the incident clearly involves personal data exfiltration (forwarded emails containing NINOs, bank details, health information), notification is likely required. If the incident involved only internal data being read (not exfiltrated), notification may not be required.

Hours 8-72 (Monday 17:15 — Thursday 09:15): Legal/DPO makes the notification decision and submits to the ICO if required. You provide additional technical details as requested.

The key insight: your technical investigation (hours 0-4) must be fast enough to give legal 48+ hours for their assessment and notification. If your containment and investigation takes 48 hours, legal has only 24 hours — insufficient for a proper assessment. Speed in the technical response creates time for the legal response.

Section 5 of the incident report doesn't require legal expertise — it requires factual answers:

"Was personal data accessed?" List the types: names, email addresses, phone numbers, NINOs, bank details, health information. Be specific: "47 emails read, 3 forwarded. Forwarded emails contained: vendor contact names (personal data), vendor bank account numbers (may constitute personal data for sole trader vendors), invoice amounts (not personal data)."

"Was personal data exfiltrated?" "Accessed" (the attacker read it) is different from "exfiltrated" (the attacker copied it to an external location). Forwarding to an external email address IS exfiltration. Reading emails in the browser WITHOUT forwarding is access without confirmed exfiltration. The distinction matters: exfiltrated data is in the attacker's possession permanently. Accessed data may or may not have been memorised, screenshotted, or otherwise captured — the risk is lower but not zero.

"Who is affected?" List the data subjects: "3 vendor contact persons (names and bank details exposed), 1 employee (home address exposed in expense claim)." These are the individuals whose rights and freedoms may be at risk.

This factual assessment gives legal everything they need. They apply the legal tests (Article 33 risk threshold, Article 34 high-risk threshold for individual notification). You provide the facts; they provide the legal conclusion.

Incident numbering and filing

Establish a consistent incident numbering system: INC-YYYY-MMDD-NNN where YYYY is the year, MMDD is the date of discovery, and NNN is a sequential number. Example: INC-NE-2026-0414-001 (first incident discovered on 14 April 2026). If two incidents are discovered on the same day, the second is INC-NE-2026-0414-002.

Include the Defender incident ID in your report for cross-reference. Your numbering system is your internal reference; the Defender incident ID is the reference your managed SOC uses. Both should appear in the report header.

File completed incident reports in a dedicated location: C:\SecurityIncidents\ or a SharePoint document library with restricted access (only IT/security staff). Index by incident number. After 12 months, archive closed incidents to a separate folder. The filing system should be simple enough that a colleague covering your role can find any incident report within 30 seconds.

Your quarterly management report references incident numbers: "Two incidents in Q2: INC-NE-2026-0414-001 (AiTM credential compromise, contained in 15 minutes, 3 vendor invoices exposed) and INC-NE-2026-0522-001 (phishing click blocked by Safe Links, no impact). Full reports available on request." This gives management the summary while pointing to the detailed documentation if they want to drill down.

The incident report is both an operational document (guiding the current response) and a historical record (enabling future reference and pattern analysis). Write it as if someone else will need to read it in 6 months — because they will, whether it's an auditor, a new IT admin, or you trying to remember what happened when a similar incident occurs.

Compliance Myth: "The 72-hour GDPR clock starts when the breach occurs"

Article 33 says "without undue delay and, where feasible, not later than 72 hours after having become AWARE of it." The clock starts when you discover the breach — not when the breach occurred. If the attacker compromised the account on Saturday and you discovered it during your Monday review, the 72-hour clock starts Monday morning. This is why monitoring cadence matters: a weekly review means the maximum time between breach and awareness is 7 days. Without monitoring, awareness might not happen for weeks — and the 72-hour clock doesn't start until awareness, but the delay in awareness itself could be viewed unfavorably by the ICO ("why didn't you have monitoring to detect this sooner?").

Decision point

Your incident report shows: attacker accessed 47 emails, 3 were forwarded to an external address. The 3 forwarded emails were vendor invoices containing the vendor's company name, bank account number, sort code, and contact person name. Is this a GDPR-notifiable breach?

Option A: No — vendor bank details are business data, not personal data.

Option B: Potentially yes — the contact person's name is personal data. The bank account details may be linked to an individual (sole trader vendors) rather than a company. Forward Section 5 of the incident report to your DPO or legal counsel for the notification decision. Your assessment: "3 vendor invoices forwarded externally containing company names, bank details, and named contact persons. Contact persons' names constitute personal data. Bank details may constitute personal data if vendors are sole traders. Risk to individuals: potential financial fraud using the exposed bank details. Recommend legal assessment for Article 33 notification."

The correct answer is Option B. Named individuals' data is personal data under GDPR regardless of the business context. You've done your job: identified the data, assessed the risk, and forwarded to legal. The notification decision is theirs — but your documentation enables them to make it quickly, within the 72-hour window.

Try it: Complete the incident report for a practice scenario

Using the template, write an incident report for this scenario:

Scenario: User a.patel's account was compromised via AiTM phishing on Wednesday at 14:30. You discovered it during the Thursday morning alert review (the managed SOC flagged it overnight). The attacker signed in at 14:45 from IP 203.0.113.77 (Romania), created 1 inbox rule forwarding "invoice" emails to external@proton.me, and read 23 emails. 2 emails were forwarded before you disabled the rule. The forwarded emails contained a supplier invoice with the supplier's bank details and a staff member's expense claim with their home address.

Fill in all 6 sections of the template. Pay special attention to Section 5 (GDPR): the staff member's home address is clearly personal data that was forwarded to an external party.

Time the exercise. Your target: a complete incident report in 15 minutes — including the GDPR assessment. After a real incident, you'll have this template and the practice to produce the report quickly while the details are fresh.

When should you write the incident report?

During and immediately after the response — fill in the timeline as you take each action, and complete the impact assessment and GDPR sections within 1 hour of containment — Correct. Real-time documentation is accurate. Reconstructed documentation is incomplete. The action timestamps in the timeline are most accurate when recorded as they happen.

At the end of the week — batch all incidents into one report — By the end of the week, you've forgotten specific timestamps, actions, and details. Each incident gets its own report, written during the response.

Only for major incidents — minor incidents don't need reports — Every TP incident needs documentation. A "minor" incident (single compromised account, quickly contained) still requires a report for your quarterly metrics, compliance evidence, and post-incident review.

After the quarterly report deadline — compile incidents from memory — Memory is unreliable for timestamps, IP addresses, and specific actions taken. Document in real-time.

Operational Artifact — Incident Report Template

6-section template: Summary (what/who/status), Timeline (chronological events with UTC timestamps), Impact (data accessed, emails forwarded, financial exposure), Containment (all actions taken with timestamps), GDPR (personal data assessment, notification recommendation), Improvements (root cause, prevention, detection, procedure updates). Save as IncidentReportTemplate.md. Copy for each incident. Fill in during the response. Forward Section 5 to DPO/legal within 24 hours for GDPR notification assessment. File the completed report in your incident log. Include incident count and metrics in your quarterly management report.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus

← Previous Next →

AD6.9 Documenting the Incident

The incident report template

The GDPR assessment — practical guidance

The GDPR notification timeline in practice

Writing the GDPR assessment for non-lawyers

Incident numbering and filing