How to Create a Data Protection Impact Assessment (DPIA)

A digital financing startup launched a credit-scoring feature based on users’ transaction history. The feature was activated right away without a risk evaluation, and three months later the regulator asked for clarification because the algorithm turned out to be accessing data that had nothing to do with its original purpose.

Cases like this aren’t rare. According to the IBM Cost of a Data Breach Report 2026, an annual study surveying hundreds of organizations that have experienced a data breach across more than a dozen countries, the average global cost of a data breach rose 12 percent, from USD 4.44 million in 2025 to USD 4.99 million in 2026. That figure doesn’t even include reputational damage, which is far harder to recover from than financial loss.

One way to prevent the scenario above is by carrying out a Data Protection Impact Assessment (DPIA) before a personal data processing activity is put into operation. This article discusses what a DPIA is, the components it needs to include, and how to build one step by step.

What Is a Data Protection Impact Assessment (DPIA)?

A DPIA, referred to in Indonesia as Penilaian Dampak Pelindungan Data Pribadi, is a systematic evaluation process used to identify, measure, and mitigate risks that may arise from a personal data processing activity. What sets it apart from a regular security audit is timing: a DPIA is carried out before a new system or process goes live, not afterward.

Article 34 paragraph (1) of Law No. 27 of 2022 on Personal Data Protection requires data controllers to carry out this assessment to evaluate potential risks to data subjects’ rights, while also preparing mitigation steps before those risks actually materialize. The focus isn’t just system security, but the real impact on the individuals whose data is being processed.

Take the example of a private hospital planning to integrate its electronic medical records with a third-party API for automated insurance claims. Before that feature goes live, the compliance team should map out who can access patient data, whether the data is encrypted when sent to the third party, and how long that data is retained in the partner’s system. It’s the results of that mapping that get put into the DPIA document, not something done after the system is already running and an incident has already occurred.

Responsibility for carrying out a DPIA rests with the data controller, meaning the party that determines the purpose and means of personal data processing. In practice, a data controller can carry out this assessment internally through a DPO, or bring in an external consultant if the company doesn’t yet have adequate capacity and expertise.

A DPIA also needs to be distinguished from the general risk register commonly used by a company’s risk management division. A risk register assesses risk from a business standpoint, such as potential financial loss or operational disruption, whereas a DPIA specifically assesses the impact on the rights and interests of the individuals whose data is being processed.

Components That Must Be Included in a DPIA Document

A good DPIA document isn’t enough if it only contains a general narrative about the importance of protecting data. There are several core components that need to be included for the document to actually function as an evaluation tool, as shown in the table below.

Component	Brief Explanation
Description of the processing	Explains the type of data, the purpose of processing, and the data flow from start to finish
Legal basis for processing	States the legal basis, such as data subject consent or contract performance
Risk identification	Maps out concrete risk scenarios, not general statements like “may potentially leak”
Risk level assessment	Measures the likelihood and impact of a risk, typically using a low/medium/high matrix
Mitigation steps	Details concrete actions to bring the risk down to an acceptable level
Review plan	Determines when and how this document will be re-evaluated

For example, in the risk identification row, the correct way to write it isn’t “customer data is at risk of leaking,” but rather something specific like “customer service staff have full access to a customer’s entire transaction history even though their job only involves handling shipping complaints.”

How to Create a DPIA: Step by Step

Once you understand the components above, the next question is how to put them together in sequence so the result is actually usable, rather than just a formality document. Below are the stages we typically use when helping clients build their first DPIA.

1. Map Out the Business Process and Data Flow

Start by mapping out the entire data flow, from the point of collection to deletion. A digital health app, for instance, needs to map out whether a patient’s symptom data is stored only on internal servers or also sent to a third-party cloud service provider.

2. Involve the Relevant Stakeholders

A DPIA isn’t the sole job of the legal team or the Data Protection Officer (DPO). Product, IT, and operations teams need to be involved from the start, since they’re the ones who best understand the technical details of how data is processed on the ground.

This is the part that, in our experience, most often becomes a bottleneck. Technical teams are sometimes reluctant to join discussions at the early stage because they see a DPIA as purely a legal matter, when in fact they’re the ones who know exactly where the data flows.

3. Identify and Assess Risks to Data Subjects

At this stage, the team draws up a list of possible risk scenarios, then assesses their likelihood and impact on individuals. For example, the risk that “a user’s location data could be accessed by an unauthorized party” would be rated high if the app stores location history indefinitely.

4. Design Concrete Mitigation Steps

