What counts as an incident
An incident is any event that threatens the security or normal operation of your systems or data. Examples include a phishing email that someone clicked, a laptop left on a train, an account sending messages its owner did not write, ransomware, a customer database exposed by a setting error, or a payment sent to a fraudulent bank account.
The reason to plan ahead is simple. During an incident people are stressed, information is incomplete and the wrong first move can make things worse. A short plan agreed in calm conditions helps people act sensibly.
A plan for a small team does not need to be long. One or two pages that people can find quickly are more useful than a thick document nobody reads.
The stages
Most incident response approaches follow similar stages. For a small team, these are enough.
1. Prepare
Preparation happens before anything goes wrong, and it is where most of the value lies.
- Keep a current list of devices, accounts and the systems that matter most.
- Make sure backups exist and have been tested.
- Turn on two-factor authentication on critical accounts.
- Write down contact details: your technical support person, your email or hosting provider, your bank, your insurer if you have one, and anyone who must be told.
- Decide who is in charge.
A good backup strategy and a basic disaster recovery outline are the foundation, since they determine how quickly you can get back to work.
2. Detect and report
Problems can only be handled if someone notices them and speaks up. Make it normal and safe to report. Staff should know:
- What to report: strange emails, unexpected password reset messages, lost devices, unusual pop-ups, files that will not open.
- Who to tell, with a phone number or channel that works when email may be affected.
- That reporting quickly is always better than waiting, and that nobody will be punished for an honest mistake.
Fear of blame is one of the main reasons incidents are reported late. Regular security awareness training helps people recognize problems and reinforces that reporting is expected.
3. Assess
Once something is reported, the person in charge makes a quick assessment:
- What happened, and what is affected: one device, one account, or more?
- Is it still happening?
- Could customer, financial or personal data be involved?
- How serious does it appear?
Write down what you know and the time you learned it. If you are unsure, assume it is more serious until you learn otherwise.
4. Contain
Containing the problem means stopping it from spreading or getting worse. Typical steps include:
- Disconnecting an affected device from the network (but not necessarily turning it off, since that can erase useful evidence, and advice may differ by situation).
- Changing passwords and signing out sessions on affected accounts, from a device you trust.
- Blocking a compromised account.
- Pausing payments if a fraud attempt is suspected, and contacting the bank.
Keep a list of containment actions for common situations, such as a compromised email account, a lost laptop, or suspected malware.
5. Fix and recover
Once the situation is contained, work on removing the cause and restoring normal service. That might mean cleaning or rebuilding a device, restoring files from backup, repairing a configuration, or installing missing software updates. Check that the original problem is genuinely gone before declaring it over, and watch for signs of repeat activity.
If a device has been seriously infected, rebuilding it from a clean state is often safer than trying to clean it by hand.
6. Communicate
Decide who needs to know and who will speak for the organization. This may include staff, customers, suppliers, your bank, your insurer, and in some cases regulators. If personal information may have been exposed, rules about notification can apply depending on where you operate, and it is sensible to get qualified advice instead of guessing. Data privacy laws vary by region, and deadlines can be short.
Keep messages factual and calm. Avoid guessing about cause or blame until you know more.
7. Review and improve
Within a few days, once the pressure is off, meet briefly and ask:
- What happened, in order?
- What worked well?
- What slowed us down?
- What one or two changes would prevent a repeat or speed up the response?
Update the plan and the checklists. Keep the review practical, not accusatory.
Roles to assign
Even in a team of three, it helps to name roles:
- Incident lead: makes decisions and keeps a timeline.
- Technical contact: carries out containment and recovery, either internally or from an outside provider.
- Communications contact: handles messages to staff, customers and others.
- Backup person for each role, since people are sometimes away.
In a very small business, one person may fill several roles. That is fine as long as it is written down, along with who steps in when they are unavailable.
Keep a simple log
During an incident, record times, actions and who did what. A shared document works, or a notebook if systems are down. A log supports the review afterward, helps outside advisers understand what happened, and can matter if insurers or regulators ask questions.
Make the plan usable
- Store a copy where you can reach it if your systems are down, such as printed or on a phone.
- Keep it short, with checklists and phone numbers rather than long prose.
- Review it at least once a year, and whenever people, suppliers or systems change.
- Practice with a short scenario: “What would we do if the owner’s email were taken over this morning?” Walking through it for thirty minutes often reveals missing contact details or unclear responsibilities.
A plan will not prevent every problem, and no plan covers every case. Its purpose is to make the first hour calmer and more organized, which usually limits the damage.