What Canadian Company Should Do After Data Breach?

More specifically, what a canadian company should do?

 

Related Regulations

1. Federal Privacy Laws

PIPEDA (Personal Information Protection and Electronic Documents Act)

PIPEDA applies to private-sector organizations across Canada that collect, use, or disclose personal information in the course of a commercial activity. 

Not covered by PIPEDA

• Personal information handled by federal government organizations listed under the Privacy Act
• Provincial or territorial governments and their agents
• Business contact information such as an employee’s name, title, business address, telephone number or email addresses that is collected, used or disclosed solely for the purpose of communicating with that person in relation to their employment or profession
• An individual’s collection, use or disclosure of personal information strictly for personal purposes (for example, personal greeting card list)
• An organization’s collection, use or disclosure of personal information solely for journalistic, artistic or literary purposes

• PIPEDA does not generally apply to:

  • not-for-profit and charity groups
  • political parties and associations

Note: https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief/

The Privacy Act 

• the Privacy Act, which covers how the federal government handles personal information;
• The Privacy Act only applies to federal government institutions listed in the Privacy Act Schedule of Institutions.
• The Privacy Act does not apply to political parties and political representatives.
• the Personal Information Protection and Electronic Documents Act (PIPEDA), which covers how businesses handle personal information.
• PIPEDA does not apply to organizations that do not engage in commercial, for-profit activities.
• Municipalities, universities, schools, and hospitals are generally covered by provincial laws. PIPEDA may only apply in certain situations

2. Provincial Privacy Laws

Health Related

• Ontario
• PHIPA (Personal Health Information Protection Act, 2004, S.O. 2004, c. 3, Sched. A)
• New Brunswick
• Newfoundland and Labrador
• Nova Scotia

Employment Related

• Alberta
• British Columbia

3. Secore-Specific Privacy Laws

Bank Act

• Financial Consumer Agency of Canada
• Banks and federal credit unionsFootnote Footnote1 
• Trust and loans companies
• External complaints bodies
• Insurance companies
• Retail associations Footnote2    

Credit Unions Related Provincial Laws

• Canadian oversight organizations
  • Financial Institutions Supervisory Committee (FISC)
  • Senior Advisory Committee (SAC)
  • CDIC Board of Directors
  • Provincial and territorial regulators
  • Insurance regulators
• Financial literacy committees and networks
  • Financial Literacy Working Group for Indigenous Peoples
  • FCAC Research Committee on Financial Literacy (2022 to 2024)
  • Interdepartmental Committee on Financial Literacy
  • ​Financial literacy networks
• International collaboration
  • International Financial Consumer Protection Organisation (FinCoNet)
  • G20-OECD Task Force on Financial Consumer Protection
  • OECD International Network on Financial Education

Consumer Credit Reporting Provincial Laws

OPC - Mandatory Reporting of Breaches

Organizations subject to the Personal Information Protection and Electronic Documents Act (PIPEDA) are required to:

• report to the Privacy Commissioner of Canada breaches of security safeguards involving personal information that pose a real risk of significant harm to individuals
• notify affected individuals about those breaches, and
• keep records of all breaches.

Note: https://www.priv.gc.ca/en/privacy-topics/business-privacy/safeguards-and-breaches/privacy-breaches/respond-to-a-privacy-breach-at-your-business/gd_pb_201810/

OPC = Office of the Privacy Commissioner of Canada

Not all breaches need to report to the OPC:

Not all . The law requires that you report any breach of security safeguards involving personal information under your control if it is reasonable in the circumstances to believe that the breach of security safeguards creates a real risk of significant harm (RROSH) to an individual.

Whether a breach of security safeguards affects one person or a 1,000, it will still need to be reported if your assessment indicates there is a real risk of significant harm resulting from the breach.

Microsoft Recommendations

 

From Microsoft: https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account?view=o365-worldwide

1. Reset the user's password immediately. Do not communicate the new password through email to the end user.

   Enable Multi-Factor Authentication (MFA) to prevent compromised accounts, especially for accounts with administrative privileges. For more information, see Set up multi-factor authentication.

