PIA and DPIA — easy to mix up

Hardly a project gets by without personal data: an application form, a CRM migration, a camera at the gate, a model trained on support tickets. Whether that harms anyone is rarely visible from inside the project — and the people it would harm are not in the room. An impact assessment puts the question on the table before the processing starts, while a change to the design still costs little.

Two names are in use for it, PIA and DPIA, and they are often treated as one. They overlap, but they are not the same: one is a method, the other a legal obligation.

What is a PIA?

A privacy impact assessment (PIA) is a systematic process for identifying and evaluating the privacy risks of a project, a programme or a system. It looks at how personal information is collected, used, disclosed, stored and deleted, what that can mean for the people concerned, and which measures bring the risk down to a level that can be answered for.

It is the older term and the wider one. In the United States, the E-Government Act of 2002 obliges federal agencies to carry out PIAs; in most other places a PIA is good practice, described in the standard ISO/IEC 29134 and in the guidance of many supervisory authorities. Its form is for the organisation to choose.

What is a DPIA?

A data protection impact assessment (DPIA) is the assessment that Article 35 of the GDPR prescribes wherever a type of processing is “likely to result in a high risk to the rights and freedoms of natural persons”. The regulation lays down when it has to be carried out, what it has to contain at the least, and who has to be consulted.

Put briefly: a DPIA is a PIA with a legal basis — narrower in its subject, stricter in its form.

PIA vs DPIA: the differences at a glance

In everyday use the line is less sharp than in the table. Many organisations say PIA and mean the assessment under Art. 35, and so do many tools and report templates — the French supervisory authority CNIL calls its DPIA software simply “PIA”. What counts is not the name on the cover but whether the content meets what the law requires.

Complaica is a DPMS software with a ready-to-use Data Protection Kit: a predefined organisational structure, the list of processing activities for Art. 30, catalogues of threats and controls, and pre-made reports for the records of processing activities and the impact assessment.

What PIA and DPIA have in common

The method. Both run through the same four stages, and both are a cycle rather than a document that is written once:

1. Context. Describe the processing: which data, whose, for what purpose, by what means.
2. Controls. Establish the measures that ensure the fundamental principles are observed — necessity, proportionality, the rights of the people concerned.
3. Risks. Assess what can happen to those people, how likely it is and how severe it would be.
4. Validation. Decide whether the level of protection reached is acceptable, and record who decided.

At every stage four things have to be settled:

• the parties: controller, processors and data subjects;
• the nature and the scope of the data;
• the purposes of the processing;
• the requirements that apply — under the GDPR, under other legislation or under both.

When is a DPIA required under the GDPR?

Whenever a type of processing, in particular one using new technologies, is likely to result in a high risk — that is Art. 35(1). Art. 35(3) names three cases in which this is always so:

• a systematic and extensive evaluation of personal aspects that is based on automated processing, including profiling, and on which decisions with legal or similarly significant effects are based;
• large-scale processing of special categories of data, or of data on criminal convictions and offences;
• systematic monitoring of a publicly accessible area on a large scale.

For everything else there are the guidelines of the Article 29 Working Party (WP 248), which the European Data Protection Board has endorsed. They give nine criteria, and as a rule of thumb a processing operation that meets two of them needs a DPIA:

• Evaluation or scoring, including profiling and prediction — of performance at work, economic situation, health, preferences, behaviour or location.
• Automated decision-making with legal or similarly significant effect, which can lead to exclusion or discrimination.
• Systematic monitoring of people, including in publicly accessible areas.
• Sensitive data: special categories such as health data or political opinions, criminal convictions, and data of a highly personal nature.
• Processing on a large scale — measured by the number of people, the volume of data, the duration and the geographical extent.
• Matching or combining datasets that come from different processing operations.
• Vulnerable data subjects: children, employees, patients, the elderly, asylum seekers.
• Innovative use of technology, such as combining fingerprint and face recognition for access control.
• Processing that keeps people from exercising a right or from using a service or a contract.

On top of this come the national lists. Under Art. 35(4) every supervisory authority publishes the kinds of processing for which a DPIA is mandatory in its country; under Art. 35(5) it may publish those for which none is needed. The lists differ, so an organisation that operates in several countries has to check each of them. Our data protection experts help to find out which apply.

What a DPIA has to contain at the least is laid down in Art. 35(7):

• a systematic description of the envisaged processing and its purposes, including the legitimate interest pursued where there is one;
• an assessment of the necessity and proportionality of the processing in relation to the purposes;
• an assessment of the risks to the rights and freedoms of the data subjects;
• the measures envisaged to address the risks — safeguards, security measures and mechanisms that protect the data and demonstrate compliance.

If the assessment shows that a high risk would remain in spite of these measures, the controller has to consult the supervisory authority before the processing starts (Art. 36).