Every identified risk must be paired with a clear mitigation step, not a vague statement like “will be fixed.” If the risk is excessive employee access, the mitigation could take the form of implementing role-based access control and regular audit logs.

5. Document Everything and Obtain DPO Approval

Once all findings and mitigation plans have been compiled, the document needs to be reviewed and approved by the DPO or the party responsible for data compliance. This approval serves as the signal that the new process is cleared to proceed.

6. Review Periodically

A DPIA isn’t a one-and-done document. Every time there’s a significant change to a business process, such as adding a new feature or switching data storage vendors, this document needs to be reviewed again to make sure the risk assessment is still relevant.

It should be acknowledged that carrying out all six of these steps at once, formally, can feel overwhelming for a small company with a limited compliance team. In cases like that, a more realistic approach is to prioritize DPIAs for high-risk processing first, then gradually expand the scope as the team’s capacity grows.

Things Companies Need to Pay Attention to When Running a DPIA

Putting together the document alone isn’t enough if the process isn’t embedded into the company’s working culture. There are several things that need to be in place for a DPIA to run consistently, rather than being a one-time formality.

• Every new initiative involving data processing should be checked upfront for whether it requires a DPIA, rather than being checked later after the system is already running.
• The DPIA obligation needs to be understood by every department, not just the legal team or the DPO, because data risk often originates from product and operations teams.
• A company’s internal policy should explicitly reference DPIA requirements, so the rule carries binding force internally.
• Companies need to prepare a standard format and process flow for DPIAs, so that each team isn’t putting together documents in different formats.
• The DPIA process should ideally be integrated into the product development cycle, rather than being an extra step tacked on just before launch.

Danny Kobrata, founder of the Indonesian Data Protection Practitioners Association (APPDI), once emphasized this point at a personal data protection masterclass in November 2023, as reported by Hukumonline: the DPIA obligation shouldn’t be known only to the legal team or the DPO, since every department that manages customer data plays a role in determining whether that risk arises or not.

As an illustration, a marketing team buying contact data from a third party for a promotional campaign often doesn’t realize that activity still falls under the category of personal data processing. If a company already has a standard workflow in place, the marketing team would automatically check whether a DPIA is needed before the campaign runs, rather than waiting for a warning from the compliance team.

Common Mistakes That Make a DPIA Ineffective

Many companies already have a DPIA document, but that document doesn’t actually help prevent risk. The following mistakes are often the cause, based on the recurring patterns we’ve seen while helping clients build and evaluate their DPIA documents.

The DPIA Is Only Put Together After the System Goes Live

The most common pattern is a team drawing up a DPIA after a feature or system is already running, usually because an auditor or prospective business partner asked for it. Its function then shifts from a prevention tool into merely a justification for a decision that’s already been made.

Risk Assessments Are Written Generically

Many documents only mention risk in general terms like “may potentially result in a data breach,” without explaining the concrete scenario that could occur in that particular process. As a result, the mitigation team doesn’t know exactly what needs to be fixed.

There’s No Follow-Through on Mitigation

Mitigation recommendations often stay on paper and are never actually carried out by the relevant team. The DPIA document ends up as a compliance archive rather than a living work guide.

The Document Isn’t Updated Even After Major Changes

When a company switches data storage vendors or starts processing a new type of data, many forget to update their old DPIA. An outdated risk assessment clearly no longer represents the actual conditions.

The Process Is Carried Out Alone, Without the Technical Team

There are also cases where a DPIA is put together by just one person on the legal or compliance team, without input from the IT or product team that understands the technical details of the data flow. The result is that many technical risks end up slipping through the assessment.

These mistakes usually aren’t about intent, but about an unstructured process. According to the DLA Piper GDPR Fines and Data Breach Survey 2026, which analyzed data from data protection authorities in 31 countries, personal data breach notifications in Europe rose from an average of 363 to 443 cases per day over the period from January 28, 2025 to January 27, 2026, a 22 percent increase that shows just how quickly data risk can turn into a real incident if it isn’t monitored continuously.

Conclusion

A DPIA is a prevention instrument, not just an administrative requirement to satisfy the UU PDP. Companies that carry it out consistently, from mapping data flows to periodic reviews, are in a far stronger position when facing an audit, a legal dispute, or a business partner’s evaluation.

This process demands cross-departmental involvement and tidy documentation, two things that are often neglected when handled manually using spreadsheets or scattered documents. Without a structured system, major risk actually tends to emerge from small missed steps, such as a document that was never updated or a mitigation that was never followed through on.

FAQ