2. Remove any suspicious forwarding addresses set at the mailbox level.

3. Remove any suspicious inbox rules set within the mailbox.

4. Go to the Microsoft Defender portal at https://security.microsoft.com > Email & Collaboration > Review > Restricted users, or directly at https://security.microsoft.com/restrictedusers. If the user is on the list, select the user and then select Unblock. Follow the steps in the flyout pane, and then select Yes to confirm. The account should be able to send messages again, usually within an hour.

5. Unblock the user from sending mail

6. Remove the user account from any administrative role groups until you are confident that the account is no longer compromised.

7. Optionals:

• Block the user account from signing-in
• Verify the contents of the Sent items folder of the account in Outlook or Outlook on the web.
• The accounts for any other services that use this account as an alternative email account might have also been compromised. After you do the steps in this article for the account in this Microsoft 365 organization, do these steps for your other accounts.
• Verify the contact information (for example, telephone numbers and addresses) of the account.

The privacy breach management toolkit from Government of Canada

The Policy on Privacy Protection requires federal institutions to have plans in place to respond to privacy breaches. These plans must:

• address privacy breaches that affect any personal information under the control of the institution, including information held by a third party as part of a contract, agreement, or arrangement with the institution
• include roles and responsibilities for managing a privacy breach
• align with security requirements
• meet the requirements of Appendix B: Mandatory Procedures for Privacy Breaches of the Directive on Privacy Practices

The toolkit provides non-mandatory guidance to institutions to support the management and prevention of privacy breaches. Although the toolkit contains four phases, there will be overlap during the breach management process. Privacy officials are encouraged to download and adapt the tools as necessary to meet the specific needs of their institutions.

Phases

Identify and contain the breach

Identifying the breach, containing it, and engaging privacy officials

Complete a full assessment of the breach

Assessing the circumstances of the breach and the risk to individuals and the institution

Mitigate the risks and communicate internally

Communicating the breach internally and notifying affected individuals

Report and prevent another breach

Implementing prevention measures and reporting a material privacy breach

Related links

• Directive on Privacy Practices
• Policy on Privacy Protection
• Privacy Act

Case Studies

https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breach-examples/

Case study 1: Failure to redact personal data

Reporting decision: Notifying the ICO and data subjects

What happened?

A data controller sent paperwork to a child’s birth parents without redacting the adoptive parents’ names and address. After discovering the breach, the data controller did not inform the adoptive parents.

Why was this a problem?

The breach presented a high risk to the adoptive parents’ safety. The birth parents visited the adoptive parents’ address and had to be removed by the police, and the adoptive parents and their children had to relocate.

What should have happened?

The controller should have notified the adoptive parents as soon as the breach was discovered. This would have allowed the adoptive parents to take steps to minimise the risk, for example by moving into alternative accommodation or putting additional safeguarding measures in place.

The incident also needed to be reported to the ICO, as there was likely to be a risk to individuals.

The controller should also investigate why the incident occurred and take steps to prevent a similar incident occurring in the future.

Case study 2: Emailing a file in error

Reporting decision: Documenting the breach on internal breach log only

What happened?

A debt insolvency agent emailed a vulnerable new client’s file in error to a colleague in a different department. The colleague who received the file immediately deleted the email and informed the sender of the error.

Why was this a problem?

The file contained a list of the client’s outstanding debts, their contact details, basic financial history, information about their mental health and reasons for seeking support with their financial situation. The client was vulnerable due to their mental state.

What did the data controller do?

The sender and recipient work for the same organisation in similar roles, but in different departments. Both work to the same data security measures and have completed training on working with vulnerable people.

The recipient correctly deleted the email and informed the sender. As a result, it is very unlikely that there would be any risk of harm or detriment to the data subject, despite special category personal data being involved. Therefore, there is no legal obligation to report the breach to the ICO or inform the affected data subject.

The organisation documented the breach internally and provided guidance to staff about checking contact details when sending emails, to minimise the risk to their data subjects. If the email had been sent to a member of the public, the risk to the data subject would have been higher.

Case study 3: Working on an unencrypted laptop

Reporting decision: Initially not reportable, but then reportable to both the ICO and data subjects

