A Small Business Incident Response Runbook

A hypothetical bookkeeping firm discovers unfamiliar forwarding rules in its shared mailbox. Employees can still sign in, so the business initially considers waiting until the next working day. A runbook should make that moment easier: identify who takes control, which evidence to preserve, which access to contain, and how business work continues while the incident is investigated.

Prepare a page people can use under pressure

Keep the first page short and available outside the systems it describes. Include the incident lead, alternate, technology provider, insurance contact where relevant, and approved external communication route. Confirm contact details periodically. A plan stored only inside a possibly compromised mailbox may be inaccessible or unsafe when needed. Maintain a protected offline or separately accessible copy of essential instructions.

Define the difference between an observation and a conclusion. An unfamiliar rule is an indicator requiring investigation; it does not establish the full extent of access or prove that data was taken. Start an incident record with time, reporter, affected account or service, observed behavior, and actions already performed. Preserve original timestamps and note the time zone rather than rewriting all observations from memory later.

NIST SP 800-61 Revision 3 frames incident response within cybersecurity risk management. This small-business runbook is an editorial operating outline, not a substitute for the organization's tailored response plan or professional investigation.

Assign decision rights before an incident

Name who can disable accounts, isolate devices, approve emergency spending, notify customers, and authorize restoration. One person may hold several roles in a small firm, but the decisions should remain explicit. Make it possible to reach an alternate when the owner is unavailable. Include provider escalation details and the information a support case will require without embedding live credentials in the plan.

Classify urgency by the consequences of continued access and disruption. A suspected account takeover, destructive activity, and a routine failed login deserve different handling. Avoid an elaborate scoring system nobody can apply under pressure. A short escalation rule can say that unexplained privileged access or active data destruction requires immediate incident-lead contact. The exact threshold should reflect the firm's actual systems and risk tolerance.

Preserve useful evidence while containing harm

Record what is visible before changing it when that can be done without prolonging active harm. Preserve relevant audit logs, provider alerts, message headers, and configuration details through approved methods. Keep copies protected and limit access. Do not ask staff to forward sensitive evidence to personal email or post it in an unrestricted team channel merely for convenience.

Containment depends on the platform and situation. Revoking suspicious sessions, restricting a compromised account, or isolating an affected device may be appropriate under the lead's direction. Avoid improvised destructive cleanup that removes evidence. If active harm is occurring, containment can take priority; document why an action was taken and what information could not be collected beforehand. Engage qualified support when the team lacks the necessary expertise.

1. Report the observation and start a timeline.
2. Assign an incident lead and assess immediate harm.
3. Preserve available evidence and contain affected access.
4. Investigate scope and coordinate required communications.
5. Restore from an understood state and review the response.

Apply the runbook to a hypothetical mailbox incident

The firm's lead confirms that a forwarding rule is unfamiliar and records its destination and creation evidence from available provider logs. The mailbox owner verifies that it was not an authorized change. The lead contacts the mail provider through a known route, contains account access using documented controls, and checks related accounts and application grants. Each action enters the timeline with its owner.

The firm does not announce that every client message was exposed solely because a rule existed. It distinguishes confirmed behavior from unknown scope and obtains advice about notification obligations for the relevant jurisdiction and contracts. Meanwhile, a verified alternate channel handles urgent client communication. This example is hypothetical and deliberately avoids promising that one password change resolves the incident or invalidates every possible credential.

Restore a trustworthy operating state

Recovery requires more than making the service available. Determine whether malicious configuration, unauthorized identities, or unsafe integrations remain. Follow provider-specific recovery procedures. For affected workstations, qualified responders may recommend rebuilding rather than attempting uncertain cleanup. Validate essential business workflows using non-sensitive cases before returning all users to normal operation. Record which checks were performed and which questions remain open.

For software delivery systems, credential and workflow review may form part of recovery. Credentials exposed through automation can affect systems beyond the original account. Review who can read secrets and whether a compromised workflow could have altered artifacts or deployment behavior. A change in one repository may therefore require coordination with the owner of the destination service rather than an isolated local repair.

GitHub's secure-use reference discusses workflow credentials and least privilege. It is relevant when Actions is among the affected systems, not a general mailbox recovery procedure.

Runbook readiness checklist

• Verify incident-lead and alternate contact details.
• Keep essential instructions accessible outside the primary service.
• Define account, device, spending, and communication authority.
• Specify protected evidence storage and time-zone recording.
• List known provider escalation routes.
• Document a business continuity path.
• Validate recovery before broad access resumes.
• Review lessons without treating uncertainty as employee blame.

Exercise the plan with a tabletop scenario before relying on it. Walk through who receives the first report, where the timeline lives, and what happens if the main communication system is unavailable. Record gaps as concrete follow-up work with owners. A completed tabletop is preparation evidence, not proof that the business can prevent or fully resolve every incident.