By Mike Taylor
Mike! Mike! Mike! What day is it? Its Security Day with Mike! Part 6 made the case that trustworthy detections are what earn an analyst’s attention, and Part 5 showed how Security Copilot compresses the investigation itself. Put those together and you have a SOC that detects well and investigates fast. The next question is how you scale it, because analyst hours do not grow to match alert volume. That is the job of automation, and it has moved well beyond the static playbook.
For a decade, SOC automation meant SOAR playbooks: if this alert fires, run these steps. That model still has a place, but it is brittle. A playbook encodes one path through a problem, and the moment reality deviates it either does nothing useful or does the wrong thing confidently. Maintaining a library of them becomes its own full-time job.
A playbook automates a decision you already made. The harder win is automating the judgment around decisions you have not seen yet.
This post looks at what automation means in the Defender portal era, how to think about the spectrum from manual to autonomous, and where to apply it without handing over judgment you should keep.
Why Static Playbooks Are Not Enough
SOAR playbooks are deterministic. Fixed trigger, fixed steps. That is exactly what you want for well-understood, repetitive work: enrich this indicator, disable that account, open this ticket. The trouble starts when the situation does not match the script.
Attacks vary, and a rigid playbook breaks on precisely the edge cases that matter most. Worse, a library of playbooks carries real maintenance debt. Every environment change, every new integration, every tweaked API means upkeep. The Defender portal shifts much of this burden into the platform itself, which changes what automation even means.
What Automation Looks Like in the Defender Portal
Modern automation is less something you script and more something the platform performs while you supervise it:
- Automated investigation and response (AIR) — the platform investigates alerts, reaches a verdict, and can remediate low-risk threats on its own.
- Automatic attack disruption — high-confidence, cross-domain containment, such as disabling a compromised account or isolating a device, at machine speed, before an analyst is even paged.
- Security Copilot agents — the emerging layer: agentic automation that reasons through a task, like phishing triage, rather than following a fixed branch of if-then steps.
The shift is from automation you author line by line to automation the platform runs and you hold accountable.
The Automation Spectrum
It helps to stop thinking of automation as on or off and see it as a spectrum:
- Manual — the analyst does everything.
- Assisted — Copilot summarizes and recommends; a human acts.
- Semi-automated — the platform acts on high-confidence cases behind an approval gate; humans handle the rest.
- Autonomous — known-bad is contained and remediated automatically, and humans review after the fact.
This mirrors the maturity model from The Path to an Autonomous SOC. You move rightward not by flipping a switch but as trust in each automated action is earned.
Where to Automate First
The fastest way to waste effort is to automate the wrong things. A simple lens helps: sort work by volume and by how much judgment it requires.
- High volume, low judgment — automate now. Enrichment, triage of known patterns, containment of high-confidence threats.
- High volume, high judgment — assist with Copilot, but keep the human decision.
- Low volume, high judgment — keep it manual. This is where your analysts add the most value.
Never automate what you cannot yet trust or measure. If you cannot tell whether an automated action was right, you are not ready to automate it.
Guardrails: Automate What You Trust
Automation without guardrails is just a faster way to be wrong. A few principles keep it safe:
- Human-in-the-loop for high-impact, low-reversibility actions, gated by approval.
- Reversibility first. Automate the actions you can undo before the ones you cannot.
- Test automation like code — the same discipline from Part 6. Validate before enabling, and watch the false-action rate.
- Measure both sides. Track automation rate from Part 4, but also the rate of wrong automated actions. Trust is earned with data, not assumed.
What This Means for Security Leaders
Automation is a trust curve, not a switch. Start where confidence and reversibility are high, measure the outcome, and expand from there. The goal is never to remove analysts. It is to spend their judgment where it matters instead of on repetitive toil. That means funding the supervision layer too: someone should own automation quality the same way someone owns detection quality, because unattended automation drifts just like an untuned detection does.
Getting Started
Microsoft’s documentation covers the built-in automation worth turning on first:
- Automated investigation and response in Microsoft Defender XDR
- Automatic attack disruption in Microsoft Defender XDR
- Automate incident handling in Microsoft Sentinel
What Comes Next
In the next post, Part 8, we turn to Building a High-Performing SOC Team. Technology and automation scale the work, but a SOC is still people. Next we look at how to structure, skill, and retain the team that runs all of this, because the best tooling in the world underperforms with the wrong operating model around it.
To revisit the previous post, Detection Engineering in the Defender Portal Era, click here.
For any earlier post in the series, click here.