A major data breach does not always begin with a sophisticated cyberattack. Sometimes an employee has more access than their role requires. Sometimes a known software vulnerability remains unpatched. In other cases, a cloud service is secure, but the organization using it has configured access incorrectly.
The breaches involving Desjardins, LifeLabs and Capital One demonstrate these differences clearly. Each incident exposed personal information on a significant scale, but each developed through a different combination of technical and organizational weaknesses.
For Canadian organizations, these cases are valuable because they move data protection beyond theory. They show where controls failed, what regulators identified afterwards, and what other organizations can do differently.
Why Data Breach Lessons Still Matter in 2026
Cyber threats continue to affect organizations across Canada. The Canadian Centre for Cyber Security describes cybercrime as a persistent and widespread threat and identifies ransomware as the leading cybercrime threat to Canadian critical infrastructure.
Its National Cyber Threat Assessment 2025–2026 reported significant growth in known ransomware incidents affecting Canadian organizations in recent years. The Cyber Centre has also warned that organizations of different sizes and across different sectors can become targets.
However, ransomware represents only part of the risk.
Some of Canada's best-known privacy incidents have involved insiders, outdated software, inadequate monitoring, excessive permissions and cloud configuration problems. That distinction matters because no single security product can prevent every type of breach.
Effective privacy protection requires several controls to work together. Organizations need appropriate technical safeguards, but they also need clear data-retention practices, access governance, vulnerability management, incident-response procedures and accountability for the personal information they hold.
The Desjardins, LifeLabs and Capital One cases illustrate what can happen when one or more of these controls fail.
Desjardins: When Excessive Internal Access Becomes a Data Breach
The Desjardins incident remains one of Canada's clearest examples of how an insider can exploit legitimate system access.
What Happened at Desjardins?
In 2019, Desjardins notified privacy regulators about a breach that ultimately affected close to 9.7 million individuals in Canada and abroad.
The compromised information included names, dates of birth, Social Insurance Numbers, residential addresses, telephone numbers, email addresses and transaction histories.
An investigation by the Office of the Privacy Commissioner of Canada found that a malicious employee had accessed or exfiltrated personal information over a period of at least 26 months.
This was particularly significant because the incident did not depend on an external attacker breaking through the organization's security perimeter. The employee was already inside the organization and had legitimate access to internal systems.
The regulatory investigation identified weaknesses involving accountability, security safeguards and the retention of personal information.
That combination makes Desjardins an important privacy case study. The problem was not simply that one employee behaved maliciously. The organization's surrounding controls allowed inappropriate access to continue for an extended period.
What Failed?
Access to personal information should correspond to a legitimate business need.
If employees can view substantially more information than they need to perform their responsibilities, an organization creates unnecessary exposure. Access controls become particularly important where information includes financial records, identification numbers or other sensitive personal details.
Retention was another important issue.
Organizations should not retain personal information indefinitely simply because storage is available. Keeping information for longer than necessary increases the volume of data that could be exposed if an incident occurs.
Information that has been securely destroyed or anonymized cannot later be taken during a breach.
These issues connect directly with the principles discussed in Key Principles of Data Protection, particularly accountability, data minimization, security and appropriate retention.
The Desjardins case therefore shows that privacy governance cannot focus only on keeping outsiders away from a network. Organizations also need to understand what authorized employees can access once they are inside.
The Lesson: Apply Least Privilege and Review Data Retention
The principle of least privilege means employees, contractors, applications and systems should receive only the access necessary to perform their current functions.
Permissions should also change when responsibilities change. Access granted for a previous role should not remain indefinitely simply because no one has reviewed it.
For systems containing sensitive personal information, organizations should combine role-based permissions with appropriate monitoring. Unusually large exports, access outside normal working patterns or attempts to retrieve information unrelated to an employee's role can signal activity that deserves investigation.
Retention policies form the second part of the lesson.
Organizations should know what personal information they hold, why they still need it, how long they are permitted or required to retain it, and how it will be securely destroyed when that period ends.
These measures cannot eliminate insider risk, but they can reduce both the likelihood and potential scale of a breach.
LifeLabs: When Known Vulnerabilities Are Not Addressed
The LifeLabs incident demonstrates a different type of failure. Instead of inappropriate employee access, attackers exploited weaknesses affecting internet-accessible systems.
What Happened at LifeLabs?
LifeLabs became aware of suspicious activity on October 28, 2019, while a third-party security company was conducting a security assessment.
LifeLabs notified the Information and Privacy Commissioner of Ontario on November 1 and the Office of the Information and Privacy Commissioner for British Columbia on November 5.
The attackers subsequently demanded payment in exchange for deleting information they claimed to have obtained, and LifeLabs paid the ransom.
The joint regulatory investigation later identified approximately 8.6 million unique individuals in four datasets returned by the attackers. Those affected were primarily in Ontario and British Columbia.
The information varied between datasets and included personal and health information such as contact details, health card numbers and laboratory information.
Early reports frequently referred to approximately 15 million customers. However, the later regulatory investigation provides a more appropriate basis for describing the confirmed datasets in a current article.
What Failed?
The regulatory investigation found that attackers initially gained access through vulnerabilities affecting two internet-accessible web servers associated with LifeLabs' online appointment-booking environment.
After obtaining access, the attackers were able to upload malicious content, execute commands and increase their privileges within the environment. Investigators identified unauthorized activity dating back to at least November 2018.
Importantly, this was not primarily a phishing case.
The investigation identified weaknesses relating to software vulnerabilities, patch management, security monitoring and broader information-security practices.
That distinction matters because the lesson is different from employee awareness training.
Employees should certainly know how to identify suspicious communications, but training alone would not have corrected vulnerable internet-facing software.
The Lesson: Treat Vulnerability Management as an Ongoing Process
Installing security updates may sound like a purely technical task, but effective vulnerability management also depends on organizational processes.
An organization needs to know which systems and applications it operates. Someone must monitor security notices and vendor advisories. New vulnerabilities need to be assessed, prioritized and addressed according to their seriousness.
If a critical system cannot immediately be patched, the organization should assess appropriate compensating controls rather than simply leaving the vulnerability unresolved.
Monitoring is equally important.
An attacker who enters an environment should not be able to operate unnoticed for an extended period. Appropriate logging, alerting and investigation procedures can help organizations recognize unusual activity earlier.
The LifeLabs case also demonstrates the importance of understanding where older information is stored. Historical databases and legacy environments can remain attractive targets even when they are no longer part of an organization's most visible systems.
Cybersecurity and data minimization therefore need to work together.
Capital One: When Cloud Configuration Creates an Opening
The Capital One incident provides another distinct lesson. Cloud services can provide strong security capabilities, but organizations remain responsible for configuring and managing important parts of their own environments.
What Happened in the Capital One Breach?
Capital One announced the breach in July 2019. Approximately 100 million individuals in the United States and six million in Canada were affected.
The information accessed largely came from credit card applications submitted between 2005 and early 2019.
Depending on the individual, the affected information included names, addresses, telephone numbers, email addresses, dates of birth and self-reported income. Some Canadian Social Insurance Numbers were also involved.
Unlike Desjardins, the incident was not centred on an employee misusing ordinary business access. Unlike LifeLabs, the main lesson was not conventional patch management.
The problem involved the configuration of cloud-connected infrastructure.
What Failed?
According to the U.S. Department of Justice, the attacker exploited a misconfigured web application firewall, which enabled access to Capital One data stored in the cloud.
Capital One determined on July 19, 2019, that an intrusion had occurred after being alerted to the possibility that data had been obtained.
The technical mechanics of the incident are complex, but the broader governance lesson is straightforward.
Using a reputable cloud provider does not transfer every security responsibility to that provider.
Organizations still need to configure access appropriately, manage identities and permissions, monitor activity and regularly assess their own cloud environments for weaknesses.
The incident also demonstrates why machine identities and service permissions deserve the same attention as employee permissions. Excessive permissions assigned to systems or services can create significant exposure even when individual employees have appropriate access.
The Lesson: Cloud Security Depends on Configuration and Identity Controls
Organizations using cloud services should know exactly who and what can access sensitive information.
Identity and access management should follow the principle of least privilege. Administrative privileges should be tightly controlled, unnecessary permissions should be removed and unusual access patterns should trigger investigation.
Cloud environments also change frequently. New services are deployed, integrations are added and permissions are modified.
A secure configuration at the beginning of a project may not remain secure indefinitely.
Regular configuration reviews and automated monitoring can help identify problems, but automation should complement rather than replace human oversight and governance.
The Capital One case therefore reinforces a wider lesson: organizations remain accountable for protecting personal information even when parts of their infrastructure are operated by third parties.
Three Breaches, Three Different Failure Points
Placed side by side, the cases show why the term “data breach” can describe very different underlying problems.
Desjardins involved inappropriate internal access, weak safeguards and retention concerns. LifeLabs demonstrated weaknesses in vulnerability management and monitoring. Capital One highlighted the risks associated with cloud configuration and access permissions.
The common factor is not one particular attack technique. Instead, each case demonstrates the need to connect privacy governance with security operations.
A privacy policy cannot repair vulnerable software. A firewall cannot determine whether an organization should still retain ten-year-old customer records. Security software cannot decide whether an employee genuinely needs access to thousands of sensitive records.
Those decisions depend on clear responsibility, documented processes and collaboration between privacy, legal, IT, cybersecurity and operational teams.
For organizations looking to review their controls more systematically, GDPR Compliance Checklist provides a broader framework covering areas such as data mapping, lawful processing, privacy governance, security and breach preparedness.
Five Lessons Organizations Can Apply
The three incidents occurred in different industries and involved different technologies, but they point to several practical measures that organizations can apply to their own environments.
-
Limit access to personal information. Employees, contractors, applications and service accounts should receive only the permissions they genuinely need. Access should be reviewed when responsibilities change and removed when it is no longer required.
-
Minimize unnecessary data retention. Organizations should be able to explain why personal information continues to be retained. Keeping information without a legitimate continuing purpose increases the amount of information that could be exposed during a future incident.
-
Maintain a reliable vulnerability-management process. Internet-facing systems, applications and dependencies should be identified and monitored. Security advisories need to reach people with both the authority and responsibility to respond.
-
Review cloud permissions and configuration. Cloud security requires ongoing attention to identity management, permissions, logging and configuration. Using a reputable cloud provider does not remove an organization's responsibility for securing its own environment.
-
Prepare for incidents before they happen. An incident-response plan should identify who investigates suspected breaches, who assesses privacy risks, which regulators may need to be contacted and how affected individuals will be notified where required.
What Are the Data Breach Notification Rules in Canada?
The legal response to a breach depends on which privacy laws apply to the organization.
Canada does not have one privacy law governing every private-sector organization in every circumstance. Federal, provincial and sector-specific requirements may apply depending on the organization, location and type of personal information involved.
Under PIPEDA, organizations subject to the Act must assess whether a breach of security safeguards creates a real risk of significant harm to an individual.
Where that threshold is met, the organization must report the breach to the Office of the Privacy Commissioner of Canada and notify affected individuals as soon as feasible after determining that the breach occurred.
PIPEDA does not impose a general 72-hour notification deadline.
Provincial requirements may also apply.
In Quebec, organizations must assess confidentiality incidents and take appropriate action where an incident presents a risk of serious injury. Quebec's privacy framework also requires organizations to maintain a register of confidentiality incidents.
Other sector-specific legislation may create additional requirements. The LifeLabs investigation, for example, involved Ontario's Personal Health Information Protection Act (PHIPA) and British Columbia's Personal Information Protection Act (PIPA).
For a broader comparison of Canadian and international privacy requirements, see Data Privacy Laws Beyond GDPR.
Where Does GDPR Fit for Canadian Organizations?
GDPR does not automatically apply simply because a Canadian organization processes personal information relating to someone associated with Europe.
Its territorial scope is more specific.
GDPR applies to processing carried out in the context of an establishment in the European Union. It may also apply to an organization outside the EU where relevant processing concerns offering goods or services to individuals in the EU or monitoring their behaviour there.
Where GDPR applies, Article 33 generally requires a controller to notify the appropriate supervisory authority of a qualifying personal data breach without undue delay and, where feasible, within 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to individuals' rights and freedoms.
That 72-hour GDPR requirement should not be presented as a general Canadian breach-notification deadline.
A Canadian organization operating across jurisdictions may therefore need to assess several legal frameworks following the same incident.
This is why organizations should identify applicable privacy laws before a breach occurs rather than trying to establish jurisdictional responsibilities during an active crisis.
Privacy Accountability Is Broader Than Cybersecurity
The three breaches also demonstrate why responsibility for personal information cannot sit entirely with an IT or cybersecurity department.
Under PIPEDA's accountability principle, an organization is responsible for personal information under its control and must designate one or more individuals who are accountable for compliance with the organization's privacy obligations.
That does not mean every Canadian organization must appoint someone carrying the formal GDPR title of Data Protection Officer.
Quebec has its own accountability requirements. In private enterprises, the person exercising the highest authority is responsible by default for protecting personal information, although this function may be delegated in writing.
GDPR separately establishes circumstances in which appointing a formal DPO is mandatory.
The distinction is important.
Job titles and statutory requirements differ between jurisdictions, but effective privacy programs still need individuals with sufficient authority, knowledge and resources to coordinate privacy responsibilities across an organization.
Our guide to the Role of a Data Protection Officer (DPO) explains the responsibilities associated with the GDPR role and how those responsibilities fit within broader privacy governance.
For professionals who need deeper knowledge of GDPR accountability, privacy risk, breach management and governance, the GDPR / Data Protection Officer (DPO) Certification provides structured training that can support work across privacy and compliance functions.
Formal privacy training should complement rather than replace technical cybersecurity expertise. Data protection is strongest when privacy, legal, IT, security and operational teams understand how their responsibilities interact.
Prevention Starts Before an Incident
One of the clearest lessons from major data breaches is that corrective action is often far more visible after an incident than before it.
Regulatory investigations may identify excessive permissions, unnecessary retention, vulnerable software, inadequate monitoring or unclear responsibilities. By that stage, however, personal information may already have been exposed and affected individuals may already be dealing with the consequences.
A stronger approach is to ask the difficult questions before a breach occurs.
Who can access sensitive personal information? Is that access still necessary? Which historical datasets are being retained? Who monitors software security advisories? How quickly are serious vulnerabilities addressed? Are cloud permissions regularly reviewed? Can unusual data exports be detected? Does the incident-response team know which privacy laws apply?
These questions connect cybersecurity controls with privacy governance.
They also help prevent organizations from assuming that compliance is achieved simply because policies exist on paper.
Regular reviews, appropriate monitoring and clear accountability can help organizations identify weaknesses while there is still time to address them.
Conclusion: Different Breaches, Shared Responsibility
Desjardins, LifeLabs and Capital One did not experience identical data breaches.
Desjardins demonstrated the risks associated with excessive internal access and inadequate retention controls. LifeLabs showed how known software vulnerabilities and weaknesses in security practices can expose sensitive health information. Capital One demonstrated how cloud configuration and access permissions can create significant risks in modern infrastructure.
The lesson is not that organizations can eliminate every possibility of a data breach.
It is that many common weaknesses can be identified and reduced before they develop into major incidents.
Access reviews, data minimization, vulnerability management, secure cloud configuration, monitoring and incident preparation all form part of that work. So does assigning clear responsibility for privacy governance.
Organizations handling personal information should therefore treat breach prevention as an ongoing privacy and security responsibility, not as a process that begins only after something goes wrong.
Professionals responsible for privacy governance can build on these principles through the GDPR / Data Protection Officer (DPO) Certification, particularly where their organizations operate across Canadian and European privacy environments.
Frequently Asked Questions About Data Breaches
What are the top 10 data breaches of all time?
Some of the world's largest reported data breaches have involved organizations such as Yahoo, Marriott, Equifax, LinkedIn, Adobe and Facebook. The exact ranking varies depending on whether incidents are measured by affected users, accounts, records or financial impact.
For organizations, the more useful lesson is to examine why these breaches happened. Weak access controls, compromised credentials, unpatched vulnerabilities, misconfigured systems and inadequate monitoring have all contributed to major incidents. The Desjardins, LifeLabs and Capital One cases discussed in this article show how different weaknesses can lead to significant exposure.
What are 80% of all data breaches caused by?
There is no reliable universal rule showing that exactly 80% of all data breaches are caused by one factor. The percentage varies between studies, industries and reporting methods.
Human-related risks remain important, including stolen credentials, phishing, misuse of legitimate access and configuration mistakes. However, organizations should not treat human error as the only problem. Strong technical controls, access governance and privacy practices are also essential. The principles outlined in Key Principles of Data Protection help explain how accountability, minimization and security work together to reduce these risks.
What are the top three causes of data breaches?
The exact ranking changes between studies, but three recurring causes are compromised credentials and social engineering, software vulnerabilities, and weak or misconfigured access controls.
These risks often overlap. An attacker may obtain credentials through phishing, exploit an unpatched application or gain excessive permissions once inside an environment. The three case studies in this blog illustrate each of these failure types in different ways.
Where do 90% of cyber incidents begin?
Claims that 90% of cyber incidents begin with phishing or human error are widely repeated, but they should not be treated as a universal statistic.
Phishing remains a common attack method, but breaches can also begin through stolen credentials, vulnerable software, exposed services, malicious insiders or cloud misconfiguration. LifeLabs and Capital One are useful examples of why organizations should not assume every breach begins with an employee clicking a malicious email.
What are the 5 C's of cybersecurity?
There is no single universally recognized “5 C's of cybersecurity” framework. Different organizations use the phrase in different ways.
For practical breach prevention, organizations should focus on core areas such as controls, configuration, credentials, communication and continuity. These should be supported by documented privacy and security processes. For a broader step-by-step review of governance and controls, the GDPR Compliance Checklist provides a useful framework.
Leave a Comment