Media Centre

Demystifying Privacy Impact Assessments

Canadian Access and Privacy Association Annual General Meeting

November 23, 2004
Ottawa, Ontario

Presentation by Stuart Bloomfield
Project Manager, Privacy Impact Assessment
Office of the Privacy Commissioner of Canada

Introduction

It is a pleasure to be here today to share with you our understanding of and experience with Privacy Impact Assessments (PIAs) which federal government departments and agencies are now required to conduct on new programs and services that "raise privacy issues."

Given the nature of this audience I presume that most if not all of you will have some familiarity with PIAs already. For this reason I will not in the limited time available to me discuss at length the rationale for conducting PIAs, but rather focus on some practical tips or rules of thumb that you can draw on in preparing your PIAs.

What is a Privacy Impact Assessment?

Understanding what an instrument is designed to do is a precondition for its effective use. Try drinking soup with a fork and you will see what I mean. The same principle or rule of thumb applies to PIAs which are themselves instruments, albeit analytic instruments.

So what is a PIA? A PIA is first and foremost a risk management tool. Like environmental impact assessments which were pioneered in the 1970s, PIAs serve as a clarion to alert decision makers about potential privacy risks associated with planned information management systems, thereby providing decision makers with an opportunity to remove or mitigate those risks prior to project implementation.

Privacy and security risks are identified by documenting specific design elements or operational features of a given program or service — what information is collected, how it is used, to whom the information is disclosed, etc — and matching these elements/features against a set of privacy best practice principles, which you will find articulated in the Treasury Board Guidelines.

The aforementioned reference to "privacy best practice principles" is significant because it speaks to one of the things that distinguish a PIA from a legal compliance audit. While strict compliance with the law forms the basis of any privacy risk analysis, the PIA Policy asks decision makers to think beyond the letter of the law.

The point I wish to make here can best be illustrated by example. It is a fundamental tenet of privacy that only information necessary to perform a specific activity be collected from individuals. This is somewhat different from the requirements of the federal Privacy Act, which merely demands that information collected "directly relate to a government operating program or activity."

Information collected may directly relate to a government program or activity, but that does not mean it is absolutely necessary. PIAs ask decisions makers to justify the collection of personal information not simply in reference to established legal requirements, but operational requirements as well.

The role of individual consent in the collection of personal information presents another example of how PIAs differ from a strict legal compliance audit. Under the Privacy Act consent is not expressly mentioned as a requirement for the collection of personal information because the authority to collect derives from the law, not from the individual.

This ought not to preclude departments from soliciting the consent of clients regarding the mode of collection where there are options — say between submitting information to government electronically or by regular mail. Different channels of communication engender different security and privacy risks, and respect for the consent principle demands that individuals under such circumstances be provided with a choice.

On the subject of information security, but for a reference to the duty to only use personal information for an administrative purpose that is "accurate and up-to-date," the Privacy Act is silent on the subject of information security. Here again the PIA Guidelines require decision makers to think beyond the letter of the law, testing the compliance of their projects and programs against best practice principles and policy standards.

Assessing compliance with these privacy best practice principles is accomplished by essentially asking questions. Does, for example, the department have the requisite legal authority to collect, use and disclose the information contemplated for the program? Is the information demonstrably necessary to fulfill the stated purpose of the initiative? Are security safeguards appropriate to the sensitivity of the information involved?

If answers to any of these questions are negative, then you have identified a privacy risk which requires remedial attention. It is by following this approach — assessing the extent to which design and operational elements of a program comply with privacy best practice principles — that privacy risks emerge, thus providing decision makers with an opportunity to avoid potentially costly and embarrassing future privacy problems.

If there is any doubt about just how costly and embarrassing non-compliance with privacy best practices can be, I need only remind you of the public outcry that erupted over Human Resource Development Canada's (HRDC) Longitudinal Labour Force File (LLFF) which eventually led to its demise at considerable cost to HRDC.

The LLFF was not was found to be problematic for failing to comply with the law, but for reasons of transparency and accountability, or rather the lack thereof. Arguably, had a PIA been done on the LLFF, HRDC could have been spared the adverse publicity and financial losses it suffered as a result of the incident.

When to Conduct a PIA?

