We have all heard the well worn joke about the manager who commands “I need a complete list of the unknown problems that may occur”. Well if you work in IT operations or security, you may soon have to be able to produce that list.
On June 18th, most aspects of the “Digital Privacy Act” came into force. The “Digital Privacy Act” is a set of amendments to the federal “Personal Information Protection and Electronics Documents” Act, more commonly known as PIPEDA. While many organizations are not directly subject to PIPEDA, these acts set the standard of behaviour for organizations in Canada, so you should be aware of them regardless if your organization directly falls under their mandate.
The Digital Privacy Act (DPA) updates several aspects of privacy practices:
- It establishes that an individual’s consent to use their personal information is only valid when it has been collected in such a way that the individual providing the consent fully understands the consequences. It enables the exchange of personal information without consent of the individuals involved when related to criminal and fraud investigations, including the exchange of information between private organizations.
- It provides for the exchange of personal information between organizations, without consent of said individuals, for the purpose of finalizing business transactions
- It establishes the requirement for organizations to inform an individual when their personal information has been disclosed in a way that could cause the individual significant harm
- It requires that organizations “keep and maintain a record of every breach of security safeguards involving personal information under its control”
All aspects of the DPA are now in force with the exception of the requirement to inform an individual when their data has been disclosed. This requirement will come into force once the relevant regulations have been drafted, which is ongoing.
The challenge
While there will be challenges addressing all these changes, it is the last one, “keep and maintain a record of every breach of security safeguards involving personal information under its control” that I want to focus on.
The intent of this provision is well meaning, and of course related to enforcement of the requirement for disclosure. Without this provision in place, the simplest and cheapest solution to the requirement to disclose breaches would be blissful ignorance. How could we inform somebody of something that we did not know about? A record of breaches provides evidence that the organization is actively managing and auditing it’s privacy compliance, and provides a basis to determine if the assessment of potential impact to individuals from any breeches were appropriate.
The problem is that unless you have the good fortune to deal with very good natured, or exceptionally incompetent, data criminals, in most cases you will discover the potential of a breach, not the actual evidence of one. It is important to note that the wording is “breach of security safeguards”, not “breach of data access”; the intent is to record the possibility of a breach, and not just when concrete evidence of a breach is found. It is going to be a challenge for organizations to establish the criteria for including items in this record.
Some events will obviously need to be included; for example the loss of an unencrypted laptop or portable storage device. If someone finds your customer records on a warez site, obviously that needs to be included. However most events are not so obvious as to whether they need to be included, and yet are potentially more serious.
For example, consider a failure in access management. Joe is in customer service, and has access to a wide range of personal information. He is transferred to human resources, but his access to personal information required in his former role is not revoked. Once this is discovered, it will need go into the record as a breach.
It is tempting to take the approach that only confirmed breaches go into the record; i.e. the lost laptop. The problem with this approach is that if a breach occurs, your organization does not detect it, and someone makes a complaint to the Privacy Commissioner resulting in an investigation, then this minimalist approach will not provide any evidence of good intent, and will take the investigation down an antagonistic path that no-one wants.
Good security management is proactive, and inclusive. Everyone in IT and business should be encouraged, and supported, to be on the look out for anomalies, issues, and potential improvements. It is of some concern that the requirement to record any breaches will put a chill on this kind of culture. If raising a potential security issue is going to result in an investigation, a lot of paperwork, and a public record of some business groups incompetence, it is going be awfully attractive to invoke Douglas Adams’ “somebody else’s problem” field.
The response
The specifics of how to respond to these requirements will need to wait on the publishing of the regulations. However, there are actions that should be started today:
- Be proactive in engaging your organizations security and privacy leadership on this issue. IT will want to be at the table from the beginning, in order to ensure that operational practicalities are considered when establishing the organizations response
- The accountability for these requirements likely will not, and probably should not, rest with IT. However the hands on work, and much of the cost, will end up with IT. One group setting the requirements, while a separate group carries the cost, is a classical way to end up with a very ugly situation.
- Accept that there is no definitive response to these requirements. The decision as to the investment made to secure compliance, and the risk level that the organization is willing to accept, will be entirely in the political realm, not the technical. It will be a challenge to engage senior management so that that they can make informed decisions.
- Keep the process as lightweight as possible. Remember, it is the presence of the record that is important, more than the contents. The problem with this process is that the organization can never be assured that the record is correct. The beauty of this process is that no one else can tell if it is correct either.
- Use this as another item in the business case to formalize and automate identity and access management. Organizations that can demonstrate they were proactive in identity and access management, and can produce the audit logs and rigorous records that an automated system provides, will be seen in a much more positive light if it comes to an investigation by the Privacy Commissioner.
While good politics, and probably well-intentioned, it is unfortunate that the requirement to record privacy breaches, and the associated requirements for disclosure, have been encoded into law. Most organizations, once they are aware of an issue of this nature, will do the right thing simply for the sake of good public image and customer relations. That these practices had to be encoded into law is an unfortunate reflection of the unprofessional practices of a few. What is left us now is to find creative and pragmatic ways to meet these requirements while minimizing the cost and disruption to our organizations.
