2019 Breach record inspections

The Office of the Privacy Commissioner of Canada

September 2020

---

In our 2019 breach record inspections, the Office of the Privacy Commissioner Canada (the OPC or Office) engaged with seven telecommunications companies as a first on-the-ground assessment of the state of compliance with breach record-keeping obligations under the Personal Information Protection and Electronic Documents Act (PIPEDA) since they became mandatory on November 1, 2018. We sought to gain insight into how organizations are meeting their breach record-keeping obligations, and how ‘real risk of significant harm’ is being interpreted. We were pleased to see that in general, based on the companies we engaged with, the telecommunications industry has record-keeping systems in place and the companies we visited appeared to be taking their obligations seriously. That said, we observed key areas where there are opportunities for improved compliance.

Maintaining records of breaches of security safeguards is a key component in ensuring organizations report breaches to the OPC and notify individuals where required. This is important not only for enabling Canadians to better understand what has happened with their information and take steps accordingly; but it is also vital for instilling a level of trust among consumers and businesses that benefits the economy.

Now that we have the benefit of over one year of experience with PIPEDA’s breach reporting obligations, we have been better able to identify some challenges presented by these requirements and build on our existing guidance. When meeting your obligations, we encourage you to consult the relevant legislative provisions, regulations and most recent guidance and OPC publications available, including this report.

Our review revealed that organizations need to enhance their assessment and recording of information about how they assessed RROSH. Importantly, breach records need to include details that can explain the basis for the organization’s RROSH assessment, particularly in cases where the breach did not create a RROSH. This information should be included in breach records as this will allow the OPC to verify compliance with breach reporting and notification requirements in PIPEDA.

At a glance…

This report looks at the learnings from our Office’s first breach record inspections exercise, which examined seven organizations’ breach records to assess compliance, and sought to get a better sense of the plans, tools and approaches organizations are using to meet their breach recording and reporting responsibilities.

The observations made in this report are based on a sample of breach records from a group of seven Canadian telecommunications companies (telcos) that were identified based on the size and/or location of their customer base. The telco industry was selected because it was one of the top industry sectors that reported breaches to the OPC in 2019, alongside the financial, retail, and insurance sectors. As well, this sector’s products and services are used by most Canadians and as such, most Canadians have a consumer relationship or an account with a telco. The telco industry also collects, uses and handles a myriad of information about Canadians, which may include information that is sensitive on its own (e.g. identifiers such as a driver’s licence number). The personal information held by telcos may also be misused as a gateway to fraud, as with SIM card swaps.^{Footnote 1}

Text version of infographic

An infographic describing statistics of the breach record inspections

• 7 telco companies had a sample of their breach records inspected.
• 237 - total number of sample records inspected
• 40% of sample records did not include sufficient information for the OPC to adequately understand the organization’s assessment of the Real Risk of Significant Harm (RROSH) created by a breach
• 1 telco company had a strategy and processes in place to deal with the retention of breach records
• 39% - percentage of sample records for breaches caused by human error
• 21% - percentage of sample records for breaches likely to involve an intentional unauthorized disclosure^{Footnote 2}
• 5 - number of telco companies that use a checklist tool to assess Real Risk of Significant Harm

Tips for assessing RROSH

Where businesses have experienced a breach of their security safeguards, mandatory breach reporting and notification requirements under PIPEDA will apply if it is reasonable in the circumstances to believe that breach creates a Real Risk of Significant Harm (RROSH) to an individual.^{Footnote 3}

Our engagement with the telco companies in this activity revealed the desire for businesses to improve their understanding of how they can interpret and assess RROSH.

The OPC’s review exercise found that:

• 5 telcos (71%) assess RROSH using a checklist tool
• 20% of sample records presented non-reported breaches that may have been reportable to the OPC

This second statistic indicates that for 20% of sample records, although the telco determined there was no RROSH, the OPC either disagreed with the telco and felt RROSH was met based on the information provided, or found that the record lacked sufficient information to determine whether a breach created a RROSH.

As every breach is different, we need to consider the context of each incident. During the OPC’s review of each sample record, we considered how sensitive the breached personal information was, how likely that information has been or might be misused, and any possible harms that might apply to affected individuals.

For example, if a breach involves the disclosure of a customer’s financial position to someone’s relative or landlord, this could harm that person’s reputation or their relationship with the third party.

Another example is that the risk of significant harm associated with accidentally disclosing a tennis club’s mailing list through a misdirected email is likely to be much lower than if an HIV clinic’s patient mailing list is disclosed.

Do you have a framework to assess RROSH?

As an accountable organization, you should have a framework for assessing whether a breach creates a RROSH.

Why? This will ensure that your business assesses all breaches consistently and in turn, suitably communicates information about breaches that meet RROSH to customers and the OPC.

Your RROSH assessment will need to factor in:

• the sensitivity of the personal information involved in the breach; and
• the probability that the personal information has been, is being, or will be, misused.

Helpful RROSH practices

Teamwork makes the dream work. In some organizations, the privacy or breach team meets regularly to discuss their RROSH assessments and consider not only the facts of the incident, but other influencing factors. If more than one person in your organization is looking at RROSH assessments, such a team approach can improve your ability to identify all of the factors that may influence each breach’s RROSH assessment. This is in addition to heightening privacy awareness and promoting consistency with respect to how the organization considers RROSH and addresses breach incidents.

Consider the Context. It is important to remember that different factors might affect the RROSH assessment of different breaches. Amongst other factors, these might include an individual’s particular circumstances (e.g., the person’s relationships, financial situation, health circumstances), immediate actions taken to contain the breach, or if an individual’s information has been previously exposed, the breach may make them more vulnerable to a further attack.

---

What is the best tool for assessing RROSH? Our review observed that businesses use a variety of tools to assess RROSH. For example, one organization may use a risk matrix, while another may use a checklist or list of questions examining the risk of significant harm resulting from the breach.

The most suitable kind of RROSH tool for your organization may depend on your business or operational needs. Regardless of what kind of tool you use, you need to ensure that your RROSH assessment considers probability factors and sensitivity factors.^{Footnote 4} And remember, tools are just that – tools, but at the end of the day you will need to apply sound judgement to your assessment of RROSH.

The bottom line on RROSH

In addition to being prepared to report privacy breaches by establishing a breach management and record-keeping system, organizations should ensure they are assessing the RROSH of a breach consistently and appropriately by having an established assessment framework.

Every breach is different. So think about using open-ended questions rather than tick-boxes to assess risk based on each individual set of facts.

Organizations should also include details of their RROSH assessment in their breach records, even where they assess there is no RROSH. Should the OPC later become aware of that breach or review your records, this will help you demonstrate your compliance with PIPEDA, and how you thought through the RROSH analysis. This is further explained later in this report.

RROSH assessment examples

Inspired from our breach record inspections exercise, here are some examples of breaches that you can use to test your knowledge and assess RROSH. Please note that these examples do not use real names and they have been modified.

Remember, every breach is different. Your organization might see two similar breaches, but the circumstances of one breach (e.g., a person’s health situation or relationships) might change whether it creates a RROSH.

The OPC has published some questions that you can consider when assessing RROSH. Please see Part 6 of the OPC’s resource: What you need to know about mandatory reporting of breaches of security safeguards.

For more information about assessing RROSH, please refer to our video, Assessing the risks of significant harm.

Record-keeping challenges

Your obligations to keep breach records

PIPEDA requires organizations to keep a record of every breach of security safeguards involving personal information under their control.^{Footnote 7} This means that whenever your organization experiences such a breach, your organization needs to maintain a record of that breach. This applies even if a breach does not meet the RROSH threshold.

Financial penalties might apply. If an organization knowingly fails to keep and maintain a record of every breach of security safeguards involving personal information, there could be financial penalties.^{Footnote 8}

Many of the records reviewed by the OPC did not contain enough information about RROSH

Breach records must contain information that enables the Privacy Commissioner to verify your compliance with your mandatory breach reporting and notification requirements.^{Footnote 9} This means that your breach records should contain information that your organization considered when determining whether RROSH applied to each incident.

For each breach record, your organization must include sufficient details for the OPC to assess if you have reasonably applied the RROSH standard and met your obligations under PIPEDA.

This could be in the form of an explanation of why your organization determined the breach did or did not meet the RROSH threshold. This kind of information should be included in order to allow the Privacy Commissioner to verify your compliance, particularly in cases where your organization did not find that the incident met the RROSH threshold or notify affected individuals.

