All projects

Turning SOC findings into a remediation process the Workplace team could run

June 2025 2 min read

  • SOC
  • Defender for Endpoint
  • CrowdStrike
  • Process
SOC to Workplace remediation processSOCWorkplaceDetectDefender, CrowdStrike, DarktraceAnalysescope, severity, affected assetsReportone format, one categoryTriagecategory → playbookRemediateisolate, reset, wipe, revokeEvidence + closewhat was done, when, by whomRepeated categories become candidates for automatic remediation

A security operations centre is good at seeing. Defender for Endpoint, CrowdStrike Falcon and Darktrace between them produce a steady flow of findings: a machine talking to something it shouldn’t, a sign-in that doesn’t fit, a file that looks like the wrong kind of file. What the SOC typically can’t do is act on a laptop in a classroom in Barcelona. That’s the Workplace team.

When I led that team, the hand-off between the two was a chat thread. Each alert arrived in a different shape, with a different idea of urgency, and the person who picked it up decided on the spot what to do. It worked, because the people were good. It didn’t scale, and it couldn’t be measured.

The process

We agreed on a standard operating procedure with the SOC, and it’s less about technology than about removing decisions from the moment of the alert:

  1. The SOC reports in one format, with one category from a short agreed list (compromised credential, malware on endpoint, data exfiltration suspected, policy violation…) and the assets involved.
  2. Each category maps to a playbook on the Workplace side: what to do first, what evidence to collect, what to do next. Isolate the device in Defender, revoke sessions in Entra, reset the password, wipe, re-enrol.
  3. Every action is recorded the same way: what was done, when, by whom, and the alert is closed back to the SOC with that record attached.

Nothing exotic. The value is that the fourth time the same category comes in, the response is identical to the first three, and the time to close it is a number you can look at.

Where it leads

The real reason to standardise is the step after. Once a category has a fixed playbook and its actions are all things an API can do (isolate a device, revoke sessions, reset a credential), that category is a candidate for automatic remediation: the SOC’s tool raises the finding, the playbook runs, a person reviews the record afterwards instead of doing the work. The process was designed so that this step is a change of executor, not a redesign.

What you could take from this

If your SOC and your endpoint team talk in chat, write down the categories first. The playbooks follow naturally, and the automation follows the playbooks.

All projects