Writing an Incident Response Plan for a Tiny Team
A tiny-team incident plan must name people and phone numbers, not only verbs such as contain and recover.
For a team under 20 people, an incident plan is useful only if someone can act from it while the normal systems are failing. Keep the core plan to one page: an out-of-band contact list, the person allowed to declare an incident, the person allowed to disable accounts or isolate devices, the external IT and insurance contacts, and the first place evidence should be stored. Put alternate phone numbers on paper or in another trusted system because a compromised email tenant should not also contain the only copy of the response plan.
A one-page plan beats a forty-page binder nobody opens
A tiny-team incident plan must name people and phone numbers, not only verbs such as contain and recover. Write who can disable an account, who can isolate a laptop, who decides whether customer operations stop, and who has authority to call the insurer, outside IT provider, counsel, or law enforcement. Add an alternate for every critical role because the primary person may be unavailable or may have the compromised account.
Name the first caller, the decision owner, and the systems to isolate
Put names, direct phone numbers, alternate contacts, and decision authority on the first page. The person who can isolate a laptop may not be the person who can disable the identity provider, notify the cyber insurer, or approve customer communication. Define those boundaries in advance and include an out-of-band contact route in case company email or chat is unavailable. A responder should not have to search an old procurement thread to discover which managed-service provider has emergency access.
Sequence matters during response. Contain the affected account or device without destroying logs, preserve relevant timestamps and messages, and avoid wiping a machine before someone decides whether evidence is needed. Notification comes after the team understands enough facts to determine who may need notice; it is not a reflexive first tweet. Test the plan with a short tabletop: one stolen admin account, one unreachable employee, and one customer asking whether data was exposed.
Preserve evidence before rebuilding
Keep an offline or printed copy of the plan because the same incident can take email, chat, password vault access, or cloud storage offline. The copy should include vendor support numbers, cyber-insurance notice instructions, domain registrar details, key cloud providers, and a clean way to contact staff. Review the numbers quarterly; a perfect response plan with an expired MSP contract number is not a plan you can execute.
Put insurer, counsel, IT, and law-enforcement contacts on the page
Run a 30-minute tabletop exercise using a plausible event such as a compromised Microsoft 365 administrator or a stolen payroll laptop. Ask exactly who notices, who isolates, what evidence is preserved, which customers or regulators might need notice, and what system is restored first. Record the three places where the team hesitated and revise the one-page plan immediately while the gaps are obvious.
A tabletop exercise for a five-person team
- □ Give the team one plausible trigger: a stolen payroll laptop, compromised Microsoft 365 administrator, or ransomware note on a shared drive.
- □ Ask who has authority to isolate accounts/devices and what evidence must be preserved before wiping, rebuilding, or rotating keys.
- □ Force one communications failure: assume normal email is unavailable and prove the offline contact card still reaches staff, IT, insurer, and counsel.
- □ End the exercise by writing the three moments where nobody knew who owned the decision, then revise the one-page plan immediately.
The plan is usable when a person who did not write it can pick it up and identify the incident lead, containment authority, outside contacts, evidence-preservation rule, first recovery priority, and notification decision owner. Keep an offline copy and test the phone numbers. Re-run the tabletop after major staff, cloud, insurer, or MSP changes; those changes can invalidate the plan even when the document itself has not expired.
Write the phone tree before the outage
A tiny-team incident plan fails when it says “notify IT” but IT is one contractor whose number is trapped in the compromised mailbox. Put names, roles, after-hours phone numbers, insurance contacts, hosting or cloud support, legal/privacy counsel if retained, and the person authorized to speak publicly on a one-page contact card that can be reached offline. Add the location of password-vault emergency access and the process for suspending a user or vendor account. The purpose is not bureaucracy; it is to prevent the first thirty minutes of an incident from becoming a search for credentials and authority.
Separate containment from destruction. If a laptop appears infected, isolating it from the network may be sensible, while wiping or reimaging it immediately can destroy evidence needed to understand scope. If a cloud account is compromised, preserve relevant audit logs before retention windows expire, but do not leave an attacker’s session active merely to collect more evidence. The correct balance depends on the incident, insurance terms, law-enforcement needs, and technical capability. FTC breach guidance advises moving quickly to secure operations and involving appropriate experts; a five-person company may need an outside provider rather than an internal forensics team.
| Moment | Decision owner | Question to answer |
|---|---|---|
| Detection | Person receiving the report | Is this a real security event, a service outage, or an unconfirmed alert? |
| Containment | Technical lead or provider | Which accounts, devices, keys, or vendor connections can be isolated without destroying needed evidence? |
| Scope | Incident lead | What systems and data were actually accessed, altered, exfiltrated, or unavailable? |
| Notification | Legal/privacy owner | Which contracts, insurers, regulators, states, customers, or partners have notice requirements? |
| Recovery | Business owner | What must be clean, restored, reset, and monitored before normal operations resume? |
Run a tabletop with one realistic scenario: the owner’s Microsoft 365 or Google Workspace account is phished on Friday afternoon and a malicious forwarding rule is discovered Monday. Walk through who disables sessions, resets credentials, checks other administrators, preserves logs, reviews mailbox rules, contacts the email provider, and decides whether customer information was exposed. Record every place the team had to improvise. Those gaps become the next plan revision. A useful incident plan is therefore a tested set of decisions and contact paths, not a document that looks complete in a binder.
Questions specific to Writing an Incident Response Plan for a Tiny Team
How long should a tiny-company incident response plan be?
It can be one or two pages if it is executable. The useful content is names, alternates, phone numbers, decision authority, systems to isolate, evidence to preserve, insurer or outside-IT contacts, and the first recovery priorities. A short plan that staff can find during an outage is better than a long document copied from an enterprise template and never rehearsed.
Should we shut down everything when we suspect an incident?
Not automatically. Containment should be proportional to what is known and should preserve evidence where possible. A compromised user account may call for disabling sessions and credentials; a ransomware event may require isolating affected systems. Your plan should identify who can make that decision and when to involve qualified IT or forensic help.
Why keep an offline copy of the response plan?
The incident may make email, chat, cloud storage, or the password manager unavailable. An offline copy preserves critical phone numbers, insurer instructions, cloud-provider contacts, and the authority chain. Review it periodically so it does not contain former employees, expired contracts, or a recovery number that itself depends on the unavailable system.
What is a useful tabletop exercise for five people?
Use one realistic scenario, such as a compromised email administrator, and walk through the first hour. Ask who notices, who isolates access, where evidence is saved, who calls outside help, which customers might be affected, and what must be restored first. Record moments of uncertainty; those gaps become the next edits to the plan.