Who is the primary responder?
This is the person who coordinates the first technical response. It can be an internal staff member or a trusted provider.
Example: Operations manager, with IT provider as backup.
Follow guided prompts for roles, first-hour actions, and common scenarios, then download a filled PDF your team can keep as response reference material.
This is not a formal enterprise plan. It helps a small team decide who responds, what happens first, and when to call for help.
Name people before an incident. During stress, unclear ownership wastes time.
This is the person who coordinates the first technical response. It can be an internal staff member or a trusted provider.
Example: Operations manager, with IT provider as backup.
This person can approve disabling accounts, taking systems offline, notifying stakeholders, or calling outside support.
Example: Executive director; deputy director if unavailable.
This person drafts staff, funder, customer, affected-person, or public messages. They should coordinate with leadership and legal if needed.
Example: Director of communications, with executive director approval.
Include IT, security, legal, insurance, hosting, and platform support. Add after-hours paths where available.
Example: IT provider helpdesk, cyber insurance hotline, outside counsel, Google Workspace admin support.
These are the first actions that keep a small incident from becoming chaos.
Record who noticed it, what account/system/device is affected, when it started, and what business impact exists.
Example: Responder opens an incident log and records reporter, time, affected account, screenshots, and current impact.
Do not wipe or delete first. Save screenshots, alerts, messages, logs, file names, timestamps, and affected usernames.
Example: Take screenshots of suspicious emails, save alert IDs, record file names, and note exact times.
Containment may include revoking sessions, resetting passwords, isolating a device, disabling an exposed link, or pausing an integration.
Example: Responder may revoke sessions and reset passwords; decision maker approves taking a system offline.
Use a place available even if email or internal systems are down. Log time, action, owner, and result.
Example: Shared emergency document and offline copy in the operations folder.
Pick likely scenarios and write the first action, what to check next, and when to communicate.
Think about password resets, session revocation, MFA, forwarding rules, connected apps, and file/email activity.
Example: Revoke sessions, reset password, verify MFA, check forwarding rules and connected apps, review recent file access.
Disconnect the device, preserve evidence, and identify which accounts and files were used on it.
Example: Disconnect from network, do not wipe, record symptoms, reset key accounts from another device, check local files and backups.
Focus on isolation, backup integrity, shared drives, admin accounts, and lateral movement.
Example: Isolate affected systems, preserve evidence, pause sync if needed, verify backups, call external support.
Find out what data was exposed, who could access it, how long it was exposed, and whether notification obligations may apply.
Example: Restrict access, preserve link settings and access logs, identify affected data, escalate notification decision to leadership/legal.
Review identity, data, backup, and incident readiness controls that support this plan.
Turn your response readiness into credible answers for funders, boards, and insurers.
Worksheets, checklists, templates, and buyer guides for small teams improving security.
Secure Origin helps small teams turn this template into a tested incident response plan, tabletop exercise, or Protect The Organization readiness track with owners and follow-up fixes.