The first and perhaps one of the most challenging tasks confronting decision makers in complying with Treasury Board's Policy on PIAs is to determine whether a given initiative actually warrants a PIA. The Policy itself lists several indicators that would trigger the need for a PIA. These include:

• a new or increased collection, use or disclosure of personal information;
• a shift from direct to indirect collection, new data matching or increased sharing of personal information;
• significant changes to the business processes or systems that affect the physical or logical separation of personal information or the security mechanisms used to manage and control access to personal information;
• contracting out or devolution of a program or service to another level of government or the private sector.

Evidence of any of these modifications to program design or delivery would, in all likelihood, signal the need to conduct a PIA. That said evidence thereof may not in itself be determinative of whether a full PIA is needed — that call is made on the basis of an assessment of the magnitude of impacts on privacy flowing from these modifications.

The Role of PPIAs

This leads me to the subject of so called Preliminary Privacy Impact Assessments or (PPIAs). Treasury Board's Policy on PIAs encourages departments and agencies to consider conducting PPIAs "if they do not yet have the detailed information required for a comprehensive assessment." The Policy further encourages departments to share these PPIAs with our Office for review and comment.

While the idea of providing our Office with a "heads-up" on new initiatives has merit, we have come to question the utility, at least in some instances, of providing us with project proposals whose design elements and features are not yet known. In these cases, PPIAs often amount to little more than incomplete PIAs, which are difficult to review or provide any meaningful comment on.

In my view, and this is a view forged from personal experience dealing with these submissions, PPIAs are most useful as an aid in determining whether a full PIA is needed, especially where the need for a PIA may not be readily apparent.

PPIAs are basically abridged PIAs, the difference between the two being essentially one of detail. Notwithstanding the differences in detail, the purpose of both PPIAs and PIAs is essentially the same — risk identification and risk mitigation.

The process of conducting a PPIA is also the same — testing the compliance of program design and operational elements against established privacy best practice principles. Again, it is through this process — asking questions — that hidden privacy risks come into relief. Whether a full PIA follows will, of course, depend on an assessment of the nature and extent of those identified risks.

Where the risk identified is of a discrete nature — say applying to notice of purpose only — there may be no need to proceed with a full PIA because the nature of the problem lends itself to an easy remedy. Proceeding with a full PIA would, under such a scenario, generate little value added. Used in this way PPIAs can prove a useful tool in identifying and addressing minor privacy risks in a cost efficient way.

Departmental Review of Project Proposals

While the PPIA questionnaire template provides the framework for risk identification, as well as mitigation, the decision whether to proceed with a full PIA ultimately comes down to assessment of the nature and magnitude of the privacy impacts associated with each risk. Here the input of a department's ATIP, IT and legal services branches can be of assistance, all of which speaks to the need for some formalized structure for reviewing project proposals.

Some departments, the large ones with significant personal information holdings, have recognized this and have established committees, composed of personnel from a variety of professions, charged with reviewing project proposals and deciding whether they warrant a PIA. We think that this kind of systematic and institutionalized approach to the review of project proposals makes sense and ought to be emulated by other departments.

In-House vs. Out-of-House Expertise

Once a decision has been made to proceed with a PIA, the next step is to decide whether to conduct the assessment with "in-house" expertise or "out-of-house" expertise. Whether you decide to go one way or the other will depend on several factors — availability of financial resources, availability of in-house expertise, time, etc.

The decision need not come down to a stark choice between one or the other. As the Policy states, the conduct of a PIA is a co-operative endeavour, requiring a variety of skill sets. Some of these skills will be available in-house, while others may not. The important thing is to recruit the right skills necessary to do the job well, and this may, in some instances, require engaging the services of out-of-house expertise.

Role of the Office of the Privacy Commissioner of Canada

The Policy, of course, requires departments to supply our Office with all PIAs conducted. The rationale for doing so is two fold: 1) to provide departments with the benefit of an independent and authoritative opinion on their work, and 2) to alert the OPC about new initiatives that raise potential privacy issues for future compliance monitoring purposes.

Our role in this exercise, and I want to stress this, is not to approve or reject project proposals. Our role is to determine whether or not departments have done a good job in identifying and assessing the risks associated with a given initiative, and to provide advice where circumstances warrant.

What does our Office look for when reviewing a PIA submission — several things:

