What it is
A privacy impact assessment (PIA) is a structured review of how a planned project, system or change will affect the privacy of the people whose data it touches. The goal is to find problems while they are still cheap to fix, on paper and in design discussions, instead of after launch when changing the system is expensive and people may already have been affected.
Some laws use related names, such as data protection impact assessment, and may make an assessment mandatory for certain high-risk activities. The details depend on the jurisdiction, so check with whoever handles legal and compliance matters. This article describes the general idea and is not legal advice.
When to do one
The sensible time is early, once the project’s purpose is clear but before key decisions are locked in. Typical triggers include:
- building or buying a new system that handles personal data
- starting to collect new categories of data, especially sensitive ones
- using existing data for a new purpose
- large-scale monitoring of people, such as employee tracking or location data
- automated decisions that significantly affect individuals
- combining data sets from different sources
- moving data to a new vendor, a new cloud arrangement or a different country
- processing data about children or other people who may be vulnerable
Many organizations use a short screening questionnaire to decide whether a full assessment is needed. Low-risk changes get a quick check; higher-risk ones get the full treatment. This keeps the process from becoming a bottleneck.
What goes into one
Formats vary, but most assessments cover similar ground.
1. Describe the project. What is being done, why, and by whom? Which systems, vendors and teams are involved?
2. Map the data. What personal data is collected, from whom, and how? Where does it flow, where is it stored and who can see it? Drawing a simple diagram of the data flow is often the most valuable part. It helps to apply data classification labels here.
3. Check necessity and proportionality. Is each data item needed for the stated purpose? Could the aim be met with less data, or less identifying data? This is where data minimization is tested. Is there a lawful or otherwise justified basis for the use, and will people be told about it clearly?
4. Identify risks to individuals. The focus is on harm to people, not only to the organization. Examples include unwanted exposure, discrimination, identity theft, loss of control over information, being tracked or profiled without expectation, and decisions based on wrong data. Consider both likelihood and severity, and keep in mind that the answers are judgments, not measurements.
5. Consider security and third parties. Are access controls, data encryption, logging and backup arrangements suitable for the sensitivity of the data? Are vendors bound by contracts, and are third-party sharing questions answered?
6. Plan for rights and retention. Can the organization answer data subject requests for this data? How long will it be kept, and how will it be deleted?
7. Decide on measures. For each significant risk, list ways to reduce it, such as dropping a field, restricting access, shortening retention, adding notices, adding human review, or choosing a different design. Note any risk that remains and who accepts it.
8. Record and sign off. The privacy lead, project owner and sometimes a senior manager review the document and approve, request changes or stop the project.
A short set of starter questions
For a small team without a template, these questions work as a first pass:
- What is the purpose, in one sentence?
- What personal data will be used, and is each item necessary?
- Who will have access, and why?
- Where will the data be stored, and who else will receive it?
- How will people be informed?
- How long will it be kept?
- What is the worst realistic thing that could happen to a person if this data were exposed or misused?
- What would we do if that happened?
Writing honest answers often exposes assumptions nobody had examined.
Who should be involved
A PIA done by one person in isolation tends to miss things. Useful participants include the project owner, an IT or security representative who knows the technical design, someone responsible for privacy or legal matters, and where relevant, the business users and a vendor contact. Where the project affects employees or customers in a significant way, some organizations also seek their views.
Linking to other processes
The assessment overlaps with the wider risk assessment and IT governance work. Its findings can feed the project’s requirements, change management approval, and vendor selection. After launch, the document should not be filed away: revisit it when the system changes, when new data is added or when an incident shows that an assumption was wrong. If an incident does occur, the assessment helps the incident response team understand what data was involved.
Common pitfalls
- Treating it as paperwork. A form completed at the last minute to get approval adds little. The value comes from discussion and from changing the design.
- Starting too late. If the system is already built, only cosmetic changes may be possible.
- Focusing only on compliance. Meeting a legal minimum does not necessarily mean people would be comfortable with the use.
- Ignoring the outcome. Recommended measures must be assigned to someone and tracked.
- Making it too heavy. A long process for every minor change leads teams to skip it. Match effort to risk.
A good assessment leaves the team with a clearer, safer design and a record of why decisions were made, which is useful long after the project is delivered.