PIAs, DPIAs, and death by spreadsheet

As a founder, I fuss about our website. Page speed, whether a paragraph reads clearly, whether we explained the product without over-explaining it. So I spend time in Search Console, reading the queries that bring people to us.

One of them stopped me. "Top PIA solutions avoiding months of tedious spreadsheet wrestling with compliance templates." That was the whole search. Nothing strange about it, except the frustration behind it was impossible to miss. I really doubt a machine reading that line would feel it, but I did.

I know this ground well, because we build compliance software for European companies and for firms outside Europe that sell into it. So let me actually answer the person who typed that.

I will not attempt to explain the whole process here. I will help you understand whether you need a DPIA, what it must contain, who signs it, and what happens if you ignore it. That is the question you have right now, isn't it?

PIA and DPIA are not the same thing

PIA is the generic term. A privacy impact assessment is a structured way to find and reduce the privacy risk in a project before it goes live. It is jurisdiction-neutral, and it predates GDPR. It grew up in Canada, Australia, and the US federal E-Government Act of 2002, and it has an international standard, ISO/IEC 29134.

DPIA is the European one with teeth. GDPR Article 35 created it as a legal instrument, not a nice-to-have. It is mandatory whenever processing is "likely to result in a high risk to the rights and freedoms of natural persons". Three cases trigger one on their own: large-scale profiling that has real effects on people, large-scale processing of special-category data such as health or biometrics, and large-scale monitoring of a public space. Article 35(7) then fixes the minimum content: a systematic description of the processing, a necessity and proportionality check, a risk assessment, and the measures to address those risks. You sign it off as the controller, and where you have a DPO, Article 35(2) says you must take their advice first. So a DPIA is a PIA with a fixed legal shape and a fine attached.

Why this bites harder in Europe

GDPR runs on accountability. Being compliant is not enough, because you also have to be able to show it. Article 30 makes almost every company that processes personal data keep a structured record of that processing, the RoPA. Article 35 makes you assess high-risk processing before it starts. Article 36 makes you consult the supervisory authority when a high risk still remains after your mitigations.

Skipping a required DPIA is itself an infringement. Article 83(4) sets the ceiling at 10 million euros or 2 percent of worldwide annual turnover, whichever is higher, and it is measured against the whole group, not the in-scope subsidiary. If your group turns over hundreds of billions, 10 million euros is a rounding error, but 2 percent of that is a number that hurts.

And the DPIA and the RoPA are usually the first documents a regulator asks for, in any audit or after any complaint. They are the paper that proves you did the thinking.

The part most tools ignore: the lists are national

DPIA duties are European in law and national in practice. Each supervisory authority publishes its own list of processing that always needs a DPIA. Germany's DSK has one, France's CNIL has another, and they do not match. The EDPB set common criteria for these lists back in 2019, and in March 2026 it went further and adopted a harmonised DPIA template to push some consistency onto the mess. That tells you how uneven the ground had become.

If you operate in six member states, you have six lists to check, not one directive. Most tools quietly skip this. We didn't, because we had to pull the right list per jurisdiction automatically, and that was some of the hardest work in the build. Do it by hand, across countries, in a spreadsheet, and you become the person who typed that search query.

DPIAs fail on process, not content

Here is what surprised me while we built this. The hard part is rarely the risk analysis itself, it is the process around it: unclear roles, a DPO who was never consulted or was consulted only after the decision was already made, a deviation from the plan that nobody wrote down. When the EDPB moved to standardise the DPIA template in 2026, this is the gap it was trying to close.

A spreadsheet is a grid of cells, and it cannot carry a process. It has no idea who was meant to sign, whether they did, or against which version of the risk. Getting a DPIA right needs a workflow with separated roles and a record of who did what, and when.

Where your records live is a decision, not a detail

There is a second reason we care about the plumbing under a DPIA tool, and it is about where the data sits.

Your RoPA and your DPIAs are the most sensitive map of your company's data life, and in my view they should never leave Europe. This year that view got a lot more concrete. On 29 June 2026 the US Supreme Court, in Trump v. Slaughter, made FTC commissioners removable at will. The EU-US Data Privacy Framework, the current bridge for sending European data to America, rests on the FTC being an independent enforcer, and that ruling weakens the pillar it stands on.

The Framework still stands, but adequacy decisions are living findings. The European Commission has to monitor them and can suspend them, and the Court of Justice has already killed two predecessors. Safe Harbour fell in 2015 in Schrems I, and Privacy Shield fell in 2020 in Schrems II, both on the reach of US surveillance and the lack of real redress. Firms that built on those bridges scrambled twice, and a third scramble may be forming right now.

So the posture for a compliance platform whose whole product is the records a regulator inspects is simple: never build a dependency on the bridge holding. Run on EU infrastructure under EU jurisdiction, and DPF litigation, FTC politics, and adequacy reviews become someone else's problem. That is the line between us and every US-hosted competitor, and this year it got stronger.

Your RoPA is a living register, not a file you finish

Back to the search that started this. The frustration in it is real, and it comes from treating a DPIA as a document you complete and forget. Article 35(11) says the opposite: you review a DPIA when the risk changes. Your RoPA moves every time you add a system, a vendor, or a dataset, while a spreadsheet freezes on the day you save it.

So the honest answer to "top PIA solutions avoiding months of spreadsheet wrestling" is to stop keeping requirements, controls, and evidence as cells, and start keeping them as linked records that update themselves. We built COMPLY.Reg to do that, on EU infrastructure, with a person signing off every determination, because it is the tool I wish the person behind that query already had.

If you want the dry legal detail, we set out when a DPIA is required and how to move off the spreadsheet in plainer, reference form. This piece was just me answering a search I could not stop thinking about.