0.2 The Automation Spectrum

Automation is not binary

Most conversations about SOC automation treat it as a switch: either you automate or you do not. In practice, automation exists on a spectrum with five distinct levels, each requiring different organizational maturity, different technical infrastructure, and different governance controls.

Level 0: Fully Manual. Every step requires a human. The analyst opens the incident, runs enrichment queries by hand, documents findings in the comments, classifies the alert, and executes any response actions through the portal. No playbooks, no automation rules, no task lists. This is where most SOCs start and where many remain. The advantage is control. The cost is the capacity deficit from Section 0.1.

Level 1: Automated Triage. Automation rules handle incident assignment, severity adjustment, tag application, and task list creation. No playbooks execute. The analyst still performs all enrichment and response, but the incident arrives pre-sorted and pre-assigned. Sentinel automation rules without playbook attachments operate at this level. You configure them in the Defender portal under Automation, and they evaluate conditions against incident properties (analytics rule name, severity, entities, tactics) to apply actions.

Level 2: Automated Enrichment. Playbooks run at incident creation or update to attach context: IP reputation from threat intelligence, user risk score from Entra ID Protection, device compliance state from Intune, recent sign-in history from SigninLogs. The analyst opens a pre-enriched incident and makes the classification decision based on data that was gathered in 30 seconds instead of 10 minutes. Zero blast radius because enrichment queries cannot modify anything.

Level 3: Semi-Automated Response. Playbooks recommend or prepare containment actions but pause for human approval before execution. An approval request arrives in Teams or email: "Incident SA-2847: AiTM confirmed for j.morrison@northgateeng.com. Confidence 92%. Recommended action: revoke all active sessions and enforce MFA re-registration. Approve or reject." The analyst reviews the enrichment, confirms the recommendation, and clicks Approve. The playbook executes. If the analyst rejects, the incident returns to the manual queue with a reason code.

Level 4: Fully Automated Response. Playbooks execute containment without human approval when the confidence threshold and blast radius assessment both pass. Session revocation, device isolation, account suspension, or inbox rule removal happens in seconds. An approval gate still exists but only triggers when the confidence is below the threshold or the entity is on the exclusion list (VIPs, service accounts, critical infrastructure). Everything above the threshold executes autonomously.

Why left-to-right matters

The levels are sequential, not optional. An organization cannot safely jump from Level 0 to Level 4 because each level produces the infrastructure and operational trust that the next level depends on.

Level 1 (automated triage) produces consistent incident routing. Without it, the analyst at Level 3 cannot trust that the right incidents reach the right approval workflow, because assignment is manual and inconsistent. Level 2 (automated enrichment) produces the data that Level 3 needs for approval decisions. If the enrichment is not already attached when the approval request fires, the analyst has to gather it manually before deciding, which defeats the purpose of the approval workflow.

Level 3 (semi-automated response) produces the operational trust that Level 4 requires. When a playbook has run 500 times in approval mode and the analyst has approved 485 of those actions, the organization has empirical evidence that the confidence threshold works. Promoting that playbook to Level 4 (fully automated) is a data-driven decision, not a leap of faith. Without Level 3 data, Level 4 is a gamble.

This left-to-right progression is how mature SOCs actually build automation. Gartner's research on SOAR adoption has consistently found that the organizations with the highest automation success rates are those that started with enrichment and graduated to response after validating the enrichment layer. Organizations that attempted to automate containment without enrichment infrastructure in place experienced higher rates of false-action incidents, where automation executed against false positives.

Consider the dependency chain concretely. A Level 3 playbook for AiTM session revocation needs to evaluate three conditions before firing the approval request: is the user a VIP (requires a watchlist lookup), is the sign-in anomalous beyond the alert itself (requires enrichment from SigninLogs), and is the confidence above the threshold (requires a score derived from enrichment data). If the Level 2 enrichment layer does not exist, the Level 3 playbook has no data to evaluate. It either fires blind, creating unacceptable risk, or requires the analyst to gather the data manually before approving, which recreates the manual workflow it was supposed to replace.

The time investment to build each level varies. Level 1 (automation rules) takes hours: you configure conditions and actions in the Defender portal. Level 2 (enrichment playbooks) takes days to weeks: you build Logic Apps or Standard workflows, configure managed identity permissions, test against production incidents, and validate that the enrichment data is accurate and timely. Level 3 (approval workflows) adds another week: you design the approval UX in Teams adaptive cards or email, define the escalation path for unanswered approvals, and test the approval-to-execution pipeline. Level 4 (autonomous execution) adds governance: you define the confidence threshold, build the blast radius assessment, configure the exclusion lists, and run the playbook in approval mode long enough to collect statistical evidence that the threshold works.

