3x24-Hour Data Requests: Get Your Website Ready for PP 33/2026

A customer sends a short message: "Please send me a copy of my data, and fix the wrong email address." On paper, Indonesia's Personal Data Protection Law (UU PDP) gives you 3x24 hours to fulfill part of that request — not three business days, not "next week". For an online store owner whose only complaint channels are an Instagram DM and an admin inbox, this 3x24-hour data subject request deadline is an underappreciated risk: the rule is already in the statute, and its enforcement machinery comes fully online through GR 33/2026 on 16 January 2027.

The good news: meeting this deadline is not about a large budget, it is about measurement — when the request arrived, when you responded, and evidence that both happened. This article breaks down which articles set the clock, how to count it, and the minimal system a small team can build in a matter of weeks.

1. The Three Articles That Set a 3x24-Hour Clock

Law 27/2022 does not attach a uniform deadline to every data subject right. Three obligations are explicitly bound to the 3x24-hour clock:

• Article 30 — correction and updating. The controller must update or correct errors and inaccuracies in personal data within 3x24 hours of receiving the request, then notify the data subject of the result.
• Article 32 — access and copies. The controller must provide access to personal data along with its processing record within 3x24 hours of receiving the access request.
• Article 46 — breach notification. When an incident occurs, written notification must go out within 3x24 hours to two audiences at once: the data subject and the supervisory authority.

Two details are easy to miss. First, Article 33 provides grounds to refuse access or changes — when fulfilling the request would endanger the safety of the subject or others, expose someone else's data, or conflict with national defense and security. Refusals still have to be documented and explainable. Second, Article 31 requires recording all processing activities — that processing record is exactly what you must hand over within 3x24 hours when an access request arrives, so it cannot be prepared in a panic at request time.

Other rights, such as erasure and portability, have no explicit statutory deadline yet, but they still need a documented procedure, because the supervisory authority will judge whether your response was reasonable.

2. Why GR 33/2026 Makes This Deadline Impossible to Ignore

During the transition period, the 3x24-hour deadline existed on paper without a tidy enforcement mechanism. GR 33/2026 — promulgated on 16 July 2026 and effective 16 January 2027 — fills that gap: the personal data protection authority begins supervising, and administrative sanctions take the form of written warnings, temporary suspension of processing, erasure of data, and fines up to 2% of annual revenue.

Three details change how you should read the deadline. Sanctions can be imposed cumulatively and are not always preceded by a warning. The fine is determined by ten variables — including business scale and compliance history — so being a small business is not immunity, it is a mitigating factor. And sanction decisions are announced publicly; the reputational effect often outlasts the fine.

There is no additional transition period after 16 January 2027. If you are still assembling the foundation, start with the PP 33/2026 website compliance checklist — then treat the 3x24-hour deadline as an SLA to be measured, not a good intention.

3. Counting the 3x24 Hours: When the Clock Starts

The statutory wording is precise: "counted from when the Data Controller receives the request." Three practical consequences:

• Calendar hours, not business hours. A request that lands Friday evening is due Monday evening — the weekend does not pause the count. A two-person support team carries the same obligation as a large company.
• "Received" needs a timestamp. An email the business owner happens to read on Tuesday when it arrived on Saturday still counts from Saturday. That is why a formal intake channel (a form, not a DM) is not bureaucracy — it is protection.
• Identity verification shares the same clock. You are not obliged to hand data to the wrong person, but verification must be fast — a confirmation link to the registered email or an OTP to the phone number already in your database, not a multi-day manual process.

Minimal practice: every request records received_at automatically from the form submission time, and the system sends an internal reminder at T-12 hours before the deadline. Those twelve hours are the difference between a punctual response and a late report.

4. Building a Measurable Data Subject Request Channel

A credible channel has three components: an entrance that timestamps, a verification step, and a trackable ticket. The intake form minimally captures: request type (access, correction, erasure, portability), verifiable identity, and a case description. Behind it, a single ticket table is enough for any small team:

CREATE TABLE dsr_tickets (
  id UUID PRIMARY KEY,
  requester_email TEXT NOT NULL,
  request_type VARCHAR(30) NOT NULL,  -- access | correction | deletion | portability
  status VARCHAR(20) NOT NULL,        -- received | verifying | fulfilled | refused
  received_at TIMESTAMPTZ NOT NULL,
  deadline_at TIMESTAMPTZ NOT NULL,
  responded_at TIMESTAMPTZ,
  refusal_reason TEXT,
  notes TEXT
);

deadline_at is filled directly from received_at + interval '72 hours'. A daily cron (or background worker) checks tickets approaching their deadline and notifies the responsible person — one named owner, not "whoever has time". Every refusal gets a refusal_reason citing Article 33, so your compliance evidence stays one query away when the authority asks.

5. Answering Access and Correction in Hours: Data Map and Export Queries

You cannot meet a 3x24-hour deadline if you do not know where customer data lives. Build a simple data map: primary tables (users, orders, addresses, consent_records), third-party systems (payment gateways like Midtrans or Xendit that hold data as processors, email vendors, CRM), and application logs that may contain PII.

From that map, prepare a single export script that produces the subject's data in a readable format — JSON per table is fine — along with the processing record. Test that script before January, not when the first request arrives. For correction requests, the fix must propagate: caches, the CRM, email vendor lists, and data warehouse copies. The list of places to touch is better kept as configuration than as someone's memory.

Finally, separate data that genuinely cannot be deleted — transaction records required for tax obligations, for instance — and document that you anonymize instead of erasing. That answer is far more convincing than silence when the question comes.

6. A 3x24-Hour Incident Runbook for Small Teams

Notifying a data breach within 3x24 hours feels impossible to a team that has never rehearsed, and reasonable to one that has. A minimal runbook:

1. Detection — anomalous admin logins, unusual database queries, or customer reports funnel into one monitored channel.
2. Containment — rotate credentials, revoke active sessions, block suspected access.
3. Inventory — which data was exposed, how many subjects, since when.
4. Notification — send written notice to the data subject and the authority. The minimum content per Article 46: the personal data exposed, when and how it was exposed, and the containment and recovery efforts.
5. Documentation — an incident timeline for the next audit.

Keep the notification template and contact list (including the authority's channel) somewhere accessible when the main server is down — not only in the internal wiki that the breach itself took offline. Rehearse once as a drill: run from detection to a drafted notice, measure the time, fix the steps that stalled. If your website security foundation is still loose, the 2026 website security checklist is the earlier starting point.

7. Table: Request Type vs Deadline vs What Must Be Ready

Read the table as a diagnosis: rows whose right-hand column is still empty are this week's work, not December's.

8. An 11-Week Checklist Toward 16 January 2027

From today, eleven weeks remain. A realistic plan for a small team:

• Weeks 1–2 — data map and the DSR ticket table with deadline_at.
• Weeks 3–4 — the access export script, tested against real data in staging.
• Weeks 5–6 — correction propagation to caches, CRM, and vendors; documented Article 33 refusal grounds.
• Week 7 — incident runbook, notification template, and one timed drill.
• Weeks 8–9 — vendor audit: DPAs, data regions, deletion support. The GCP asia-southeast2 (Jakarta) region reduces cross-border transfer complexity.
• Week 10 — review the processing record (Article 31); install the request channel on a public page.
• Week 11 — a final end-to-end test, then freeze changes until 16 January.

If you want the conceptual base first, the practical UU PDP guide for websites and apps explains data subject rights from the product side; this article is its operational layer.

Conclusion

The 3x24-hour data subject request deadline has been in the statute since UU PDP took effect, and GR 33/2026 — effective 16 January 2027 — gives it teeth: a supervisory authority, fines up to 2% of annual revenue, and public announcements. What separates a calm business from a scrambling one is not a legal retainer, but three engineering artifacts: a request channel that timestamps, an export script that has been tested, and an incident runbook with a ready-to-send template.

At Zero Args Technology, we help UMKM and product teams in Indonesia build websites with data compliance measured in from the start — not patched on the eve of a regulatory deadline. Start a conversation if you want your data subject request channel and 3x24-hour runbook ready before January.