A staff member approves an unexpected sign-in request. A customer receives a payment message that nobody remembers sending. A laptop starts showing an unfamiliar warning. You do not yet know whether there is a serious incident, but somebody needs to take charge.
A small business incident response plan makes the first conversation easier: who to contact, what to record, and who can authorize the next action. It should help an owner coordinate qualified support without requiring every employee to investigate a technical problem.
If something is happening now
Stop interacting with the suspicious message or request. Contact your trusted IT support using a number you already know, preferably from a device you believe is unaffected. Tell the business owner or designated incident lead promptly. Do not wait to finish writing a plan.
If money may have been sent to a fraudster, contact your bank’s fraud team immediately using a verified contact method. Get qualified help to secure affected systems and preserve evidence. Avoid wiping, resetting, or experimenting with devices while responders are assessing the situation.
The FTC’s breach response guidance explains the importance of coordinated technical, legal, and communication support. Notification requirements depend on the facts and applicable obligations; seek advice promptly rather than assuming a generic deadline applies.
1. Choose the person who coordinates the response
Your incident lead does not have to fix the technology. They need to gather facts, reach the right people, and keep decisions moving. In a small company, the owner or office manager may fill this role.
Write down a backup person too. Decide who can authorize outside assistance, approve an interruption to normal work, and speak on behalf of the business. Clarify what staff should do if neither person answers.
Keep the plan short enough that someone can find those decisions quickly. Put the contact route ahead of background policy wording.
2. Make the contact list usable without company email
Record your IT provider’s urgent support number, the owner and backup lead, insurer contact details, and any relevant legal or specialist support contacts. Add key service providers and banking contacts where appropriate.
Ask your IT provider how urgent requests are handled outside normal hours. Do not assume an ordinary support mailbox is monitored overnight. If your insurance policy sets a specific incident reporting route, confirm it with your insurer before an incident.
Keep a controlled copy of the essential contacts available outside the systems you might lose access to. Protect personal phone numbers and review the list when responsibilities change.
3. Give staff a clear reporting instruction
An employee should know how to report a concern without deciding whether it qualifies as a breach. A report such as an unexpected account recovery message is useful even if it later turns out to be harmless.
Your instruction could be: stop engaging with the request, call the designated contact, and describe what you saw. If you entered a password or approved a prompt, say so immediately. Encourage early reporting without blaming people for asking for help.
Do not ask staff to forward sensitive files through personal email or open a suspicious attachment again to collect more detail. Your provider can advise how evidence should be captured safely.
4. Record observations separately from conclusions
Use a simple incident record with the time discovered, person reporting, affected account or device, observed behavior, business impact, and actions already taken. Include the time zone when people work in different locations.
Write unknown where a detail is not yet established. A customer reporting a strange email does not prove how the message was sent. Distinguishing an observation from a theory helps the next responder ask useful questions.
Keep a decision log: who approved an action, who performed it, and when it happened. Store the record securely because it may contain sensitive information.
5. Agree how technical decisions will be handled
The plan should identify who directs containment, investigation, and recovery. Your provider or incident specialist may need to restrict access, isolate a device, review activity, or arrange recovery. Ask who will confirm those actions have worked.
Avoid promising staff a universal fix such as changing one password and returning to work. Different problems need different responses. A compromised mailbox can involve active sessions, recovery settings, or unauthorized rules as well as a stolen password.
Use a separate trusted channel for coordination if ordinary business email may be affected. Share sensitive findings only with the people who need them.
6. Plan for business decisions as well as technical work
Who will tell staff what work can continue? Who handles customer questions? Which tasks can temporarily move to a manual process? Which changes need the owner’s approval?
An example business might pause payment changes while it verifies supplier requests. Another might need a temporary way to schedule appointments. Record practical workarounds and have your provider confirm that the alternatives do not introduce new exposure.
Use your recovery priorities to guide the conversation. Our backup-check guide explains questions to ask before relying on a restore.
7. Practice a short scenario
At a team meeting, discuss this example: a colleague approved an unexpected sign-in prompt and can no longer access email. Who do they call? Where are the contacts? What work would stop? Who records the facts?
Walk through the conversation without simulating an attack or changing live systems. Record any missing numbers, unclear responsibilities, or assumptions. Assign one person to resolve each gap.
What a useful first plan looks like
You have an owner and backup, reachable contacts, a simple reporting instruction, a secure incident record, and a clear route to technical and business decisions. You have also practiced finding those details.
Revisit the plan after a real incident, a practice session, or a change of provider. Pair it with your IT policies so everyday staff guidance points to the same reporting route. This is a practical preparation guide, not an investigation service or a substitute for incident-specific advice.