PP 33/2026 Pelindungan Data Pribadi: A Developer Guide

Every summary I saw of PP 33/2026 opened with the same three numbers: a 3x24-hour breach notice, a 2% fine ceiling and a data protection officer. They read like new burdens. Before writing any ticket for them I wanted to know which of those the regulation actually introduced, and which were already sitting in Law 27 of 2022.

This post reads the regulation article by article against the 2022 law, then turns the parts an engineer can act on into code. It is a different angle from the existing UU PDP posts, which cover the law and AI features; this one is about the implementing regulation. Research date: 17 October 2026.

What PP 33/2026 is, checked by its title

The instrument is Peraturan Pemerintah Nomor 33 Tahun 2026 tentang Peraturan Pelaksanaan Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi. The full text records that it was set in Jakarta on 16 July 2026, promulgated the same day, and published as Lembaran Negara Republik Indonesia Tahun 2026 Nomor 88. Meridian Hukum lists the same gazette number plus Tambahan Lembaran Negara 7190.

Pasal 225 says it takes effect six months after promulgation. Counting from 16 July 2026 gives 16 January 2027, which is also the date Katadata gives. ABNR counts 225 articles in 12 chapters, and the chapter headings in the text I read agree: general provisions, personal data categories, processing, rights and duties, cross-border transfer, international cooperation, public participation, supervision, administrative sanctions, dispute resolution, transition and closing.

The preamble says it exists to carry out ten delegations the 2022 law left open: objections to automated processing, compensation, portability, processing implementation, impact assessments, mergers, data protection officers, cross-border transfer, sanction procedure and the agency's powers. That list is the useful frame. The regulation is mostly procedure, and procedure is what turns into tickets.

Which headline numbers are actually new

I put the five most quoted items side by side with the 2022 law, using the BPK PDF of UU 27/2022 for the left column and the full regulation text for the right.

So the 3x24-hour notice, the 2% ceiling and the DPO triggers are carried over from the law, and the claim that notification is required regardless of severity describes wording that Pasal 46 already had: neither article mentions a severity threshold. That is a correction to how the regulation is sold, not a reason to relax. What is new is everything that turns a duty into something an auditor can test: when the clock starts, what the record contains, how a fine is built.

The breach clock, Pasal 114 to 119

Pasal 114 requires written notice to the data subject and to the agency within 3x24 jam, and Pasal 114(3) sets three minimum contents: which data was exposed, when and how, and what you are doing about it. Pasal 114(4) adds the DPO or designated contact. Pasal 116 then requires documentation of the incident and says it is submitted to the agency, and Pasal 117 requires a written policy covering roles, classification, documentation, reporting and periodic review.

The sentence that matters for engineers is in the explanation of Pasal 114(2): a controller is treated as knowing the failure pasti, patut, dan wajar based on the conclusion in the documentation it produced about the incident. The start of the clock is therefore a recorded decision. That makes the timestamp and its reasoning a data model problem, not a legal footnote.

// incident-record.ts
// The record Pasal 116(1) says you must be able to hand to the Lembaga,
// plus the contact Pasal 114(4) says every notice must carry.
export type PdpIncident = {
  id: string;
  protectedData: string[]; // 116(1)a: which personal data was protected
  description: string; // 116(1)b: what happened, when and how
  impact: string; // 116(1)c: effect on data subjects and on you
  response: string[]; // 116(1)d: handling and recovery done, running, planned
  contact: string; // 114(4): the DPO or the designated contact

  // Pasal 114(2) starts the clock when the failure is known "secara pasti,
  // patut, dan wajar". The Penjelasan says that is judged from the
  // documentation YOU produced about the incident. So this field is a decision
  // you record with a name and a reason, not the instant an alert fired.
  establishedAt: string; // ISO 8601
  establishedBy: string;
  establishedBecause: string;

  notifiedSubjectsAt?: string; // 114(1)a
  notifiedAuthorityAt?: string; // 114(1)b - the Lembaga, see section 7
  notifiedPublicAt?: string; // 115: only for public-service or serious public impact
};

// "3 x 24 (tiga kali dua puluh empat) jam" is 72 elapsed hours as written.
// The text I read does not say business days.
const NOTICE_WINDOW_MS = 3 * 24 * 60 * 60 * 1000;

export function noticeDeadline(i: PdpIncident): Date {
  return new Date(Date.parse(i.establishedAt) + NOTICE_WINDOW_MS);
}

export function isOverdue(i: PdpIncident, now = new Date()): boolean {
  const late = now.getTime() > noticeDeadline(i).getTime();
  return late && !(i.notifiedSubjectsAt && i.notifiedAuthorityAt);
}

