SOC automation: what to automate first

At 9:40 on a Tuesday, the SIEM raises an alert for a sign-in from two countries an hour apart. It joins 300 other alerts in the queue. An analyst reaches it after lunch, looks up the user by hand, and messages them on Slack. The user is on leave and doesn’t reply.

By the time IT resets the password, the attacker has set up a mail-forwarding rule. The reset doesn’t remove it, and nobody checks.

None of those steps happened in one tool. The alert came from the SIEM, the user’s details from the identity provider, the conversation from Slack and the reset from the service desk.

This post walks through the seven parts of security operations automation, where each one breaks, and what to automate first.

What is SOC automation?

SOC automation is the work a security team runs every day, done by workflows instead of by hand. It collects the logs detections need, triages alerts, works phishing reports, responds to compromised accounts and endpoints, and routes vulnerabilities and bug reports to the teams that fix them. It runs across the SIEM, identity, endpoint, ticketing and chat systems.

The seven parts, and where each one breaks

1. Security log collection. Sign-in, admin and audit events from every SaaS app reach the SIEM in one shape, minutes after they happen. It breaks when an app’s log feed stops and nobody notices until an investigation needs the missing week. The feed that stopped.
2. Alert triage. Each alert arrives with its owner, asset and history attached, and known noise is held back. It breaks when the one alert that mattered is closed as noise by an analyst four hours into the queue. The alert closed as noise.
3. Phishing report triage. Reported emails are checked, grouped into campaigns and answered, and every copy is found across the company. It breaks when forty people report the same email, forty tickets open, and the copies stay in everyone else’s inbox. Forty reports, one email.
4. Compromised account response. A risky sign-in is checked with the user, and a confirmed takeover has its sessions revoked and its sign-in reset within minutes. It breaks when the password is reset and the attacker’s open session keeps working. The session left open.
5. Endpoint alert containment. A serious detection on a laptop or server isolates the device, tells the user and opens a case, with a person approving where it matters. It breaks when an on-call engineer’s laptop is isolated at 2 a.m. and nobody tells them why. The laptop cut off at 2 a.m..
6. Vulnerability routing. Scanner findings are ranked by real exposure, grouped by fix and sent to the team that ships it. It breaks when thousands of findings land in one security queue and the ones fixed are whichever sit at the top. Whatever’s on top.
7. Bug bounty report triage. Researchers’ reports are checked for duplicates, sized and routed to the owning team, and the researcher hears back on time. It breaks when a valid report waits three weeks for an owner and the researcher posts about it first. The report that waited.

Why security work stalls between systems

Alerts arrive without context. The analyst looks up the user, the device and the history in four tools before deciding anything.

Duplicates multiply the work. One phishing email or one outdated library shows up as dozens of tickets.

Containment waits for someone who isn’t there. Night and weekend alerts wait for the morning, even when the response is clear and can be undone.

Security doesn’t own the fix. Vulnerabilities and bug reports need engineering, and the handoff is an email or a spreadsheet.

Nobody tells the user. The person whose account was locked or whose laptop was isolated finds out when it stops working.

What to automate first

1. Check every log feed daily. A feed that stops sending is an alert of its own.
2. Enrich alerts before anyone opens them. Attach the owner, the asset, recent sign-ins and past alerts on the same user or device.
3. Group duplicates. One phishing campaign is one case. One fix is one ticket, however many findings it closes.
4. Contain the clear cases without waiting. Revoke sessions when the user says a sign-in wasn’t them. Send production servers and administrator accounts to a person for approval, with the evidence attached.
5. Route fixes into engineering’s own tracker. The owning team sees the work where it plans, with a due date set by severity.
6. Tell the user what happened. Send a message in Slack or Teams when their account or device is affected, with how to get it back.

Where AI agents fit

Agents do the reading and the summing up. They read a reported email and explain what is wrong with it, summarize a case for the analyst who picks it up, check a bug report against past ones, and draft the reply to the researcher. An agent never cuts off access or isolates a device on its own. Those steps run on the security team’s written rules, or wait for a person to approve them.

How this differs from a SOAR product

A SOAR product runs playbooks inside the security stack. Much of security work reaches outside it: the HR record that says someone is leaving, the service desk ticket, the engineering tracker that ships the fix, and the chat thread where the user confirms a sign-in. Tray.ai connects those in the same workflow, and works alongside a SOAR product if you already run one.

Tray.ai holds itself to the same standard: it’s audited for SOC 1 and SOC 2 Type 2, tested by independent penetration testers every year, and runs its own bug bounty program. The details are on the Tray.ai trust page.

Three neighboring processes share these systems. The IT service desk resets passwords and fixes laptops, employee offboarding removes access when someone leaves, and vendor risk assessment checks new suppliers before they reach company data.