Security Breaches: Treat the Disease Not The Symptoms

In Canada, if not already, breach notification should be a corporate topic of conversation.

A brief survey of the Canadian landscape would reveal that Ontario requires breach notification under the Personal Health Information and Protection Act for custodians of personal health information; upon full proclamation, Newfoundland will require breach notification under its Personal Health Information Act; Nova Scotia’s new legislation on personal health information (to be reintroduced) will as well; New Brunswick also deals with the subject in its new (2009) Personal Health Information Privacy and Access Act; Alberta has recently amended its Personal Information Protection Act to require breach notification, and the federal government’s response to the 2007 review of the Personal Information Protection and Electronic Documents Act indicates that Act will be amended to require breach notification. There is no definitive date yet but rumour has it that this may occur in 2010.  It is understood that the Uniform Law Conference of Canada will develop a uniform breach notification statute and the topic is slated for discussion later this year.

However, dealing with breaches is like treating the symptoms: organizations really need to address the underlying problems. To that end, I would suggest that anyone considering how best to “do” breach management should really think in terms of “incident management”.  What’s the difference between incidents and breaches?  A lot and a thorough understanding the former may help minimize the latter.

There are a few definitions for “breach” out there and generally involve the concept of an unauthorized acquisition, access, use, or disclosure of personal information and usually, either implicitly or explicitly, link it to potential or real harm to the individual(s) concerned. The U.S. National Institute for Standards and Technology considers an incident as “a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices”. While this definition is limited to information technology security incidents, the concept of an actual or anticipated violation of policy or practices is one to keep.

Why focus on incidents? Incidents do not generally involve any leakage of information outside of the organization or create the possibility of harm to the affected individual(s).  They nonetheless indicate problems with a technology deployment or a business process or reveal a need to renew employee security training. In not tracking and addressing incidents, sooner or later, an incident may well turn into a breach because of poor security practices.

A starting recipe for incident management? Build a reporting structure, combine with metrics to track the number, location and nature of incidents; analyze and respond to them. Proactively addressing situations can help prevent them from becoming an audit issue or even a breach. Encouraging employees and others to report potential security incidents has the benefit of engaging them in an organization’s privacy/security program. However, it’s important to keep in mind that such reporting should not be immediately linked to disciplinary action (every rule has exceptions but start with this rule). The object isn’t to punish people for mistakes but to find the out about the mistakes and respond with positive changes.

As the poet Emily Dickenson noted:

“If you take care of the small things, the big things take care of themselves. You can gain more control over your life by paying closer attention to the little things.”

This seems an appropriate rationale for incident management in light of the expanding universe of Canadian breach notification laws.