Start by auditing the current automation pain points and identifying the workflows that break most often or consume the most analyst time. Then prioritise high-volume, repetitive use cases such as phishing triage or endpoint alerts. Establish baseline metrics for MTTR, alert volume, and analyst hours before migration so you can measure whether the new operating model is actually improving outcomes.
Why This Matters for Security Teams
Replacing legacy SOAR is usually not a tooling exercise, it is an operating-model change. The first decision point is whether the current automation is failing because of brittle playbooks, poor alert hygiene, weak integrations, or simply because analysts spend too much time on repetitive triage. If that is not measured up front, teams tend to automate the same friction at higher speed instead of fixing the underlying workflow. For many organisations, the right starting point is a small set of high-volume, low-judgement tasks that can be standardised and proved against baseline metrics.
That matters because AI-driven automation changes the control surface, not just the user interface. A legacy SOAR workflow that is deterministic and rule-bound can be audited differently from an AI-assisted workflow that classifies, summarises, or recommends actions. Teams need to know which parts of the process are safe to automate, which require human approval, and where false positives or poor context will create new operational noise. In practice, many security teams discover their automation debt only after analysts have already been compensating for broken workflows by hand.
How It Works in Practice
The sensible first step is to inventory the current automation estate and separate three things: what is automated today, what breaks most often, and what consumes the most analyst time. That usually exposes a short list of candidates for replacement rather than a wholesale migration plan. Good candidates are repetitive, high-volume, and bounded by clear decision criteria, such as phishing triage, commodity endpoint alerts, ticket enrichment, or simple containment routing.
A practical migration path usually looks like this:
- Map the current SOAR playbooks and mark where humans intervene.
- Measure baseline performance for MTTR, alert volume, re-open rates, and analyst hours.
- Rank workflows by frequency, fragility, and business impact.
- Choose one or two use cases with predictable inputs and well-understood outputs.
- Define where the AI system can recommend versus where it can execute.
That distinction is critical. AI is strongest when it reduces classification and routing overhead, while deterministic automation is still better for tightly defined response actions. The migration should therefore start with workflows where the model can add value without being asked to invent policy or infer intent from sparse evidence. If the process depends on ambiguous context, exception-heavy decisions, or poorly structured source data, the first project will probably fail for reasons that look like model weakness but are actually workflow design problems.
A useful supporting discipline is to compare candidates against an incident-priority lens rather than a technology lens. The more consistently a workflow appears in operations, the easier it is to standardise and measure. The more often it requires cross-team clarification, the more likely it needs redesign before automation. For teams formalising triage and response priorities, FIRST EPSS is a useful reminder that prioritisation should be risk-informed, not just volume-driven. These controls tend to break down when alert data is inconsistent across sources because the automation layer cannot reliably distinguish genuine signal from noisy enrichment.
Common Variations and Edge Cases
Tighter automation usually improves speed, but it also increases the cost of a bad workflow decision, so organisations have to balance scale against reversibility. In mature environments, the first replacement target is often not the highest-severity incident path but the most repetitive one, because that is where AI can remove toil without expanding blast radius.
A few edge cases matter:
- If the existing SOAR logic depends on brittle field mapping or outdated integrations, fix the data flow before introducing AI.
- If analysts already distrust current alerts, use a pilot that proves accuracy and explainability before broad rollout.
- If the workflow has regulatory or legal consequences, keep human approval in the loop until evidence quality is stable.
- If the use case is highly seasonal or low-frequency, it may not be a good first migration target even if it is technically automatable.
There is no universal standard for which workflows should be converted first, but current guidance suggests prioritising use cases where outcome quality can be measured quickly and where failure will not create irreversible impact. That is why many organisations begin with alert triage rather than response actions that touch production systems. A representative benchmark from The State of Secrets in AppSec shows how operational friction persists even when teams believe their controls are strong, which is a useful warning for automation programmes: confidence is not evidence. The same pattern applies when teams attempt to replace legacy SOAR without first proving which workflows are actually worth preserving or reengineering.
Risk and Threat Considerations
The main risk in replacing legacy SOAR too quickly is that organisations automate broken judgment paths rather than broken manual work. That can increase false positives, create uncontrolled auto-response, or leave analysts unable to explain why a workflow fired. If AI is used to classify or route incidents, poor input quality and weak guardrails can also create trust issues that slow adoption instead of improving it.
Failure mechanism: The failure usually comes from over-automating a workflow before the team has measured its error rate, exception rate, and dependency chain. In that situation, AI may accelerate triage on routine cases but also amplify mistakes when alerts are malformed, context is incomplete, or the playbook assumes a level of consistency the environment does not actually have.
Impact: Organisations can end up with faster but less dependable response, higher analyst rework, and weaker auditability. In the worst case, an automated action is taken on the basis of an inaccurate classification, which creates operational disruption and erodes confidence in the security function.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Establishes measurable risk and performance baselines before changing the SOAR operating model. |
| GV.OC-03 — External Dependencies and Ecosystem Role | Helps identify workflow dependencies and integrations that legacy SOAR relies on. | |
| Recommendation — Define baseline risk and performance metrics before replacing legacy automation. Map workflow dependencies before migrating automation to avoid hidden breakage. | ||
| CIS Controls v8 | CIS 8 — Audit Log Management | Supports measuring alert handling, escalation, and response outcomes during migration. |
| CIS 17 — Incident Response Management | Directly governs triage, containment, and workflow consistency for automated response. | |
| Recommendation — Preserve logging and response evidence so new automation can be validated. Prioritise repeatable incident workflows for phased automation and human approval. | ||
Practitioner Guidance
What to prioritise: Start with workflows that are frequent, repetitive, and easy to verify, not the ones that look impressive in a demo. The best first candidates are usually triage and enrichment paths where the team can compare before-and-after performance without risking production impact.
What to verify: Confirm that the current baseline is real, not anecdotal. You need usable measurements for alert volume, analyst hours, escalation rate, and MTTR before migration, otherwise the new model cannot be judged fairly. If a workflow has no measurable failure pattern, it is probably not the right first target.
Decision rule: If the AI system must make a judgment that could cause irreversible operational impact, keep a human approval step in place until the workflow has been proven on real data. If the action is reversible and the input is stable, automation can move faster.
Practitioner takeaway: The first migration decision should be based on operational pain and measurability, not on how aggressively the organisation wants to adopt AI. Successful replacements usually begin by removing toil from the most predictable workflows, then expanding only after the team can prove the new process is safer and faster than the old one.
Related resources from NHI Mgmt Group
- What should organisations do first when AI-driven attacks speed up exploitation?
- What should organisations prioritise first: AI automation or access cleanup?
- What should organisations do first when they start governing AI agent behaviour?
- When should organisations restrict AI-driven automation in security operations?
