2019 Breach record inspections
The Office of the Privacy Commissioner of Canada
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.
One key observation from this exercise was that 40% of sample records did not include sufficient information for the OPC to adequately understand the organization’s assessment of whether the breach created a Real Risk of Significant Harm (RROSH).
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 disclosureFootnote 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.
When developing a tool to assess RROSH, you should also refer to the relevant legislative provisions and regulations.Footnote 5 The OPC also has an online resource that can help: What you need to know about mandatory reporting of breaches of security safeguards
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.
Example 1 : Employee snooping
Telco A discovered that a senior Human Resources employee viewed the HR files of 48 other employees without a legitimate business purpose. The employee had access to salary, performance, and medical information of other Telco A’s Human Resources employees.
This breach meets the RROSH standard. This example illustrates a situation where there is a real possibility or risk that unauthorized access could result in humiliation and/or damage to reputation or relationships. Due to the Human Resources employee’s senior position and the sensitive information in the Human Resources files, it is also possible that affected individuals could experience loss of employment or professional opportunities.
Additionally, in some cases of employee snooping, the RROSH to affected individuals may be elevated if the employee had malicious intent, which could lead to financial loss or identity theft.
For more information about employee snooping, please read the OPC’s Ten tips for addressing employee snooping.
Example 2 : Misdirected correspondence
Gabriel received an email from Telco B that was a ‘welcome email’ for another customer, Liam. The email confirmed that Telco B had set up Liam’s account and included his full name, billing address, and account number. Gabriel contacted Telco B to tell them about the error and that he did not know Liam. The representative apologized for their mistake and asked Gabriel to delete the email. Gabriel told the representative that he had deleted the email from his inbox and deleted items.
This breach does not meet the RROSH standard. In this case, the affected information is not highly sensitive. Additionally, Gabriel and Liam do not have an existing relationship, so there does not appear to be a real risk of humiliation or damage to reputation or relationship. Telco B also confirmed the deletion of the email with the information accidentally disclosed to Gabriel. As Gabriel reported the situation to Telco B and confirmed that he had deleted the email, the possibility that Gabriel has misused or will misuse Liam’s information appears to be low.
Don’t forget, in other cases similar to this breach, the circumstances could create a RROSH. For example, you should also think about:
- Does Gabriel know Liam? If he does, Liam might feel distressed if Gabriel knew that he had set up an account with Telco B.
- Are there any indications of malicious intent? If so, how likely will the affected information be used to cause harm?
- How sensitive was the information involved? Could any of this information lead to identity theft or financial loss? Were a number of pieces of personal information breached, thus raising the risk of misuse?
- How and when did Telco B become aware of the breach? A longer period of exposure, or time until an organization identifies a breach, will generally increase the likelihood of RROSH. If organizations can establish mechanisms to identify and contain breaches sooner, then this can reduce the risk of harm to affected individuals.
- What if we can’t confirm that Gabriel deleted the email? This might increase RROSH, particularly if Gabriel and Liam had an existing relationship and/or especially sensitive information was involved.
- Furthermore, if we can’t confirm that Gabriel deleted the email and the information pertained to more than one individual, then this could also increase the likelihood of RROSH. In particular, this may be the case where one or some of those individuals have different circumstances that might create a risk of significant harm (e.g., humiliation, financial loss, identity theft, negative effects on the credit record, etc.)
Further information is available in the ‘Mail, E-Mail, and Fax’ section of the OPC’s Interpretation Bulletin: Safeguards. This includes other case summaries that involved misdirected correspondence and mass mailouts.
Example 3 : Lost laptop
An employee of Telco C’s collections team accidentally left their work laptop on a bus. Even though the employee retraced their steps and contacted the bus company, they were unable to recover the laptop. The laptop was protected with a password but no other safeguards (e.g., device encryption, feature to erase device contents remotely).
Telco C’s investigation revealed that, as the employee had saved work documents containing customer information on to the hard drive, they had broken Telco C’s policy that prohibits the retention of customer information on company devices. It is possible that the work documents on the laptop included information of up to 8000 customers. In some cases, the information contained only a name, contact details and an account number. In other cases, the information could have also included payment account details and/or driver’s licence numbers.
This breach meets the RROSH standard. As the affected information could have included payment details and/or driver’s licence details, it is clear that sensitive information was involved. Additionally, the probability that information will be misused for identity theft or fraudulent activities increases RROSH due to the lack of additional device protections, the inability of Telco C to recover the laptop, and a high number of affected individuals.
Remember: your assessment should consider a range of factors. You might also like to think about:
- What if there were no payment details or driver’s licence details involved? Depending on the context, any information can be sensitive. In this case, the sensitivity of the customers’ name, contact details and account number might depend on other factors, such as what other information it could be associated with or linked to.
- How and when did Telco C become aware of the breach? A longer period of exposure, or time until an organization identifies a breach, will generally increase the likelihood of RROSH. If organizations establish mechanisms to identify and contain breaches sooner, then this can reduce the risk of harm to affected individuals.
- Is the personal information adequately encrypted, anonymized or otherwise not easily accessible? Additional safeguards will enhance information protection and can reduce the likelihood of RROSH or help an organization contain or investigate a breach. Examples of additional measures include: strong password protection; auto-expiring credentials; strong and up-to-date device encryption; and features to erase device contents remotely, automatically purge information after a certain period of time, and to detect access or user login.
Have other organizations been notified of the breach? Depending on the circumstances, notifying relevant government institutions or organizations can reduce the risk of harm that could result from the breach. Notably, you might be required to notify other organizations of the breach in some cases.Footnote 6
Further information is available in the ‘Internet and Technology’ section of the OPC’s Interpretation Bulletin: Safeguards. This includes other cases that refer to safeguards that organizations can use to protect portable devices.
Example 4 : SIM card swap
When Telco D received a phone call about Alex’s mobile account, the caller confirmed Alex’s name, billing address, account number, and date of birth. The representative asked the caller to confirm the account personal identification number (PIN) before granting access to the account, just as they were trained by Telco D.
Suddenly, the caller became very upset and explained that they were just trying to activate their replacement SIM card because they had recently had their mobile phone stolen and they needed a way to contact their utility company as they had just moved to a new house. As they wanted to provide good customer service and show their customer empathy, the representative disregarded the account PIN and granted the caller with access to Alex’s account. At the caller’s request, the representative also activated the new SIM card.
The following morning, Telco D received another phone call about Alex’s mobile account. This time, the representative confirmed all of Alex’s details, including her PIN. Alex explained that she was confused as she didn’t seem to be receiving text messages, she also commented that she had been having issues with her debit card.
On looking over the account notes, Telco D discovered that the representative’s earlier interaction with the caller was unauthorized and a breach had occurred. When Telco D contacted Alex to explain what happened, Alex became distressed as she realized that the unauthorized caller had used the replacement SIM card to access her bank account and make fraudulent transactions.
This breach meets the RROSH standard. An account takeover or SIM swap can result in identity theft and/or financial loss.
Once fraudsters take over the victim’s cellular phone account, they have access to unique codes that can allow them to gain control of a victim’s online accounts. This might include a person’s bank, social media, email or any other account that they have linked with their cellular phone number.
For more information about SIM swap scams, you might like to read the OPC’s blog, The SIM card swap scam: What it is and what you can do to minimize risk.
This review exercise highlighted challenges associated with how organizations keep records about breaches of their security safeguards.
In particular, we found that:
- 40% of sample records did not include sufficient information for the OPC to adequately understand the organization’s RROSH assessment
- Only 1 organization had implemented a clear breach record retention strategy
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.
|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
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.
For more information, including details about what else to include in your breach records, please visit our online resource: What you need to know about mandatory reporting of breaches of security safeguards.
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”.
To report a breach to the OPC, please complete our online form: PIPEDA breach report form.
For more information about your notification and breach reporting obligations, please visit our online resource: What you need to know about mandatory reporting of breaches of security safeguards.
Report a problem or mistake on this page
- Date modified: