Workflow Template

Security Incident Response Workflow

Enables a security team to intake suspected cyber events, automatically classify severity, assign a responder to contain/investigate/eradicate the threat, escalate high-severity events, assess breach notification requirements, and record lessons learned before closing the incident.

When a suspected breach lands in someone's inbox at 5pm on a Friday, security teams scramble through email threads and spreadsheets to figure out severity, who owns it, and whether legal needs to know. The Security Incident Response Workflow captures every incident the moment it's reported, auto-classifies severity, routes high-risk events for human review and escalation, and forces a breach notification assessment before anyone can close the case. Teams get a consistent, auditable response every time instead of ad-hoc firefighting that misses steps under pressure.

Business Outcomes

Cut incident triage time from hours to minutes with automatic severity classification
Eliminate missed escalations with forced routing on high-severity events
Reduce breach notification compliance risk with a mandatory assessment step before closure
Create a full audit trail of containment, investigation, and eradication actions
Capture lessons learned on every incident instead of only major ones

Workflow Steps

Steps

1
Create Incident Recordcreate record
Registers the reported incident as a security_incident record.
2
Set Status to Openupdate record
Marks the incident as Open on creation.
3
Classify Severityai classification
AI classifies the incident severity based on indicators and impact.
4
Route on Severity Classification
Routes low-confidence classifications to human review; otherwise proceeds.
_ai_clf_classify_severity_needs_human_review: "true"→Human Review of Severity
_ai_clf_classify_severity_category: "human_review"→Human Review of Severity
Default→Persist Severity to Record
5
Human Review of Severityrequest approval
A senior analyst manually reviews and confirms the incident severity.
6
Route on Severity Review Outcome
Routes based on whether the manual severity review is approved.
approval_status: "approved"→Persist Severity to Record
approval_status: "rejected"→Escalate Severity for Senior Review
Default→Persist Severity to Record
7
Persist Severity to Recordupdate record
Writes the determined severity classification to the incident record.
8
Assign Responderassign user
Assigns the incident to a security responder for handling.
9
Contain, Investigate and Eradicatecreate task
Responder contains the threat, investigates root cause, and eradicates it.
10
Persist Containment/Investigation Dataupdate record
Writes containment, investigation and eradication details to the record.
11
Route on Escalation Requirement
Escalates internally if the responder flagged the incident as high-severity or requiring escalation.
escalation_required: "Yes"→Escalate Internally
Default→Assess Notification Requirement
12
Escalate Internallyupdate record
Escalates the high-severity incident to senior security management.
13
Notify Security Managementcreate task
Creates a task for security management to review the escalated incident.
14
Assess Notification Requirementcreate task
Responder assesses whether affected parties or regulators must be notified.
15
Persist Notification Assessmentupdate record
Writes the notification decision and details to the record.
16
Route on Notification Requirement
Sends notifications if required before proceeding to recovery.
notification_required: "Yes"→Send Notification to Reporter
Default→Record Recovery, Lessons Learned and Corrective Actions
17
Send Notification to Reportersend email
Notifies the reporter that affected-party notification is underway.
18
Record Recovery, Lessons Learned and Corrective Actionscreate task
Responder confirms recovery and documents lessons learned and corrective actions.
19
Close Incidentupdate record
Persists lessons learned, corrective actions and marks the incident as Closed.
20
Escalate Severity for Senior Reviewupdate record
Manual severity review was rejected; escalate to senior analyst for a final severity determination before proceeding.
21
Begin Recoveryupdate record
Marks the incident as Recovering as the responder confirms recovery before documenting lessons learned.

Fields

Reporter Name*
Reporter Email*
Affected Users
Affected Devices or Systems*
Date/Time Detected*
Indicators of Compromise*
+11 more fields

Forms

Security Incident Report

8 fields

Data Views

All Security Incidents

security_incident_ref, incident_status, detected_at, affected_devices_systems +1 more

