[BreachExchange] Canada: Once more unto the breach regulations

Audrey McNeil audrey at riskbasedsecurity.com
Thu Oct 26 20:54:11 EDT 2017


http://nationalmagazine.ca/Blog/October-2017-(1)/Once-more-unto-the-breach-
regulations.aspx

The news of a data security breach can send a chill through your bones.
Anyone who’s ever shared sensitive information online is vulnerable, and
these days that’s more and more of us – think of the three billion people
affected by the breach at Yahoo! this summer.

The federal government is drafting regulations under PIPEDA on how and when
to notify people whose information may have been caught up in a breach.
They published those draft regulations in the Canada Gazette in September.

Overall, the comments by the CBA’s Privacy and Access Law Section and CCCA
on the draft regulations are aimed at finding the sweet spot for consumer
protection and the business exigencies of the notifying organization.

They congratulate the government for accepting earlier CBA recommendations
not to require notices and reports of a breach to identify, or speculate
on, the types of harm that may result from it. “The CBA Sections
recommended that the content of reports be based on facts,” the latest
submission says.

The draft regulations require “a notice to be sent to each individual
affected by a breach of security safeguards where it is reasonable in the
circumstances to believe that the breach creates a real risk of significant
harm to the individual.”

But the draft regulations go too far when they require the notices of a
breach to include information about the organization’s internal complaint
process, the submission says. Providing a number to call for more
information is sufficient. The focus of the notice, the submission says,
should be on giving the individual a user-friendly message on how they can
obtain further information about the breach and what they can and should do
to protect themselves.

The draft regulations set out a number of ways to notify an affected
person, which the Sections believe can be simplified to: a) email, b)
secure messaging (if the affected individual has consented to receiving
information from the organization in this manner), c) letter, d) oral
communications (which may or may not include voice mail), and e) in-person
meetings.

The Sections also argue that the use of email for this purpose should not
require previous consent since it would not be classified as a “commercial
electronic message” for CASL purposes.

“Direct notification is intended to alert individuals to a privacy breach
and to give them an opportunity to reduce the risk of harm resulting from
the breach, or to mitigate that harm. Expedited timing is critical to give
individuals the best chance at risk mitigation and harm reduction. Imposing
a prior consent pre-condition on the ability to send a notification via
email reduces the capacity of an organization and individual to achieve
that objective.”

The Sections also point out inconsistencies in the requirements for
addresses and phone numbers – “last known address” and “home” phone, but
not necessarily “last known phone number.” There is no reason for these
specific requirements – requiring all contact points to be “last known” is
sufficient.

Sometimes it is better – or more feasible – to notify individuals affected
by a data breach indirectly. The Sections suggest amending the draft
regulations to allow this when the contact information is “likely” to be
out of date (the draft regulations say “is” out of date), or when the cost
of directly notifying each individual in the affected group would be
prohibitive to the organization.

And where the regulations state that the manner of indirect notification
could be an “advertisement,” the Sections recommend using the word
“announcement” instead, as “advertisement” is a narrow term with commercial
connotations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20171026/40ffddc7/attachment.html>


More information about the BreachExchange mailing list