Does your new feature need a DPIA? Decide before you ship, and write the answer down.

Take a feature I will call Trust Score, because some version of it exists in most products that have ever had a spam problem. It watches how a new account behaves in its first hour, gives it a number, and uses that number to decide what the account may do next: invite teammates, send outbound mail, or nothing at all until a human has looked. It ships Thursday.

Somebody asks whether it needs a data protection impact assessment, the written risk assessment the GDPR requires before certain kinds of processing start. The instinct in the room is no, because a DPIA is what hospitals and biometric vendors do, and this is a spam filter. Worth being sure, because both wrong answers cost you. If Trust Score does need one and it surfaces a risk you cannot design away, you owe your regulator a consultation it has eight weeks to answer and can extend by six. Thursday becomes February. And if it needs none, you still have to write down why, or the honest answer in eighteen months is that nobody ever decided.

When does a new feature need a DPIA?

When the processing is likely to result in a high risk to people's rights, and the assessment has to be done before that processing starts. Article 35(1) puts it in statutory words: processing "in particular using new technologies", judged on its "nature, scope, context and purposes", that "is likely to result in a high risk to the rights and freedoms of natural persons" 1. So an assessment written after launch records the gap rather than closing it.

The duty sits on the controller, meaning whoever decides why and how personal data gets processed. For a feature that scores your own signups, that is your company. Score your customers' end users instead and the controller is usually the customer, the DPIA is theirs, and your duty under Article 28(3)(f) is to assist them with it 1. Everything below assumes the first case.

A feature can process nothing more exotic than timestamps and IP addresses and still qualify, if what it does with them affects someone's access to your product. Sensitive data is one way in, not the only one.

Article 35(3) names three cases that always count, and the one a scoring feature runs at is Article 35(3)(a): a systematic and extensive automated evaluation of personal aspects on which decisions are based that produce legal effects or similarly significantly affect the person 1. It says these are required "in particular", so the three are examples rather than the full list.

Trust Score sits awkwardly against Article 35(3)(a): whether an hour of signals is "systematic and extensive", and whether gating an account "similarly significantly affects" someone, can both be argued either way. Most features land in that same gap, and the criteria below are what resolve it.

What counts as "likely to result in a high risk"?

Nine criteria answer that. They come from guidance endorsed by the European Data Protection Board, the body where the EU's national privacy regulators agree common positions 23:

1. Evaluation or scoring, including profiling and predicting.
2. Automated decision-making with legal or similarly significant effect.
3. Systematic monitoring used to observe, monitor or control people.
4. Sensitive data or data of a highly personal nature.
5. Data processed on a large scale.
6. Matching or combining datasets from operations with different purposes.
7. Data concerning vulnerable people, including children and employees.
8. Innovative use of new technological or organisational solutions.
9. Processing that prevents people from exercising a right or using a service or contract.

The working rule attached to them: in most cases a controller can consider that processing meeting two criteria requires a DPIA, and in some cases one criterion is enough 2.

The guidance also works an e-commerce site showing adverts for vintage car parts based on items viewed on its own website, and marks it unlikely to require a DPIA: that is evaluation or scoring and nothing else, so it meets one criterion 2. Most of what a small SaaS ships looks like that, which lowers the odds of needing an assessment without removing the step of deciding so.

Trust Score is not in that group. It meets criterion 1, because it scores people, and criterion 3, because it observes behaviour to control an outcome. That is two, which clears the working rule on its own, and it also reaches criterion 9, covering processing aimed at allowing, modifying or refusing access to a service 2. So the answer is yes, and sensitivity never entered into it.

Why does the answer depend on which country you are in?

Because Article 35(4) obliges every supervisory authority, meaning each country's national data protection regulator, to establish and publish its own list of processing operations that need a DPIA 1.

Only one of those lists is yours. If you are established in a single member state and sell across the EU, Article 56(1) makes the regulator of that main establishment your lead supervisory authority for cross-border processing, and Article 56(6) makes it your sole interlocutor 1. A Danish company reads Datatilsynet's list, not all twenty-seven.

The lists are deliberately not copies of each other. Reviewing Denmark's draft under the GDPR's consistency mechanism, the procedure that puts one authority's draft in front of all the others before adoption, the EDPB said that being subject to it "does not mean that the lists should be identical" 6.

