Lesson 11 — Summarising Security Incidents
Security Copilot can rapidly turn a complex Microsoft Defender XDR or Sentinel incident into an initial attack story.
A useful summary identifies the important alerts, entities, timeline, evidence, impact and unresolved questions without reproducing every event or treating AI interpretation as fact.
This lesson explains how to generate, refine and validate incident summaries for technical investigation, SOC handover, escalation, executive reporting and closure.
What you will learn
This lesson begins Module 2 with practical AI-assisted incident investigation and reporting.
Incident summary workflow
↓
Confirm tenant, workspace and incident ID
↓
Generate the Security Copilot draft summary
↓
Identify the proposed attack story
↓
Extract users, devices, mailboxes, indicators and resources
↓
Build a chronological timeline
↓
Open alerts, entities and source records
↓
Remove duplicates and unrelated activity
↓
Separate confirmed facts, inference and unknowns
↓
Describe verified impact, containment and remaining work
↓
Rewrite for the intended audience
↓
Approve the final human-validated summary
Incident summary types
| Summary type | Primary content | Purpose |
|---|---|---|
| Technical analyst | Evidence, entities, indicators, timeline, hypotheses and next pivots. | Investigation and escalation. |
| SOC handover | Current state, actions completed, outstanding risk and assigned tasks. | Shift continuity. |
| Executive | Business impact, response status, remaining risk and decisions. | Leadership communication. |
| Incident commander | Scope, workstreams, blockers, approvals and communication. | Coordinated response. |
| Closure | Final cause, scope, remediation, residual risk and lessons learned. | Case completion and improvement. |
Learning objectives
- Generate Defender and Sentinel incident summaries.
- Identify the attack story and key entities.
- Consolidate duplicate and unrelated alerts.
- Build verified timelines.
- Separate fact, inference and unknowns.
- Adapt summaries for different audiences.
- Validate every major conclusion.
What is an incident summary?
An incident summary condenses alerts, entities, activity, evidence and current understanding into a clear account of what may have happened.
Summary is not closure
A summary supports orientation and communication; it does not prove the incident, determine final scope or replace investigation.
Incidents group related alerts
Microsoft Defender and Sentinel incidents can contain multiple alerts that may represent one attack story or several unrelated events.
Start with the incident source
Open the original Defender XDR or Sentinel incident before relying on the AI-generated summary.
Embedded Defender summary
In the Microsoft Defender portal, Security Copilot can generate an incident summary from the current incident context.
Standalone Defender workflow
In the Security Copilot standalone experience, the Defender XDR plugin can investigate and summarise a specified incident.
Embedded Sentinel summary
Microsoft Sentinel can provide Security Copilot incident summaries in supported portal experiences.
Standalone Sentinel workflow
The Sentinel plugin can investigate a specified Sentinel incident from the Security Copilot standalone experience.
Confirm the incident identifier
Use the correct incident number, tenant and workspace before submitting a prompt or promptbook.
Define the audience
A Tier 2 analyst, shift lead, executive and incident commander need different levels of technical detail.
Define the summary purpose
Decide whether the summary supports triage, handover, escalation, executive communication or closure.
Start with the attack story
Describe the likely sequence from initial activity through observed impact without overstating unsupported stages.
Identify the first confirmed event
Distinguish the earliest verified event from a suspected initial-access hypothesis.
Identify the latest confirmed event
Record the most recent verified activity so the reader understands whether the incident may still be active.
List affected identities
Include users, service principals, administrators and authentication context that are genuinely in scope.
List affected devices
Include device names, IDs, owners and roles rather than counting duplicate records as separate assets.
List email entities
Record mailboxes, senders, recipients, messages, URLs and attachments relevant to the incident.
List network indicators
Include IP addresses, domains, URLs and ports only when they are supported and relevant.
List files and processes
Identify suspicious files, hashes, commands, scripts, parent-child processes and persistence evidence.
List cloud resources
Include subscriptions, resources, applications, workloads and permissions when cloud activity is in scope.
Describe detection sources
Identify which Defender, Sentinel, Entra, email, endpoint, cloud or data-security products supplied the evidence.
Summarise alert relationships
Explain why alerts appear related rather than merely listing them.
Identify duplicate alerts
Repeated alerts can inflate apparent incident size and should be consolidated carefully.
Separate unrelated activity
Events close in time may belong to different users, devices or operational workflows.
Create a chronological timeline
Sort verified events by time and show the source product for each event.
Normalise time zones
Use one stated time zone across the summary and preserve original timestamps where needed.
Highlight evidence gaps
Identify missing logs, unavailable products, retention limits and permissions that constrain the summary.
Highlight conflicting evidence
Include facts that weaken the leading attack story instead of hiding them.
Separate fact from inference
Use clear sections for confirmed evidence, likely interpretation and unresolved questions.
State confidence
Assign confidence to individual conclusions rather than to the entire incident as one block.
Describe business impact
Explain affected services, users, data and operations using verified information.
Avoid invented impact
Do not claim data theft, persistence or business disruption unless evidence supports it.
Describe containment status
Record actions already completed, such as account disablement, token revocation, device isolation or email removal.
Describe outstanding actions
List investigation and response work that remains incomplete.
Request evidence references
Ask Copilot to identify the alerts, entities, source links or records supporting major claims.
Use follow-up prompts
Refine identity, endpoint, email, cloud and timeline questions separately after the initial summary.
Ask what does not fit
Request alerts or entities that may be unrelated to the primary attack story.
Ask for unresolved questions
A good summary makes uncertainty visible and tells the next analyst what still needs investigation.
Technical analyst summary
Include evidence, timestamps, entities, indicators, hypotheses, confidence and next pivots.
SOC handover summary
Prioritise current state, actions taken, outstanding risk, ownership and next shift tasks.
Executive summary
Focus on business impact, risk, response status, remaining exposure and decisions required.
Incident commander summary
Highlight scope, severity, active workstreams, blockers, approvals and communication needs.
Closure summary
Record the final evidence-based conclusion, remediation, residual risk and lessons learned.
Use concise structure
A summary should reduce cognitive load rather than reproduce every event and alert.
Preserve source attribution
Readers should be able to identify which product supplied each important fact.
Use tables for complex scope
Tables can clarify affected users, devices, indicators, evidence and confidence.
Use timelines for attack stories
Chronological presentation is often clearer than grouping activity only by product.
Do not copy raw AI output blindly
Edit the generated response for accuracy, clarity, audience and organisational terminology.
Remove unsupported adjectives
Words such as sophisticated, targeted, severe and malicious require evidence and context.
Check severity separately
Product severity, business impact and analyst priority are related but not identical.
Check incident status
Confirm whether the incident is active, contained, resolved, reopened or awaiting evidence.
Check automation results
Automated investigation and response evidence should be reviewed before being summarised as fact.
Check guided responses
Security Copilot recommendations can support triage but remain proposals requiring analyst judgement.
Protect sensitive information
Exclude unnecessary personal, confidential, regulated or investigative information from broad summaries.
Review before sharing
Confirm accuracy, classification and recipient need before exporting or sharing the session.
Record Copilot contribution
Document that Security Copilot generated or assisted the draft while humans validated the final summary.
Measure summary quality
Evaluate factual accuracy, missing evidence, readability, usefulness and time saved.
Improve the prompt template
Update standard prompts when recurring omissions, assumptions or unclear output are identified.
Use summaries as investigation checkpoints
Generate a fresh summary after meaningful evidence or scope changes rather than relying on an outdated narrative.
Final validation remains human
The analyst approves the attack story, scope, impact and next actions after reviewing the original evidence.
Example incident-summary prompt
Include:
1. The likely attack story in chronological order
2. The first and latest confirmed events
3. Affected users, devices, mailboxes and cloud resources
4. The most important alerts and supporting evidence
5. Confirmed containment or remediation actions
6. Business impact supported by evidence
7. Alerts or entities that may be unrelated
8. Missing or conflicting evidence
9. Confirmed facts, inference and unresolved questions
10. The next five investigation steps
Use one stated time zone and cite the source product for each major finding.
Agent Foskett investigation: “The incident looked enormous…”
↓
Security Copilot produced a one-page attack summary
↓
The draft described 12 devices and six affected users
↓
The incident appeared widespread
↓
Agent Foskett opened the alert and entity evidence
↓
Twenty-nine alerts were duplicates or repeated detections
↓
Three device names referred to the same reimaged laptop
↓
Two users were service accounts involved in expected automation
↓
One cloud alert belonged to an unrelated test subscription
↓
The verified incident affected one user and one endpoint
↓
The phishing message had been delivered and clicked
↓
Endpoint activity confirmed a short-lived malicious PowerShell process
↓
No evidence supported cloud compromise or data theft
↓
The final summary became shorter and more accurate
↓
The AI draft had organised the incident
↓
The analyst had defined its real scope
Incident-summary validation checklist
| Area | Question | Validation action |
|---|---|---|
| Incident | Is the correct tenant, workspace and incident selected? | Confirm identifiers and portal context. |
| Alerts | Are alerts duplicates, related or unrelated? | Review alert evidence and grouping. |
| Entities | Are users and devices counted correctly? | Confirm immutable IDs and ownership. |
| Timeline | Are events in one stated time zone? | Normalise and verify timestamps. |
| Attack story | Does evidence support each proposed stage? | Remove unsupported transitions. |
| Impact | Is business or data impact proven? | State only verified impact. |
| Containment | Were response actions actually completed? | Check action status and results. |
| Uncertainty | Are gaps and conflicts visible? | Document unknowns and confidence. |
| Audience | Does the detail match the reader? | Rewrite for technical or business use. |
| Approval | Who validated and approved the final summary? | Record human ownership. |
Key takeaways
- Security Copilot can summarise Microsoft Defender XDR and Sentinel incidents in embedded and standalone experiences.
- An incident summary is an initial orientation aid, not a final investigation verdict.
- Useful summaries identify attack story, entities, evidence, impact, containment and unresolved questions.
- Duplicate alerts and repeated entity records can make an incident appear larger than it is.
- Chronological timelines should use one stated time zone and preserve source attribution.
- Confirmed facts, likely inference and unknowns should be clearly separated.
- Technical, handover, executive, commander and closure summaries serve different audiences.
- Business impact must be supported rather than assumed.
- Every major claim should be validated in the original incident, alert, entity or log source.
- The final summary remains a human-approved security record.
What Agent Foskett checked
- Incident identifier
- Duplicate alerts
- User identities
- Device IDs
- Email delivery
- PowerShell activity
- Cloud alert scope
- Timeline
- Business impact
- Final confidence
Best practices
- Open the source incident.
- Define the audience.
- Request evidence and uncertainty.
- Remove duplicates.
- Verify entities.
- Normalise timestamps.
- Separate fact from inference.
- State verified impact only.
- Review before sharing.
- Record human approval.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you summarise security incidents with Microsoft Security Copilot?
Security Copilot can create incident summaries in Microsoft Defender XDR and Sentinel embedded experiences and through the corresponding standalone plugins.
Microsoft Defender XDR incident summaries
A useful Defender XDR incident summary identifies the attack story, alerts, entities, evidence, timeline, impact, containment and unresolved questions while preserving links to the original source records.
AI-assisted SOC incident reporting
Analysts can refine one validated incident into technical, SOC handover, executive, incident commander and closure summaries suited to different audiences.
