Most failures are not sophisticated
Boards tend to picture a determined attacker and an unlucky organisation. What we actually find, again and again, are the same handful of ordinary gaps — an account without a second factor, a supplier nobody assessed, a backup nobody restored. None of them require a talented adversary. All of them are visible before anything happens, if somebody looks.
These are the patterns, written so you can hold them against your own organisation.
The breach arrived through someone else’s system
Nothing failed inside the organisation. A supplier — payroll, a CRM, a managed IT provider — was compromised, and the personal information they held on the organisation’s behalf went with them. The organisation found out when the supplier told them, often days later, and then discovered it still had to do its own assessment, its own regulator report and its own notifications, on its own clock.
What actually failed: Nobody had ever asked that supplier what protections they had, and the contract said nothing about how quickly they must tell us.
Ask this at your next board meeting: Which of our suppliers hold personal information about our customers or staff, and when did we last see evidence — not assurances — of how they protect it?
One password, no second factor, everything behind it
A single set of credentials was reused, phished or guessed. There was no second factor on the account, and the account turned out to reach far more than anyone assumed — a shared mailbox, an admin console, a remote access tool that had been set up years earlier and never reviewed.
What actually failed: Multi-factor authentication existed for most staff but not for service accounts, contractors or the one executive who found it inconvenient.
Ask this at your next board meeting: Is multi-factor authentication on every account that can reach our data, including service accounts and third-party access — and who is exempt?
The backups existed. Nobody had ever restored one.
The organisation had backups and believed it was covered. When it needed them, the restore was slower than anyone expected, or incomplete, or the backups had been reachable from the same network the attacker was on and had been encrypted too.
What actually failed: Backups were monitored for completion, never tested for recovery, and were never truly separated from the systems they were protecting.
Ask this at your next board meeting: When did we last restore a real system from backup, how long did it take, and was the backup reachable from the network that would be compromised?
It took three weeks to decide who should decide
The incident was found quickly. What took time was working out who had authority to call it a breach, who could approve telling the regulator, and who would sign the letter to customers. The delay itself became the thing the organisation had to explain.
What actually failed: No one had been formally made accountable for privacy, so the first hours went on convening people instead of acting.
Ask this at your next board meeting: Who is named as accountable for personal information here, who deputises for them, and would that person recognise the authority if we phoned them tonight?
Client information went into a public AI tool
Someone pasted a contract, a customer list or a patient note into a free chatbot to summarise it. No attacker was involved and no system was breached. The information simply left the organisation’s control, and there was no record of what went or when.
What actually failed: There was no list of approved AI tools, so “use only approved tools” was an instruction nobody could follow.
Ask this at your next board meeting: Which AI tools are approved here, who approved them, and what has been agreed about whether our data trains anyone’s model?
Access that was never taken away
A leaver, a former contractor or an ended supplier still had a working account months later. In some cases it was used. In others it was simply found during an assessment, which is worse in a different way — nobody could say whether it had been used.
What actually failed: Leaving was an HR process and a payroll process, but it was never an access process, and ending a contract never triggered anything technical.
Ask this at your next board meeting: How many active accounts belong to people or companies who no longer work with us, and what would tell us if that number grew?
The regulator asked for the record. There was no record.
The organisation had handled several small incidents sensibly — an email to the wrong person, a lost phone — and had judged each one not worth reporting. Those judgements may well have been right. It could not evidence any of them, because nothing had been written down.
What actually failed: PIPEDA requires a record of every breach of security safeguards kept for two years, and Quebec requires a register of every confidentiality incident kept for five. Neither existed.
Ask this at your next board meeting: Can we produce our breach register this week — and does it include the incidents we decided not to report?
Why no names
We describe the failure, not the organisation it happened to.
There is no Canadian register of breached companies to link you to, and there is a good reason we would not build one. Naming an organisation that has already been through an incident tells you nothing you can act on, and being the firm that publishes such a list is not the same as being the firm you would call. The pattern is the useful part. Every one of these is drawn from what we and others have found repeatedly across Canadian organisations, described so that no single organisation is identifiable.
If one of these reads uncomfortably close to home, that is the point of writing it down.
Seven questions is a start. There are thirty-six.
Each pattern above maps to something in our control set — the full list of what we assess against, published so you can work through it yourself. If you want the short version first, the ten-question self-check takes about four minutes and tells you how many of these you could evidence today.