Managed SOC Incident Response: From Alert to Contained
This post explains how incident response works with a managed Security Operations Centre, following a practical seven-step flow tailored to UK SMEs. Using a real-world Microsoft 365 and endpoint case, it shows how alerts are triaged to P1 or P2, how containment and forensics run, what evidence is captured, and how communication, tabletop exercises, and post-incident hardening strengthen your security posture.

When something suspicious pings on an endpoint at 02:14, you want one outcome. Fast confirmation, safe containment, clear communication, and a clean recovery that protects your data and keeps people working.
This is where a managed Security Operations Centre (SOC) earns its keep. In this post, we walk through a real-world, anonymised incident timeline that starts with a single endpoint alert and ends with a hardened environment. You will see how signals from Microsoft 365 sign-ins are correlated, how triage maps to P1 or P2, what is said to the customer and when, what evidence is captured, and which steps turn a scare into a learning moment.
The aim is simple. Help you picture what good incident response looks like so you can plan for it, test it, and sleep easier.
The seven steps of incident response
There are several recognised models. Our managed SOC works to a practical seven-step flow that maps cleanly to UK SME needs.
- Preparation
- Detection and analysis
- Triage and prioritisation
- Containment
- Eradication
- Recovery
- Post-incident hardening and lessons learned
Some teams talk about five steps. In that framing, preparation is assumed, and eradication and recovery are often merged. The core journey remains the same.
A real-world timeline, end to end
Scenario: An employee laptop triggers an Endpoint Detection and Response (EDR) alert for suspicious PowerShell spawned from Outlook. Almost in the same window, Microsoft 365 shows an impossible travel sign-in on the same account.
02:14 Detection. EDR flags script activity with known credential-harvesting patterns. The SOC platform automatically enriches the alert with device, user, and process tree details, then checks linked Microsoft 365 sign-ins. An anomalous sign-in from a foreign IP stands out against typical UK logins.
02:16 Triage. The duty analyst correlates endpoint telemetry with Entra ID risk events. Because there is lateral movement potential and active identity risk, the incident is promoted to P1 (priority 1) under the playbook. If the sign-in anomaly had been a benign VPN pattern and the script was blocked at launch, this would likely sit at P2.
02:18 Initial containment. Automated actions isolate the endpoint from the network while preserving SOC control. Conditional Access forces reauthentication, and the user account is moved to a restricted policy requiring strong MFA and a password reset on next sign-in. External forwarding rules and inbox rules are queried and removed if found.
02:20 Customer communication 1. A short, plain-English message goes to the nominated on-call contacts. Example: “We detected suspicious activity on one device and a risky sign-in on the same account. The device is isolated, the account is protected with forced MFA and reset on next sign-in. No confirmed data exfiltration at this point; investigation in progress. We will update in 30 minutes or sooner if status changes.”
02:25 Forensics kick-off. The SOC collects volatile data from the endpoint, captures EDR timelines, and exports relevant Microsoft 365 audit logs. Indicators of compromise (IOCs) are carved out for threat hunting across the estate. Attachments, URLs, and processes are preserved for later analysis.
02:35 Threat hunt and scope. Using IOCs, the SOC searches other endpoints and cloud workloads. Defender XDR and sign-in logs are checked for similar behaviour, mailbox rules, OAuth app grants, and legacy authentication attempts.
02:42 Eradication. The malicious script artefacts and any persistence mechanisms are removed from the affected device while it remains isolated. Any suspicious OAuth grants are revoked. If a phishing email was the trigger, copies are removed from other mailboxes using targeted purge.
02:55 Customer communication 2. “Eradication complete on the affected endpoint. No lateral movement observed. Two other mailboxes received the same lure; messages removed. We are proceeding to controlled recovery of the isolated device. Estimated time to return the user to service: 45 to 60 minutes.”
03:10 Recovery. The device is rejoined to the network behind stricter policy. Patches and Defender baselines are re-applied. The user completes a supervised credential reset with phishing-resistant MFA where available. Data integrity checks confirm no file encryption or mass deletion.
03:45 Monitoring window. The SOC holds the environment in heightened watch status, tracking for repeat indicators. If backups are in scope, quick restore tests are performed on a non-production slice to validate recovery paths.
08:30 Post-incident hardening. Findings are translated into actions: tighten Conditional Access, block legacy auth if any residue remains, tune anti-phishing, deploy stricter application control, and schedule focused micro-training for those targeted.
How P1 vs P2 decisions are made
Priority is set by potential business impact and likelihood. Examples:
- P1: Confirmed malicious execution on an endpoint and concurrent risky sign-ins; ransomware-like behaviour; domain admin compromise; exfiltration in progress.
- P2: Blocked malware with no execution; suspicious but inconclusive sign-in that scores low risk; isolated alert on a non-critical asset with compensating controls.
This avoids noise while ensuring real threats move quickly from alert to contained.
What we capture as evidence
Good response preserves truth. During containment, we gather:
- EDR timelines, process trees, hashes, and registry changes
- Microsoft 365 audit events, sign-in logs, inbox rules, OAuth grants
- Copies of malicious emails, attachments, and URLs
- Device state summaries and configuration snapshots
This enables clear reporting to leadership, insurers, and regulators if required.
Communication that reassures, not alarms
Updates are short, time-bound, and honest. We avoid speculation and share what we know, what we are doing, what we need, and when to expect the next update. If user action is required, we provide exact steps and offer a helpline window to keep people moving.
How tabletop exercises improve outcomes
Tabletops turn theory into reflex. By walking through realistic scenarios with IT, leadership, and comms, teams clarify roles, test contact trees, refine P1/P2 thresholds, and rehearse the exact words that go to staff and customers. The result is faster decisions, fewer handoffs, and less downtime. They also surface gaps that feed directly into hardening.
If you have not rehearsed this journey, start with one scenario that mirrors your highest risk: credential theft in Microsoft 365 or a ransomware attempt on a key file server.
From incident to stronger posture
The best incidents end with fewer ways to get in next time. Typical hardening actions include enforcing MFA everywhere, blocking legacy authentication, improving Conditional Access, tightening application control, rolling out phishing simulations to the targeted teams, and validating immutable backups. When cloud workloads are in play, review sharing, DLP policies, and restore runbooks so recovery is predictable.
For a deeper look at continuous monitoring and practical containment, see our guide to network security monitoring and how a managed security service provider coordinates detection and response across endpoints, identities, and cloud signals.
FAQ
- What are the seven steps of incident response? Preparation; detection and analysis; triage and prioritisation; containment; eradication; recovery; post-incident hardening and lessons learned.
- How do you respond to a security incident? Confirm the signal, set priority, contain quickly, preserve evidence, remove the threat, recover systems under supervision, then fix root causes and update playbooks. Communicate clearly at each step.
- What are the five steps of incident response? Many teams compress the model to identification, containment, eradication, recovery, and lessons learned. Preparation is assumed, but we prefer to call it out.
- What is an example of a security incident? A phishing email leads to a risky Microsoft 365 sign-in and script activity on a laptop. The managed SOC isolates the device, resets credentials, removes inbox rules, and verifies no data left the tenant.
Summary and next step
A managed SOC turns alerts into action. By correlating endpoint detection with Microsoft 365 sign-ins, applying tested playbooks, and keeping communication calm and clear, you move from alert to contained to hardened in hours, not days. If you want to pressure-test your plan, schedule a tabletop exercise and a quick posture review. We can help you prioritise controls, tune detections, and keep your business ready for whatever lands next.



