Is it a breach, a complaint, or a quality issue? Why getting that wrong matters
Here’s a scenario that plays out in organisations more often than most people realise. A customer gets in touch, something has gone wrong, and the person who picks up the call does what feels natural — they apologise, fix it, and log it as a complaint. But what if it was actually a data breach? Knowing the difference between a data breach and a complaint, and making sure the right people find out about it, matters more than most organisations realise.
Job done. Except it isn’t, because what they’ve just handled as a customer service issue was actually a data breach.
This isn’t a hypothetical. It’s one of the most consistent gaps we see when working with organisations on their information security and data protection arrangements. Staff aren’t deliberately ignoring the rules. They simply don’t recognise what they’re looking at — and so the incident gets routed to the wrong place, handled by the wrong process, and never reaches the people who needed to know about it.
The problem with labelling things on instinct
When something goes wrong, people tend to describe it in terms of whatever feels most obvious. A customer is unhappy — so it’s a complaint. A process didn’t work as it should — so it’s a quality issue. A piece of paper ended up in the wrong bin — so it’s a housekeeping matter.
The trouble is that real incidents don’t arrive neatly labelled. A complaint from a customer about receiving the wrong documents might simultaneously be a data breach under UK GDPR. Finance documents thrown in the general waste might be both an environmental issue under ISO 14001 and a data security failure under ISO 27001. Something that looks like a process problem on the surface might carry serious information security implications underneath.
We’ve seen this play out with quiz data from staff awareness sessions too. When asked which standard applies when a colleague prints unnecessary finance documents and throws them in general waste, almost half chose only one standard — when the correct answer was two. Not because they don’t understand the standards individually, but because they’re not used to thinking about how a single incident can touch more than one framework at the same time.
What happens when a data breach gets logged as a complaint?
If an incident gets mislabelled, it gets mishandled. A data breach that’s treated as a complaint might never reach your data protection officer at all. That matters because most incidents, when properly assessed, won’t meet the threshold for reporting to the ICO — but that assessment still needs to happen, and it needs to happen quickly. The 72-hour notification window starts from the point you become aware of a potential breach, not from the point someone decides it’s serious enough to escalate. If it’s sitting in a complaint queue, the clock is still running.
And if it does eventually come to light — through a follow-up complaint, an audit, a subject access request — the fact that it wasn’t handled correctly the first time becomes a problem in its own right.
The same applies to subject access requests. An SAR can arrive looking like almost anything. A politely worded email asking “what information do you hold on me?” is obvious enough. But what about the customer who says they’re thinking about making a complaint and “just want to understand what you’ve got on file”? Or the former employee who asks HR for copies of their appraisal records? These are SARs too, and they carry legal obligations — a one-month response window being the most pressing — that don’t apply to an ordinary customer query.
If the person who receives the request doesn’t recognise it for what it is, the clock still starts ticking.
Why staff absorb rather than escalate
There’s another layer to this that’s worth being honest about. Even when staff have a feeling that something might be more serious than it looks, there’s often a pull towards resolving it themselves rather than escalating. Partly it’s a desire to be helpful. Partly it’s uncertainty about whether something “counts” as a breach or an SAR. And partly, frankly, it’s concern about what happens if they flag something that turns out to be nothing.
The result is a kind of informal triage that was never designed to exist — where the most important routing decisions in your compliance framework are being made by the people least equipped to make them, with no process to fall back on.
So what actually helps?
The fix isn’t more policy documents. Most organisations already have a privacy notice, an information security policy, and a data breach procedure. The issue is that these are written for the people who manage compliance, not for the people who are first to encounter a problem.
What actually helps is making the recognition step simple. Staff don’t need to know the full text of UK GDPR. They need to know three things: what kinds of situations might be a breach or an SAR, what to do when they’re not sure, and who to go to. That’s it. The rest is someone else’s job — as long as the escalation happens.
That’s the gap that good staff awareness training is designed to close. Not turning everyone into a data protection specialist, but making sure that the right situations reach the right people before the clock runs out or the audit window closes.
If you’re not confident that your team would recognise a data breach or an SAR when it landed in their inbox, our Introduction to Data Protection course is a good starting point. It’s practical, jargon-free, and designed for the people who handle these situations without having ‘data protection’ in their job title. And for those who have been tasked with implementing data protection policies and procedures, or who just want to understand more about the UK GDPR regime, our Data Protection for SME Owners and Directors course is a good starting point