• we will want to make sure that the department has the requisite legal authority to collect, use and disclose the information, demonstrated by citing the relevant provisions of the law and, where necessary, backed by a legal opinion;
• we will want to ensure that the PIA is very clear about the amount and type of personal information that will be collected, how it will be used, and to whom it may be disclosed. The usual result of this exercise is a high-level description of the business process;
• we will want to satisfy ourselves that the privacy risks associated with the initiative have been identified.

To this end decision makers should pay particular attention to:

• • departmental policies and practices dealing with notice and consent;
  • departmental policies and procedures dealing with transaction monitoring;
  • departmental policies and procedures relating to access controls, such as user profiles, user authentication procedures, password management;
  • departmental standards relating to electronic and physical security controls, such as the use of firewalls, intrusion detection software, and on-site access protocols;
  • departmental standards relating to transmission security, such as the use of encryption;
  • departmental policies and procedures relating to system failure or breach of security;
  • departmental policies and practices relating to the inclusion of privacy and security protection clauses in contracts with third party service providers; and
  • departmental policies and practices relating to the inclusion of privacy and security protection clauses in information sharing agreements.
• we will want to satisfy ourselves that all the risk mitigating measures proposed are reasonable and appropriate. Risk mitigating measures must directly address the risk identified; and
• we will want to know what the department ultimately intends to do to mitigate the risks identified. Remember, a PIA is not an end in itself, but rather a means to achieving an end — namely a project that is compliant with privacy best practice principles

To assist us in conducting our review of the PIA, we would encourage departments to include in their submission certain background documents. These include the following:

• Legal opinions where legislative authority may not be self evident;
• Provisions dealing with privacy and security in agreements, where third party participants are involved;
• Threat and Risk Assessment (TRA) reports, where new information management systems are involved;
• Project feasibility studies, where conducted to support a business case;
• Project management plans as they relate to program or project administration; and
• Departmental policies and procedures governing the collection, processing, access, transmission, storing and disposal of personal information.

Ready access to these documents can significantly expedite the review process, and I again would urge departments to include them in their submissions where relevant.

Although the TBS Policy does not require the OPC to respond to or provide advice on all the submissions we receive, we are committed to doing so. Some of you who have had experience dealing with our Office on PIAs, especially lately, may have noted some delays in receiving comments from us. This I can't deny, but it is not indicative of an abrogation of our responsibility under the Policy.

Just as departments have struggled to comply with the Policy's requirements without additional resources, so have we at the OPC. When the Policy was launched in May 2002, a division with was set up in the Office's compliance audit branch with the mandate to review and provide comment on PIA submissions. This division had a staff complement of five persons, drawn from other branches within the OPC.

Through attrition that staff complement has been reduced to one — ME — and my responsibilities are not confined to reviewing PIAs. This has all occurred at a time when there has been a steady increase in the volume of PIA and PPIA submissions to our Office.

Under the current circumstances we cannot guarantee that comments on submissions will be delivered within time frames that are meaningful to departments. We are concerned that this might impact adversely on our credibility as a timely source for advice, as well as on the effectiveness of the Policy itself. I would like to take this opportunity to reassure you that OPC is working with the Treasury Board to remedy the situation. However, it may be some months before we are fully staffed again. Until then all I can do is ask for your patience and understanding.

Assessment of the PIA Policy

Notwithstanding continued uncertainties regarding the appropriate interpretation of some of the provisions within the Policy and its Guidelines; notwithstanding evidence that departments continue to make certain errors in their analysis; and notwithstanding the constraints that we at the OPC currently face in providing advice to departments on their submissions, the Policy has, in my view, been an enormous success.

Indeed, I can think of no other initiative launched by the federal government, apart from the enactment of the Privacy Act itself, which has had such a significant impact on increasing awareness of the importance of privacy in the federal public service as has the PIA Policy.

Departments can no longer create new databases, link information holdings, enter into information sharing arrangements with other departments or launch new programs or services without considering their potential impact on privacy.

The Policy, having engaged the attention of departmental personnel at all levels, from the Deputy Minister to the front-line service provider, has made an important contribution to ensuring that privacy is truly a core consideration in the conception, design and implementation of government programs and services. This is a very significant achievement whose impact cannot be understated.

Thank you.