Each level's investment is smaller than the previous level's ongoing manual cost. An enrichment playbook that takes a week to build and saves 5 minutes per incident pays for itself within a month on a 200-incident-per-day queue.

Classifying automation actions

Each action inside a playbook maps to a point on the spectrum. A single playbook can contain actions at multiple levels. The classification depends on two properties: whether the action modifies anything, and what the consequence of incorrect execution is.

Read-only actions query data without changing it. Checking SigninLogs, pulling a user's risk score from Entra ID Protection, querying threat intelligence for an IP reputation, retrieving device compliance state from Intune. These are Level 2 actions. Their blast radius is zero. If the alert is a false positive and the enrichment runs anyway, no harm occurs. You have extra context on a benign incident, which is useful information in itself.

Write-back actions with low blast radius modify non-critical properties. Adding a tag to an incident, updating the severity, adding a comment with enrichment results, creating a task list for the analyst. These are Level 1 actions. If the tag is wrong, an analyst corrects it in seconds. If the severity is adjusted incorrectly, the incident is still visible and triageable.

Write-back actions with moderate blast radius modify security state in reversible ways. Revoking a user's active sessions forces re-authentication but does not disable the account. Enforcing an MFA re-registration challenge requires the user to re-enroll but does not lock them out. Quarantining a suspicious email removes it from the inbox but preserves it in the quarantine store. These are Level 3 candidates: impactful enough to warrant approval, reversible enough that a mistake can be corrected within minutes.

Write-back actions with high blast radius modify security state in ways that are difficult or slow to reverse. Disabling a user account blocks all access across M365, including email, Teams, SharePoint, and any applications using Entra ID as the identity provider. Isolating a device from the network removes it from all connectivity until an administrator releases it. Blocking an IP at the firewall affects all traffic from that address. These are Level 4 candidates only when the confidence threshold is high and the blast radius assessment passes. Even at Level 4, VIP exclusions and critical infrastructure safeguards remain active.

{
  "action_classification": {
    "level_2_read_only": [
      "Query SigninLogs for user authentication history",
      "Check IP against TI feeds (VirusTotal, AbuseIPDB)",
      "Pull user risk score from Entra ID Protection",
      "Retrieve device compliance from Intune",
      "Check VIP watchlist membership"
    ],
    "level_3_reversible": [
      "Revoke active user sessions (forces re-auth)",
      "Enforce MFA re-registration challenge",
      "Quarantine suspicious email message",
      "Add user to Conditional Access block policy (report-only)"
    ],
    "level_4_high_impact": [
      "Disable user account in Entra ID",
      "Isolate device from network via Defender for Endpoint",
      "Block IP at firewall",
      "Remove OAuth consent grants"
    ]
  }
}

Use this classification when you design playbooks. Every action in the playbook maps to a level. If the playbook contains a mix of Level 2 and Level 4 actions, the Level 4 actions need either approval gates (Level 3 deployment) or confidence thresholds (Level 4 deployment). The Level 2 actions can run unconditionally because they are read-only.

Placing your SOC on the spectrum

Most SOCs are at Level 0 or Level 1. They may have a few automation rules that assign incidents to analysts based on severity or analytics rule name, but enrichment is manual and response is entirely human-driven.

To place your own SOC, answer three questions. First, do automation rules handle incident routing (assignment, severity, tags) without human intervention? If yes, you are at least Level 1. Second, do playbooks attach enrichment data (TI, user risk, device compliance, sign-in history) to incidents before an analyst opens them? If yes, you are at Level 2. Third, do playbooks execute or recommend response actions (session revocation, device isolation, account actions) with approval gates? If yes, you are at Level 3. If any of those actions execute without human approval based on confidence thresholds, you have elements of Level 4.

Most organizations will find they have uneven coverage: Level 1 for assignment, Level 0 for enrichment, Level 0 for response. That unevenness is normal. It tells you exactly where to focus first: bring enrichment to Level 2 before attempting Level 3 response.

You can quantify the gap more precisely. For each of your top 10 alert types by volume, document what automation currently handles. If the answer for most alert types is "assignment only" or "nothing," you are at Level 0-1 across the board. If enrichment playbooks fire for some alert types but not others, you have partial Level 2 coverage. The gap between what is automated and what could be automated, measured per alert type, is your automation deficit map. This map becomes the prioritization input for SA0.6 when you assess Northgate Engineering's automation landscape.

The velocity of progression matters more than the starting point. A SOC that moves from Level 0 to Level 2 in three months and stays there for six months while accumulating trust data will reach stable Level 3 faster than a SOC that attempts Level 4 immediately and retracts after a false-action incident. Speed of safe progression, not speed of aggressive deployment, determines long-term automation maturity.