Imagine it’s nine in the evening and your phone won’t stop ringing. Customers are calling in a panic because they’ve received personal messages from criminals threatening to expose their data. Staff members are receiving the same messages. And you, as the owner, have to decide within the hour who communicates what to the outside world, while you don’t even fully know yet what was actually stolen.
This is what happened to supermarket Flink. After a hack, both customers and staff were extorted directly by the attackers. The news focused on the breach, but the more interesting story lies in what followed: the chaos that erupts when a crisis hits and there’s no agreed plan in place.
The breach is rarely the real problem
A data breach is unpleasant, but on its own it’s often manageable. Things get genuinely difficult when the consequences spill outside your own walls: customers receiving messages you never anticipated, staff asking questions no one can answer, journalists calling before you have a story ready.
That’s the moment an organisation’s true nature shows. The policy document written years ago suddenly doesn’t matter: things run according to whoever shouts loudest, whoever happens to be reachable, and whoever feels compelled to say something. That’s not crisis management. That’s sheer panic.
Who actually decides?
The core question after an incident is rarely technical. It’s a question of ownership: who decides what gets communicated, to whom, and when? Who contacts affected customers? Who informs staff who have themselves become victims? Who is the point of contact for regulators, insurers, and the press?
If those questions only get asked during the crisis, you’re already too late. That’s when confusion sets in, messages start contradicting each other, and in the worst case, reputational damage grows larger than the breach itself. Customers and staff who already feel vulnerable notice immediately whether a company is in control or not.
Policy before technology
At Motics we regularly see companies invest heavily in technology (firewalls, backups, monitoring) without having an answer to who decides what when things go wrong. That’s the wrong order. Technology protects your systems, but policy protects your organisation.
A solid crisis protocol lays out in advance:
- Who owns communication during an incident, and who steps in if that person is unreachable.
- What steps are taken as soon as there are signs of a breach or extortion attempt, including who alerts whom, and within what timeframe.
- How customers and staff are informed, in what tone and through which channel.
- When and how external parties are involved, such as a lawyer, insurer, or police.
This doesn’t need to be a thick document. Above all, it needs to be something people know, understand, and can act on without having to think it through in the moment itself.
Measure first, then make policy
Before you can draft a protocol, you need to know what it’s actually about. What data on customers and staff do you hold, where is it stored, and who has access to it? Without that overview, you’re making policy based on feeling rather than fact, which is exactly what you don’t want for something that needs to be demonstrable to regulators and, under NIS2, throughout your supply chain as well.
That’s why we always start with measuring: mapping out what exists, where the real risks lie, and who should be responsible for what. Only after that comes policy, and only after that the technology that supports it.
Bring your people along in advance
A crisis protocol only works if the people who need to carry it out know it before it’s ever needed. That means discussing it with your management team, explaining it to staff who could themselves become victims, and testing whether everyone knows what to do. That way it doesn’t feel like a rule handed down from above, and everyone is prepared for it together.
What you can do right now
Start small and concrete. Map out what personal data of customers and staff you actually hold, and where. Decide who within your company owns crisis communication, and put that in writing. Discuss with your team what would happen if a message similar to Flink’s landed tomorrow. And test whether your current approach actually holds up, or whether it only exists on paper.
A few questions we’re often asked
Who should actually draft this kind of crisis protocol for us?
The owner or director is usually the best starting point, since they ultimately carry responsibility for the decisions. The protocol itself can be drafted together with your management team and possibly an external partner, but ownership of the decisions themselves should always rest clearly with one person.
Isn’t this mainly something for large companies with their own communications department?
Smaller companies actually need this more, because there’s often no separate department to absorb the chaos. In an SME, you’re often the one picking up the phone yourself, and it helps enormously if you already know what you’re going to say.
What if we don’t even know exactly what data we hold?
That’s exactly the starting point, not a reason to wait. Without that overview you can’t build a meaningful protocol, so begin with a simple inventory of where customer and staff data is stored before moving on to policy.
How do you make sure this protocol doesn’t just end up in a drawer?
By walking through it with your team at least once a year, ideally using a short, realistic scenario. That kind of exercise takes little time but immediately shows whether people know what to do, and where the gaps still are.
Want to know where your business stands when it comes to ownership and crisis communication? We’re happy to think it through with you, starting with a clear picture of what you already have.