Dashboard Widgets

Incidents by StatusIncident OverviewRecent Incidents

Recommended integrations

Setup the following integrations to extend workflow capability.

Send email in the workflow
AWS SES

security incident responsecyber incidentcybersecurity workflowdata security incidentincident response

Similar Workflows

it incident management data breach response vulnerability remediation

Similar Categories

information technology governance compliance

FAQs

What happens if the automatic severity classification is wrong?

The workflow includes a Human Review of Severity step after the automatic classification, so a security analyst always checks and can override the system's rating before it's persisted to the record. The Route on Severity Review Outcome step then sends the incident down the correct path based on the confirmed severity, not just the initial guess. This two-layer check keeps automation fast without letting a misclassified critical incident slip through as low-priority.

Can this handle incidents that don't need breach notification?

Yes. The Assess Notification Requirement step evaluates each incident individually, and the Route on Notification Requirement step branches the workflow so only incidents that actually require notifying affected parties trigger the Send Notification to Reporter step. Incidents that don't meet the threshold skip straight to recovery and closure, so you're not sending unnecessary notifications or wasting legal review time.

What if an incident needs to be escalated after it's already assigned?

The Route on Escalation Requirement step can trigger at any point where escalation criteria are met, sending the incident to Escalate Internally and Notify Security Management even if a responder is already working containment. Escalation doesn't restart the workflow — it runs in parallel, alerting leadership while containment and investigation continue. You can adjust escalation thresholds directly in assess.one to match your team's risk tolerance.

Can we customise who gets assigned as the responder?

Yes, the Assign Responder step's routing logic is fully configurable inside assess.one, so you can set assignment rules by severity, incident type, on-call rotation, or team specialty. You can also change approval logic, notification recipients, and role permissions at each step without needing developer support. Changes take effect immediately on the next published version of the workflow.

Who needs access to this workflow?

Typically security analysts, incident responders, and security management need active roles in the workflow, while legal or compliance stakeholders may only need visibility into the notification assessment step. Access and permissions are configured per role inside assess.one, so you control exactly who can view, edit, or approve at each stage. This keeps sensitive incident data restricted to people who need it.

What if containment fails and the threat isn't actually eradicated?

The Contain, Investigate and Eradicate step doesn't force a one-way path — the responder can loop back and re-run containment actions as new findings emerge, and all updates are captured in Persist Containment/Investigation Data. The incident stays open and in the responder's queue until eradication is genuinely confirmed. This prevents premature closure on incidents that resurface.

How long does it take to get this workflow running?

This is a ready-to-use template, so publishing it takes minutes, not weeks. Once published, your security team can start logging incidents and running the live process immediately — there's no implementation project or software installation required. You can still fine-tune steps, routing rules, and notifications after go-live as your process evolves.

What compliance considerations does this workflow address?

The mandatory Assess Notification Requirement and Persist Notification Assessment steps ensure every incident gets evaluated against notification obligations before closure, creating a documented decision trail. Combined with the Lessons Learned and Corrective Actions step, you get an audit-ready record showing what happened, how it was assessed, and what was done about it. This structure supports internal audits and regulatory reviews without extra manual documentation work.

Can we run multiple incidents through the workflow at the same time?

Yes, each incident generates its own record and moves through the workflow independently from Create Incident Record to Close Incident. Responders and management can have multiple incidents open simultaneously without them interfering with each other's status, severity, or notification tracking. This is standard behavior in assess.one and requires no extra configuration.

What happens at the Lessons Learned step if the team skips it?

The workflow places Lessons Learned and Corrective Actions before Close Incident, so the incident can't be marked closed until that step is completed. This prevents teams from rushing past post-incident review under pressure to clear the queue. You can adjust who's required to complete this step — for example, requiring manager sign-off — directly in the workflow's approval logic.

Ready to use this workflow?

Create a free account and customise this workflow for your business.