A customer opens your app, taps a button, and asks you to delete everything you hold about them. From that moment, the clock starts. Under Indonesia’s data protection law, you have 72 hours to act.
For a fintech platform or an online store handling thousands of these requests, doing it by hand is not realistic. This article explains the 72-hour rule in plain terms, why it’s hard for fast-moving digital businesses, and how to build a system that handles it automatically.
What Is UU PDP?
UU PDP (Undang-Undang Perlindungan Data Pribadi) is Indonesia’s main law for protecting people’s personal data (Law No. 27 of 2022), and it has been fully in force since October 2024.
It sets out what rights individuals have over their data and what companies must do when those rights are exercised. It applies to any business handling the data of people in Indonesia, including foreign companies serving the Indonesian market.
What Are Data Subject Rights?
A “data subject” is just the person whose data you hold: your customer, your app user, your borrower. UU PDP gives that person a set of rights over their own information.
Articles 5 through 13 of the law spell these out. In plain terms, a person can:
- Ask what data you hold about them and why
- Get a copy of their data
- Correct data that’s wrong or out of date
- Ask you to delete their data (the “right to be forgotten”)
- Withdraw consent they gave earlier
- Restrict or pause how you process their data
- Move their data to another provider
These provisions are not optional marketing options. True compliance requires that data subject rights be fully facilitated through engineered backend systems and tested workflows, rather than merely referenced inside a static privacy policy.
The 72-Hour Rule Explained
Here’s the part that catches companies off guard. For certain requests, you don’t have weeks to respond. You have three days.
Whenever an individual submits a formal data subject access request, the obligation to locate, verify, and fulfill the request must be completed within 3×24 hours.
According to the Future of Privacy Forum’s analysis of the law, organisations have just 72 hours to respond to specific data subject requests such as access, correction, and restriction. Law firm ARMA Law confirms the same: when a person requests these actions, the obligation is to comply within 3×24 hours of the request.
To put that in context, Europe’s GDPR generally gives companies a full month to respond to the same kind of request. Indonesia’s window is far tighter. The UAE’s law allows 14 days. UU PDP’s 72 hours is one of the strictest response times of any major data protection regime.
It’s easy to mix these up. UU PDP has two separate 72-hour deadlines:
- Data subject requests: responding to a customer asking for access, correction, or restriction.
- Breach notification: telling the regulator and affected people after a data breach.
This article is about the first one. Both run on a 3×24 hour clock, but they’re triggered by different events.
Why This Is Hard for Fintech and E-Commerce
Plenty of businesses could handle a data request in 72 hours if they got one a month. The problem is scale and sprawl.
1. Requests come in volume
A single request is easy. A hundred a week is a different problem.
After a campaign or a privacy scare, requests can flood in. The manual process can’t keep up: support emails engineering to pull the data, then marketing to remove it, then tries to confirm it all happened. That chain works once. Run it fifty times and things slip. Emails get buried, someone’s on leave, a team forgets to reply, and the 72-hour clock quietly runs out.
2. Customer data is scattered
This is the real challenge. As Adaptist points out, deleting someone’s data isn’t as simple as removing one row from one database. A single customer’s information is usually spread across many systems: the main user database, the CRM, the marketing tools, customer support records, and backups.
To honour a deletion request properly, you have to find and act on that person’s data in every one of those places, consistently. Miss one system, and you haven’t actually complied.
3. The clock doesn’t care about weekends
Seventy-two hours is seventy-two hours. The law counts calendar hours, not working days, so the deadline runs through nights, weekends, and holidays. A request that lands at 6pm Friday is nearly a day gone by Monday morning.
If the right person is away or it sits unread in a shared inbox, you can miss the deadline without anyone making a mistake. The time just runs out. An automated system doesn’t take weekends off: it logs the request, starts the timer, and begins the work the moment it arrives.
How to Automate the 72-Hour Response
To secure compliance across a compressed, repeatable timeline, technical teams must design out human dependencies. A mature, automated architecture relies on four core pillars:
- Unified intake architecture: Establish a single programmatic entry point, such as an in-app portal or a dedicated web form, that automatically records the initial submission timestamp and initiates the countdown.
- Ironclad identity verification: Speed must never result in unauthorised data exposure. The system must dynamically verify the requester’s identity before any analytical data is compiled, modified, or permanently deleted.
- Orchestrated API propagation: Deploying enterprise-grade DSAR automation ensures that once a request passes identity validation, an orchestration engine simultaneously propagates the required action across all internal databases, third-party software-as-a-service (SaaS) tools, and cloud storage layers, eliminating the risk of manual handoff failures.
- Immutable audit logs: Maintain a precise, timestamped record of the entire lifecycle, logging when the request arrived, how identity was verified, which systems were modified, and exactly when completion was achieved. If a regulatory audit occurs, this historical log serves as your definitive proof of compliance.
What Happens If You Miss the Deadline
Ignoring these rules carries real cost. UU PDP allows administrative penalties that escalate from a written warning, to an order to stop processing data, up to a fine of as much as 2% of a company’s annual revenue, as set out in the law’s summary by the US Library of Congress.
For a fintech or e-commerce business, there’s a second cost that doesn’t show up on a penalty notice: trust. A customer who asks for their data and gets silence is a customer who stops believing you handle their information with care.
Build the System Before the Requests Arrive
Three days sounds like enough time, right up until a deletion request has to reach six different systems and someone has to prove it happened. The companies that handle this well aren’t faster on the day. They built the system before the requests started coming in.
That’s the work we do at Zentara.
We help Indonesian fintech and e-commerce teams turn data protection rules into systems that run on their own, so a 72-hour deadline becomes a routine process instead of a scramble. Our VAPT testing also checks that the systems holding your customer data can stand up to a real attack.
If you’re not sure your current setup could meet the 72-hour rule at scale, that’s worth finding out now rather than after the first complaint. Talk to the Zentara team for a clear picture of where you stand and what to build first.
