Key takeaways

UU PDP has no equivalent of GDPR Article 28. No provision mandates a standard data processing agreement form, so a written agreement is your evidence, not a separate obligation.
Pasal 51 keeps responsibility for the processing with the controller while the processor follows instruction, and moves it to the processor the moment the processor steps outside that instruction and purpose.
A processor must obtain the controller's written consent before engaging another processor. The statute does not say whether a standing list satisfies this.
A GDPR-style agreement usually already covers instruction, security, and records, but it almost always falls short on two points: the 3x24 hour breach notice to both the authority and the data subject, and a basis for transferring data out of Indonesia under Pasal 56.

The question usually reaches us in this shape: a vendor refuses to sign a UU PDP data processing agreement and offers GDPR terms in the contract instead. The answer may be a relief. UU PDP has no provision equivalent to GDPR Article 28, so there is no mandatory DPA form to satisfy, and a GDPR-style agreement generally gives you more than Indonesian law asks for. What needs checking is the two gaps that are almost always left open, and neither has anything to do with what the document is called.

The provision that actually governs the controller and processor relationship is Pasal 51 of Law No. 27 of 2022, not Pasal 56, which governs transfers outside Indonesian jurisdiction. The distinction matters because the two articles say very different things.

UU PDP requires a clear instruction, not a document with a particular name

Pasal 51 ayat (1) states that where a controller appoints a processor, the processor must process personal data on the controller's instruction. The word "agreement" does not appear, and there is no list of mandatory clauses of the kind you find in GDPR Article 28(3). What the statute asks for is that an instruction exists, and that you can show what was in it when asked.

That is why a written agreement remains the most practical way to comply. Not because UU PDP names one, but because a verbal instruction cannot be evidenced two years later when a regulator asks what purpose customer data was sent to a vendor for. The difference in mindset is real: under GDPR you satisfy a clause list, under UU PDP you prove where the instruction ended.

The four Pasal 51 rules that decide who carries what

The rest of Pasal 51 allocates responsibility, and this is where its practical value sits. Ayat (3) states that processing carried out by the processor falls within the controller's responsibility. Ayat (4) allows a processor to involve another processor, and ayat (5) requires the controller's written consent before it does. Ayat (6) is the counterpart: if the processor processes data outside the instruction and purpose the controller set, responsibility for that processing moves to the processor.

Ayat (6) only helps when the instruction was specific. If the scope you wrote reads "process customer data for service purposes", almost anything the vendor does can be argued to sit inside the instruction, and the responsibility stays with you.

The controller duties that travel to the processor

Pasal 52 closes a gap that is easy to miss. The controller obligations in Pasal 29, Pasal 31, Pasal 35, Pasal 36, Pasal 37, Pasal 38, and Pasal 39 apply to processors as well. In order, those are: ensuring the accuracy, completeness, and consistency of the data; recording all processing activity; protecting and securing the data through technical and operational measures and setting the security level against the nature and risk of the data; maintaining confidentiality; supervising every party involved in processing under the controller's control; protecting data from unlawful processing; and preventing unauthorised access.

So your processor carries those duties directly from the statute, whatever the contract says. A good contract restates them so they are enforceable between the parties, but a bad contract does not remove them.

Now the part that prompted the question. A GDPR-style data processing agreement is built around documented instructions, security measures, processing records, and sub-processor restrictions. All of that meets, and in places exceeds, what Pasal 51 and Pasal 52 ask for. Refusing such an agreement because it does not mention UU PDP is a refusal of the name, not of the substance.

Two things are usually left uncovered, and both belong in an Indonesia-specific annex.

The first is breach notification. Pasal 46 ayat (1) requires written notice within 3x24 hours to the data subject and to the authority. GDPR gives 72 hours to the supervisory authority and reaches data subjects only where the risk is high. A clause drafted for GDPR therefore gives you a longer clock and fewer recipients than Indonesian law requires. Pasal 46 ayat (2) also sets the minimum content of that notice: the personal data that was exposed, when and how it was exposed, and the controller's handling and recovery efforts. If your processor only tells you on day three, the deadline is already unreachable.

The second is transfers. The transfer annex in a GDPR agreement addresses data leaving the European Union, which is an entirely different question from data leaving Indonesia.

Transfers out of Indonesia sit separately in Pasal 56

Pasal 56 works as a cascade, and the order binds. Ayat (2) is the first test: the country where the recipient is domiciled must have a level of personal data protection equal to or higher than UU PDP. Where that is not met, ayat (3) requires adequate and binding personal data protection. Where neither is met, ayat (4) requires the data subject's consent. Ayat (5) leaves the further detail to a government regulation.

In practice, what you need on file is which step you are relying on for each destination. An agreement that says only "transfers are made in accordance with applicable regulations" does not answer that, and will not help when the question comes from a regulator. For the wider comparison between the two regimes, see UU PDP and GDPR.

What we check before an agreement is signed

The review order is simple and the first step needs no lawyer. Is the processing purpose specific enough that you could show when the vendor stepped outside it. Is there a written consent mechanism for sub-processors, and are those consents actually kept. Is the vendor's incident notice deadline to you shorter than 3x24 hours. Pasal 46 does not say when that clock starts, so the safe reading is from the failure itself rather than from the moment the vendor told you. Are the transfer destinations named, and is the Pasal 56 step identified for each.

Those four questions settle most of the DPA disputes we see. Banks and financial institutions face an additional layer from the POJK regime, which we set out in UU PDP compliance for banking and finance.

The key question, then, is not whether a vendor agreement is formally labelled a DPA. It is whether the agreement documents the responsibilities UU PDP places on the controller and the processor. For organisations in Indonesia, a well drafted DPA or vendor agreement is the practical way to hold processing instructions, security requirements, sub-processors, personal data breaches, and cross-border transfers in one place, in the form the law actually asks for.

References

Law Number 27 of 2022 on Personal Data Protection, BPK RI regulation database. Pasal 51 and 52 govern the controller and processor relationship, Pasal 46 governs breach notification, and Pasal 56 governs transfers outside Indonesian jurisdiction.
General Data Protection Regulation (Regulation EU 2016/679) Article 28, GDPR.eu, for the mandatory clause list in a GDPR data processing agreement.
GDPR Articles 33 and 34, GDPR.eu, for the breach notification comparison.