// Wrong: backfill establishedAt to the day the postmortem was signed.
//   Nothing in Pasal 114 says that is "wajar", and the evidence of when you
//   knew is your own ticket history.
// Right: write establishedAt in the incident ticket at the time of the
//   decision, with the reason, and let the postmortem refer to it.

Two more rules sit close by. A processor must report a failure to the controller pada kesempatan pertama, at the first opportunity (Pasal 118), so your processor contracts need an explicit hand-off time. Pasal 115 requires public notice when a failure disrupts public service or has serious impact on the public. Pasal 119 leaves further detail on notification to an agency regulation, which I could not read because it does not exist yet.

Rights deadlines, records and defaults

The part of the regulation that most changes a backlog is not the breach article. It is a set of fixed 3x24 jam deadlines on data subject requests, plus a records duty with a minimum field list. I read each of these in the full text.

One tension is worth flagging. Pasal 77(2) lets you grant access after verifying the request, but Pasal 77(1) counts the 3x24 jam from receipt. I read that as verification having to fit inside the window, not pausing it, and I would build the timer that way until the agency says otherwise. ABNR describes the periods as generally running from receipt and, where applicable, verification, so treat my stricter timer as a design choice.

-- data_subject_request.sql (PostgreSQL)
-- One timer for the four 3 x 24 jam duties: correction (Pasal 71), access
-- (77), stopping after consent withdrawal (92), restriction (99).
create table data_subject_request (
  id           bigserial primary key,
  kind         text not null check (kind in ('correct','access','withdraw','restrict')),
  subject_ref  text not null,
  received_at  timestamptz not null default now(),
  verified_at  timestamptz,          -- verification is a step, not a pause button
  fulfilled_at timestamptz
);

-- Run this every hour and page whoever owns the queue.
-- The clock is received_at, not verified_at: Pasal 71(1), 77(1), 92(2) and
-- 99(1) all count "terhitung sejak ... menerima permintaan".
select id, kind, received_at,
       received_at + interval '72 hours' as due_at
from   data_subject_request
where  fulfilled_at is null
  and  now() > received_at + interval '72 hours'
order  by received_at;

What the regulation means for AI features

The regulation touches AI in two places. Pasal 93 defines the objection right with examples: a decision has legal effect if it affects legal status or rights, such as a visa refusal, and significant effect if it greatly affects life, behaviour or choices, such as credit refusal, job rejection or differential pricing based on personal data. Pasal 94 then requires a mechanism to answer objections, adequate information about the technology and its consequences, and, when a verified objection is accepted, an alternative involving human intervention.

The second place is the DPIA. Pasal 120(2) lists automated decisions with legal or significant effect, and the new technology case, which the explanation says includes artificial intelligence and machine learning. So an AI feature that scores, ranks or prices people is a DPIA case by the text, before any agency regulation arrives. The code below is the minimum I would log to be able to answer an objection.

// automated-decision-log.ts
// What Pasal 93-95 and 120 push an AI feature to be able to show.
export type AutomatedDecision = {
  id: string;
  subjectRef: string;
  feature: string; // e.g. "credit-prescreen", "cv-ranking", "dynamic-price"
  modelVersion: string;
  solelyAutomated: boolean; // 93: the right covers decisions "hanya didasarkan"
  effect: "legal" | "significant" | "none"; // 93: akibat hukum / berdampak signifikan
  inputsSummary: string[]; // which personal data categories fed the decision
  outcome: string;
  decidedAt: string;
  objection?: {
    receivedAt: string;
    accepted: boolean | null; // null = still being assessed
    humanReviewerRef?: string; // 94(3): accepted objection -> human involvement
    outcomeAfterReview?: string;
  };
};

// Pasal 94(3): when a verified objection is accepted, offer an alternative
// that involves a person and/or does not rest on the automated result.
export function requiresHumanPath(d: AutomatedDecision): boolean {
  return Boolean(d.objection?.accepted) && !d.objection?.humanReviewerRef;
}

// Pasal 95(1) lets you refuse an objection only when BOTH hold:
//   a. there is no legal or significant effect, and
//   b. you have very accurate systems and mitigation.
// So "effect: none" must be a reasoned entry, never the default.

Pasal 95 allows refusing an objection only when both conditions hold: no legal or significant effect, and a system with very good accuracy and mitigation. Pasal 96 leaves detail on automated processing to an agency regulation, so ABNR is right that parts are left for later, but the right, the human alternative and the DPIA trigger are already written.

DPO and cross-border transfer

Pasal 142 requires a DPO, which the regulation calls PPDP, from controllers and processors in three cases: public service processing, core activities needing regular and systematic large-scale monitoring, or core activities consisting of large-scale processing of specific or criminal-offence data. Pasal 144 says the duty must consider structure, size and needs, and that the DPO can be one person or several, from inside or outside the organisation. Pasal 146 requires independence, access to top management, adequate resources, and no conflict of interest.

