How to set up an incident response plan

Most security teams don't lack incident response knowledge — they lack a plan that survives contact with an actual 2 a.m. page. When a credential leaks, a build pipeline gets tampered with, or a dependency turns out to be malicious, the difference between a contained incident and a multi-day breach disclosure usually comes down to whether someone wrote the playbook before the fire started. This guide walks through how to set up an incident response plan for a software supply chain organization, from defining severity tiers through running your first tabletop exercise. By the end, you'll have a working incident response playbook template, clear escalation paths, and the logging and alerting hooks needed to detect and respond to incidents in your build and deployment pipeline — not just your production servers.

Step 1: Define Scope and Objectives Before You Set Up an Incident Response Plan

Before writing a single procedure, decide what "incident" actually means for your organization. Supply chain security incidents span a wider surface than classic network intrusions — compromised CI/CD credentials, a poisoned npm or PyPI package pulled into a build, a tampered container image in your registry, or a leaked signing key all count.

Start with a short charter document that answers:

• What systems are in scope (source control, CI/CD, artifact registries, package managers, production infrastructure)?
• What triggers plan activation (a confirmed compromise vs. a suspicious alert)?
• Who owns the plan and who can declare an incident?

Then define severity tiers so responders aren't debating priority mid-incident:

Write this down and get sign-off from engineering leadership and legal/compliance — you'll reference it constantly once you move into the security incident response steps below.

Step 2: Build Your Incident Response Team and RACI

An incident response plan without named owners is a wish list. Define an incident response team (IRT) with clear roles:

• Incident Commander (IC) — coordinates the response, makes the call decisions, owns communication timing.
• Technical Lead — drives containment and forensics (often a security engineer or SRE).
• Communications Lead — handles internal updates and, if needed, customer/regulator notifications.
• Scribe — maintains the timeline log in real time (this becomes your post-incident record).

Map this to a RACI so there's no ambiguity during a live incident:

Role            Detection  Containment  Eradication  Communication
IC              C          A            A            R
Security Eng    R          R            R            C
Platform/SRE    C          R            R            I
Legal/Comms     I          I            I            R

Keep an on-call rotation and a backup for every role — supply chain incidents rarely happen during business hours, and a plan that only works when the one expert is awake isn't a plan.

Step 3: Create Your Incident Response Playbook Template

This is the operational core: a repeatable incident response playbook template you fill in per incident type (leaked secret, malicious dependency, compromised build, unauthorized registry push). Each playbook should follow the same skeleton so responders don't have to relearn structure under pressure:

playbook: compromised-cicd-credential
trigger: "Anomalous API calls from CI/CD service account"
severity_default: SEV-2
steps:
  detect:
    - confirm_alert_source
    - check_credential_scope_and_permissions
  contain:
    - revoke_credential
    - rotate_dependent_secrets
    - freeze_affected_pipelines
  eradicate:
    - audit_recent_pipeline_runs
    - scan_artifacts_built_with_credential
  recover:
    - reissue_scoped_credential
    - re-enable_pipelines
    - verify_clean_build
  communicate:
    - notify: [ic, security-team, affected-service-owners]
    - external_notification_required: false

Store these as version-controlled files (a playbooks/ directory in your security repo works well) so they're reviewed via pull request like any other config. Build at least one incident response playbook template for each of your top five threat scenarios — this is also a good place to keep a redacted ir plan example from a past incident or industry postmortem so new responders can see what "done" looks like.

Step 4: Instrument Detection, Logging, and Alerting

A plan is only as good as your ability to detect the trigger conditions. For software supply chain incidents, make sure you're capturing:

• Build and pipeline logs (who triggered a build, what credentials it used, what it pulled)
• Package/dependency resolution logs (new or changed lockfile entries, unexpected registry sources)
• Artifact signing and provenance events (SLSA/in-toto attestation failures)
• Registry push/pull events, especially from unfamiliar IPs or service accounts

A simple alerting rule to start with, using a log-query style pseudocode against your SIEM:

SELECT actor, pipeline_id, credential_id, source_ip
FROM cicd_audit_log
WHERE action = 'credential_use'
  AND source_ip NOT IN (known_runner_ip_ranges)
  AND timestamp > now() - interval '15 minutes'

Wire this into your paging tool (PagerDuty, Opsgenie) with routing tied to the severity tiers from Step 1, and make sure the on-call IC is one of the first three people notified — not buried in a shared inbox.

Step 5: Document Communication and Escalation Procedures

Under pressure, people default to whatever channel is fastest — which is exactly when you need pre-agreed structure. Define:

• A dedicated incident channel naming convention (e.g., #inc-2026-0142) created automatically by your paging tool integration
• A status update cadence (every 30 minutes for SEV-1, hourly for SEV-2)
• Pre-approved external communication templates for customers and regulators, reviewed by legal in advance
• A clear decision tree for when a security incident triggers breach notification obligations (SOC 2, GDPR, customer contractual SLAs)

Draft your customer and regulator notification templates now, while calm, not while your IC is trying to compose one during an active SEV-1.

Step 6: Run Tabletop Exercises to Validate the Plan

A plan nobody has rehearsed is a hypothesis. Schedule tabletop exercises at least quarterly, walking the IRT through a realistic scenario end to end — a compromised dependency merged into main, a leaked deploy key, a tampered container image. Use these sessions to:

• Time how long it actually takes to reach containment following the security incident response steps you wrote
• Identify gaps (missing runbook steps, unclear ownership, tooling that doesn't actually revoke access fast enough)
• Update the incident response playbook template based on what broke

Track a simple metric after each exercise: mean time to detect (MTTD) and mean time to contain (MTTC). If these numbers aren't improving release over release, the plan needs revision, not just repetition.

Step 7: Establish Post-Incident Review and Continuous Improvement

Every real incident — and every tabletop — should end with a blameless post-incident review within 5 business days. Capture:

• Full timeline from detection to resolution (this is why the Scribe role matters)
• Root cause and contributing factors
• What worked, what didn't, and specific action items with owners and due dates
• Updates needed to the relevant playbook or the overall plan

Feed action items back into Steps 3 and 4 so the plan is a living document, not something that gets written once and reopened only during an audit.

Troubleshooting and Verification

Once the plan is drafted, verify it actually works before you need it:

• Test your paging path end to end. Trigger a synthetic alert and confirm it reaches the correct on-call IC within your SLA — not just that the alert fired, but that a human acknowledged it.
• Confirm credential revocation actually works. Many teams discover mid-incident that a "revoked" API key still has cached validity for 15 minutes due to token TTLs. Test this in advance and document real revocation latency in your playbooks.
• Check that playbooks are discoverable under stress. If your playbooks/ directory isn't linked from your on-call runbook or paging tool, responders will waste critical minutes searching for it.
• Validate communication templates render correctly with real incident data (channel names, severity, affected systems) rather than only reviewing them as static text.
• Audit who has permission to declare an incident and edit the plan. Overly restrictive access delays response; overly broad access risks the plan itself being tampered with during an attack.
• If a tabletop reveals that containment steps depend on a person or tool that wasn't available, add an explicit backup path rather than assuming it won't happen again.

How Safeguard Helps

Safeguard is built for exactly the gap most incident response plans leave open: the software supply chain itself. Instead of relying on generic infrastructure logs, Safeguard gives you provenance-aware visibility into your build pipelines, dependencies, and artifacts, so the detection step in your plan has real signal to act on — anomalous package sources, unsigned or tampered artifacts, and unexpected changes to CI/CD configuration are surfaced before they reach production.

When an incident does happen, Safeguard's audit trail of build and dependency events gives your Technical Lead and Scribe the timeline data they'd otherwise have to reconstruct manually, cutting hours out of the containment and post-incident review steps. And because Safeguard integrates with your existing alerting and ticketing tools, the detections it generates plug directly into the escalation procedures and playbooks you set up in Steps 4 through 6 — so your incident response plan isn't just a document, it's connected to the systems that will actually catch the next incident.