Incident Response Runbooks for a Two-Person Ops Team

Incident response runbooks for a two-person operations team cannot assume a twenty-four-seven security operations center, a dedicated forensics retainer on speed dial, or luxury staffing. They must assume that one person may be unavailable, that customers may notice before you do, and that evidence vanishes if you reboot first and think later. Good runbooks are short, role-aware, and tested.

This guide outlines severity definitions, role splitting, communications, and evidence preservation that a two-person team can actually execute under stress.

Roles when there are only two of you

Pre-assign primary and secondary responsibilities for technical containment, communications, and evidence handling. During an incident, one person should lead technical actions while the other handles notifications, timeline notes, and vendor calls. Swapping mid-incident is fine if spoken out loud; silent role confusion is not.

Technical lead: containment, eradication steps, system changes.
Comms lead: internal stakeholders, customer messaging drafts, status page.
Both: agree on severity within the first fifteen minutes.
Neither: freelances irreversible actions without a quick verbal check when both are present.

Severity that drives behavior

Define three or four severity levels with examples tied to your product: confirmed or likely data exposure, full customer-facing outage, partial degradation, and suspicious but contained activity. Severity selects paging urgency, executive notification, and whether to pause feature work. Ambiguous severity wastes the first hour.

Communications templates

Write templates before you need them: internal incident channel kickoff, executive summary bullets, customer status updates, and a holding statement if facts are incomplete. Templates prevent improvisation under stress from becoming accidental over-promise or under-disclosure.

Evidence preservation

Snapshot critical disks and freeze relevant logs before major rebuilds when a breach is plausible.
Copy authentication and audit logs to storage outside the potentially compromised account.
Record commands run and times in a shared timeline document.
Avoid destroying the only compromised host before imaging if forensics may be needed.
Preserve cloud trail events and identity logs early; default retention can be short.

Containment without making it worse

Prefer disabling compromised credentials, isolating network paths, and blocking known bad indicators over reckless mass reboots. Document assumptions. If you must choose between uptime and preserving evidence for a likely breach, escalate that choice explicitly rather than guessing silently.

After-action for tiny teams

Within a week, write a one-page post-incident review: what happened, what worked, what to change in runbooks, and which backlog items now jump the queue. Tiny teams skip this when busy; that is how the same incident repeats.

Millennium Science publishes practical operations and cybersecurity guidance for teams that run real production systems. Use this article as a working checklist, adapt it to your architecture, and revisit it when people, vendors, or threat models change.

Paging and personal limits

Two-person teams burn out if every severity page both people forever. Define when a single primary is enough and when both must join. Protect sleep with explicit handoff notes. Exhausted responders destroy evidence and miss containment opportunities.

Cross-train at least one engineer outside the core two for communications or status-page updates during vacations. A runbook nobody else can read is a single point of failure.

Tooling that fits the staffing model

You need a shared incident channel, a timeline document, out-of-band contact methods if corporate email is suspect, and pre-staged cloud roles for containment. Fancy case-management software is optional; disciplined notes are not.

Further implementation guidance

Translate guidance into tickets with owners, due dates, and verification steps. Controls without owners become folklore. Partial improvements that shrink blast radius this week beat waiting for perfect projects that never ship. Document residual risk in plain language leaders understand.

Keep decisions beside runbooks engineers open during incidents. Link diagrams, dashboards, and exception registers. After the first related incident, run a short retrospective and update procedures while memory is fresh.