What happened?

An employee lost his briefcase, containing work on an unencrypted laptop and unredacted paper files relating to a sensitive court case – including information on criminal convictions and health information.

Initially, the employee told his manager that he believed the laptop was encrypted and the paper files were redacted. The manager reported the incident to the IT department, who remotely wiped the laptop.

At that point, the data controller did not report the breach to the ICO as they believed there was little or no risk to data subjects, though they did record the incident on their breach log.

After being informed by the IT department that the laptop was unencrypted, and after the employee discovered the paper files had not been redacted, the controller reported the breach to the ICO and informed the data subjects.

Why was this a problem?

The paper files were unredacted and not secured, so somebody could have accessed sensitive data. As the laptop was unencrypted, there was no way for the controller to know whether the data had been accessed. Therefore, they could not be certain that a risk to the data subjects would not occur.

What did the data controller do?

They updated the internal breach log to reflect the new information and documented the developing situation, including the way the breach changed from being not reportable to reportable. On discovering the possibility of a risk to data subjects, the controller correctly reported the breach to the ICO and informed the data subjects.

The controller was then able to use their internal breach log to explain the delay in reporting the breach to the ICO, outside the required 72 hours.

Case study 4: Sending medication to the wrong patient

Reporting decision: Documenting the breach on internal breach log only

What happened?

A courier, delivering medication for a Scottish pharmacy, delivered one set of medication to the wrong patient (Patient A).

Patient A called the pharmacy to complain. The pharmacist then realised the prescription was for a different patient with a similar name (Patient B). After contacting the courier, the unopened medication was collected and delivered to Patient B.

Why was this a problem?

Patient A and Patient B both complained to the pharmacist. Patient B felt their medical information and address had been shared inappropriately with Patient A.

What did the data controller do?

The pharmacist decided that any risk to Patient B was unlikely, due to the actions of Patient A, the pharmacy and the courier. However, they decided to report the breach to the ICO in case Patient B subsequently complained to the ICO about how their personal data had been handled.

Did the data controller need to report the breach?

As the pharmacy had concluded it was unlikely there was a risk to Patient B, the breach did not need to be reported to the ICO.

There would be no further action for the pharmacy to take, assuming they had documented the details of the breach, their decision not to report and any safeguards put in place to prevent a recurrence. The threshold for informing data subjects is higher than for informing the ICO. Therefore, the pharmacy didn’t need to tell data subjects about the breach either. Informing individuals about minor breaches that are unlikely to cause risk or harm can cause unnecessary worry to data subjects and can also result in data subjects becoming fatigued if informed of numerous breaches.

The pharmacist should have had confidence in their decision making and taken responsibility for it. If, having received a complaint from the data subject, the ICO wanted to know why the pharmacy had not reported the breach, they would be able to refer to the rationale recorded on the internal breach log.

Note that if the pharmacy had been in England, it would have reported the incident via the Data Security and Protection Incident Reporting tool, regardless of the threshold for reporting to the ICO.

Case study 5: A phishing attack

Reporting decision: Notifying the ICO and data subjects

What happened?

A law firm employee failed to recognise a phishing attack. They received an email, clicked a link to download a document, then inadvertently entered login credentials into what they believed was a legitimate website.

A while later, the employee contacted the company’s IT department as they noticed they were no longer receiving emails.

Why was this a problem?

The data controller discovered the employee’s email account had been compromised when they entered their login details. A forwarding rule had also been set up, diverting the employee’s emails to a third party.

Additionally, the third party had responded to several emails using a spoofed email account, advising the recipients of a change in bank details. This resulted in two clients making significant payments to the third party.

The controller also discovered that the compromised email account contained scanned copies of client ID documents.

What did the data controller do?

The controller reported the breach to the ICO and notified affected clients about the breach.

The controller identified a high risk to affected clients’ rights and freedoms, partly due to the financial detriment that two clients experienced after making payments to the third party. It is also likely that other clients will have received emails asking for payments.

Also, the controller identified that there was a high risk of identity theft or fraud, due to scanned copies of ID documents being held on the compromised account.

References