Almost every digital project Adaptist Consulting has supported follows the same pattern: the IT team finishes building the system, the vendor contract gets signed, and only then does someone ask, “Wait, have we actually assessed the privacy risk on this?”
The answer is almost always no.
The result? Compliance gaps surface only after the system is already live. Fixes that would have been simple at the design stage turn into standalone projects that drag on for weeks. It’s not unusual for post-implementation remediation to cost three times more than it would have if a Privacy Impact Assessment had been built into the planning process from day one.
That’s the whole point of a Privacy Impact Assessment (PIA). It’s a working tool that helps organizations catch privacy risk before it grows into a real problem.
What Is a Privacy Impact Assessment (PIA)?
A Privacy Impact Assessment (PIA) is a structured process for identifying, evaluating, and mitigating the privacy risks of a personal data processing activity right before that activity goes live or undergoes a significant change.
The process answers six concrete questions:
- What personal data is being collected?
- Why is that data needed?
- Who can access it?
- What risks does this create for the data subject?
- How can those risks be reduced?
- Does this activity meet applicable regulatory requirements?
A PIA is different from a standard security audit. It doesn’t just check whether a system is technically secure, it also asks whether the data processing itself is lawful, transparent, and proportionate.
A technically secure system can still violate the principle of data minimization if it collects more information than it actually needs. That’s exactly the kind of issue a PIA is designed to catch.
PIA vs. DPIA: What’s the Difference?
Both PIA and DPIA assess privacy risk, but they differ in scope and regulatory context.
PIA is the general term for the process of assessing privacy risk in a data processing activity. A DPIA (Data Protection Impact Assessment) is a specific form of PIA, explicitly mandated under Article 35 of the GDPR for high-risk processing activities.
| Aspect | PIA | DPIA |
|---|---|---|
| Purpose | Identify and mitigate privacy risk | Assess high risk to individual rights and freedoms |
| Scope | General and flexible | More formal and specific |
| Risk level | All risk levels | High risk only |
| Related regulation | Various privacy laws and frameworks | GDPR Article 35 |
| Typical use | Privacy governance and risk management | GDPR compliance |
One distinction that often gets overlooked: a DPIA must be referred to the supervisory authority if residual risk remains high even after mitigation. A standard PIA carries no such formal consultation requirement.
For organizations operating under both the GDPR and Indonesia’s PDP Law, both processes need to run in parallel, since their requirements don’t fully overlap.
Which Regulations Require a PIA?
A PIA isn’t just a best practice. In Indonesia, Law No. 27 of 2022 on Personal Data Protection (PDP Law) requires data controllers to implement protective measures proportionate to the risk level of their processing activities.
This impact assessment obligation becomes especially relevant when a processing activity involves:
- Personal data at scale
- Specific or sensitive categories of personal data (health, biometric, financial)
- The use of new technology
- Automated decision-making
- Systematic monitoring of individuals
The PDP Law has been fully in effect since October 2024, following a two-year transition period. Under Article 57(3) of the law, administrative fines for data breaches can reach 2% of an organization’s annual revenue.
For a company with annual revenue of Rp 500 billion (roughly USD 28 million), that works out to about Rp 10 billion (around USD 560,000), and that’s before factoring in the separate criminal penalties set out in Articles 67 through 73.
Learn about the PDP Law
The Personal Data Protection Law (UU PDP) regulates how personal data must be managed and protected, while also defining the rights of data subjects and the responsibilities of parties that process such data.
UU PDP
Deepen your understanding and explore the provisions in detail by downloading this PDF. Your data is safe with us!
Internationally, Article 35 of the GDPR sets out the DPIA obligation explicitly. Other regulations that take a broadly similar approach to assessing privacy risk include the UK GDPR, Australia’s Privacy Act, and Canada’s public-sector privacy framework.
For organizations operating across multiple jurisdictions, running PIAs consistently can help satisfy several regulatory frameworks at once, though each one still needs to be tailored to its specific requirements.
Why Does a PIA Matter for Your Company?
Catching and Mitigating Risk Early
While supporting the rollout of a biometric attendance system at a manufacturing company, we ran a PIA in the project’s third week and found that fingerprint data was going to be stored directly on a local server, unencrypted.
Caught at the design stage, that finding took two days to fix. Had it surfaced after the system was already live and being used by 1,200 employees, the fix would have been far more complex and likely would have required notifying affected employees.
It’s worth putting the scale of what early prevention avoids into a wider context. According to IBM’s 2025 Cost of a Data Breach Report, the average global cost of a data breach was USD 4.44 million per incident. And while that’s actually down about 9% from the year before, it’s still a staggering number for an organization of any size.
The same report found that organizations that detect breaches internally save close to USD 900,000 compared to those that only find out from an outside party. Investing in early detection, including through PIAs, continues to pay for itself financially.
Reducing the Risk of Compliance Penalties
Many organizations only get around to evaluating privacy after implementation is already complete. That’s not just expensive to fix, it also leaves a window of time during which the organization is operating with an active compliance gap.
Data from ELSAM, the Institute for Policy Research and Advocacy, an Indonesian civil society organization, shows that from the time the PDP Law took effect through the end of 2023, at least 668 million personal data records were allegedly leaked from six data controllers, spanning both public and private sector organizations.
Most of those incidents involved systems that never went through an adequate privacy risk assessment before going live.
Better Visibility Into Your Data
One of the most consistent findings to come out of the PIAs we run is that organizations often don’t actually know what data they’re collecting.
It’s not that they don’t care, it’s that the data is scattered across so many poorly documented systems that getting a clear picture becomes genuinely difficult. A PIA forces that mapping to happen explicitly.
Building User Trust and Brand Reputation
Customers are paying closer attention to how their data gets used. The IAPP’s Privacy and Consumer Trust survey, which covered 4,750 individuals across 19 countries, found that 68% of consumers globally said they were concerned or very concerned about their online privacy.
More than 35% of respondents also named regulatory compliance as the single biggest factor pushing companies to protect personal data.
On the other hand, a joint survey by Indonesia’s communications ministry, known as Kominfo at the time, since renamed Komdigi (the Ministry of Communication and Digital Affairs), and Katadata Insight Center, covering 10,000 respondents across Indonesia, found that 53.6% of Indonesians still have a low level of personal data protection.
In other words, public trust isn’t there yet — which gives companies that demonstrate strong privacy practices real room to stand out.
When Should You Run a PIA?
The simple rule: before a new system is built, not after it’s already finished.
The earlier a PIA happens, the easier it is to build privacy controls directly into the system’s design. That’s the principle of privacy by design, and it’s a lot cheaper than privacy by remediation.
The situations that most often call for a PIA:
- New system implementation. Any system that collects or processes personal data, no matter how small, has the potential to create a risk that didn’t exist before.
- New technology adoption. AI, machine learning, biometrics, and facial recognition often introduce risks that don’t show up in conventional systems, particularly around profiling and automated decision-making.
- Third-party integration. When data is shared with a vendor or cloud provider, the organization needs to confirm the third party’s safeguards match its own internal standards. In many of the cases we’ve handled, a Data Processing Agreement (DPA) with the vendor either didn’t exist yet or didn’t spell out specific enough obligations.
- Sensitive data processing. Health, biometric, and financial data all require layered protection. A single control is never enough.
- A change in purpose. Using data that’s already been collected for a new purpose — say, using customer transaction data to train an AI model — almost always calls for a fresh PIA.
Who Needs to Be Involved?
A PIA isn’t a one-team job. It needs input from several functions at once, because privacy risk can show up from angles you wouldn’t expect.
- The DPO (Data Protection Officer) leads the assessment methodology and provides mitigation recommendations based on the applicable regulatory framework.
- Legal evaluates the lawful basis for processing, vendor contracts, and the legal risk of the activity under review.
- IT explains the system architecture and data flows, including integrations with other systems that may not be documented at the business level.
- Information Security evaluates technical controls such as encryption, access management, and logging. Crucially, their job is to judge whether existing controls are sufficient, not just whether they exist.
- Business process owners are often the most important source of information on how data is actually used day to day, which doesn’t always match the technical documentation.
- Vendors or third-party partners need to be brought in whenever processing involves an external system, to confirm they can provide an equivalent level of protection.
How to Conduct a Privacy Impact Assessment
1. Identify the Processing Activity
Define the project or activity being assessed. Document the purpose of the processing, the parties involved, and the underlying business need.
At this stage, the project boundaries need to be explicit: a PIA for System A doesn’t automatically cover the risks of System B, even if the two share a database and are integrated.
2. Map the Personal Data Involved
Identify every piece of personal data being processed: its source, category, storage location, retention period, and who receives it.
The results are often surprising. In one e-commerce project we supported, data mapping revealed that the system was storing customer credit card data in three separate locations, two of which the business team had no idea existed.
3. Analyze Privacy Risk
Assess the risks that could affect individuals: unauthorized access, use of data beyond its stated purpose, uncontrolled transfers to third parties, or a lack of transparency with the data subject. Every risk needs to be scored on two dimensions: likelihood and impact.
4. Evaluate the Impact on Individuals
Define the concrete consequences a data subject might face if a given risk materializes. Don’t stop at a category like “financial loss”, get specific about how much, in what context, and who’s most vulnerable.
More vulnerable groups, minors, or patients with certain medical conditions, for example, need a more careful impact assessment.
5. Define Mitigation Controls
Identify mitigation steps that are specific and verifiable: encryption for data at rest and in transit, multi-factor authentication for access to sensitive data, pseudonymization, role-based access restrictions, and improvements to the consent mechanism.
Avoid vague controls like “improve system security” as they can’t be audited.
6. Document the Findings
Every finding, decision, risk, and mitigation plan needs to be documented. This isn’t a box-checking exercise. When a regulator or auditor asks for proof of compliance, the PIA document is one of the first things they’ll request.
7. Review Regularly
A PIA isn’t a one-and-done document. Update it whenever the system changes, a vendor changes, regulations change, or the purpose of processing expands.
As a baseline, we’d recommend scheduling an annual review by default, plus an ad hoc review any time a system that’s already been assessed undergoes a material change.
Ready to Manage Privacy Compliance as a Business Risk?
See how GRC helps map personal data risks, monitor compliance with the PDP Law, and prepare companies for audits without complicated manual processes.
Common Mistakes We See in Practice
Running the PIA Too Late
Adaptist Consulting once supported a company rolling out a cloud-based HR management system. The PIA didn’t start until week 10 of development, by which point the system was nearly ready to launch. The team found that the vendor was storing employee data on servers outside Indonesia without an adequate data transfer agreement in place.
Fixing it took six weeks of vendor contract renegotiation and pushed back the launch. Had the PIA been done before the vendor was selected, this issue could have been resolved during vendor selection — not after the contract was already signed.
Leaving Out Business Process Owners
A PIA run solely by IT or compliance often misses the most significant operational risks. In one case, the technical team documented that customer data was only ever accessed by an automated system.
In reality, the customer service team had manual access that wasn’t recorded in any technical documentation. That risk only came to light once business process owners were brought into the conversation.
Assessing Risk Only Through an Information Security Lens
Privacy and information security aren’t the same thing. A system that encrypts everything perfectly can still violate the principle of data minimization if it’s collecting information that has nothing to do with its stated purpose. A PIA needs to ask whether the processing should happen at all, not just whether it’s safe to do so.
Letting the Documentation Go Stale
PIA documentation that hasn’t been touched in 18 months, while the system itself has gone through three major update cycles, is a document that no longer reflects reality.
This isn’t just an administrative headache: when an incident happens, an organization that can’t produce an up-to-date risk assessment is in a far weaker position in front of regulators.
Treating the PIA as a Formality, Not a Working Tool
This is the most common failure mode of all. The PIA gets finished, then filed away and forgotten. The mitigation recommendations never get implemented because there’s no clear follow-up mechanism.
The fix is simple: every mitigation item in the PIA document needs a named owner and a specific deadline, and it needs to live in the same project tracker as every other development task.
Conclusion
There’s a simple way to gauge how privacy-ready an organization really is: ask when their last PIA was done, and ask to see the document.
If the answer is a document from two years ago that’s never been updated, or there’s no document at all, that organization isn’t managing privacy risk. It’s just hoping nobody asks.
An effective PIA isn’t measured by how thick the document is. It’s measured by how honestly an organization documents the risks it knows are there, and how seriously it follows through.
