An incident response plan is a written playbook that tells your team what to do when a security or availability incident happens, who is responsible, and how you communicate until the situation is under control. It covers cyber attacks such as ransomware and phishing-led account takeovers, as well as serious outages that stop staff or customers from using critical systems.
Writing the plan early saves time under stress. Aim for a clear sequence a small team can follow, not a perfect document.
What counts as an incident
For most small and mid-sized businesses, useful triggers include:
- Confirmed or suspected account compromise: staff email, cloud admin or finance systems used without authorisation.
- Malware or ransomware: encrypted files, ransom notes, or widespread suspicious activity on endpoints or servers.
- Data exposure: customer or staff personal data sent to the wrong place, left in a public folder, or copied by an attacker.
- Major service outage: website, payment, email or internal systems down long enough to harm operations.
- Payment or supplier fraud: urgent requests to change bank details that may be business email compromise or a deepfake scam.
Your plan should say who decides an event is an "incident" and when routine troubleshooting becomes a formal response.
Typical phases of response
Names vary, but most plans follow a similar sequence:
- Prepare: contacts, access rights, logging, backups, and short playbooks for the scenarios you care about most.
- Detect and report: how staff raise a concern, which alerts matter, and how quickly the response lead is notified.
- Contain: limit damage — isolate a device, reset credentials, revoke sessions, or take a compromised service offline in a controlled way.
- Eradicate and recover: remove the cause where you can, restore from known-good backups, and bring services back in a tested order.
- Learn: a short note on what happened, what worked, and what to change.
For a small team, stopping the spread and protecting payments usually matter more than deep forensics.
Who should be on the response team
Even a small company needs named roles, with deputies when someone is away:
- Incident lead: decides severity, coordinates steps, and owns the timeline.
- Technical lead: systems, cloud, email and logging; works with your IT provider if you outsource.
- Communications: internal updates to staff and, when needed, customers or partners — using approved wording.
- Business / finance: payment freezes, bank contact, and operational workarounds.
- Legal / compliance contact: personal data questions and any notification steps your advisers recommend. Point people to counsel rather than inventing legal duties.
Keep an up-to-date contact list: mobile numbers, your MSP or hosting provider, bank fraud desk, and for Hong Kong cyber incidents the HKCERT incident reporting channel (advisory hotline +852 8105 6060). Keep an offline copy too.
What to put in the written plan
Keep it short enough that people will open it. Include:
- severity levels (for example low / medium / high) and who must be called at each level;
- a first-hour checklist: contain where practical, reset high-value accounts, and open a single incident channel;
- account and access rules: how to revoke access quickly, including role-based access control reviews after compromise;
- authentication: require multi-factor authentication on email, VPN, cloud admin and finance tools before an incident;
- backup and restore notes: where backups live, who can restore, and a last successful restore test date;
- external contacts and decision rules for taking systems offline.
How to keep the plan useful
Review the plan when staff change, when you move email or cloud providers, and after any real incident. Once or twice a year, run a short tabletop exercise: pick a scenario such as ransomware or a payment diversion request, walk through the checklist, and fix gaps. Update contacts when someone leaves.
Preparation also means current software, least-privilege admins, useful logging, and backups someone has restored. The plan organises people when controls fail; it does not replace them.
Frequently asked questions
Is an incident response plan only for large companies?
No. A small team often needs a clearer plan because fewer people hold critical knowledge. A short document with contacts, severity rules and a first-hour checklist is enough to start.
How is this different from a disaster recovery plan?
Disaster recovery focuses on restoring systems and data after a major outage. Incident response covers the human and security steps during an attack or suspected breach — containment, credentials, communication and evidence — as well as recovery. Many SMEs keep both topics together but still separate the checklists.
Should we hire a retainer for incident response?
It depends on your risk and in-house skills. Many businesses use their IT provider for first response and call specialists for ransomware or complex forensics. Decide in advance who you will call at 2 a.m., and put those numbers in the plan.
Do we need to report every incident to a regulator?
That depends on the data involved, your sector and advice from your legal or compliance advisers. Your plan should say who asks that question and how quickly. In Hong Kong, the PDPO does not currently make data breach notification mandatory, but the PCPD encourages data users to notify it voluntarily using its data breach notification form. Banks, SFC-licensed firms and other regulated businesses may have separate reporting duties, so check these with your advisers.
If you want help reviewing access, MFA, logging or an incident-ready checklist for your stack, see our cybersecurity and compliance services.