Earlier this week, I wrote about new Alberta breach reporting obligations in the Alberta Health Information Act. This post considers how distinctions between suspected, probable, unconfirmed and confirmed data breaches matter in cloud computing agreements.
Not every security incident is a security breach, and not every suspected security breach turns out to be an actual breach exposing personal data. I would argue that Canadian breach reporting laws generally focus on actual breaches; but, I would also argue that this doesn’t necessarily mean that the breach must be confirmed. For example, Canada’s new federal breach reporting law in the Personal Information Protection and Electronic Documents Act defines a “breach of security safeguards” as:
“the loss of, unauthorized access to or unauthorized disclosure of a personal information resulting from a breach of an organization’s security safeguards that are referred to in clause 4.7 of Schedule 1 or from a failure to establish those safeguards.”
It would be a stretch to interpret the words “the loss” etc. and “resulting from” as actually meaning “the suspected loss” or “possibly resulting from”. On the other hand, it is unlikely that a breach must be confirmed in the sense of there being no reasonable doubt. Courts find facts based on the balance of probabilities. It is very likely, therefore, that a court would conclude that probable breaches fall within the definition of a “breach of security safeguards”. This isn’t a foregone conclusion. It still requires the court to read into the provision a threshold that the court may be reluctant to do. On the other hand, “confirmed” may be too high a test once the court has access to information about how difficult it is in some instances to confirm a breach to the level of “no reasonable doubt”.
Ontario’s Personal Health Information Protection Act is similar. PHIPA imposes a reporting obligation to notify an individual if:
“personal health information about an individual … is stolen or lost or if it is used or disclosed without authority…”
It would be challenging to read “is” as “may have been”. On the other hand, it would substantially weaken the protections of this provision if “is” were to be read as requiring confirmation that puts the breach beyond reasonable doubt.
So, what is the right test for contractual breach reporting obligations in a cloud computing agreement? Should cloud service providers report anything less than a probable or confirmed breach? Should every security incident be reported? There may be good reasons to request reporting of security incidents that are only suspected breaches. Arguably, reporting on all security incidents might provide users of cloud computing services with additional data that can be used to exercise oversight and ongoing due diligence of the cloud service provider. Reporting of suspected breaches may be appropriate if the organization expects or wants to be involved in the investigation to determine whether a breach occurred.
However, I’d argue that information on all security incidents or even just suspected breaches has minimal relevance when dealing with public cloud computing services and can be misleading as to the overall risk profile of those services. What is more meaningful is to understand how the cloud service provider investigates security incidents and classifies them. Ideally, users of cloud services would obtain information during due diligence and contractual commitments that would provide users with assurance that investigations into security incidents are and will be properly resourced and auditable and that these investigations are and will be timely and effective in resulting in establishing whether the incident involved a confirmed breach or, if not fully confirmed, sufficiently probable that the incident should be treated as a breach.
What do you think? DM me on Twitter – @TM_Banks.
Categories: Cloud Computing, Cybersecurity, Data Breach, Privacy