As shown in Figure 1, a significant number of the records we inspected did not include sufficient details for the OPC to understand the telco’s decision about RROSH. In some of these cases, the OPC was not provided with the complete breach record because of the telco’s claim of solicitor-client privilege. In other cases, records were simply light on details or no explanation was included.

For example, one sample record noted an incident where a customer service representative (“CSR”) gave account access to a third party so that they could make changes on a customer’s account even though they were not listed as an authorized contact on the account. The record noted that the telco determined that the incident did not meet RROSH, but the record did not clearly explain why. Through discussion with the OPC, the telco explained why they assessed there was no RROSH by clarifying that the CSR immediately identified their error allowing the telco to contact the authorized customer soon after and verify with that customer that the third party was a relative and could be authorized. The breach record should have included these details to explain what the telco considered in its assessment.

Text version of Figure 1

 

A column chart describing the percentage of records that contain information versus those that do not contain information.

Percentage of sample records containing information as per OPC Guidance

	Records containing information	Records NOT containing information
Date of the breach	98%	2%
Description of the circumstances of the breach	97%	3%
Type of personal information compromised	98%	2%
Explanation of decision about RROSH	60%	40%

Does solicitor-client privilege apply?

Some organizations stated they could not provide us with access to their records or parts of their records because they contained information that is subject to solicitor-client privilege.

As noted earlier, your breach records must meet the requirements prescribed in the Breach of Security Safeguards Regulations, i.e., they must contain enough information for the Privacy Commissioner to verify compliance with mandatory breach reporting and notification requirements.^{Footnote 10} Further, organizations must provide the OPC with access to, or a copy, of such a record on request.^{Footnote 11}

This means that even if you need to withhold part of a record because of solicitor-client privilege, your organization needs to ensure your record still includes the prescribed information, if requested by the OPC.

This requirement extends to information that you considered for your RROSH assessment. Again, one way to meet this obligation could be to include an explanation of why your organization determined the breach did not meet RROSH.

Text version of Figure 2

A pie chart describing information about the RROSH assessment and the relation between sensitivity and probability.

RROSH asessment factors considered
Sensitivity: 13%
Probability: 55%
Both: 32%

Remember to reflect probability and sensitivity

We found that information about the RROSH assessment frequently did not include details about the sensitivity of the personal information involved, and only recorded how the telco considered the probability that the personal information might be misused.

Breach records need to include information that demonstrates you considered probability and sensitivity factors in your RROSH assessment. This is particularly important in cases where you find that the breach did not meet RROSH.

Including this information will also help you demonstrate your compliance with PIPEDA, and show how you thought through your RROSH analysis.

Most telcos did not have a defined record retention period

Organizations must maintain a record of every breach of security safeguards for 24 months after the day on which the organization determines that the breach has occurred.^{Footnote 12} However, you may have other legal obligations that require you to keep records for longer.

We found that 6 out of 7 telcos did not have a clear breach record retention strategy and process.

While your organization must retain breach records from the date of determination (i.e. not the date that the breach occurred, but the day that you determined the incident that occurred was a breach), you should consider whether a longer retention period is appropriate.

Why would I retain records for longer than 24 months? Your organization might decide to retain records for a longer period if it can improve your ability to identify breach trends and/or systemic issues. Please see the following section for more information about identifying trends with your breach management system. In some cases, the measures you are taking to remedy the breach might take an extended period and it may be appropriate to retain a record of that breach as a reference point while you complete your remedial actions.

Other things to remember

A primary goal of this breach record inspection exercise was to review how the selected companies kept breach records as required under PIPEDA. That said, the OPC also invited the telcos to voluntarily provide details about their breach reporting process and practices.

Here are some of our takeaways from this activity about best practices and a note on your legal obligations for notifying the OPC and individuals of a breach.

Your breach management system

Organizations should be prepared to report and manage privacy breaches by establishing a breach management and record-keeping system that enables compliance with PIPEDA.

Enhance your system to identify trends. Organizations might improve their ability to identify and correct systemic issues or trends by retaining various kinds of incidents or breaches (e.g., relating to privacy, data and security) in one place. When recording breaches, it can also be helpful to consider how much detail about the breach you need to achieve this. Recording more detail might improve your ability to identify systemic issues or trends and take corrective action. Importantly, find the right balance when recording information and as always, think about whether recording certain details could also compromise an individual’s privacy. It’s likely that you can identify breach trends without recording any personal information, or as little personal information as possible.

What about your blind spots? On the flipside, breaches that appear infrequent or that are not often being reported to you might represent under-reporting within your business.

Based on the sample breach records in our review, only a minority of incidents involved loss (1%), theft (4%) and unauthorized browsing or employee snooping (3%). We were surprised that we didn’t see more of these incidents. Based on breaches reported to the OPC, we are seeing more incidents caused by loss (11%), theft (8%) and employee misuse (7%). Misuse includes incidents of employee snooping and data exfiltration.^{Footnote 13}

Organizations should continue to think about what they can do to identify reporting gaps. For example, could there be a break in your reporting system? Alternatively, do your front-line workers know how to spot and report a breach? Or does your privacy team need to re-think how it interprets RROSH?

Continue to improve your system. Once implemented, organizations should be proactive in continuing to improve their breach-reporting framework. For example, given we are more than 18 months into the Mandatory Breach Reporting Regime, there should now be a critical mass of incidents that would allow your organization to conduct an audit (e.g., identifying whether staff are under-reporting privacy breaches).

Staff education is important for ensuring breaches are not overlooked or under-reported. This applies to all employees, especially public-facing employees who interact with affected individuals. For example, you may want to conduct refresher or specialized training that educates staff on how to identify and prevent certain breaches (e.g. phishing attacks or social engineering attempts).

Promote privacy across all business areas

Organizations can benefit from sharing privacy and breach knowledge across different business lines as this can promote consistency and help with quickly identifying and escalating privacy-related incidents, trends and risks.

Engagement with executive and senior managers. Additionally, executive and senior managers can also improve compliance by regularly maintaining their lines of communication with their privacy teams. This engagement can contribute to embedding privacy within the organization’s culture and decision-making processes. Is Breach Reporting a recurring agenda item for Privacy Debriefs at senior Executive meetings? If not, it should be.

What else is happening in your industry? Businesses can also consider sharing their breach experiences across their industry. In the case of breaches caused by malicious actors, we have received reports that actors move from one business to the next, using the same attack methods. Proactively sharing information about a breach that affected one business can help another business understand why that breach happened and take action to prevent similar incidents. When sharing information about your experience, consider how much detail you really need to provide. For example, think about whether you can share anonymized or aggregate data. Will sharing information with other businesses disclose any personal information? Can you anonymize the information that you’re sharing?

You need to report the breach to the OPC, and notify individuals, as soon as feasible

Mandatory breach reporting and notification is key in ensuring that individuals are informed and able to take steps to mitigate any further harm falling out of a breach.

Under PIPEDA, if a breach of your security safeguards meets the RROSH standard, you are required to complete the following as soon as feasible:

• report the breach to the OPC,^{Footnote 14}
• notify any individuals that have been affected by that breach.^{Footnote 15}

Additionally, you should consider whether PIPEDA requires you to notify any government institutions or other organizations of the breach. If this applies, the notification must also be given as soon as feasible.^{Footnote 16}

What happens if your organization doesn’t report or notify?

The OPC might investigate. The OPC can launch an investigation either on its own initiative or in response to a complaint.^{Footnote 17} This can apply to issues that come to the OPC’s attention through a variety of sources, including when it receives a complaint from an individual or when the OPC learns of an incident from the media. An investigation can lead to a variety of outcomes such as recommendations or a compliance agreement aimed at improving an organization’s privacy compliance. In some cases, if the Privacy Commissioner considers it to be in the public interest, the Commissioner may make public any information that comes to his knowledge in the performance or exercise of an investigation.^{Footnote 18}

Non-compliance could lead to fines.^{Footnote 19} Remember, breach reporting to the OPC and breach notification to affected individuals are legal obligations that can lead to financial penalties should your organization be found to knowingly not meet PIPEDA’s breach reporting requirements.

Don’t compromise your reputation, or your bottom line. In cases where organizations have failed to issue breach notifications, we have seen and heard that these businesses have taken a reputational hit that as a consequence, will hurt their “bottom line”.