Automated Incident Response

Why automate incident response?

When a security incident is confirmed, speed matters. Every minute between detection and containment is a minute the attacker has to move laterally, exfiltrate data, or escalate privileges.

Manual incident response is slow because it involves multiple tools and multiple teams:

• Isolate the compromised host (EDR console)
• Block the attacker's IP (firewall console)
• Disable the compromised account (Active Directory / IdP)
• Preserve forensic evidence (endpoint collection tool)
• Notify stakeholders (email, Slack, ticketing system)
• Document everything (case management, compliance records)

OpenSOAR helps by making the alert-to-incident path explicit, keeping the case artifacts together, and letting Python playbooks do the repetitive enrichment and response work around that workflow.

Incident response with OpenSOAR core

In the current public core release, the incident workflow is built around a few concrete operator surfaces:

• Create a new incident from the alert detail page when the work becomes case-level.
• Link additional alerts into that incident without leaving the investigation flow.
• Assign an incident owner directly from the incident page.
• Use the shared incident timeline for comments, handoff notes, and system activity.
• Add incident-scoped observables for IPs, domains, hashes, and other case artifacts.
• Review lightweight incident suggestions based on unlinked alerts that share a source IP.

What the workflow looks like

Escalate alerts into incidents without losing context

A practical OpenSOAR playbook usually does two things well: it enriches or preserves useful context, and it leaves the alert ready for a human to continue the case. The actual incident create/link action then happens in the operator workflow.

from opensoar import add_current_alert_comment, playbook, update_current_alert

@playbook(
    trigger="webhook",
    conditions={"severity": ["critical"]},
    order=10,
)
async def escalate_critical_alert(alert):
    await asyncio.gather(
        lookup_ip_reputation(alert.get("source_ip")),
        preserve_host_context(alert.get("hostname")),
    )

    await update_current_alert(
        status="in_progress",
        determination="suspicious",
        reason="Critical alert escalated for incident handling",
    )
    await add_current_alert_comment(
        "Enrichment and evidence preservation completed. Create or link an incident from the alert detail page."
    )

    return {"status": "incident_ready"}

Sequence playbooks when the order matters

Some incident workflows are easier to operate as multiple focused playbooks instead of one giant file. OpenSOAR now supports explicit playbook ordering, so related playbooks can execute sequentially when the order matters.

@playbook(
    trigger="webhook",
    conditions={"tags": ["docker"]},
    order=10,
)
async def preserve_container_state(alert):
    await collect_container_logs(alert.get("hostname"))


@playbook(
    trigger="webhook",
    conditions={"tags": ["docker"]},
    order=20,
)
async def restart_container(alert):
    await restart_service(alert.get("hostname"))

Coordinated response across tools

Real incident response spans multiple tools. OpenSOAR orchestrates them from Python playbooks while the incident page stays the shared case-management surface:

• EDR: Isolate hosts, collect artifacts, run remote scans
• Firewall: Block IPs, domains, update threat feeds
• Identity: Disable accounts, force password resets, or escalate suspicious access
• Email: Search for and quarantine related phishing emails
• OpenSOAR incident workflow: Create incidents, link alerts, assign owners, and preserve comments/observables
• Communication: Notify stakeholders via Slack, Teams, or email

Incident workflow templates

Good OpenSOAR incident playbooks tend to follow a repeatable pattern:

• High-signal triage — enrich first, then move the alert to in_progress with a clear determination and note
• Case escalation — create or link an incident once multiple alerts or artifacts belong together
• Ownership — assign the incident to the analyst coordinating the wider case, not just the first alert
• Shared artifacts — add observables to the incident when they matter across multiple linked alerts
• Ordered remediation — split playbooks and use order=... when the recovery sequence must be deterministic

Compliance and documentation

Incident timelines, alert state transitions, comments, and observable additions create a durable investigation record that is much easier to review during audits or post-incident work:

• SOC 2 incident response documentation
• internal post-incident reviews and handoffs
• regulated environments that need an understandable chronology of analyst and system actions

Build incident response workflows in Python and run the casework from incidents. Get started with OpenSOAR →