Security Incident Response Workflow

What happens if the AI can't confidently rate the severity of an incident?

The workflow routes the incident to a security lead who reviews it and manually sets the severity. The workflow waits for this task to be completed, and the manually set severity is saved to the record just as the AI rating would have been. This keeps every incident moving forward even when automated rating is uncertain.

Can this handle both high severity and lower severity incidents differently?

Yes. High severity incidents are routed to a fire-and-forget escalation task for the security manager and get a responder task due in 1 day, while Medium and Low severity incidents get a responder task due in 3 days. All severities then proceed through the same response, recovery and closure stages.

What if external notification isn't required for an incident?

The responder records whether external notification is required as part of their containment and investigation task. If it's marked as not required, the workflow skips the privacy officer task and moves the incident straight to Recovery status. If it is required, a privacy officer task is created to record who was notified and when.

Who is responsible for each stage of the incident response?

A security lead sets severity manually when the AI is unsure, a security manager receives escalation notes on High severity incidents, a responder handles containment, investigation, eradication and recovery confirmation, and a privacy officer handles external notification details when required. Each task is assigned to a workspace member and, apart from the escalation task, the workflow waits for it before moving on.

What does the reporter see or receive during this process?

The reporter submits the initial request through a form and receives an acknowledgement email with their incident reference number right after the record is created. They receive no further contact until the incident is closed, at which point a closure email is sent letting them know the incident has been resolved.

Can we customise the responder task due dates or the fields collected?

Yes. The workflow can be changed by describing the change in plain English or by editing steps directly in the workflow editor, and earlier versions are kept if you want to revert. This means due date rules, form fields, or task assignments can be adjusted to match how your team actually runs incident response.

What information ends up on the incident record versus staying with a task?

Fields entered on tasks the workflow waits for — like containment actions, investigation findings, recovery confirmation and notification details — are saved to the record and visible in its timeline. The escalation task notes for the security manager stay with that task in the record's task list since the workflow doesn't wait for it, so it's not saved as a record field.

How do we track where an incident is in the process?

Each incident is a record with a reference number, a status, and a timeline showing what has happened. Status moves through Reported, Responding, Recovery and Closed, and table views and dashboards can show all incidents grouped by their current status.

What if an incident needs to loop back through containment after recovery starts?

The workflow as defined moves from response through to a single recovery confirmation task once external notification handling is complete. If your team needs additional containment or investigation cycles, the workflow's steps can be edited to add extra tasks or routing before recovery, since it's changed by describing the change in plain English or editing steps in the workflow editor.

Does this workflow help with regulatory reporting obligations?

The workflow records who was externally notified and when, along with the incident's full timeline and status history, which can support a business's own reporting process. Each business should confirm its own regulatory and compliance obligations separately, as this workflow tracks the information entered rather than determining what is legally required.