A Worked DPIA Example for Malaysia: One Loyalty App, Five Steps
Most articles about JPDP's DPIA guideline stop at the thresholds. You learn that an assessment is needed above 20,000 people, nod, and close the tab. Then someone in your company asks you to actually do one, and there is no example anywhere of what a finished Malaysian DPIA looks like.
So here is one. It is fictional but realistic, it follows the five steps in the guideline, and you can copy its shape for your own.
The short version
- A Data Protection Impact Assessment (DPIA) is a documented check, done before you launch, of whether a processing activity puts the people whose data it is at unacceptable risk.
- JPDP's DPIA Guideline, released on 30 April 2026, requires one above set volumes (personal data of more than 20,000 people, or sensitive personal data of more than 10,000) and wherever qualitative triggers apply, such as automated decision-making and profiling, children's data, systematic monitoring, or decisions affecting a person's legal or financial position.
- The method has five steps: describe the processing, evaluate necessity and proportionality, identify the risks, consider the safeguards, and assess the residual risk, which senior management then accepts or reduces.
- A good DPIA changes the design. If nothing in your product changed because of it, it was paperwork, not an assessment.
The scenario: a retail loyalty app
A Malaysian retail chain with 60 outlets is launching a loyalty app. Members sign up with their name, phone number, email and date of birth. The app records purchases, and it wants to send offers when a member is near an outlet, based on the phone's location. Marketing also wants to group members by spending pattern and target offers at each group. The chain expects about 150,000 members in the first year.
Everything below is an illustration. The numbers and decisions are ours, not JPDP's. What is real is the structure, which follows the guideline.
Screening: does this app need a DPIA?
Yes, on three separate grounds, and the screening record should say so. It is also the one document most organisations never keep: when an activity does not need a DPIA, that decision and its reasons are evidence too.
| Test | Result for the loyalty app | Triggered? |
|---|---|---|
| More than 20,000 data subjects | About 150,000 members expected in year one | Yes |
| Sensitive personal data of more than 10,000 | None collected by design | No |
| Systematic monitoring | Location used to detect when members are near an outlet | Yes |
| Automated decision-making or profiling | Members grouped by spending pattern to target offers | Yes |
| Children's data | Sign-up is restricted to adults (see step 2) | No, if enforced |
The profiling ground matters on its own. Under the DPIA guideline, automated decision-making and profiling is a qualitative trigger whatever the volume, so even a small pilot would have needed an assessment.
Step 1: describe the processing
Describe the processing, not the system. "We use a CRM" says nothing. What the assessor needs is each piece of personal data, why it is collected, where it goes and how long it stays.
| Data | Purpose | Where it goes | Kept for |
|---|---|---|---|
| Name, phone, email | Membership account and receipts | App backend (cloud, region to be confirmed) | While the account is active |
| Date of birth | Birthday offer, age check | App backend | While the account is active |
| Purchase history | Points, spending groups | App backend, analytics tool | To be decided (see step 2) |
| Location | Nearby-outlet offers | App, push notification provider | To be decided (see step 2) |
| Device ID, push token | Sending notifications | Push notification provider | While notifications are enabled |
Two things surface immediately. The push notification provider is a data processor, so it needs a contract with the right clauses. And if the cloud region or the push provider sits outside Malaysia, this is also a cross-border transfer, which needs its own Transfer Impact Assessment under JPDP's cross-border guideline (valid for up to three years).
Step 2: evaluate necessity and proportionality
This is the step that changes the product. For each piece of data, ask whether the purpose could be met with less. Here is what our assessor found, and what the chain changed:
- Continuous precise location was not necessary. The purpose is an offer when a member is near an outlet. A geofence check while the app is open meets that purpose. Background tracking of every movement does not add anything the business needs. Changed: location only while the app is in use, and only compared against outlet geofences on the device.
- Full date of birth was more than needed. A birthday offer needs the month; the age check needs a yes or no. Changed: collect birth month plus an "I am 18 or over" confirmation.
- Purchase history had no retention limit. Changed: purchase detail kept for 24 months for points and grouping, then reduced to totals.
- The notice had to match reality. The privacy notice must explain location use and spending groups plainly, and under section 7(3) of the PDPA it must be in both Malay and English.
Notice that the DPIA has already made the app less risky before we have even listed a risk. That is the point of doing it before launch.
Step 3: identify the risks to individuals
The guideline asks about risk to the people whose data it is, not risk to the company. Rate each on the same likelihood and severity scale every time, so two assessors reach the same answer.
| Risk to members | Likelihood | Severity | Rating |
|---|---|---|---|
| Location history reveals where a member lives, works or goes, if kept or leaked | Medium (before changes) | High | High |
| Member database breach, leading to phishing or fraud using real names and purchases | Medium | Medium | Medium |
| Spending groups used to exclude or pressure members, or feel intrusive | Low | Medium | Low |
| Push provider or cloud host outside Malaysia with weaker protection | Medium | Medium | Medium |
| Minors signing up despite the age rule | Low | Medium | Low |
Step 4: consider the safeguards
Every safeguard should point at a named risk. A list of generic security controls with no link to the risks is the most common weakness in DPIAs we review.
| Risk | Safeguard | Owner |
|---|---|---|
| Location history | In-use location only; geofence matched on the device; no location history stored on the server | Product lead |
| Database breach | Access limited by role, multi-factor sign-in for admins, encryption at rest, breach response plan covering PDPA notification | IT lead |
| Spending groups | Groups used for offers only; members told in the notice and able to opt out of personalised offers | Marketing lead |
| Overseas processors | Processor contract with breach notification and assistance clauses; Transfer Impact Assessment for any non-Malaysian host | DPO |
| Minors | Age confirmation at sign-up; account closure process when a minor is identified | Customer service lead |
Step 5: residual risk and sign-off
After the safeguards, the location risk falls from high to low, because there is no stored history to leak or misuse. The database breach risk stays at medium: it is reduced, not removed, which is true of every system that holds personal data. The remaining risks are low.
That summary goes to senior management, with the DPO's advice written alongside it. Management then makes the decision the guideline expects: accept the residual risk, or reduce it further before launch. In our example the chain accepts it, and records two review triggers that will reopen the DPIA: adding any new data type (for example, a payment wallet), or changing the push notification or cloud provider.
If the DPO had disagreed with management's decision, that disagreement belongs in the record too. A DPIA where everyone always agreed tends to read as one nobody challenged.
What should the finished DPIA record contain?
- The screening decision and its reasons
- The processing description (step 1), at the level of the table above
- The necessity and proportionality findings, including the design changes made
- The risk ratings, on a consistent scale
- The safeguards, each linked to a risk, with an owner
- The residual risk summary, the DPO's advice, and management's decision and date
- The review triggers that reopen the assessment
Keep every DPIA in a register with its owner, sign-off date and review triggers. When a regulator, a customer or a court asks how you assessed a system, the register is what you hand over.
Frequently asked questions
Is a DPIA mandatory in Malaysia?
JPDP's DPIA Guideline of 30 April 2026 sets when one is expected: processing the personal data of more than 20,000 people or the sensitive personal data of more than 10,000, or where a qualitative trigger such as automated decision-making or profiling, children's data, systematic monitoring or decisions affecting a person's legal or financial position applies.
Who should carry out the DPIA?
The business owner of the activity, working with IT and the product team, with the DPO advising. Senior management accepts or reduces the residual risk. An outside assessor helps where the internal team is too close to the project to challenge it.
How long does a DPIA take?
A screening can take an hour. A full assessment like the one above usually takes a few weeks of elapsed time, mostly spent waiting for the right people to be available. Starting early in the project is what keeps it from delaying launch.
Do we need a new DPIA every time the app changes?
Not for every change. Reopen it when a review trigger fires: a new type of personal data, a new processor or host, a new purpose, or a change in how decisions about people are made.