When is a PIA called for?

A PIA belongs at the beginning of a project and accompanies it through its whole life cycle. The guidance of the US Office of Management and Budget on the E-Government Act (M-03-22) lists the typical occasions for federal agencies, and they carry over to any organisation:

• paper records are converted to electronic systems;
• anonymous information becomes attributable to persons;
• an existing IT system is managed in a significantly new way, for instance with new technologies;
• databases holding personal information are merged, centralised or matched;
• authentication technology — passwords, digital certificates, biometrics — is newly applied to a system the public has access to;
• information from commercial or public sources is brought into existing systems;
• data is used or exchanged in a new way across organisations;
• a change to a business process leads to new uses or disclosures of information;
• new items of personal information are added to a collection and raise the risk — health or financial data, for example.

A PIA or DPIA in ten steps

Whichever of the two is due, the work follows the same sequence:

1. Gather the information. Collect what is known about the processing: project brief, data flows, systems, contracts.
2. Involve the people who know. Talk to the business owners, to IT and security, to legal and to the data protection officer.
3. Establish the legal requirements. Which laws, regulations and contracts apply to this processing?
4. Assess lawfulness and necessity. Is the processing lawful, transparent, necessary and proportionate to its purpose?
5. Identify and rank the risks. Where are the gaps, and what would they mean for the people concerned?
6. Seek outside advice where needed. From external experts — and from the supervisory authority where the law requires it.
7. Define the measures. Technical, organisational or contractual changes that reduce the risk.
8. Have the result approved. The findings and the plan are signed off by those who answer for them.
9. Implement the plan. With owners and dates — a measure nobody owns is not carried out.
10. Review and update. At fixed intervals, and whenever the way the data is used changes.

The sequence is a guide, not a form. Small projects pass through several steps in one meeting; large ones repeat some of them more than once.

How to prepare for a PIA

Preparing means gathering precise information on the processing. US federal agencies, for example, record in every PIA under the E-Government Act:

• what information is collected;
• why it is collected and what it is to be used for;
• with whom it is shared, inside and outside the organisation;
• how individuals are informed and how their consent is obtained;
• how the information is secured.

No single person knows all of this. Who is asked depends on the subject: if the assessment is about a marketing platform, the marketing manager can say what business goals the platform serves — and IT, which data it really moves.

How to prepare for a DPIA

A DPIA needs the same facts and, in addition, what Art. 35 asks for in particular. It helps to have the following on the table before the assessment starts:

• The project proposal or brief — it supplies the business context.
• The people concerned — customers, employees, applicants, patients.
• The categories of personal data — from contact details to online behaviour.
• Sensitive data — special categories, or data such as precise location.
• The sources of the data — account creation, tracking cookies, third parties.
• The scope of the processing — local or international, with or without transfers to third countries.
• The third parties involved — vendors, business partners, other parts of the company.
• The privacy notices and policies that apply to the activity.
• The contractual obligations — what the organisation’s contracts say about this processing.
• The measures already in place — the technical and organisational measures the processing can build on.

Much of this is already written down where the records of processing activities under Art. 30 are kept up to date. A well-kept record is the best starting point a DPIA can have.

PIA and DPIA with Complaica

An assessment kept in a text document answers the question once. The processing changes and the document does not — and at the next audit nobody can say which risk was accepted by whom, and when. That is the reason to keep the assessment where the rest of data protection management is kept.

Complaica brings DPMS and ISMS together in one tool:

• Data Protection Kit. A predefined typical organisational structure, the list of processing activities for Art. 30 and catalogues of threats and controls for data protection — you adapt them instead of starting with an empty system.
• Reports for the audit. Pre-made reports for the records of processing activities (Art. 30) and the impact assessment (Art. 35).
• One risk management. Technical and organisational measures from the ISMS are reused in data protection, and identical threats are managed once.
• AI assistant. Complaica supports MCP and connects with ChatGPT, Claude or a locally hosted AI service — to document structures in natural language, or to ask what a requirement demands.
• Integrations. i-doit, GSTool, Jira, SAP, Office 365 and others, or your own systems via the REST API.
• External data protection officer. As a service, by our experts.

Get to know the Complaica DPMS software

Data protection consulting

Where the time or the experience for an assessment is missing, our data protection experts step in:

• DPMS as a service. We help to identify risks, to develop policies and procedures and to improve the security status continuously.
• Data protection analysis. We analyse your data processing and identify the potential risks.
• Data protection implementation. We develop policies and procedures that suit your company, implement them and support the training of your employees.
• Data protection monitoring. Regular reviews keep your data protection concept up to date.
• External data protection officer. Our experts are up to date with the law, so that you stay compliant.
• Support line. From 9 am to 6 pm, for questions on information security and data protection.