Back to Cybersecurity Incident Response

Process Runbook / SOP

How the automation works day-to-day: what is automatic, what needs a human, how exceptions are handled, and who to contact.

4 pagesPDF · Operations
FS-DOC-03Operations

Process Runbook / SOP

Cybersecurity Incident Response

[YourCompany.com] · IT Department · Prepared by FullSpec · [Today's Date]

This runbook is the day-to-day operating guide for the IT Manager responsible for cybersecurity incident response at [YourCompany.com]. It describes how the automated process works from the moment a Microsoft Defender alert fires through to post-incident documentation, clarifies the single step that requires human judgement, and sets out what to do when something goes wrong. FullSpec has built and tested every automated step. Your team owns the review-and-confirm checkpoint and the ongoing configuration decisions described in Section 05.

01Process overview

When a security alert fires in Microsoft Defender, the automation platform picks it up immediately and hands it to the Triage Agent, which classifies the alert against a standardised severity rubric, pulls the relevant audit logs and sign-in data from Microsoft 365, and creates a fully populated Jira incident ticket. The Notification Agent then routes a formatted alert to the correct Slack channel and, for Critical or High severity incidents, escalates automatically via PagerDuty before a human has opened their inbox. The IT Manager reviews the classified ticket and confirms or overrides the containment recommendation. Once the ticket is resolved, the Incident Documentation Agent compiles a structured Notion incident report and posts the post-incident summary to Slack. The process runs across 12 to 20 alerts per week and reduces the IT Manager's active handling time from roughly 195 minutes per incident to 20 to 40 minutes.

Process name
Cybersecurity Incident Response
Trigger
A new security alert fires in Microsoft Defender or a connected monitoring tool
Final output
A resolved Jira ticket, a completed Notion incident report, and a post-incident Slack summary sent to stakeholders
Agents running
Triage Agent, Notification Agent, Incident Documentation Agent
Tools involved
Microsoft Defender, Microsoft 365, Jira, PagerDuty, Slack, Notion
Weekly volume
12 to 20 alerts requiring triage
Human checkpoint
IT Manager reviews the classified incident in Jira or Slack and confirms or overrides the containment recommendation (approx. 20 min per incident)
Process owner
IT Manager
Process Runbook / SOPPage 1 of 4
FS-DOC-03Operations

02Step-by-step: what happens and who acts

What you actually need to do: Your only required action in this process is Step 6. When an alert is classified and the Jira ticket is open, you will receive a Slack notification (and a PagerDuty page for Critical or High severity incidents) with the severity tag, alert summary, and a direct link to the ticket. Open the ticket, review the Triage Agent's classification and the attached log excerpts, then either approve the suggested containment action or override it with your own. Everything before and after that step is handled automatically.
Step
What happens
Who acts
Type
1
Microsoft Defender fires a security alert. The automation platform detects it via the Defender API or webhook and passes it to the Triage Agent immediately, with no manual reading required.
Automation
Automated
2
The Triage Agent scores the alert against the agreed severity rubric, tagging it as Critical, High, Medium, or Low based on alert type, affected asset category, and user context pulled from the Defender payload.
Triage Agent
Automated
3
The Triage Agent fetches the relevant audit logs and sign-in activity for the affected user or device from Microsoft 365 and attaches a structured log summary to the incident record, capturing evidence at the earliest possible moment.
Triage Agent
Automated
4
A Jira incident ticket is created automatically with the severity tag, alert details, affected asset name, and the log summary pre-filled. No manual data entry is needed.
Triage Agent
Automated
5
The Notification Agent posts a formatted Slack message to the IT incident channel containing the severity level, a plain-English summary, and a direct link to the Jira ticket. For Critical or High severity tickets, PagerDuty simultaneously pages the on-call contact without waiting for the IT Manager to escalate manually.
Notification Agent
Automated
6
The IT Manager opens the Jira ticket via the Slack link or PagerDuty alert, reviews the Triage Agent's severity classification and the attached log excerpts, and either approves the suggested containment action (such as account isolation or device quarantine) or overrides it with a different action. This is the only step that requires a human decision.
IT Manager
Human
7
As the IT Manager updates the Jira ticket with their actions and resolution details, the Incident Documentation Agent compiles a structured Notion incident report page in real time, pulling the alert data, log excerpts, ticket updates, and resolution status into the standard template.
Incident Documentation Agent
Automated
8
Once the Jira ticket is marked as resolved, the Incident Documentation Agent sends a post-incident summary to the Slack channel and links the completed Notion report for stakeholder reference. The audit trail is complete without anyone writing it from memory.
Incident Documentation Agent
Automated
Process Runbook / SOPPage 2 of 4
FS-DOC-03Operations

03Handling exceptions

Situation
What the system does
What you do
Alert arrives with missing or incomplete data (e.g. no affected user or asset identifier in the Defender payload)
The Triage Agent tags the ticket as 'Incomplete Data' and sets the severity to High by default as a precaution. A Slack notification is sent to the IT incident channel flagging the missing fields.
Open the Jira ticket, manually add the missing asset or user details, then confirm or adjust the severity tag before approving any containment action. Do not approve containment on an incomplete ticket.
A duplicate alert fires for the same incident within a short window (Defender sometimes generates multiple alerts for a single event)
The automation checks for an open Jira ticket with a matching alert signature. If a match is found, the duplicate is linked to the existing ticket and no new ticket is created. A note is added to the original ticket log.
No action is required unless the linked duplicate contains new information not present in the original ticket. Review the original ticket and close if resolution is already confirmed.
The Triage Agent cannot find matching log data in Microsoft 365 (e.g. the affected account has no recent sign-in activity or the log retention window has passed)
The Jira ticket is created without the log attachment. The ticket notes that log retrieval returned no results, and the severity classification is flagged as 'Low Confidence' for your attention.
Review the alert in Microsoft Defender directly to gather context, attach any relevant findings to the Jira ticket manually, and adjust the severity tag if needed before confirming any action.
The IT Manager does not act on the Jira ticket within 30 minutes of a Critical or High severity alert being raised
PagerDuty sends a follow-up escalation page to the on-call contact. If still unacknowledged after a further 15 minutes, a second escalation is sent to the backup contact defined in the PagerDuty schedule.
Acknowledge the PagerDuty alert as soon as possible. If you are genuinely unavailable, confirm the backup contact in your PagerDuty schedule is correct and reachable. Do not silence the escalation without acting on the ticket.
PagerDuty is unavailable or fails to deliver the escalation notification
The automation logs the PagerDuty delivery failure and sends a direct Slack message to the IT Manager and the escalation contact as a fallback. The Jira ticket remains open and the failure is logged in the error trail.
Check the IT incident Slack channel directly if you suspect a PagerDuty outage. Confirm the incident has been acknowledged by a team member and escalate via phone or email if Slack also has issues. Report the PagerDuty failure to support@gofullspec.com.
Notion is unavailable when the Incident Documentation Agent attempts to create the incident report
The agent retries three times at five-minute intervals. If all retries fail, the raw incident data (alert details, log summary, and ticket updates) is saved as a structured JSON record in a fallback location and a Slack alert is sent to the IT Manager.
When Notion comes back online, notify support@gofullspec.com so the FullSpec team can trigger a manual re-run of the documentation step using the saved fallback record. Do not write the Notion report from scratch; the data is preserved and will be compiled automatically once connectivity is restored.

04Who to contact and when

Fill in the rows below once your team is confirmed. The FullSpec rows are fixed. Keep this table accessible to anyone who might need to act on an incident, and update it whenever a role or contact changes.

Role
Name
How to reach them
IT Manager (process owner)
[Your name]
[Your email / Slack handle / phone]
Escalation contact (on-call backup)
[Rep name]
[Rep email / PagerDuty schedule link]
Operations Lead
[Rep name]
[Rep email]
FullSpec builder (build and configuration questions)
FullSpec team
support@gofullspec.com
FullSpec support (errors, failures, urgent issues)
FullSpec support
support@gofullspec.com
For any live automation failure, an active incident where the automation is not behaving as expected, or a situation covered by the exception table that you cannot resolve yourself, contact support@gofullspec.com and include the Jira ticket number and a screenshot of the relevant Slack or PagerDuty notification. The FullSpec team will investigate and respond as a priority.
Process Runbook / SOPPage 3 of 4
FS-DOC-03Operations

05Ongoing maintenance

When
What to do
Who
Whenever your Microsoft 365 or Defender configuration changes (new users, new devices, new alert policies)
Notify the FullSpec team so the Triage Agent's log-pull logic and severity rubric can be reviewed for compatibility. New alert types not covered by the current rubric will be misclassified until the rubric is updated.
IT Manager, with FullSpec support
Whenever the Notion incident report template or Jira ticket fields are changed
Contact FullSpec before making structural changes to the Notion page template or adding mandatory Jira fields. The Incident Documentation Agent maps directly to the existing field structure; changes without updating the agent will cause report generation to fail.
IT Manager notifies FullSpec at support@gofullspec.com before making changes
Monthly spot-check (first week of each month)
Review three to five recent Jira tickets end-to-end. Confirm that severity tags are correct, log excerpts are attached, the Notion report page was created, and the post-incident Slack summary was sent. Flag any gaps to FullSpec.
IT Manager
Weekly error-log review (every Monday)
Check the automation platform's error log for any failed steps, missed retries, or Notion fallback events from the previous week. A summary can be provided by FullSpec on request if you do not have direct log access.
IT Manager, or FullSpec on request
Whenever a team member changes role or leaves (IT Manager, escalation contact, on-call backup)
Update the contact table in Section 04 of this runbook, update the PagerDuty on-call schedule, and notify FullSpec if the process owner changes so documentation and access permissions can be updated accordingly.
IT Manager or Operations Lead
Quarterly volume review (every three months)
Review the weekly alert volume against the current threshold settings. If alert volume has grown significantly beyond 20 per week, the classification logic and Slack channel routing rules may need adjustment to avoid notification fatigue. Contact FullSpec to discuss.
IT Manager, with FullSpec support
The most common maintenance issue for this process is severity rubric drift. Over time, new alert types from Microsoft Defender will not match the original rubric categories, and the Triage Agent will assign incorrect severity tags to unfamiliar alerts. If you notice that Low severity tickets are being escalated via PagerDuty, or that Critical alerts are not triggering the escalation path, the rubric almost certainly needs updating. Contact support@gofullspec.com and the FullSpec team will review the classification logic and update the rubric with you.
Process Runbook / SOPPage 4 of 4

More documents for this process

Every document generated for Cybersecurity Incident Response.

Launch Plan
Operations · Owner
View
ROI and Business Case
Finance · Owner
View
Developer Handover Pack
Technical · Developer
View
Integration and API Spec
Technical · Developer
View
Test and QA Plan
Quality · Developer
View