Full-Scale PIA – Background information

This segment provides answers to some questions that an organisation about to conduct a PIA may pose. The topics addressed are:

• Why do a Privacy Impact Assessment?
• What triggers a PIA?
  
• When to do a PIA
• What is and is not a PIA?

Why do a Privacy Impact Assessment?

Public trust in its institutions is generally felt to be in decline, with individuals tending to feel distanced, alienated and even disengaged. Government and corporate reputations can be fragile and easily undermined. In order to maintain and enhance their reputations these organisations need to act responsibly in relation to key issues like privacy, and to be seen to be acting responsibly. Experience shows that once an organisation’s reputation is damaged and trust is lost it is then very hard to regain that trust.

There are much more concrete and specific reasons to do a PIA. Organisations take considerable care to manage a variety of risks, including competitive manoeuvres by other corporations, natural disasters, environmental contamination, cyber-attacks, and the risk of embarrassment to executives and Ministers. 'Issues management' has emerged as a common activity based on contingency planning.

For many organisations, privacy now represents risks which need to be as professionally managed in a similar way to other categories of risk. Organisations that handle personal data need to monitor their ongoing operations, whether they are dealing with clients, employees, or the public in general.

Of particular significance are new initiatives, especially ones that deploy advanced technologies which bring both new opportunities and new threats.

In summary, the reasons an organisation undertakes a PIA are as follows:

• The avoidance of loss of trust and reputation
• The identification and management of risks
• Cost avoidance
• Meeting and exceeding legal requirements

The Avoidance of loss of trust and reputation

Customers value privacy. A PIA is a means of ensuring that systems are not deployed with privacy flaws which will attract the attention of the media, competitors, public interest advocacy groups or regulators, or give rise to concerns among customers. In this context a PIA will help to maintain or enhance an organisation’s reputation.

The identification and management of risks

The kinds of projects that give rise to privacy concerns generally involve a considerable amount of effort and investment.. Company Directors and the senior executives of government agencies are responsible for ensuring that risks are identified, assessed and managed. That responsibility extends to checking whether privacy issues exist. If that is the case, then the risks need to be assessed, and a risk management plan needs to be devised and implemented. In short, at senior levels of organisations, a PIA is part of good governance and good business practice.

At project management levels, a PIA is a means of addressing project risk. Risk management has considerably broader scope than privacy alone; so organisations may find it appropriate to plan a PIA within the context of risk management. Apart from business publications and textbooks on the subject, a formal standard exists: ISO/IEC 27001:2005 (formerly BS 7799-2:2002).

One small but important part of privacy protection is information security, and some aspects of a PIA need to reflect this. This area is well-supported by text-books, business publications, and formal standards (e.g. ISO/IEC 27002:2005, formerly ISO/IEC 17799:2005).

Cost Avoidance

By performing a PIA early in a project, an organisation avoids problems being discovered at a later stage, when changes and the 'retrofitting' of features are much more expensive. Making clear a project's objectives, the organisation's requirements and the justifications for particular design features all have important benefits for project management generally, rather than just as part of privacy impact assessment.

A further benefit of building privacy-sensitivity into the design from the outset is that it provides a foundation for a flexible and adaptable system, reducing the cost of future changes and ensuring a longer life for the application.

Meeting and exceeding legal requirements

The Data Protection Act already stipulates eight Data Protection Principles, but these only address certain aspects of privacy.

There are other dimensions, and with modern business practices and technologies some or all of these may come into play as well.

• Privacy of the person. Examples of the kinds of issues that arise are bodily intrusions (e.g., demands for bodily fluids, or for submission to biometric measurement), and threats to personal safety. Physical safety is of particular concern to persons at risk)
• Privacy of behaviour. Common issues in this area include CCTV, substance-abuse testing, and the surveillance of people's physical and electronic activities
• Privacy of communications. This relates to such issues as the monitoring of conversations, the interception of messages, traffic analysis and access to recorded and stored messages

Where the project affects these dimensions of privacy, and the public may be concerned about it, it will be to the organisation's advantage to define the scope of the PIA to extend beyond information privacy.

What triggers a PIA?

The need for a Full-Scale PIA may be triggered in several ways.