The two I know best are shaped differently:

Denmark's first four entries read like biometric data, genetic data, location data or new technologies "in combination with at least one further criterion" from the guidelines, and the remaining four stand on their own 4. France names situations instead, each with worked examples 5.

For a feature like Trust Score the two lists give different answers, and that is the point. Denmark's fifth entry covers processing leading to decisions about a person's rights to a product, a service, an opportunity or a benefit, based on any form of automated decision including profiling 4. It needs no second criterion and drops the "legal effects or similarly significantly affects" threshold, so the argument about whether gating an account is significant enough never arises in Denmark. France's nearest row is narrower: profiling that can lead to exclusion from the benefit of a contract, or its suspension or termination, with behavioural analysis detecting prohibited conduct on a platform among its examples 5. If the accounts Trust Score holds can end up suspended or closed, it lands in that row. If they are only ever released after review, it may not.

What if you decide the feature does not need one?

Then you write down why, and that is the branch most teams get wrong. The guidance addresses this case explicitly: processing may match the criteria above and still be judged by the controller not to be likely to result in a high risk, and in such cases "the controller should justify and document the reasons for not carrying out a DPIA, and include/record the views of the data protection officer" 2.

There is no third branch where nothing gets recorded. Either you produce the assessment, which under Article 35(7) has to describe the processing and its purposes, assess whether it is necessary and proportionate, assess the risks, and set out the measures that address them 1. Or you write a short note saying which criteria you considered and why you concluded the threshold was not met. Skipping both means that when someone asks in eighteen months why the score was fine, the honest answer is that nobody ever made a decision, which is a worse position to be in than having made the wrong one.

Make that note a paragraph rather than a template.

Who signs off?

The controller, which is the company rather than a named person 1. Inside the company it belongs with whoever decides the purposes and means, so in a startup that is normally the founder or the product owner, not the engineer who wrote the scoring function.

The data protection officer does not sign off, and cannot be made to. Article 35(2) requires the controller to seek the DPO's advice where one is designated, and Article 39(1)(c) describes that role as giving advice when asked and monitoring how the assessment is performed 1. Neither of those is a decision, so accountability stays where Article 35(1) put it.

Whether you have a DPO at all is worth checking rather than assuming. Article 37(1) compels one for public authorities and for core activities involving large-scale monitoring or large-scale sensitive data, which few early SaaS companies meet. But Article 37(4) lets Member State law add cases, and Germany has done so: under section 38(1) of the BDSG, Germany's federal data protection act, a controller undertaking processing subject to a DPIA "shall designate a data protection officer regardless of the number of persons employed in processing" 1. So in Germany, concluding that you need a DPIA is itself what triggers the requirement to appoint one.

What happens the next time the feature changes?

Article 35(11) requires the controller, where necessary, to review whether processing is still performed in accordance with the DPIA, and to do so at least when there is a change of the risk represented by the processing operations 1. What triggers that review is a change in your product, not a date in the calendar, so the schedule is set by your releases.

For a scoring feature, the risk moves on ordinary product work: a new input added to the score, an enrichment vendor supplying part of it, the score extended from signups to existing customers, or a suspension that a human used to approve becoming automatic. Each of those is a merge, and none of them looks like a legal event on the day it happens. It is the same failure as a privacy policy drifting away from the product it describes: the document is accurate the day it is written, nothing is scheduled to check it again, and so the check never happens at all.

What to do before Thursday

Take the feature closest to shipping. Find your own regulator on the EDPB's list of national authorities, open its Article 35(4) list, count how many of the nine criteria your feature meets, and record the answer whichever way it comes out.

If the count is two or more, start the assessment now rather than in launch week. Where a DPIA indicates the processing would result in a high risk you cannot mitigate, Article 36(1) requires consulting your supervisory authority before the processing starts, and it has up to eight weeks to respond, extendable by six 1. That is the clock from the opening, and it only runs against you if you leave the question late.

Then decide what catches the next change. Lawcel is the product we build for that job: it puts the merge that adds automated approval in front of you while it is still a pull request, rather than eighteen months later when somebody asks who decided. It reads each change in your GitHub, Linear or Jira against a record of what your company does with personal data, and tells you when the two have stopped agreeing. It does not write your DPIA, and I would not trust software that claimed to.