Privacy Impact Assessment Guidelines

Roger Clarke

Principal, Xamax Consultancy Pty Ltd, Canberra

Original of 10 February 1998, latest rev. 25 August 1999

© Xamax Consultancy Pty Ltd, 1998, 1999

This document is at http://www.xamax.com.au/DV/PIA.html

Abstract

This document presents a set of guidelines whose purposes are:

• to guide the preparation of Privacy Impact Assessment (PIA) processes;
• to assist in the evaluation of plans to undertake PIAs: and
• to enable the review of PIA processes that have already been undertaken.

Contents

• 1. Introduction
• 2. Triggers for a PIA
• 3. Objectives of a PIA
• 4. Resourcing of a PIA Process
• 5. Participation in a PIA Process
• 6. Phases of a PIA Process
• 7. Initiation of the PIA Process
• 8. Impact and Implications Analysis
• 9. Cost/Benefit Analysis
• 10. Checklists of Impacts and Implications
• References

1. Introduction

The discipline of technology assessment (TA) is 'the thorough, systematic and balanced identification, analysis and evaluation of the real and potential impacts and implications, both beneficial and detrimental, that a particular technology may have on environmental, economic, social, cultural and political systems and processes' (adapted from OTA 1977, p.10).

Studies of the effects of technologies as a whole are inevitably abstract. They need to be complemented by studies relating to major applications of each technology. Because of the widespread and serious concerns about harm to the physical and biological environment, an environmental impact statement (EIS) has become a requirement for all schemes that may have significant impacts on nature, and hence on people. (Many EIS suffer, however, from being undertaken much too late in the project's life-cycle, after major financial investments have been made, after political commitment to it has been announced, and even after the main design parameters have been determined. A further deficiency is that an EIS tends to be regarded as a product rather than a process).

Many projects have potential impacts that extend beyond the physical environment, and hence social and economic impact assessment is becoming increasingly necessary for large infrastructure projects such as airports, new trainlines and expressways, and bids for major events such as the Olympics.

The impacts of information technology have been steadily increasing during the last 30-40 years. Moreover, the scale and scope of IT applications has been increasing as well. The result is that IT's social and economic impacts in general, and its privacy impacts in particular have become a strategic factor for governments and corporations alike. Clarke (1996) provides guidance to corporations and government agencies in relation to privacy strategy.

Privacy Impact Assessment (PIA) is a process whereby the potential impacts and implications of proposals that involve potential privacy-invasiveness are surfaced and examined.

The primary motivations for the conduct of a PIA are generally some combination of the following:

• to ensure that benefits can be maximised, and that negative aspects can be avoided or ameliorated, variously for:
  • the primary sponsor;
  • other involved organisations; and
  • people affected by the proposal;
• to assure public confidence, and hence:
  • public acceptance and adoption of, the project; and
  • sustained support for the project by all involved orgnisations;
• to pre-empt negative coverage by the media; and
• to avoid unnecessary intervention by legislatures and regulatory agencies.

The nature and scale of each PIA need to be commensurate with the extent and gravity of the proposal's impacts on and implications for privacy. This document provides guidelines for the design of PIAs, focussing primarily on major projects. By 'major' is meant:

• proposals for new schemes that involve large numbers of data subjects, significant amounts of personal data, particularly sensitive data, more than one organisation, new technologies and/or particularly advanced privacy-intrusive technologies; and
• proposals for significant modifications to existing schemes which evidence one or more of the above characteristics.

These guidelines are also relevant to projects that do not qualify as 'major' under the above test, e.g. because they are internal to a single organisation, their scope is relatively limited, they are less grossly invasive, they involve less personal data, and/or they apply mainstream and non-intrusive technologies. In such cases, the guidelines should be considered in full, the relevant aspects should be identified, and a project process should be devised that addresses the needs, but that also reflects the financial and other costs involved.

2. Triggers for a PIA

A PIA is applicable to a proposed or projected scheme that has significant potential impacts on, or implications for, groups of people or organisations other than the primary sponsor. Generally, such a proposal will be likely to involve information technology (IT), but it may involve other kinds of technology as well as or even instead of IT.

The 'primary sponsor' for a proposal may be a corporation, or a government agency, or a partnership or joint venture involving several organisations from either or both the public and private sectors. The term 'other involved organisations' is used to refer to other corporations or government agencies that may be contributers to, or beneficiaries of, the scheme.

The need for the process described here arises from the scale of the proposal's impacts and implications, and is independent of the question as to whether it is a public or private sector initiative. Examples of schemes that are very likely to require PIAs include:

• databases involving personal data, especially where:
  • the data is sensitive;
  • the number of people involved is substantial; and/or
  • the record about each person is intensive;
• identification and identity authentication schemes, especially proposals for multi-purpose identifiers, intrusive identifiers such as biometrics, and digital signature initiatives;
• schemes whose effect is to convert anonymous or pseudonymous transactions into identified transactions;
• smartcard-based schemes;
• location and tracking schemes, e.g. in mobile telephony and other forms of telecommunications;
• intelligent transportation systems; and
• law enforcement and national security information systems, and criminal intelligence systems.

There are several reasons why a PIA process may be initiated. These include:

• a requirement in law;
• appreciation by the primary sponsor, or some other involved organisation, that a proposal has broad and significant implications that should be subjected to investigation. The motivation of the organisation may be public policy, business ethics / corporate citizenship, or a desire to ensure public and consumer confidence and hence insure return on investment; and
• public concerns, perhaps arising from media-fanned rumours about an initiative.

3. Objectives of a PIA

The objectives of a PIA process are likely to include the following:

• to identify the first-order impacts, and the second-order implications, of the proposal;
• to enable the perspectives of the various stakeholders to be developed, to be appreciated by the proposal's sponsors, and to be reflected in the scheme's design features;
• to assure stakeholder groups that their perspectives have been taken into account;
• to enable the design to work towards maximisation of the positive impacts and implications of the scheme;
• to avoid the emergence of new requirements at a late stage in the design process (or, worse still, during construction, implementation, or even operation), when modifications are much more expensive, slower and risk-prone;
• to enable negative impacts and implications of the scheme to be avoided, or at least ameliorated; and
• to be publicly credible, in order to underwrite public confidence in the scheme.

In particular circumstances, additional objectives may exist, such as:

• awareness-raising and education for:
  • executives, managers or operational staff of the primary sponsor and/or other involved organisations;
  • the public generally, its representatives, and/or advocates;
  • regulators and legislators;
• the countering of misinformation; and
• the commitment of advocates and stakeholder representatives to support the project, in order to avoid the emergence of opposition at a late and expensive stage in the design process.

4. Resourcing of a PIA Process

It is highly desirable that the PIA process be performed by the primary sponsor, rather than by a third party such as a government agency, a consultancy, a university, or an ad hoc organisation.

The reasons are that:

• the cost burden thereby falls on the primary sponsor, and hence is factored into the cost/benefit analysis for the project as a whole;
• regulatory agencies are able to participate in the process without losing the independence essential to the performance of their functions; and
• the likelihood is much higher that the primary sponsor will assimilate the messages arising from the process.

Staff allocated to perform the pivotal roles in a PIA need to combine expertise in the relevant technologies, in large-scale project management, in public policy and public policy formation processes, and in public consultative processes. The services of specialist consultants are likely to be needed, to assist with particular aspects of the process.

5. Participation in a PIA Process

The objectives of a PIA cannot be achieved if the process is undertaken behind closed doors. In a complex project applying powerful technologies, there are many segments of the population that are affected. It is intrinsic to the process that members of the public provide input to the assessment, and that the outcomes reflect their concerns.

A PIA needs to involve the following:

• public representation on the PIA steering committee;
• a sufficient diversity of participants to ensure that all perspectives are represented, and all relevant information gathered;
• multiple rounds of:
  • information provision by the sponsor to the public;
  • consultation between advocates and stakeholder groups on the one hand, and the primary sponsor on the other;
• assimilation of the information provided by all parties into the subsequent rounds of activities and consultations; and
• participation by stakeholder groups in the design and implementation activities.

It is useful to distinguish two categories of participant on behalf of people:

• representatives, which have plausible claims to represent the interests of some relevant constituency, and whose credibility hinges on the extent to which they are close to that constituency, and are sense their concerns; and
• advocates, which have plausible claims to understand the nature of the interests of some relevant group of people, and whose credibility is based on the coherence of their evidence and arguments.

In some cases, security considerations may militate against full openness of the consultative processes. In order that public confidence can be engendered, it is essential that:

• the PIA be undertaken in as open a manner as is practicable; and
• in respect of all aspects that are subject to security limitations, proxy measures be devised that are as effective and credible as possible.

At the outset, the primary sponsor should:

• identify the issues that it considers arise from the proposal;
• seek out advocates who claim to have specialist knowledge about the relevant public interests;
• identify the stakeholder groups that it considers likely to be affected by, or concerned about, the proposal; and
• seek out representatives of those stakeholder groups.

It should invite those advocates and representatives to participate in the process; but should also ensure that additional advocates and representatives can become involved, and that members of the public unaligned with any particular group can also participate.

It is important to appreciate that the concept of participation involves more than information-provision, and more than consultation, and that it commences early, and continues throughout the project life-cycle.

6. Phases of a PIA Process

The phases of a PIA process are as follows:

1. announcement. A preliminary statement needs to be published by the primary sponsor to the effect that a proposal is forthcoming, and including outline descriptions of the proposal, and of the nature of the intended PIA process;
2. issue of a conceptual design and issues paper. Information needs to be provided by the primary sponsor, in sufficient detail that other involved organisations, community organisations, members of the public, their representatives, and advocates, can assess its relevance to them. It needs to contain an outline cost/benefit analysis. This is so critical that it is discussed in further detail below;
3. consultations. An initial round of communications is needed, such that interested members of the public can understand the nature of the proposal, and provide semi-formal feedback. This would most commonly take the form of public presentation-and-discussion sessions. These need to be followed by the opportunity for formalised submissions;
4. assimilation. The primary sponsor needs to assimilate the information provided, and to consolidate it into a document that reflects the perceptions of all stakeholders. This document needs to culminate in a statement of requirements that reflects all interests, and is to guide the design of the scheme. It also needs to contain the cost/benefit analysis (see below). The document needs to be published, to ensure that all parties have the information available to them;
5. consultations. Depending on the extent to which commonality of understanding has been achieved, a further round of consultations may be necessary at this stage;
6. logical/functional design. The conceptual design needs to be refined and further developed, such that the key features of the proposed scheme are apparent. This needs to be published, as a basis for further consultations;
7. consultations. A further round of consultations is necessary. Its conduct, intensity and length depend a great deal on the extent to which commonality of understanding has been achieved, and to which the logical design reflects the statement of requirements;
8. detailed design. The logical/functional design needs to be articulated into a detailed design document from which the scheme can be constructed. It is desirable that this document also be publicly available. This may need to be partial, however, because it may involve information of considerable commercial value, and/or it may not be readily understandable by stakeholders. In such circumstances, it is important that the logical design document be updated to reflect the detailed design, and the revised document, including reference to the changes, published;
9. consultations. A further round of consultations is necessary. Its conduct, intensity and length depend a great deal on the extent to which commonality of understanding has been achieved, and to which the detailed design, and the revised logical design, reflect the statement of requirements;
10. construction and piloting. The scheme needs to be developed, and trialled. Advocates and representatives of stakeholder groups need to be involved in the trials, to ensure that the requirements are satisfied;
11. consultations. A further round of consultations is necessary. Its conduct, intensity and length depend a great deal on the extent to which commonality of understanding has been achieved, and to which the piloted scheme reflects the statement of requirements;
12. implementation. The scheme needs to be deployed;
13. post-implementation review. After the scheme has been operational for a short time, a review needs to be undertaken, including the participation of advocates and stakeholder groups, in order to assess the extent to which the statement of requirements has been satisfied, the extent to which the cost/benefit expectations have been fulfilled, and the need for any adaptations of the scheme to reflect the experience gained;
14. audit. Two categories of audit are needed (see Clarke 1997b):
    • periodic audit of compliance with the requirements, e.g. on an annual basis, as part of a broader audit process; and
    • occasional audits, typically in response to incidents, or expressions of public concern, and whose scope tends to reflect the nature of the trigger.

7. Initiation of the PIA Process

The PIA process needs to be primed by the publication of a conceptual design and issues paper. This needs to contain the following:

• a description of the context or setting in which the proposal is being brought forward (including relevant social, economic and technological considerations), leading to a statement of the motivations, drivers or opportunities underlying it;
• a statement of the proposed scheme's objectives;
• the initial conceptual design of the scheme. This should reflect the primary sponsor's current thinking about the matter. It should be at a level such that participants can develop an understanding of the idea and ponder its impacts and implications; but it should not be so advanced or detailed that salient design features have been pre-determined;
• brief descriptions of options and sub-options that the primary sponsor has identified, including both those already dismissed, and those that remain under consideration;
• an outline cost/benefit analysis;
• an outline of first-order impacts and second-order implications, as perceived by the primary sponsor at the time of publication;
• descriptions of the PIA process and of the broader scheme development process;
• lists of involved organisations, advocates, stakeholder groups and representatives who have been invited to contribute to the PIA;
• addenda, as appropriate.

It is vital to the effectiveness of a PIA that the participants have a sufficient understanding of the technologies involved. This may necessitate that the primary sponsor make available technical briefings and documentation. For an example of such a document, see Clarke (1998b).

8. Impact and Implications Analysis

The term 'impact' is used here to refer to a likely outcome of the implementation of the scheme which is a fairly direct result of the scheme's design. Examples include discrimination among individuals based on stored information, refusal of access to benefits or to premises as a result of mis-identification, and non-availability of services due to the failure of critical elements of the infrastructure.

The term 'implication' is used here to refer to second-order effects, which are potential, indirect results of the scheme's design, and are mediated by other factors. Examples include inequities arising from distance, from lack of access to equipment, from lingual inadequacies, and from lack of documentation.

Analyses needs to be undertaken from the differing perspectives of the multiple stakeholder groups. They should be initially outlined, or at least framed, by the sponsor; but it is the role of public interest advocates and stakeholder representatives to articulate and extend the preliminary analyses.

Analyses need to embody comparisons among the present situation, any relevant past situations, and alternative future situations that depend on aspects of the scheme's design.

Consideration needs to be given to alternative future economic and social environments. It may be possible to do this using a structured approach; alternatively, scenario analysis may need to be applied in order to tease out potential second-order effects. Account must be taken not only of inevitable impacts and implications, but also of contingent effects that will only arise under particular circumstances.

Analyses need to identify the loci of the impacts and implications, i.e. what kinds of people or organisations will experience the various effects, and under what circumstances.

Analyses also need to consider relevant legal considerations, including responsibilities that exist in relation to both direct impacts and indirect implications, and contingent liabilities that may arise in the event that risks eventuate.

Analyses need to take into account the options canvassed in the accumulated documentation about the proposal, and identify which options have which impacts and implications.

Analyses also need to identify further options, features and concomitant measures that would avoid, or, where avoidance is not possible, ameliorate the negative implications.

9. Cost/Benefit Analysis

The wide-ranging perceptions of the various stakeholders need to be consolidated into an overall view of the project. The appropriate technique for doing so is cost/benefit analysis (CBA).

CBA is undertaken from the perspective of society as a whole, not from that of any particular individual, organisation or group, and hence considers all gains and losses arising, regardless of to whom they accrue. Its aim is to ensure efficiency in the allocation of resources to society's aims. It is distinguished from financial evaluation, which is conducted from the viewpoint of an individual corporation or government agency. The technique involves the identification of all of the costs and benefits arising in relation to the scheme in question, and to the extent practicable and economic, their measurement. It is also important that the risks and uncertainties involved in the scheme be expressly considered.

A description of CBA, together with references, are provided at Clarke (1995).

10. Checklists of Impacts and Implications

The scope of the privacy concept is often unclear, and even contentious. At Clarke (1997a), it is defined as "the interest that individuals have in sustaining a 'personal space', free from interference by other people and organisations". It has multiple dimensions, relating to the person, personal behaviour, personal communications, and personal data.

Privacy interleaves and interacts with a range of other social interests. This section accordingly provides checklists of both broad social impacts and implications (which might be defined within or outside the scope of any particular PIA), and more specific impacts and implications (which are clearly within the scope of any PIA).

Checklist of Broad Social Impacts and Implications

• availability of service (e.g. 9-5 on workdays, or 24/7)
• reliability of service (e.g. percentage of uptime)
• robustness of service (e.g. recovery time from outages)
• reach of service (e.g. locations from which available)
• accessibility of service (e.g. connection requirements)
• consumer rights impacts (e.g. risk-bearing in the event of malfunction or fraud)
• choice in relation to the use of the scheme as a whole, including benefits foregone if it is not used, and penalties for non-use
• consent in relation to the use of the scheme as a whole, versus legal and/or technical compulsion
• job-market and industry structure impacts
• geographical equity impacts, e.g. differential service depending on location or access to facilities
• social equity impacts, e.g. differential service depending on ethnic background, lingual skills, education or physical limitations

Checklist of Privacy Impacts and Implications

• privacy of the person
• privacy of personal behaviour
• privacy of personal communications
• privacy of personal data:
  • collection
  • storage
  • quality assurance
  • primary uses
  • any disclosure to or access by third parties
  • any secondary uses (e.g. for matching or profiling)
  • access by the data subject
• identification, anonymity and pseudonymity
• multiple-use identification
• conversion of anonymous transactions to identified form
• choice in relation to features of the scheme, including benefits foregone if it is not used, and penalties for non-use
• consent in relation to the use of features of the scheme, versus legal and/or technical compulsion

References

Clarke R. (1995) 'Computer Matching by Government Agencies: The Failure of Cost/Benefit Analysis as a Control Mechanism', Informatization and the Public Sector (March 1995), at http://www.anu.edu.au/people/Roger.Clarke/DV/MatchCBA.html#CBA

Clarke R. (1996) 'Privacy and Dataveillance, and Organisational Strategy', Proc. Conf. I.S. Audit & Control Association (EDPAC'96), Perth, 28 May 1996, at http://www.anu.edu.au/people/Roger.Clarke/DV/PStrat.html

Clarke R. (1997a) 'Introduction to Dataveillance and Information Privacy, and Definitions of Terms', at http://www.anu.edu.au/people/Roger.Clarke/DV/Intro.html

Clarke R. (1997b) 'Information Systems Audit & Information Privacy', 1997, at http://www.anu.edu.au/people/Roger.Clarke/DV/Audit.html

Clarke R. (1998a) 'Privacy Impact Assessments', February 1998, at http://www.anu.edu.au/people/Roger.Clarke/DV/PIA.html

Clarke R. (1998b) 'Smart Card Technical Issues Starter Kit', Centrelink, April 1998, at http://www.anu.edu.au/people/Roger.Clarke/DV/SCTISK.html

OTA (1977) 'Technology Assessment in Business and Government' Office of Technology Assessment, document #PB-273164, January 1977, at http://www.wws.princeton.edu/~ota/disk3/1977/7711_n.html

Navigation

Go to the Xamax Consultancy Home-Page.

Send an email to Roger Clarke

Created: 10 February 1998

Last Amended: 25 August 1999

Xamax Consultancy Pty Ltd, ACN: 002 360 456
78 Sidaway St
Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 1472, 6288 6916
Roger.Clarke@xamax.com.au