Human error data breaches are the most reported and the least investigated class of incident in UK organisations. Most published advice on the subject ends in the same place: quote a vendor statistic, recommend more awareness training, move on. The training matters. It is also incomplete, because a large share of staff mistakes leaves a trace outside your perimeter, in places your internal controls never look, and that is usually where an attacker finds it first.
This piece takes the regulator's own categories as the starting point, then works outwards: which mistakes are visible from the internet, how quickly they surface, and what a security team can actually do about them before the 72 hour clock starts running.
What the ICO's breach reporting actually records
The Information Commissioner's Office publishes quarterly data security incident trends, broken down by cause and by sector. Across the quarters it has released, the dataset now runs into the tens of thousands of reported incidents, which makes it the largest open evidence base on how UK organisations actually lose personal data.
The classification is the useful part. Incidents are split into non-cyber and cyber causes. Non-cyber includes data emailed to the wrong recipient, failure to use BCC, failure to redact, loss or theft of paperwork or data left in an insecure location, data posted or faxed to the wrong recipient, and verbal disclosure. Cyber includes phishing, ransomware, brute force and unauthorised access. Check the latest quarter before you quote anything from it, as the breakdown shifts.
Where the 95% figure comes from, and why it is not the regulator's
Almost every page ranking for this topic opens with a claim that 95% of breaches are caused by human error. That number is usually traced back to IBM's Cyber Security Intelligence Index, published in 2014. It is vendor research, not regulatory data, and it is more than a decade old.
The ICO's category breakdown is more useful for a budget conversation anyway. A percentage tells you human error exists. A category list tells you that misdirected email and redaction failures sit near the top of reported non-cyber incidents year after year, which is an argument for mail controls, a redaction step and external discovery, not for another annual e-learning module.
The 72 hour clock and the detail that hurts
Under UK GDPR, you have 72 hours from becoming aware of a personal data breach to notify the ICO where there is a risk to individuals' rights and freedoms, and you must tell affected individuals where that risk is high. The ICO sets out the thresholds in its personal data breach reporting guidance.
The word that carries the weight is "aware". If your notification says you learned of the exposure from a customer, a journalist or a researcher, you have told the regulator that your detection failed and your awareness programme did not compensate. Self-reported data also undercounts by design: an incident only enters the statistics once somebody inside the organisation notices it. Nobody reports the subdomain they forgot they owned.
Five staff mistakes that leave an external trace
Human error gets treated as an internal problem, so nobody goes looking for it externally. In practice, these are the five patterns that surface on the open internet, in criminal marketplaces or in DNS records, often weeks before an internal alarm fires.
1. Credentials typed into unmanaged devices
A member of staff checks the CRM from a home laptop, or signs into a SaaS tool in a personal browser profile. The machine picks up an infostealer. The password, the saved autofill data and the session cookies go into a log that gets bundled, resold and eventually pasted into a Telegram channel with your domain sitting in the username column.
2. Documents and backups published to misconfigured storage
Open buckets, public file shares and repositories with live keys committed in a config file. The mistake takes one click. The exposure is indexed, crawlable and often reachable without authentication, which means it is equally findable by a researcher, a regulator's complainant and an attacker running automated discovery.
3. Shadow IT and assets that outlive the project
A marketing agency registers a campaign subdomain and points it at its own hosting. The campaign ends. The contract ends. The DNS record stays. Months later the hosting account lapses and the subdomain becomes claimable by anyone who notices, now serving content under your brand. This is the mechanism behind a great deal of attack surface drift between inventory reviews.
4. Oversharing by staff and executives
Named finance staff on LinkedIn, an org chart in a conference deck, badge photos, supplier logos on a case study page, and an out-of-office reply that confirms the CFO is away until the 22nd. Assembled, that is a complete pretext. It is the raw material for fraudulent data requests and impersonated approvals, and it is not a soft risk: it is a measurable input to a specific attack.
5. Domains nobody renewed
Expired registrations, near-miss typo domains somebody else picked up, and the old trading name that still appears in email footers. Each one can be used to send mail that passes a casual look and collects data from your customers.
Misdirected data and failure to redact: the quiet majority
Autocomplete is still the single most productive attack on your data, and it is not even an attack. Three characters typed, the wrong Sarah selected, a spreadsheet of client records sent outside the organisation. Reply-all does the same job at scale.
Redaction failures are worse because they look resolved. Black rectangles drawn over text in a PDF leave the underlying characters intact and recoverable with copy and paste. Spreadsheets get sent with hidden columns, filtered rows and the original data still present. Published documents carry metadata, author names and revision history. A subject access response is the highest-risk document most organisations produce, and it is frequently assembled under time pressure by someone who is not a security specialist.
Controls that measurably reduce this category:
- Delayed send on outbound mail, even 60 seconds, with a visible recall window.
- External recipient warnings and banner colour changes on anything leaving the tenant.
- Mail merge locked to approved templates and a tested recipient list, with BCC enforced for bulk sends.
- A flatten-and-verify redaction step: text removed, not covered, then checked by a second person before release.
Keep the controls boring and automatic. Anything that depends on a tired person remembering a rule at 17:40 on a Friday will fail at some point.
How to spot human error data breaches from the outside
Most organisations do not have a complete view of their external attack surface, which is why mistakes sit unnoticed. The fix is detection that runs continuously and treats change as the signal.
Continuous external discovery
Map every public-facing asset from the attacker perspective: domains, subdomains, IP ranges, cloud services, APIs, exposed admin panels and third-party hosted pages. The value is not the first inventory, it is the second and the hundredth. A new subdomain appearing without a corresponding ticket is a shadow IT finding on the day it happens, not an audit note next March.
Dark web and Telegram monitoring
Credential dumps, stealer log entries and channel chatter routinely name corporate domains long before anything internal flags an anomaly. Monitoring criminal channels and marketplaces for your domains, brand terms and executive names gives you a chance to act while the credentials are still worth resetting. The common failure here is treating Telegram monitoring as a keyword alert rather than as research with human analysis behind it.
DNS surveillance and lookalike domains
Registration patterns around your brand are an early indicator of a pretexting campaign. Watch for new registrations, certificate issuance and MX records being configured on domains that resemble yours, collect the evidence properly, and pursue takedown. The signals worth prioritising are set out in our domain spoofing detection playbook.
Per-person risk, not just per-asset risk
Exposure is distributed unevenly across a workforce. A named CFO with a public speaking schedule carries a different risk profile from a developer with a public repository, and both differ from a service account. VIP and executive exposure monitoring exists because targeted pretexting follows seniority and signing authority. Classify identities as internal or external, score them, and watch the top of that list closely, as covered in our guide to executive protection cyber monitoring.
Cutting the noise
Duplicate findings destroy credibility faster than missed ones. Run infrastructure and web application scanning across the same estate and you will get overlapping results under different names, and the third time engineering receives the same issue rebadged, remediation stops. Deduplication, correlation and automatic resolution of fixed items are what keep the backlog honest enough for anyone to act on it.
Build a response that assumes mistakes will happen
Write the 72 hour process down before you need it, with names against each step: who confirms the exposure is genuinely yours, who pulls and preserves the evidence, who makes the risk assessment, who drafts the ICO notification, who signs it off out of hours.
For a leaked credential, work in this order:
- Confirm the account exists and belongs to you, rather than a mangled or recycled entry.
- Check reuse across SSO, VPN, email and any legacy system without MFA.
- Force a reset, then revoke active sessions and refresh tokens. A password reset alone leaves a stolen session cookie working.
- Establish whether the infected machine was personal or corporate, because that determines whether you have one exposed password or an entire browser profile in criminal hands.
- Look at everything else the same log contained from that device, which is the step most teams skip. Our stealer log triage guide covers the full sequence.
Mistakes also propagate through suppliers. A misdirected file or a compromised account at a third party becomes your incident the moment it contains your data, so continuous supplier threat intelligence, threat scoring and accreditation tracking such as ISO 27001 belongs in the same programme as your internal awareness work, not in a procurement folder nobody opens.
Finally, route findings into the tools your teams already use. Slack, Microsoft Teams, Jira, your SIEM or your ticketing system. Findings emailed around as attachments do not get closed.
Reporting exposure to people who do not read vulnerability scans
Boards and DPOs need a short, repeatable picture. A weekly "what has changed"update works well: new assets discovered, new exposures confirmed, new credential hits, and what closed since last week. Four lines, same format every time.
Give executives their own view, delivered on screen, as a PDF or scheduled by email, covering their personal exposure separately from the corporate estate. Senior people engage with their own risk far more readily than with an asset table.
Three metrics survive a board meeting: time from exposure to detection, time from detection to takedown or remediation, and which asset types keep reoffending. That last one usually points straight at a process gap, typically agency-managed domains or unticketed cloud deployments.
Those same metrics are what you show the ICO and your insurers. Training attendance records prove you ran a course. Detection and remediation timelines prove you found the mistake and fixed it, which is a materially stronger position when a human error data breach is being assessed.
If you want to see what your own external footprint looks like from the attacker's side, including the assets nobody remembers creating, DarkInvader's external attack surface management platform is the place to start.
Frequently Asked Questions
What counts as a human error data breach under UK GDPR?
Any security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data, where the cause was a mistake rather than a deliberate attack. Typical examples recorded by the ICO include data emailed to the wrong recipient, failure to use BCC, failure to redact, and loss or theft of paperwork or devices.
Is it true that 95% of data breaches are caused by human error?
That figure comes from vendor research, usually traced to IBM's Cyber Security Intelligence Index published in 2014, and it is not an ICO statistic. The regulator publishes incident counts by cause instead, and non-cyber causes such as misdirected email and redaction failures consistently account for a large share of reports. Use the category breakdown rather than the headline percentage.
Do human error data breaches have to be reported to the ICO?
Yes, where the breach poses a risk to individuals' rights and freedoms, and you must notify within 72 hours of becoming aware of it. If the risk is high, you must also tell the affected individuals without undue delay. Breaches that do not meet the risk threshold still need to be recorded internally.
Which staff mistakes are visible from outside the organisation?
Credentials captured by infostealers and traded in dumps, documents or backups left in misconfigured public storage, repositories containing live keys, shadow IT such as forgotten campaign subdomains, lapsed domain registrations, and public oversharing of roles, suppliers and absences. Continuous external discovery and dark web monitoring are how you find these without waiting for someone to report them.
How quickly can leaked employee credentials show up on the dark web?
Timelines vary considerably. Infostealer output can be packaged and circulated in criminal channels within days of infection, while credentials from a larger breach may surface months later when a dataset is resold or dumped publicly. Because you cannot predict the delay, continuous monitoring of marketplaces and Telegram channels is more reliable than periodic checks.
