When Does a SaaS Product or App Need a DPIA
A SaaS product team adds a feature that analyzes user actions and assigns them a risk score. Clients will be able to use it to restrict operations in their accounts. From a development perspective, this means a new set of events, a scoring model, and a screen displaying the result. For the people whose actions are assessed by the system, the consequences may be more serious: an incorrect score could result in loss of access to a service or create an unfounded suspicion.
In such a situation, a DPIA — Data Protection Impact Assessment — may be required before launch. Its purpose is not to confirm product readiness through a formal document. The assessment should identify the consequences the new processing may have, determine whether the objective can be achieved in a less risky way, and establish what changes need to be made to the feature before release.
When Is an Assessment Mandatory?
Under the GDPR, a DPIA must be carried out before processing begins if, taking into account its nature, scope, context, and purposes, it is likely to result in a high risk to the rights and freedoms of individuals. Therefore, the mere fact that a new feature is being released does not automatically mean that a full assessment is required. At the same time, the absence of health or financial data does not guarantee that there is no risk.
The GDPR specifically identifies, among other things, three situations: large-scale systematic evaluation of personal characteristics based on automated processing, where decisions produce legal or similarly significant effects; large-scale processing of special categories of data or data relating to criminal convictions; and large-scale systematic monitoring of publicly accessible areas. Supervisory authorities also publish lists of processing operations for which a DPIA is required. When launching a product in a specific country, the relevant list should be checked.
For a digital product, factors that may indicate the need for closer assessment include profiling, combining data from different sources, continuous monitoring of behavior, processing data relating to vulnerable individuals, or using the result to make a decision that significantly affects a person. It is the combination of circumstances that matters, rather than whether the feature description contains terms such as “AI,” “analytics,” or “scoring.”
| New Feature | What to Determine Before Deciding Whether a DPIA Is Required |
| Report on the Number of Active Users | What data is needed for the calculation and whether an aggregated result can be obtained without monitoring the actions of a specific individual |
| Session Recording in the App | Which screens and actions are recorded and whether messages, payment information, or sensitive data may be captured in the recording |
| Candidate Assessment in an HR Service | What data affects the result, who makes the final decision, and whether an incorrect assessment could deprive a person of an employment opportunity |
| Automatic Identification of “Suspicious” Clients | Whether the assessment results in an account restriction or denial of service, whether the result can be challenged, and how model errors are reviewed |
The table does not establish that a DPIA is always mandatory for each of the listed features. It illustrates why the decision cannot be made based solely on the name of the tool: the data involved, the scale of processing, and the actual consequences for the individual all matter.
At What Stage of Product Development Should a DPIA Begin?
The assessment should be carried out while it is still possible to influence the architecture of the feature. If the team has already selected a provider, collected historical data, and enabled the feature for all clients, the DPIA turns into a description of an already completed solution. Correcting identified problems at that stage requires significantly more time.
A practical point for the initial assessment is during the discussion of the feature requirements. The product team describes the objective and expected outcome, the technical team explains what data will be required and how the processing will work, and the data protection specialist assesses whether there are indicators of high risk. If there are none, the decision and the reasons for it are documented. If such indicators are present, a full DPIA is initiated and refined as development progresses.
What Changes Require the Assessment to Be Revisited?
A DPIA does not end with the first release. Even if the initial version of the feature has been assessed, the conditions of its use may change:
- A new data source has been added. For example, data from a CRM or a third-party provider has been added to actions within the service. This combination makes it possible to draw conclusions that were not possible with the original processing.
- The consequences of the result have changed. Initially, the risk score served as guidance for an operator, but now it automatically triggers an account restriction. The data may remain the same, but the potential harm to the individual becomes more serious.
- The audience or scale has expanded. A feature tested on a small group has been enabled for all clients or has begun to be applied to children, employees, or another group whose circumstances require particular attention.
- Data has been transferred to a new provider. An external service has gained access to the source data or model results. Its role, the purposes for which it uses the information, its retention practices, and its impact on the previously selected safeguards need to be reviewed.
Each such change does not mean that the assessment must be rewritten from the first page. However, the team should check whether its conclusions remain valid and update the DPIA before launching the modified processing if the risk has changed.
What to Analyze Using a Scoring Feature as an Example
Suppose a platform helps companies identify suspicious activity in customer accounts. Initially, it displayed a list of unusual events to an operator. In the new version, the system will assign each user a risk score and automatically restrict access once a certain threshold is reached.
The purpose of the feature is clear: to reduce the risk of fraud. For a DPIA, however, this explanation is not sufficient. The specific processing chain needs to be examined: which events contribute to the score, whether information from other services is used, how long the history is retained, who can see the score, and exactly what happens when the model is triggered.
The potential consequences for individuals are then assessed. An incorrect restriction could prevent someone from accessing their own funds or an essential service. Giving the client’s employees overly broad access to risk scores could lead to unfounded conclusions about a user. If the model is trained on data from multiple clients, a separate question arises as to the purposes for which that information is used and the legal basis for doing so.
The DPIA may result in changes to the product: removing unnecessary features from the model, shortening the retention period for historical data, replacing automatic restrictions with employee review, or providing individuals with a clear way to challenge a decision. Such an assessment affects the requirements for the feature, not merely the content of the documentation.
What Should Be Included in the Assessment Itself?
The GDPR requires the planned processing operations and their purposes to be described, the necessity and proportionality of the processing to be assessed, the risks to individuals to be identified, and measures to mitigate those risks to be defined. For a SaaS team, this can conveniently be translated into several practical questions:
- Why is the feature needed, and what data is actually necessary for it? The team should check whether the objective can be achieved with less data, a shorter retention period, or without linking events to a specific user.
- What harm could the processing cause? The assessment should consider more than data breaches or unauthorized access. An incorrect conclusion by the model, an unfair restriction of a service, and the inability to challenge a decision may also affect an individual’s rights.
- What measures change the level of risk? For each significant risk, a specific solution should be identified: access restrictions, human review, changes to the model’s logic, data quality controls, or a clear appeals procedure.
- What risk remains after these measures? The team documents the outcome, those responsible for implementing the changes, and the conditions under which the feature can be launched.
It is useful to discuss the DPIA with those who design and use the feature. Where appropriate, the views of individuals affected by the processing, or their representatives, should be taken into account. If the company has appointed a DPO, their advice should also be obtained as part of the assessment.
Who Conducts a DPIA in B2B SaaS?
If a client uses the SaaS for its own purposes and determines whose data is uploaded to it and how the results are used, the obligation to assess such processing usually lies with the client as the data controller. The product provider should provide the information and assistance necessary for the assessment: a description of how the feature works, the categories of data involved, its settings, risks, and safeguards.
At the same time, the provider should not treat the issue as entirely outside its responsibility. It makes architectural decisions and may itself determine the purposes of certain processing operations, such as using data to develop its own product. Such operations require a separate assessment of its role and, where there is a high risk, its own DPIA.
For a scalable SaaS product, it is useful to prepare materials about the feature that each client can use in its own assessment. These materials save time, but they do not replace an analysis of the specific use case: one client may use the result only as guidance for an employee, while another may use it to automatically deny a service. The consequences are different.
When Should the Release Be Postponed?
A DPIA does not give a company permission to accept any risk simply by recording it in a table. If the assessment identifies a high residual risk that cannot be mitigated by appropriate measures, prior consultation with the competent supervisory authority is required before the processing begins. The disputed feature cannot be launched until this issue has been resolved.
More often, the assessment leads to a more practical solution: changing the default settings, removing an automated action, limiting the pilot audience, or adding human review of the result. The risk is reassessed after these changes. A DPIA should therefore be included in the criteria for determining whether a feature is ready for release, alongside testing and security.
The key question for the team is: what will change for the individual after the feature is launched, and can the company explain and limit the potential harm? If answering this question requires changes to the product, the DPIA has been carried out at the right time.
Wolja Digital helps SaaS companies and app developers determine whether a DPIA is required for a new feature, conduct the assessment together with the product team, and translate its conclusions into specific data processing requirements before launch.