Automating Repetitive Steps Out of Incident Response

This case study generalizes a recurring pattern from professional work across multiple security engineering roles. Employer, client, tooling and figures have been abstracted or approximated to preserve confidentiality.

Problem

Incident response is largely the same handful of steps repeated with different inputs: pull context, check known sources, enrich a ticket, notify the right people. Analysts did this by hand across disconnected tools — slower, and inconsistent depending on who was on shift.

Approach

Treat the SOAR platform as the integration layer, not just an alerting inbox: automate the mechanical parts of triage consistently, and leave analysts the judgement calls that actually need a human.

Architecture

• Custom commands and integrations connected the SOAR platform to internal and third-party APIs.
• Playbooks encoded the repeatable parts of response: context, enrichment, routing by severity.
• TAXII-based intel feeds gave automations current, structured context instead of stale, manually maintained lists.
• Built for maintainability, so other engineers could extend or debug without reverse-engineering the original intent.

Implementation

Built primarily in Python as custom SOAR integrations and commands. Most of the effort went into the playbook logic itself — branching cleanly across different alert types, handling failures without leaving a ticket stuck mid-flow, and coordinating several integrations into one workflow that behaved consistently every time.

Lessons

The hard part of automation isn’t wiring up an API — it’s the orchestration logic that has to hold up under every edge case a real alert can throw at it. A playbook that only works for the clean, expected case isn’t done.