• A PIA may be a requirement in law. At present, there are no laws requiring a PIA in the U.K. at the time of writing this handbook.
• A PIA may be a requirement of Government organisational policy. For example, it might be stipulated that one be performed prior to approval of the detailed design phase of a particular project or a particular category of projects, or of funding for product acquisition or system development work
• The organisation conducting a project, or some other participating organisation, may appreciate that a proposal has significant implications that should be the subject of investigation. The motivation of the organisation may be public policy, business ethics / corporate citizenship, or a desire to achieve public and consumer confidence and hence ensure return on investment
• There may be existing public concerns about the particular proposal or about proposals of that kind, perhaps arising from stories which have appeared in the media.

The most common trigger for a PIA, however, is that the lead organisation, or perhaps some other participating organisation, considers that a proposal may give rise to public concerns, which would represent significant project risk. To address this, a risk management plan is called for.

When to do a PIA

Making any kind of change to specifications, and fixing any kind of error, requires re-work which incurs delays and costs, and because it is error-prone it risks even more work afterwards. The cost of making changes increases rapidly the later in the project they are made. Therefore, privacy-protective features should be designed into a system, rather than “bolted-on” later.

In order to achieve that, the following guidelines are suggested.

• Start early to ensure that project risks are identified and appreciated before the problems become embedded in the design
• If possible, commence a PIA as part of the Project Initiation Phase (or its equivalent in whichever project method the organisation uses)
• If the project is already under way, start today, so that any major issues are identified with the minimum possible delay

A PIA can be conceived and conducted as a one-time activity. If so, it takes into account the information available about the project at the time, and feeds ideas forward into the design. But it cannot reflect information, often of a more detailed nature, that becomes available at a later stage.

A PIA can be conceived and conducted as a stand-alone activity, alongside the project and separate from it. This may, however, create distance between the staff conducting the PIA and the project team, and resistance to insights arising from the PIA by designers and other project team members.

However, particularly in major projects, the most beneficial and cost-effective approach may be to conceive of the PIA as:

• a cyclical process
• linked to the project's own life-cycle
• re-visited in each new project phase

Each version can then take account of both the more detailed specifications that are currently available for the scheme, and the outcomes of previous phases of the PIA. More specifically, later versions can correspond with the later phases of the project (e.g. requirements analysis, logical design, physical design, construction, integration and deployment of the new system, or their equivalents in whichever project method the organisation uses).

Finally, the organisation may conduct a more general risk assessment as part of the project, or may have generic risk management processes in place. If so, consideration should be given to undertaking the PIA within the context of a broader risk management framework.

What is and is not a PIA?

Privacy Impact Assessment is usefully defined as a process whereby a project's potential privacy issues and risks are identified and examined from the perspectives of all stakeholders, and a search is undertaken for ways to avoid or minimise privacy concerns.

A PIA is a tool for executives and management. The organisation needs to know what the problems are, and how to devise solutions to them. In particular, the organisation needs to ensure that the people affected by the initiative are comfortable with the shape that the new initiative is taking. Measures are needed to ensure that the media doesn't misunderstand or misrepresent the initiative in ways that could harm the undertaking. To achieve these ends, a PIA adopts a risk management approach to privacy issues.

As a management tool, a PIA is most effective if it is undertaken in a systematic manner, is commenced at an early stage in the process, and is oriented towards process rather than outputs.

Although the PIA process takes the Data Protection Act and other relevant laws into account, it does not focus on them. A complementary process is needed to ensure that the project is legally compliant. That process can begin early, but cannot be finalised until late in the project life-cycle, when the design is complete. Separate guidance is provided in this Handbook relating to the conduct of compliance checking. The cost and delay involved in compliance checking need not be great, because the process draws heavily on work undertaken during the course of a PIA.

Finally, a PIA needs to be distinguished from a privacy audit. An audit is undertaken on a project that has already been implemented. An audit is valuable in that it either confirms that privacy undertakings and/or privacy law are being complied with, or highlights problems that need to be addressed. To the extent that it uncovers problems, however, they are likely to be expensive to address and may disturb the conduct of the organisation's business. A PIA aims to prevent problems arising, and hence avoid subsequent expense and disruption.