How to Start an AI SOC Program Without Replacing Your Existing Stack
A practical AI SOC program starts with one measurable workflow, not a platform replacement. Prove the control model before expanding what the agent can do.
How to Start an AI SOC Program Without Replacing Your Existing Stack
A practical AI SOC programme starts with one measurable workflow, not a large platform replacement. Prove the control model before expanding the agent’s permissions.
Days 1–30: observe
Choose alert summarisation or related-event collection. Keep the agent read-only and capture baseline analyst time and correction rate.
Days 31–60: assist
Add reviewable query generation, report drafting, and bounded ticket actions. Create approval screens and audit records.
Days 61–90: improve
Compare outcomes, remove weak automations, refine playbooks, and decide which low-risk actions can be delegated.
Four things to settle before day 1
Labels: "Documented" = in zcr's product documentation; "Recommended pattern" = our advice; "Customer configuration" = yours to set.
- Asset and identity context. An agent asked who owns a host can answer fluently with no data behind it. Recommended pattern: a list of crown-jewel assets and privileged accounts with owner, environment and criticality, readable by the agent's account. Done when an analyst finds a pilot alert's host owner and criticality in one place.
- Log coverage. List the sources your pilot alert type needs and confirm each arrives with the source's own timestamp. Recommended pattern: check source health with something other than the agent, since an agent that reports "no related activity" while a source is down fails unseen. Done when a silent source raises a flag a person sees. zcrLog is Computer Crime Act log retention, which the pilot does not need.
- Ticketing. Customer configuration: a service account with a bounded role in your existing ticket system, and a field recording the analyst's verdict on each draft. Documented: zcrSOAR connects to ticketing tools; test the connector for your product first. Done when a query counts the verdicts.
- Named approval owners. Recommended pattern: before the first playbook, write down for each action you might automate one approver, one backup, and who can switch the agent's access off. Documented: zcrSOAR routes approval by action type, severity, asset, site or business unit and limits actions by role. Done when every planned action has an approver and a backup.
Choosing the pilot use case
Recommended pattern: pick one alert type that passes all five rules.
- The output is a read or a draft, for example a summary or an enriched ticket, not a system change.
- It recurs often enough to give you a baseline within 30 days.
- Everything it needs already arrives through tools you run; a new endpoint agent or log source makes it a second project.
- A wrong answer shows up within the same shift and is cheap to undo.
- One named person owns it and reads the output every working day.
Brute force can pass rules 2 and 3 if it recurs and its data already reaches you; zcrSIEM has a predefined use case for it and zcrSOAR an out-of-the-box playbook type (documented). Isolating the host or disabling the account behind the same alert fails rules 1 and 4, so leave it out.
The 30/60/90-day roadmap
A window ends only when every exit statement is true, read from tickets and logs by a person or a query, never from the model's own account.
| Window | Objective | Concrete deliverables | Exit criteria (yes/no) | What stays manual |
|---|
| Days 1–30: observe | Run the agent read-only on the pilot alert type and learn your baseline | Read-only access to the pilot sources; a review log putting each agent summary beside the analyst's own work; the manual procedure written down; baseline analyst time per alert and correction rate | The baseline covers the whole window; every summary links to its raw events; every "no related activity" answer was checked against source health | Every triage decision, ticket update and system change |
| Days 31–60: assist | Bring drafts and bounded actions into the live workflow with named approvers | Drafts and generated queries in the live ticket, marked as drafts; one playbook for the pilot alert type (out-of-the-box or AI-drafted) kept in Dry-run or Simulation Mode until authorised, state-changing steps at Approval or Blocked; approvers in the matrix, backups on a roster | Every draft has an analyst verdict; no state-changing step ran without a recorded approver; every approver has a backup | Severity and closure; containment and account changes stay a person's decision, run or approved |
| Days 61–90: improve | Compare with the baseline, remove what did not earn its place, decide what may run without a person | A before-and-after comparison built by a query from ticket data; a keep, narrow or remove decision for each automation; playbook version history reviewed and a rollback tested; a written Approval, Autonomous or Blocked decision per step | The pilot owner reviewed the comparison; every automation decision cites recorded evidence; a rollback worked in a test; a go, hold or stop decision exists for the next use case | Crown-jewel assets, anything irreversible, and any step whose owner has not signed the delegation |
Documented in the table: zcrSOAR's per-step gating, Dry-run and Simulation Mode, version history with rollback and AI-drafted playbooks; zcrSIEM's reviewable queries.
Customer configuration: service account and its access, verdict field, approval matrix, backup roster. The rest is a recommended pattern.
Limits, failure modes and stop conditions
OWASP's LLM06:2025 Excessive Agency names three root causes (excessive functionality, permissions and autonomy) and lists human approval for high-impact actions as a mitigation. Recommended pattern: at each new window ask what the agent can call, with what rights downstream, and what runs without a person.
Stop, return to the manual procedure for the pilot alert type and tell the pilot owner when:
- a pilot source went silent unnoticed until someone checked the agent's output;
- a summary left out an event the raw evidence held (hold scope until you know why);
- a state-changing step ran without a recorded approver;
- the approval queue outgrows careful reading (narrow the scope rather than add approvers).
Recommended pattern: alert fields such as email subjects, URLs and user agents are attacker-controlled text, so treat them as data to summarise, never as instructions.
An Approval step waits for a person, so an approval at 2 a.m. with nobody on call waits; decide in advance whether that is acceptable.
Frequently asked questions
Can we start without replacing our SIEM, EDR or ticketing system?
Yes. zcrSOAR connects to existing firewall, Active Directory, EDR, SIEM, email security, identity and ticketing tools and does not require zcrSIEM. zcrSIEM, a separate product, parses and normalises CEF, LEEF, Syslog and JSON logs from your existing sources without changing the source system; it needs no zcrLog and includes no SOAR.
Can the AI write our playbooks?
Only as drafts: zcrSOAR's AI assistant drafts a playbook from a prompt for review. A draft is still unapproved, so start every state-changing step at Approval or Blocked (recommended pattern).
When should part of this go to a managed service?
Recommended pattern: consider it if nobody can approve out of hours or read the agent's output daily. zcrMDR is a managed service delivered through an approved channel partner. Hours, scope and integrations are agreed at contract and onboarding, so confirm whether approvals are in scope.
Sources
Continue: How AI Agents Reduce Alert Fatigue Without Hiding Evidence, Human-in-the-Loop SOC, From Alert to Evidence: An Auditable AI SOC Workflow and the AI SOC Agent guide.
Explore zcrMDR · Compare pricing · Contact zcr
If you'd rather talk through your own environment, here's how to reach us.
Read next