Cross-border transfer is the other gate an engineering team meets. Pasal 160 defines a transfer as making personal data available to a controller or processor outside Indonesian jurisdiction. By my reading that covers a foreign-hosted analytics, support or LLM API that receives personal data. Pasal 165 sets three tiers, tried in order.

Before any of the tiers, Pasal 161 asks for a mapped transfer cycle, data limited to what the purpose needs, an identified legal instrument, an effectiveness assessment before transfer and periodic re-evaluation, and Pasal 162 lists the data format as a factor, including whether it travels as plain text, masked or encrypted. That is a reason to redact before the request leaves your network, which is also the cheapest control you own.

The failure mode: a regulator that does not exist yet

The notices in Pasal 114 go to the Lembaga, the agency the PDP Law creates. ABNR, writing on 15 September 2026, says that agency is to be created by Presidential Regulation, that none had been issued, and that until then the Directorate General of Digital Space Supervision under KOMDIGI administers personal data protection matters. I could not verify that statement against a primary source, so treat it as dated reporting.

The consequence is structural. In the full text I counted 34 sentences that delegate detail to a Peraturan Lembaga, while ABNR says about 30 provisions need agency regulations. I did not reconcile the two counts. Pasal 223 says that until those regulations exist, processing is allowed so long as it does not contradict the regulation, and Pasal 224 keeps existing rules in force where consistent. So the substantive duties arrive on 16 January 2027 while the channels, forms and thresholds do not.

The trade-off is cost against rework. Building the timers, records and logs now costs engineering time against rules that an agency may still reshape. Waiting costs a scramble in January. I would build the pieces that are already fully specified, the deadlines, the records and the incident record, and leave the pieces that depend on the agency, such as forms and country lists, as configuration.

What to do on Monday

None of this needs the agency. Six things can be started this week, in this order, and each produces something a reviewer can open.

1. Read the signed text for the articles named above and note any difference from this post. Mark the date you checked.
2. Write a ropa.yaml entry for every processing activity, using the thirteen fields of Pasal 74(2). Start with the ones that call an external API.
3. Add the 72-hour timer to correction, access, consent withdrawal and restriction requests, and alert on overdue items.
4. Add establishedAt, establishedBy and establishedBecause to your incident template, and add the processor hand-off time to every processor contract.
5. Run a DPIA for each AI feature that scores, ranks or prices people, using the four contents of Pasal 121(2).
6. List every foreign vendor that receives personal data and record which tier of Pasal 165 you rely on, even if the answer is still unknown.

# ropa.yaml - one entry per processing activity, kept in the repo.
# The thirteen keys are the minimum list in Pasal 74(2) a-m. Pasal 74(7)
# says update it when any of them changes, so review it in the same pull
# request that changes the processing.
- activity: "support-chat-summarisation"
  controller: { name: "PT Contoh Digital", contact: "privacy@example.co.id" }  # a
  dpo_contact: "dpo@example.co.id"                                              # b
  collected_from: ["customer chat widget"]                                     # c
  sent_to: ["LLM API (hosted outside Indonesia)"]                              # c
  lawful_basis: "consent"                                                      # d
  purpose: "summarise a support conversation for the agent"                    # e
  data_types: ["name", "email", "order id", "free-text message"]               # f
  subject_categories: ["customers"]                                            # g
  other_parties_with_access: ["LLM API vendor", "support contractor"]          # h
  rights_handling: "DSR queue, 72h timer, owner: support-lead"                 # i
  data_flow_map: "docs/flows/support-chat.md"                                  # j
  retention: "transcripts 90 days, summaries 30 days"                          # k
  security_measures: ["TLS 1.2+", "field-level redaction of card numbers"]     # l
  transfers_abroad:                                                            # m
    - { to: "LLM API vendor", instrument: "to be assessed (Pasal 162)", assessed_on: null }
  dpia_required: true   # automated outputs plus new technology: Pasal 120(2)

The record below is the artefact I would start with, because it feeds three other duties: the DPIA flag, the transfer inventory and the rights timer.

PP 33/2026 does not make Indonesian privacy law stricter in the places the headlines point to, because the 3x24 jam notice, the 2% ceiling and the DPO triggers were already in the 2022 law. It makes them testable: a defined clock start, fixed rights deadlines, a records list and an AI objection route. Build to the testable parts now and treat the agency-dependent parts as configuration.

Related reading on this site

• UU PDP compliance checklist for AI features
• UU PDP compliance guide for developers in Indonesia