Full-Scale PIA - Project background paper

The preliminary phase of the five-phase PIA process leads to the preparation of a project background paper for the project that is subject to the PIA. 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 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 primary sponsor at the time the document is prepared.
• Brief descriptions of options and sub-options that the primary sponsor 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:
  • a 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
• biometrics