Data Breach Response Plan for Small Companies: Who Does What

A data breach response plan for a small company hands five jobs (contain, assess, notify, record and fix) to named people. That way nobody is guessing who does what in the first few hours. And the trigger can be anything: a laptop left on a train, a hijacked mailbox sending invoices to your clients, a CRM login that shows up somewhere it really shouldn’t. Below I go through each step in order and say who owns it.

Who does what in a small company’s data breach response plan?

You need three roles. That’s it: an incident lead, a technical person and a communications person. First, a definition. A personal data breach is any security incident where information about identifiable people gets lost, changed, destroyed or seen by someone who shouldn’t see it. Every role also needs a named backup. Why? Because incidents don’t wait for everyone to get back from holiday.

• Incident lead (owner or office manager): decides whether to report, signs off on messages and keeps the timeline. Backup: a partner or senior employee.
• Technical person (in-house IT or an outside provider): locks accounts, secures devices, collects evidence. Backup: a second contact at the provider.
• Communications person: writes the notices to customers, staff and partners and handles the replies. Backup: the incident lead.

Keep a one-page contact sheet, printed or stored offline. Put your IT provider, software vendors, lawyer and national supervisory authority on it. A compromised mailbox is a bad place to go looking for phone numbers (ask anyone who’s tried).

Step 1: Contain the damage in the first hour

Cut off further access first. Investigate later. The technical person moves first, and what they do depends on what went wrong:

• Lost or stolen laptop: lock or wipe it remotely, then change every password that was saved on it.
• Hijacked mailbox: reset the password, sign out all active sessions and delete any forwarding rules the attacker added.
• Leaked CRM login: disable that user and change every shared password they could get to.

While you’re at it, kill the accounts that shouldn’t exist anymore. Former staff and old contractors are a classic gap, so removing access when people leave belongs in every plan. One more thing. Don’t delete evidence. Keep the suspicious emails, the screenshots, the timestamps.

Step 2: Assess what data was exposed and whose

Now figure out which kinds of data and which people were affected, and how likely it is that they’ll actually be harmed. The incident lead and the technical person work through these together:

• Which system was involved, and what records did it hold?
• Roughly how many people are affected?
• Was the data encrypted, and can you restore it from backups?

Here’s the catch: one customer’s details usually live in email, spreadsheets and the CRM at the same time. Tracing one person’s data across all of those tools gives you a much more honest picture of the exposure. On a cloud CRM? Then check what the vendor is responsible for and what’s on you. Reading up on shared responsibility in cloud CRM before you call them saves a lot of back and forth.

Step 3: GDPR breach notification - who must be told and by when

The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. That rule comes from Article 33 of the General Data Protection Regulation on EUR-Lex, and it has one exception: breaches that are unlikely to result in a risk to people’s rights and freedoms. Who makes that call? The incident lead.

Under Article 33(3), the notification covers the nature of the breach, the categories and approximate number of people and records involved, a contact point, the likely consequences and the measures taken or proposed. You don’t have to send it all at once, either. Phases are allowed.

Notifying affected customers is a separate duty, under Article 34. If a breach is likely to result in a high risk to people, you tell them directly, in clear and plain language. No legalese. The communications person drafts it, the incident lead approves it. Not sure whether a case needs reporting? Ask your national supervisory authority or a lawyer. That is better than guessing.

Step 4: Record everything in a breach log

Article 33(5) says you document every breach, its effects and what you did about it. Every one, including the ones you decide not to report. Your breach log should cover:

1. Date the breach was found
2. Who found it
3. What happened
4. Data and people affected
5. Risk decision and the reasoning behind it
6. Who was notified and when
7. Fixes applied

One owner for the log, usually the incident lead. And keep it somewhere the incident can’t touch: a separate drive, a paper folder. Not the mailbox that just got compromised. (Sounds obvious. People still do it.)

Step 5: Fix the cause so it does not happen again

Close the hole that let the breach in, then take a hard look at the plan itself. The usual fixes are pretty boring, in a good way: a unique password for every account, fewer people who can see full customer lists, encryption on every laptop and phone, and clean data restored from backups where records got damaged.

Your software can do some of the heavy lifting. EpicCRM uses user roles for limiting who sees customer data, so a sales rep doesn’t get the whole contact base. It also runs on EU servers with encryption, backups and access control, and there’s a data processing agreement (DPA) on the website.

Wrap up with a short review meeting. What worked? What was slow? Then update the contact sheet.

Incident response checklist to print and keep

Here’s the whole thing on one page, five steps and who owns each:

• Contain: technical person
• Assess: incident lead with the technical person
• Notify: incident lead decides, communications person drafts
• Record: incident lead
• Fix: technical person, reviewed by the incident lead

My advice? Write your data breach response plan before you need it. Run it once a year against a made-up scenario, and put real names next to every role. Start writing it on the day of the breach and you’re burning time you simply don’t have.

FAQ

Read also:

• Forecasting With Thin Data: What a Young Company Can Honestly Predict
• Sales Playbook for Small Teams: What to Write Down First
• Sales Cycle Automation: A 90-Day Plan for Small Teams