The five stages of a full-scale PIA

This section of the handbook provides more in depth advice and guidance on the five phases of a full-scale privacy impact assessment (PIA).

• Preliminary phase.
• Preparation phase.
• Consultation and analysis phase.
• Documentation phase.
• Review and audit phase.

1. Preliminary phase

This is phase one of the five-phase PIA process.

The purpose of this phase is to ensure that a firm basis is established for the PIA to be conducted effectively and efficiently. The suggested deliverables are a project plan and a project background paper.

The following tasks are suggested:

• Review the outcomes and documents from the initial assessment. If necessary, prepare any documents that were not produced during the initial assessment and which might be helpful in completing the PIA.
• Develop the project outline produced in the initial phase.
• Ensure at this stage that the terms of reference, the scope and the resources dedicated to the PIA are appropriate.
• Hold preliminary discussions with relevant organisations. These discussions would generally focus on relevant parts of the organisation itself and any key participating organisations. Early discussions with external organisations, including the Information Commissioner’s Office, may also be advisable in some circumstances.
• Hold preliminary discussions with representatives of and advocates for stakeholder groups. This is likely to be of importance where particular external parties may be significantly affected by the project and what it delivers.
• Conduct a preliminary analysis of privacy issues. This is likely to commence with a deeper re-consideration of the outcomes of the screening process.
• Prepare the project background paper. This document will establish the basis for discussions with stakeholders.

Developing the project outline

You will have produced or got hold of an outline or background paper for the project that is subject to the PIA. The preliminary phase of the five-phase PIA process leads to the development of this project background paper. The following provides guidance in relation to its content.

The purpose of the project background paper is to establish a sound base for the subsequent preparation, consultation and analysis. The project background paper should contain the following, many of which will already exist in some form.

• A description of the context or setting in which the proposal is being brought forward (including relevant social, economic and technological considerations).
• A statement of the motivations, drivers or opportunities underlying the project.
• A statement of the project’s objectives, scope and business rationale.
• A description of the project’s design reflecting the organisation’s current understanding of how the project will take shape. The explanation needs to be at a sufficient level of detail that participants can consider the project’s impacts and implications. The detail available will vary depending on the developmental stage of the project. The design description may be conceptual and sketchy if salient design features have not been pre-determined. If the project has already been through the requirements analysis and design phases, the project background paper can describe the flows of personal information at the appropriate level of detail. These may be placed in appendices containing diagrams that depict process descriptions and lists of items of personal data involved.
• An initial assessment of potential privacy issues and risks, including both obvious or direct impacts and longer-term or secondary impacts on privacy, as perceived by the lead organisation at the time the document is prepared.
• Brief descriptions of options and sub-options that the lead organisation has identified, including both those already dismissed, and those that remain under consideration.
• The business case which explains the justification for the features that give rise to the potential impacts on privacy, expressed both as:
  • an explanation of how the key features of the scheme will achieve the objectives; and
  • a cost / benefit analysis.
• Descriptions of the project plan as a whole, the PIA process within it, and the consultation processes within the PIA.
• Lists of involved organisations, stakeholder groups and representatives and advocates who have been or will be invited to contribute to the PIA.
• Attachments, as appropriate, that will contribute to understanding the project and its potential privacy implications.

The project background paper should contain a clear and well-argued case for the project as a whole, and particularly for those features that have greatest potential for negative privacy impacts. This will help the identification and collaborative examination of privacy risks and, ultimately, in having an effective PIA.

This process of rigorous challenge and justification for privacy-intrusive aspects of schemes should be continued through logical design, to physical design, construction and integration, and on to implementation. This process facilitates the discovery of alternatives to achieve project goals while minimising negative impacts, and the creation of compensating measures to address project features with negative impacts that are judged to be necessary despite their downsides.

Where some of the information is subject to commercial or security sensitivity, that information can be separated into an appendix, which can be distributed less widely and/ or subject to clear confidentiality constraints. This enables the issue to be managed without compromising the openness of the bulk of the information.

There may be resistance within the organisation to providing some of this information to stakeholders. For example, designers may consider that they do not need to give any explanations of the reasons for aspects of the concept or the design that some stakeholders may see as privacy-threatening. The project manager may hesitate to make available the business case underlying particular features or even the project as a whole. This may be in part for understandable commercial or security reasons. On the other hand stakeholder trust needs to be achieved. It is important that information is not withheld because it exposes poor thinking.

Where elements of the document cannot be delivered at the outset, it may be appropriate to distribute the information in two or more instalments. Additional information may be needed in the case of projects that involve technologies that are new, or are otherwise unlikely to be understood by the participants in the consultation process.

To achieve an effective consultation process, the primary sponsor may need to make available technical documentation and briefings, and perhaps demonstrations. Examples of technologies for which this is currently likely to be needed include:

• contact-based smartcards;
• contactless smartcards and RFID tags;
• identity management;
• portals for services and authentication;
• data warehousing and data mining;
• locator technologies; and
• biometrics.