Obligations of controllers and processors

What the GDPR provides. GDPR Article 5(1) sets the processing principles. Point (a) requires processing to be lawful, fair and transparent in relation to the data subject, point (b) requires collection for specified, explicit and legitimate purposes, and point (c) limits the data to what is adequate, relevant and necessary for those purposes. Article 5(2) then makes the controller responsible for compliance and able to demonstrate it, which is the accountability principle.

The four adjectives in Pasal 27 line up one for one with the GDPR terms. Terbatas answers to Article 5(1)(c), spesifik to the specified purposes in Article 5(1)(b), and sah secara hukum and transparan to the lawfulness and transparency limbs of Article 5(1)(a).

What is absent from the article is the remaining limb of Article 5(1)(a), fairness, though it is not absent from the regime: PP Pasal 60 ayat (2) requires transparent processing to be carried out secara jujur dan iktikad baik, and PP Pasal 35 ayat (3) forbids asking for consent by deceptive or misleading means, which is the direct answer to the interfaces the deceptive design guidelines describe.

The difference is rank rather than presence. In the EU fairness is a principle in Article 5(1)(a) that reaches every basis and every stage; in Indonesia it arrives as a qualifier on transparency and on consent gathering. Article 5(2) accountability has no home in Pasal 27 either, and the nearest Indonesian equivalent is not the recording duty at Pasal 31 but UU Pasal 16 ayat (2) huruf h, which requires processing to be bertanggung jawab dan dapat dibuktikan secara jelas.

Minimisation is where the EU line has moved most: C-446/21 held that Article 5(1)(c) precludes data being aggregated, analysed and processed for targeted advertising without restriction as to time and without distinction as to type of data, and C-439/19 shows the same principles limiting a public register even where a statute authorises the disclosure.

PP Pasal 59 makes that argument operative in Indonesia, since it defines terbatas dan spesifik as minimisation and sets three tests, relationship to the purpose, sufficiency for the purpose, and no excess beyond what the purpose needs.

What the GDPR provides. Purpose limitation in GDPR Article 5(1)(b) has two halves. Data must be collected for specified, explicit and legitimate purposes and must not be further processed in a manner incompatible with them, and the same provision deems further processing for archiving in the public interest, scientific or historical research or statistical purposes not incompatible, where the safeguards in GDPR Article 89(1) are in place.

GDPR Article 6(4) supplies the compatibility test where the reuse rests neither on the data subject's consent nor on a Union or member state law of the kind it describes, weighing the link between the purposes, the context of collection, the nature of the data, the consequences for the subject, and safeguards such as encryption or pseudonymisation.

UU Pasal 28 carries only the first half of the idea. The second half, the bar on further processing incompatible with the original purpose, has no Indonesian counterpart at either level.

PP Pasal 68 is a documentation duty, requiring the purpose and its changes to be recorded and stated in the internal policy and the privacy notice, and PP Pasal 67 ayat (4) sends a controller with an additional or new purpose back to the requirements of the regulation itself rather than to a compatibility test.

So whether analytics or model training can ride on an existing purpose has no operative test in Indonesia, where the GDPR answers it inside Article 6(4). Indonesia adds something the GDPR does not carry: PP Pasal 67 ayat (2) huruf b requires the purpose to be set against the balance of the data subject's interests, which pulls a weighing exercise into purpose specification.

On the EU side the compatibility route is narrower than it looks, but not because of the collection basis. GDPR Article 6(4) opens where the further processing is not based on consent or on a qualifying Union or member state law, and Recital 50 confirms that consent to the new purpose removes the need for any compatibility assessment.

The constraint on a controller that collected on consent comes from the consent rules instead: EDPB Guidelines 05/2020 paragraph 58 requires additional consent for a new purpose unless another basis better reflects the situation, and paragraph 123 forbids swapping out of consent.

Because consent is the dominant basis in Indonesian practice under Pasal 20, that limit will bite hard on secondary use if the PP is read the same way, and C-175/20 shows how tightly the Court holds a public authority collecting data afresh to the specific purposes stated in its own request and to the period strictly necessary.

What the GDPR provides. GDPR Article 5(1)(d) requires personal data to be accurate and, where necessary, kept up to date. The duty is framed as an obligation of means: every reasonable step must be taken to erase or rectify inaccurate data without delay, having regard to the purposes for which it is processed. There is no standalone duty to verify, and completeness and consistency are not named as separate qualities.

Article 16 supplies the subject-driven counterpart, including completion of incomplete data by a supplementary statement.

Article 5(1)(d) is purpose relative, so the reasonable steps to erase or rectify are measured against what the data is used for. C-434/16 is the clearest statement of that logic, holding that a candidate's written answers at a professional examination are personal data whose accuracy is assessed for what the record is, not for whether the answers were correct.

UU Pasal 29 ayat (1) carries no such qualifier and adds kelengkapan and konsistensi as duties in their own right, and ayat (2) converts a standard into a process by making verification freestanding. That inverts the burden of design: an EU controller argues that no reasonable step was called for here, while an Indonesian controller has to show the verification happened, and UU Pasal 57 ayat (1) lists Pasal 29 among the provisions carrying administrative sanction.

The benchmark is not blank. PP Pasal 69 ayat (3) makes the controller fix the mechanism or data quality standard first, ayat (5) sets a floor of four things every verification must reach, the truth or trustworthiness of the data, its completeness against the purpose, uniformity of form or format, and how often verification is needed, ayat (4) makes it periodic or ad hoc, and ayat (8) requires the result to be documented.

What ayat (9) defers to a Peraturan Lembaga is implementation, so the open question is how a regulator will test a controller's own standard, not what the duty covers.

What the GDPR provides. GDPR Article 16 gives the data subject a right to have inaccurate data rectified without undue delay and incomplete data completed, including by a supplementary statement. Article 12(3) sets the outer clock: the controller must tell the subject what action it took within one month of receiving the request, extendable by two further months for complex or numerous requests provided the subject is told of the extension and the reasons within the first month.

Article 12(6) lets the controller ask for further information first where it has reasonable doubts about the requester's identity. Article 19 then requires the correction to be passed to each recipient of the data unless that proves impossible or disproportionate, and the recipients to be named to the subject on request.

The gap is not only the length of the clock but what has to fit inside it.

Under GDPR Article 12(3) the month absorbs identity checking under GDPR Article 12(6), the assessment of whether the data really is inaccurate, and the reply, and how contested that middle step becomes is visible in C-460/20, where the Court held that a search engine operator answering a de-referencing request cannot be required to investigate the facts and that the requester must establish the manifest inaccuracy of the content.

UU Pasal 30 leaves the same work inside 3 x 24 jam with no extension mechanism, where GDPR Article 12(3) allows two further months for complex or numerous requests, and with no identity check provision of the Article 12(6) kind.

C-434/16 marks the cost of a fast clock, since rectification reaches the record and not the substance of what was recorded, so a controller that simply complies alters something it was never obliged to alter. The assessment step itself is not missing on the Indonesian side.

PP Pasal 71 ayat (2) requires the controller to verify the exercise of the right against the purpose of processing, ayat (3) makes replacement follow that verification, ayat (5) allows refusal, ayat (7) requires the refusal and its reasons to be notified, and ayat (4) allows a supplementary note where the original data cannot be replaced, which answers the supplementary statement in GDPR Article 16.

Downstream the two regimes end up close. UU Pasal 30 ayat (2) stops at telling the subject, but PP Pasal 72 ayat (1) carries the correction on to other controllers and processors and ayat (2) carries the same escape as GDPR Article 19 where transmission is impossible or involves disproportionate effort. What the PP does not carry is the second half of Article 19, the right of the data subject to be told who those recipients were.

What the GDPR provides. GDPR Article 30 requires a written register, not a log. A controller records the purposes of processing, the categories of data subjects and of personal data, the categories of recipients, transfers to third countries with the safeguards relied on, the envisaged erasure time limits where possible, and a general description of the security measures.

Article 30(2) sets a shorter list for processors, and Article 30(4) makes the register available to the supervisory authority on request. Article 30(5) exempts an organisation employing fewer than 250 persons unless the processing is likely to risk rights and freedoms, is other than occasional, or covers special category or criminal conviction data.

Two differences run here, and the exemption is only the visible one. GDPR Article 30(5) lets an enterprise or organisation employing fewer than 250 persons keep no register, but the relief falls away where the processing is not occasional, where it is likely to result in a risk to rights and freedoms, or where it covers special category or criminal conviction data, and it lifts the register duty alone rather than anything else in the Regulation.

The Indonesian text grants no relief at any size. The second difference is what is being recorded. GDPR Article 30 is an inventory of processing operations, written once and kept current, whereas perekaman terhadap seluruh kegiatan pemrosesan reads naturally as capturing every processing event, which is a duty of a different order and cost.

PP Pasal 74 ayat (2) settles that as an inventory of thirteen fields, and huruf k already carries Masa Retensi, which is the envisaged erasure time limit that GDPR Article 30(1)(f) folds into the register, with PP Pasal 75 adding a separate retention policy document on top.

The role split survives, but by a different route: GDPR Article 30(2) binds the processor in its own name and GDPR Article 30(4) puts the register in front of the supervisory authority on request, while PP Pasal 74 ayat (3) and ayat (5) make the Pengendali ensure the Prosesor records and prescribe the shorter processor list, so the processor duty runs through the controller rather than directly.

What the GDPR provides. GDPR Article 15(1) gives the data subject confirmation of whether their data is processed and, where it is, access to the data plus a prescribed set of information: purposes, categories of data, recipients or categories of recipients, retention period, the existence of the other rights, the source where the data did not come from the subject, and the logic of automated decision-making.

Article 15(3) adds a right to a copy of the data undergoing processing, the first copy free of charge. Article 15(4) cuts the copy back where it would adversely affect the rights and freedoms of others. The reply is due under Article 12(3) within one month, extendable by two.

Both provisions give access to the data and to something about how it was handled, but the second half was defined very differently.

Article 15 lists metadata and its edges had to be litigated: C-154/21 turned categories of recipients into the actual identity of recipients where the subject asks, C-487/21 made a copy mean a faithful and intelligible reproduction rather than a summary, and C-579/21 held that consultation logs fall inside the right while the identity of the employees who consulted does not, save where that identity is essential to the exercise of the subject's rights.

UU Pasal 32 ayat (1) starts roughly where the EU arrived, with rekam jejak pemrosesan named as an object of the right and bounded by the retention period rather than by a list of fields. The limits then sit in a different place and cut harder. GDPR Article 15(4) keeps the third party ceiling inside the access right, so the controller trims what it releases and hands over the rest.

UU Pasal 32 carries no limit of its own, and the third party question is answered one article later at UU Pasal 33 huruf b, where disclosure of another person's data obliges the controller to refuse. The C-579/21 outcome, log released and names withheld, therefore has no obvious route in the Indonesian text, because the ground that narrows the answer in the EU defeats the request in Indonesia.

Timing compounds it: ayat (2) allows 3 x 24 jam to resolve questions the CJEU needed several references to settle, and the whole right depends on the Pasal 31 records duty, since a controller cannot disclose a processing history it never kept.

What the GDPR provides. The GDPR does not oblige a controller to refuse an access request. It limits the right instead, and it does so in two different ways. GDPR Article 15(4) is a ceiling that binds the controller directly: the right to obtain a copy shall not adversely affect the rights and freedoms of others, so the controller must hold back the part that would.

GDPR Article 23 is a permission addressed to the legislator, letting Union or member state law restrict Articles 12 to 22, Article 34 and the corresponding parts of Article 5 for a closed list of objectives, national security and defence among them, but only where the restriction respects the essence of the right and is necessary and proportionate.

GDPR Article 23(2) then fixes what such a law must itself contain where relevant, including the scope of the restriction, the safeguards against abuse, and the subject's right to be told a restriction applies unless telling would defeat its purpose. GDPR Article 12(4) requires the controller to tell the subject without delay and at the latest within one month why it is not acting, and to point to the supervisory authority and to judicial remedy.

The mandatory limb is the difference. UU Pasal 33 says wajib menolak, so a controller that grants access on one of the three grounds is itself in breach. The GDPR has no duty to refuse a request as such.

Article 15(4) obliges the controller to hold back only the part of a copy that would harm others, and Article 23 is a permission addressed to the legislator, not to the controller.

The route differs as much as the obligation: under GDPR Article 23 a restriction has to be created by a legislative measure carrying the Article 23(2) content list, so the controller applies a rule someone else drafted and that can be tested for necessity and proportionality, whereas UU Pasal 33 puts the three grounds in the statute and hands the assessment to the controller with no proportionality test on its face.

Limb b, disclosure of another person's data, is the limb the EU has actually litigated: C-487/21 reads GDPR Article 15(4) as requiring, wherever possible, a means of communicating the data that does not infringe the rights of others, and C-579/21 lets employee identities be withheld from log data while the log data itself is handed over, so third party data narrows what must be produced rather than defeating the request.

The national security limb has no controller side counterpart at all, because GDPR Article 23 keeps that judgement with the legislator and leaves it reviewable.

The remedy side does not close the gap either: PP Pasal 26 leaves the conditions of refusal to the controller under other legislation and PP Pasal 27 gives the subject a route to report to the Lembaga, but neither carries the GDPR Article 12(4) duty to give reasons on a one month clock or to point to a judicial remedy.

What the GDPR provides. GDPR Article 35(1) requires a data protection impact assessment before processing likely to result in a high risk to rights and freedoms, in particular where new technologies are used. GDPR Article 35(3) names three cases where one is always required: systematic and extensive automated evaluation producing legal or similarly significant effects, large scale processing of special category or criminal conviction data, and large scale systematic monitoring of a publicly accessible area.

GDPR Article 35(2), (7) and (9) add advice from the data protection officer, a fixed minimum content of description, necessity and proportionality test, risk assessment and mitigating measures, and the views of data subjects where appropriate.

GDPR Article 36(1) then requires the controller to consult the supervisory authority before processing where the assessment shows the processing would be high risk in the absence of measures taken to mitigate that risk, which recital 94 and WP248 rev.01 read as a test of the risk left after mitigation.

The seven triggers at UU Pasal 34 ayat (2) do not track GDPR Article 35(3), which names three. They correspond to the WP29 impact assessment guidelines, WP248 rev.01, whose nine criteria are evaluation or scoring, automated decision making with legal or similarly significant effect, systematic monitoring, sensitive data, large scale processing, matching or combining datasets, vulnerable data subjects, innovative use of new technology, and processing that in itself prevents subjects from exercising a right.

Eight of the nine appear in ayat (2), all but vulnerable data subjects, compressed into seven limbs because huruf d carries evaluation or scoring and systematic monitoring together, which is why the list is longer and flatter than Article 35(3).

The article stops tracking at the back half, where GDPR Article 35(4) makes every supervisory authority publish a list of processing that always needs an assessment and GDPR Article 36(1) makes consultation mandatory where mitigation has not removed the high risk, while PP Pasal 122 leaves consultation with the Lembaga to the controller's choice.

What Article 36 measures is the risk left after mitigation, so a controller that mitigates well never consults, and dropping the duty removes the single moment at which a regulator sees a failed assessment before processing starts. C-634/21, an Article 22 ruling, fixes the threshold the first Indonesian trigger uses, holding that the automated production of a probability value counts as the decision where a third party draws strongly on it.

What the GDPR provides. GDPR Article 32(1) requires the controller and the processor to implement technical and organisational measures appropriate to the risk, judged against the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing.

It names four things those measures should deliver as appropriate: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of systems and services, restoration of access after an incident, and a process for regularly testing and evaluating effectiveness. GDPR Article 32(2) sets the appropriate level by reference to the risks of accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access.

GDPR Article 32(3) lets adherence to an approved code of conduct or a certification serve as an element of proof.

Both texts calibrate security to risk and UU Pasal 35 huruf b does the work of GDPR Article 32(2), but the calibration inputs and the addressee both differ.

GDPR Article 32(1) weighs risk against the state of the art and the cost of implementation, which is what lets a supervisory authority call a measure adequate in one year and inadequate two years later, while UU Pasal 35 huruf b weighs only the nature and risk of the data, so the Indonesian standard carries no moving benchmark and no cost factor to argue from.

GDPR Article 32(1) also binds the processor directly and in its own name, where UU Pasal 35 addresses the Pengendali alone. GDPR Article 32(3) offers a demonstration route through codes of conduct and certification that has no Indonesian counterpart, so there is no pre-approved way to show the chosen security level was the right one, which throws the whole question back onto the assessment itself.

C-340/21 shows what that costs, with the burden of proving the measures were appropriate sitting on the controller and an attack succeeding not proving by itself that they were not. C-687/21 makes the same point from the other side, holding that an unauthorised disclosure by an employee does not by itself show that the measures fell short.

What the GDPR provides. The GDPR has no free-standing duty of confidentiality resting on the controller. GDPR Article 5(1)(f) pairs confidentiality with integrity and states it as a security principle, protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, by appropriate technical and organisational measures.

Secrecy as such is handled by other instruments: GDPR Article 28(3)(b) requires the processor contract to bind the processor's authorised persons to confidentiality or to an existing statutory secrecy duty, and GDPR Article 29 with Article 32(4) stops anyone acting under the controller's or the processor's authority from processing except on instructions.

GDPR Article 90 creates no secrecy duty of its own; it lets member states set out how far a supervisory authority's powers under Article 58(1)(e) and (f) reach into controllers already bound by professional secrecy.

The two provisions do different jobs behind similar words. UU Pasal 36 is a secrecy duty, keep the data confidential, stated once and owed by the Pengendali. GDPR Article 5(1)(f) is a security duty that happens to use the word confidentiality, requiring appropriate security of the data, and it is read with GDPR Article 32 rather than as an independent obligation of silence.

The GDPR's secrecy obligations reach natural persons through instruments and not directly, by contract at GDPR Article 28(3)(b) for a processor's authorised persons and by instruction at GDPR Article 29 and Article 32(4) for anyone acting under the controller's authority. That gives the two systems different failure points.

In the EU a controller that took no steps to bind its own staff to instructions breaches Article 32(4), while the leaking employee ordinarily answers to national law rather than as a controller, though Guidelines 07/2020 accept that a person who processes for their own purposes outside the organisation's activities can become a controller in their own name.

Under UU Pasal 36 the duty and the sanction land on the Pengendali whether or not any instrument exists, and PP Pasal 125 ayat (2) then folds the processor in by making the controller ensure the Prosesor can support the same confidentiality, which is the work of GDPR Article 28(3)(b) done without a contract term.

The consequence is that an EU controller answers first for the instruments it put in place, and an Indonesian one answers for the confidentiality whether or not it put any instrument in place at all.

What the GDPR provides. The GDPR imposes no free-standing duty of supervision. It imposes a duty to select, to contract and to verify: GDPR Article 28(1) lets a controller use only processors providing sufficient guarantees, Article 28(2) forbids engaging a sub-processor without prior authorisation and Article 28(4) passes the same obligations down the chain.

GDPR Article 28(3) fixes eight mandatory contract terms, including that the processor makes available all information needed to demonstrate compliance and allows and contributes to audits and inspections by the controller. GDPR Article 24(1) sits above all of it and requires measures appropriate to risk, reviewed and updated where necessary.

GDPR Article 28 attaches to a moment and to an instrument. The controller must satisfy itself before engaging the processor and must put the relationship into a binding contract carrying the Article 28(3) terms, with the audit right at Article 28(3)(h) as the checking mechanism, and the EDPB reads Article 28(1) as a continuing obligation to re-verify those guarantees at appropriate intervals.

UU Pasal 37 states the duty as a continuing one and fixes no moment, but it is not formless once the regulation is read with it: PP Pasal 126 ayat (2) names the parties covered, the Prosesor, the controller's own units and representatives, and other controllers involved, and PP Pasal 127 requires the controller to hold a processing policy, a perjanjian pemrosesan Data Pribadi setting out protection obligations and responsibilities, and a public reporting channel.

The agreement is the Indonesian counterpart of the Article 28(3) contract, though it carries no prescribed list of terms and no audit right, and PP Pasal 128 leaves the rest of the standard to a Peraturan Lembaga not yet issued. The Indonesian duty is wider in reach than Article 28, which governs processors, since it runs to internal units as well.

The GDPR reaches those people too, but by a different device, the instruction rule at Article 29 and the duty to take steps to enforce it at Article 32(4), which is narrower than supervision because it asks only whether they processed on instructions. Two judgments show what the EU does with the space instead of a supervision duty.

C-807/21 holds a controller can be fined for an infringement committed by any person acting in the course of its business and on its behalf, without identifying a natural person at fault.

C-683/21 works up the chain rather than down it, holding that a body that commissioned the development of an app can be a controller though it processed nothing itself and never consented to the release, unless it expressly objected before release, and that joint control needs no arrangement between the parties, so EU law allocates status by who decided rather than by who was supervised.

What the GDPR provides. The GDPR splits unlawful processing in two. GDPR Article 6(1) makes processing without one of the six legal bases unlawful in itself, which is a lawfulness question under GDPR Article 5(1)(a). GDPR Article 5(1)(f) is the other half and is a security duty, requiring that data be processed in a manner ensuring protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, by appropriate technical and organisational measures.

GDPR Article 5(2) makes the controller responsible for both and able to demonstrate it, and GDPR Article 24(1) requires measures appropriate to risk that are reviewed and updated.

UU Pasal 38 does not say whose unlawful processing is being guarded against, and that silence carries the article. Read as a security duty it lands on GDPR Article 5(1)(f), protection of the data from unlawful processing by others. Read as a lawfulness duty it lands on GDPR Article 5(1)(a) with Article 6(1), processing without a basis.

The tracker places it with PP Pasal 129 beside the security provisions, which resolves it the first way, and the resolution matters because the two produce different defences. A security failure is judged by whether the measures were appropriate.

A lawfulness failure is judged by whether a basis applied, which is a narrower argument, though not a closed one, since GDPR Article 6(1)(f) turns on a balancing of interests and Article 6(4) on a compatibility test.

The GDPR keeps the two apart on purpose, which is why Article 5(1)(f) has Article 32 to say how the duty is discharged while Article 6 has no equivalent article of measures, only the conditions at Articles 6(2) to (4), 7, 8 and 9.

C-340/21 shows the appropriateness route running, with the burden on the controller to prove its measures were adequate and an intrusion not proving by itself that they were not, and C-807/21 shows how far responsibility for other people's unlawful acts reaches, to any person acting in the course of the controller's business and on the controller's behalf.

What the GDPR provides. Unauthorised access is both a security question and a breach question under the GDPR. GDPR Article 32(1)(b) requires measures ensuring the ongoing confidentiality, integrity, availability and resilience of processing systems and services, and GDPR Article 32(2) names unauthorised disclosure of or access to personal data among the risks that set the appropriate level. GDPR Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of those measures.

GDPR Article 4(12) then defines a personal data breach as a breach of security leading to, among other things, unauthorised access to personal data. A security failure that lets someone in therefore engages GDPR Article 33, which requires notification to the supervisory authority without undue delay and where feasible within 72 hours of the controller becoming aware, unless the breach is unlikely to result in a risk to rights and freedoms.

GDPR Article 34 then requires the subject to be told where the risk is high.

The GDPR duty attaches to processing. The Indonesian duty attaches to the electronic system. UU Pasal 39 ayat (2) requires the system to be operated andal, aman, dan bertanggung jawab, which is the formula UU ITE Pasal 15 ayat (1) already uses for electronic system operators rather than anything drawn from GDPR Article 32, and ayat (3) then sends the reader back out to the wider legislation.

That produces an effect the two texts do not show side by side: an Indonesian controller's security question is answered partly by the electronic system regime and its sectoral rules, while an EU controller's is answered inside Article 32 and its state of the art test, with no external standard doing the work.

The second asymmetry is at the back end, where GDPR Article 32 is joined to Articles 33 and 34, so a failure of prevention is also a personal data breach under Article 4(12) and puts the controller on a clock that starts when it becomes aware, subject to the risk threshold at Article 33(1), while UU Pasal 39 stops at prevention and leaves the consequence to the notification provisions elsewhere.

C-340/21 is where both halves met, an unauthorised access at a tax authority, with the Court holding that the fact of the intrusion does not by itself prove the Article 32 measures were inadequate and that the burden of proving they were appropriate sits on the controller.

What the GDPR provides. GDPR Article 7(3) gives the subject the right to withdraw consent at any time, requires withdrawal to be as easy as giving it, preserves the lawfulness of processing carried out before withdrawal, and requires the subject to be told all of this before consenting. Withdrawal removes the legal basis, so processing after it has no ground under GDPR Article 6(1).

GDPR Article 17(1)(b) gives a right to erasure where consent is withdrawn and no other legal ground applies. GDPR Article 12(3) sets a separate clock of one month, extendable by two, for answering a request made under Articles 15 to 22.

The GDPR sets no deadline for stopping because it does not need one. Withdrawal removes the basis, so processing after that moment is already unlawful under GDPR Article 6(1), and the one month at GDPR Article 12(3) governs the reply to a request, not the cessation.

UU Pasal 40 ayat (2) grants 3x24 hours instead, which reads as fast beside a month and slow beside zero, and because PP Pasal 92 runs that clock from verification the controller's own step decides when the permitted window opens; GDPR Article 12(6) identity checks bear on requests, never on the effect of a withdrawal.

The larger gap is at ayat (1), which requires processing to stop on withdrawal without saying what happens where another basis covers the same processing, a question GDPR Article 17(1)(b) settles expressly by making erasure follow withdrawal only where no other ground applies.

Two limbs of GDPR Article 7(3) have no counterpart in the Indonesian text either, that withdrawal must be as easy as consent and that it leaves earlier processing lawful. C-129/21 shows the step UU Pasal 40 stops short of, where withdrawal of consent obliged the controller to take appropriate technical and organisational measures to pass that withdrawal on to the other controllers it had supplied.

What the GDPR provides. GDPR Article 18(1) lets a data subject obtain restriction of processing on four closed grounds: contested accuracy, unlawful processing where the subject prefers restriction to erasure, the controller no longer needing the data while the subject needs them for legal claims, and a pending objection under Article 21(1).

Once restriction bites, Article 18(2) permits storage and nothing else, save with consent, for legal claims, to protect another person's rights, or for important public interest. Article 18(3) requires the controller to tell the subject before the restriction is lifted. The response clock sits in Article 12(3): one month, extendable by two.

The entry gate is inverted. GDPR Article 18(1) opens only on four closed grounds, so a controller can refuse a bare restriction request as outside the article, while UU Pasal 41 ayat (1) starts the duty on receipt and moves the closed list to the exception side at ayat (2).

The exception at Pasal 41 ayat (2) huruf c has no GDPR counterpart of any kind: the Regulation nowhere lets a contract with the controller switch off a data subject right, and Article 12(2) runs the other way by requiring the controller to facilitate the exercise of Articles 15 to 22.

Timing separates them again, since Article 12(3) gives a month to respond while Pasal 41 ayat (1) gives 3 x 24 hours to have the restriction actually in place, which makes it an operational capability rather than a case handling deadline. The notice also lands at a different moment, because Article 18(3) speaks before the restriction is lifted and Pasal 41 ayat (3) speaks after it is imposed.

One caution for a reader reaching for European practice: the marking duty at PP Pasal 101 has no operative equivalent, since the only GDPR text asking for a restriction to be indicated in the system is Recital 67.

What the GDPR provides. GDPR Article 5(1)(e) requires data to be kept in identifiable form no longer than necessary for the purposes, with longer storage allowed only for archiving, research or statistics under the Article 89(1) safeguards. Article 5(1)(b) requires the purposes to be specified at collection and bars further processing incompatible with them, compatible further processing being permitted and tested under Article 6(4).

Article 17(1)(a) turns the same idea into a right once the data are no longer necessary, and Article 7(3) stops future consent based processing on withdrawal. There is no GDPR article that says processing must end; the end is an effect of the principles plus the erasure right.

Both regimes stop processing at the same three points, but the GDPR never states the duty, it derives it. That changes what an enforcer has to prove, and C-77/21 shows how narrow the finding then is.

The Court held that purpose limitation does not preclude copying data into a test database where the further processing is compatible with the purposes of the original collection, compatibility being tested against the Article 6(4) criteria, and it located the infringement in Article 5(1)(e) alone, for keeping the copy longer than the tests required.

UU Pasal 42 ayat (1) is an express wajib with a named trigger, so nothing has to be reconstructed from principle. Article 5(1)(e) fixes no period at all, and what makes it auditable is the disclosure duty at Article 13(2)(a) and the envisaged erasure time limits recorded under Article 30(1)(f), while Pasal 42 ayat (1) huruf a points at a masa retensi that PP Pasal 75 turns into a standing policy document, a heavier artefact than anything the GDPR names.

The third trigger is the real divergence: Pasal 42 ayat (1) huruf c reads as an unqualified subject request, whereas GDPR request grounds are closed at Article 17(1) and cut down further by Article 17(3), so the Indonesian text is broader on its face and narrowed only by the reference back to legislation at ayat (2).

What the GDPR provides. GDPR Article 17(1) gives a right to erasure without undue delay on six grounds, among them that the data are no longer necessary for the purposes, that consent has been withdrawn and no other basis applies, and that the data have been unlawfully processed. Article 17(2) adds that a controller who made the data public must take reasonable steps to inform other controllers of the request.

Article 17(3) then removes the right where processing is needed for freedom of expression, a legal obligation, public health, archiving under Article 89(1), or legal claims. Article 7(3) supplies the withdrawal mechanism that feeds the second ground.

The limbs track Article 17(1) and in its order. Pasal 43 ayat (1) huruf a is Article 17(1)(a), huruf b is Article 17(1)(b) read with Article 7(3), and huruf d is Article 17(1)(d), the omitted grounds being the objection route at Article 17(1)(c), the legal obligation route at (e) and the child and information society route at (f).

One limb was widened in transit: Article 17(1)(b) erases only where consent is withdrawn and no other legal ground applies, while huruf b states bare withdrawal, so a controller holding a second basis keeps the data in Europe and loses that argument on the face of the Indonesian text. What was not carried across matters more.

The statute has no counterpart to the Article 17(3) balance with free expression, public health or archiving. The exceptions that do reach Pasal 43 are the four state interests at UU Pasal 50 ayat (1), which cover huruf a to huruf c only and overlap Article 17(3) at nothing wider than the public task limb of Article 17(3)(b), so the rest of that balance sits a tier lower, at PP Pasal 83.

Article 17(2) has no Indonesian counterpart either, and C-129/21 shows what that costs: the Court held that Article 17(2) does not preclude a supervisory authority ordering a directory provider to take reasonable steps to inform search engine providers of a withdrawal, and it grounded the parallel duty to inform the originating operator and other directory providers in Article 5(2) and Article 24.

Note finally the drafting effect of huruf c: naming a subject request as one trigger among four leaves the other three as duties the controller runs on its own initiative, whereas Article 17(1) is built as a right the subject exercises and the search engine practice in C-131/12 and C-460/20 assumes a claimant who asks.

What the GDPR provides. The GDPR has no destruction duty distinct from erasure. It uses the word destruction in Article 4(2), where destruction is one form of processing, and in Article 4(12), Article 5(1)(f) and Article 32, where it is something a breach does to data.

Disposal in the Regulation runs on three provisions: the storage limitation principle at Article 5(1)(e), the erasure obligation at Article 17, and the processor's duty at Article 28(3)(g) to delete or return the data at the end of the service. The Regulation prescribes no method, so deletion, overwriting and irreversible anonymisation are each capable of discharging it.

Article 17(3)(b), (d) and (e) hold data back where they are needed for a legal obligation, for archiving in the public interest under Article 89(1), or for legal claims, and Article 89(3) lets Union or member state law derogate from the rights in Articles 15, 16, 18, 19, 20 and 21 for archiving in the public interest.

Three of the four Pasal 44 triggers are GDPR erasure grounds wearing another name: huruf a is Article 5(1)(e) with Article 17(1)(a), huruf b is a request under Article 17(1), and huruf d is Article 17(1)(d). What diverges is the architecture and one trigger.

Europe runs a single disposal track, principle at Article 5(1)(e), obligation and right at Article 17, processor clean up at Article 28(3)(g), while Indonesia runs penghapusan at Pasal 43 and pemusnahan at Pasal 44 as separate wajib with separate sanctions, so the destruction duty and its sanction at PP Pasal 84(1) have nowhere to land in a control set derived from GDPR mappings.

Pasal 44 ayat (1) huruf c is the trigger with no European shape at all. The limbs are joined by dan/atau, so on its face the absence of a link to penyelesaian proses hukum can start the duty on its own, a reading that cannot be intended and is better treated as an open drafting question.

Read either way it runs against Article 17(3)(e), which makes the presence of a legal claim a shield against erasure, so the same diligence output is a defence in Europe and a condition on the Indonesian side. The jadwal retensi arsip hook at huruf a ties the trigger to Indonesian archives law, and the GDPR supplies no answer of its own, because Article 89 gives safeguards and a derogation power for archiving rather than an archive schedule.

One design consequence follows: anonymisation can discharge Article 17 because the GDPR test is identifiability, whereas Pasal 44 is keyed to the archive schedule and to lawfulness of acquisition, so one technical measure does not necessarily close both.

What the GDPR provides. GDPR Article 19 requires the controller to communicate any rectification, erasure or restriction carried out under Article 16, Article 17(1) or Article 18 to each recipient to whom the data were disclosed, unless that proves impossible or involves disproportionate effort. Its second sentence reaches the data subject, but only on request, and only to name those recipients.

Article 17(2) sits beside it for published data, requiring reasonable steps, including technical measures, to inform other controllers of the erasure request. The subject learns what was done through Article 12(3), which requires information on action taken within one month of a request.

The addressee is inverted on both sides. Article 19 points at recipients by default and reaches the subject only if the subject asks, and only to name those recipients, while UU Pasal 45 points at the subject unconditionally and says nothing about recipients.

The GDPR has no free standing duty to confirm to the subject that erasure has happened, because that confirmation arrives through the request handling machinery at Article 12(3), which means it does not arise where the controller erased on its own initiative. Pasal 45 does arise there, since it attaches to any penghapusan or pemusnahan including the controller initiated triggers at Pasal 43 ayat (1) huruf a and Pasal 44.

In the other direction the Indonesian propagation duty stops at the processor, because PP Pasal 88 is a flow down to processors, while the Article 19 recipient, defined at Article 4(9), takes in independent controllers downstream.

How far the European chain runs is set by more than Article 19: in C-129/21 the Court grounded the duty to inform the originating operator and other directory providers in Article 5(2) and Article 24, and held that Article 17(2) does not preclude an authority ordering reasonable steps to inform search engine providers. So the two regimes are strong at opposite ends, Indonesia on proving the act to the subject, the GDPR on chasing the data through the chain.

What the GDPR provides. GDPR Article 33(1) requires notification to the supervisory authority without undue delay and where feasible within 72 hours of the controller becoming aware of a breach, unless the breach is unlikely to result in a risk to rights and freedoms.

Article 33(3) fixes the content, including the categories and approximate numbers of subjects and records, the likely consequences and the measures taken, and Article 33(4) allows the information to be supplied in phases.

Article 34(1) reaches the data subject only where the breach is likely to result in a high risk, and Article 34(3) removes even that where the data were encrypted, where the risk has since been contained, or where individual contact would take disproportionate effort, in which case a public communication substitutes. Article 33(5) requires the controller to document every breach, notified or not.

The clock is the difference that gets missed, and it is a difference about the start, not the length.

Article 33(1) runs 72 hours from the controller becoming aware, and Guidelines 9/2022 devotes a section to when awareness begins, whereas UU Pasal 46 ayat (1) fixes 3 x 24 hours against the occurrence of the kegagalan and omits the terhitung sejak formula that Pasal 41 ayat (1) uses for the restriction clock, so a controller that spends two days confirming an incident cannot tell from the statute whether it is early or already late.

PP Pasal 114 ayat (2) supplies the start the statute omits, counting from when the failure is known with certainty, properly and reasonably, and its elucidation ties that knowledge to the conclusion of the controller's own incident documentation.

Then the filters, which Indonesia does not have on either limb: the GDPR notifies the authority unless risk is unlikely and the subject only on high risk, so Pasal 46 produces notices in cases where an EU controller would document and stay silent.

The public notice is not the convergence it looks like either, because Article 34(3)(c) offers a public communication as a substitute for individual notice, while Pasal 46 ayat (3) adds one on top of the individual notice that ayat (1) huruf a already requires.

The sharpest inversion is evidential, because Article 33(5) makes the internal register of all breaches directly enforceable and fineable under Article 83(4)(a), which is how a supervisory authority audits the risk judgment behind a decision not to notify, and C-340/21 adds the litigation half, holding that in an Article 82 damages claim the controller bears the burden of proving its Article 32 measures were appropriate.

The tracker records PP Pasal 116 as neither wajib nor listed at Pasal 184(1), so Indonesia removed the discretion and also removed the record that would have tested it, which is a coherent design only for as long as no one asks what happened before the notice went out.

What the GDPR provides. GDPR Article 5(2) makes the controller responsible for the Article 5(1) principles and requires it to be able to demonstrate compliance with them, a pairing the Regulation itself names accountability. Article 24(1) turns that into a duty to implement technical and organisational measures appropriate to the risk and to review and update them.

Article 24(2) requires data protection policies where proportionate, and Article 24(3) allows adherence to a code of conduct or a certification to be used as an element of the demonstration. The artefacts that carry the proof are elsewhere: records under Article 30, security under Article 32, impact assessments under Article 35.

Pasal 47 pairs responsibility with the ability to show it, in the same order as Article 5(2). The objects are not identical. Article 5(2) keys both limbs to the Article 5(1) principles, while Pasal 47 makes the controller responsible for pemrosesan Data Pribadi and keys only the demonstration limb to the principles, so the first limb reaches wider than Article 5(2) and sits closer to Article 24(1), whose object is compliance with the Regulation entire.

What did not travel is the evidence catalogue. Article 30 records, Article 32 measures and Article 35 assessments are each independently enforceable and each fineable under Article 83(4)(a), which is what converts Article 5(2) from a statement of posture into a file a regulator can open without proving harm to anyone.

PP Pasal 28 and Pasal 138 rebuild part of that, but the list of things a controller must be able to produce is shorter, so the demonstrability duty in Indonesia points at fewer named documents than its European source does.

One question the Indonesian text leaves open has been answered in Europe: C-807/21 holds that a fine may not be made conditional on prior attribution of the infringement to an identified natural person, and that a fine may be imposed only where the controller acted intentionally or negligently, so accountability there is fault based rather than strict, and C-683/21 says the same about fault while settling who counts as the controller bearing it.

What the GDPR provides. The GDPR has no article on mergers, demergers, acquisitions, consolidations or dissolution. A database moving in a transaction falls back on the ordinary tools: the acquirer needs a legal basis under Article 6(1), a compatibility test under Article 6(4) if the purpose shifts, and Article 14 information to the subject because the data came from a source other than the subject, at the latest within one month under Article 14(3)(a).

Article 13(3) catches any controller that collected from the subject and then processes for a new purpose, which is how the seller side is reached. Corporate succession is left to national company law, and the Regulation says nothing about winding up.

The GDPR reaches the notification limb through two general duties rather than a dedicated one. The acquirer owes Article 14 information because it obtained the data from a source other than the subject, discharged once and after the event, at the latest within one month under Article 14(3)(a).

The seller is reached by Article 13(3) where the transfer is a purpose other than the one it collected for, and that information is owed before the further processing begins. So Europe does produce a notice on each side of the transaction, but split across two controllers and two provisions and triggered by a purpose change, where Pasal 48 ayat (2) puts both notices on the transferring entity and triggers them off the corporate act itself.

Dissolution is the wider gap. Article 5(1)(e) and Article 17 still apply to a company being wound up, but the Regulation never says who performs the deletion or what becomes of the data when the controller ceases to exist, whereas Pasal 48 ayat (3) and ayat (4) put storage, transfer, erasure and destruction on the dissolution itself and require the subject to be told.

The exit an acquirer reaches for in Europe is narrower than it looks, because Article 14(5)(b) is read by the transparency guidelines as tied to archiving, research and statistical purposes and not to be relied on routinely outside them, with the number of data subjects only one factor in the balance, so it is a weak defence in Europe and no defence at all under Pasal 48, which UU Pasal 50 does not list among the exempted duties.

The practical consequence for diligence is that an EU style checklist hangs the seller's notice off a purpose change, so a pre closing notice tied to the corporate act, as at PP Pasal 133, has no line to sit on and gets found after signing.

What the GDPR provides. GDPR Article 31 requires controllers, processors and their representatives to cooperate with the supervisory authority, on request, in the performance of its tasks. The power to give binding directions sits elsewhere, in the enumerated corrective measures at Article 58(2)(a) to (j), which run from warnings and reprimands through orders to bring processing into compliance, temporary limitations and outright bans, and to which a member state may add only by law under Article 58(6).

A legally binding decision of a supervisory authority is reviewable by a court under Article 78(1). Non-compliance with an order made under Article 58(2) falls in the higher fine tier under Article 83(6).

UU Pasal 49 states the duty from the regulated party's side, as a standing obligation to carry out the orders of the lembaga. The GDPR never puts it that way.

It builds the same result from the other end, by listing at Article 58(2)(a) to (j) exactly which measures a supervisory authority may impose, then penalising defiance of one at Article 83(6), and C-46/23 shows the list doing work, since the Court read Article 58(2)(d) and (g) as reaching an erasure order made without any request from a data subject. Indonesia has a list too.

UU Pasal 60 huruf g gives the lembaga the power to issue orders following supervision, and Pasal 49 bounds the duty by reference to penyelenggaraan Pelindungan Data Pribadi under the same statute. The difference is what the lists do. Article 58(2) is closed, extendable only by member state law under Article 58(6), and an order outside it can be challenged as outside the power under Article 78(1).

UU Pasal 60 huruf g names a power to order without saying what an order may require, and Pasal 61 sends the tata cara to a Peraturan Pemerintah, so the content of a lawful perintah is set below the statute rather than in it.

Article 31 does not fill the European side of that gap, because it is only a duty to cooperate on request and sits in the lower fine tier under Article 83(4)(a), where non-compliance with an Article 58(2) order sits in the higher tier at Article 83(6). The Indonesian provision folds cooperation and obedience into one sanction backed duty, carried into PP Pasal 29.

What the GDPR provides. GDPR Article 23 lets Union or member state law restrict the scope of the obligations and rights in Articles 12 to 22, Article 34 and the corresponding parts of Article 5.

The restriction must come by legislative measure, must respect the essence of fundamental rights and freedoms, and must be necessary and proportionate in a democratic society to safeguard one of the listed objectives, among them national security, defence, public security, criminal enforcement and other important objectives of general public interest.

Article 23(2) then dictates what that measure must contain: purposes, categories of data, scope of the restriction, safeguards against abuse, the controller, storage periods, risks to data subjects, and whether data subjects are told about the restriction. A restriction cannot be inferred, and nothing in Article 23 lets an administrative practice stand in for the legislative measure.

Only one of the four interests in UU Pasal 50 ayat (1) is handled in the EU by scope rather than by exception: processing by competent authorities for criminal law purposes is carved out by Article 2(2)(d) and lands in the Law Enforcement Directive with its own rights regime.

National security is not the clean carve-out it looks like, because Article 2(2)(a) removes the state's own activity while a private controller compelled to process for a national security objective stays inside the GDPR, which is why national security also appears as a restriction ground at Article 23(1)(a).

The other two limbs, public interest in the administration of the state and financial sector supervision, are Article 23(1)(e) territory, but Article 23 would still demand a distinct legislative measure carrying the Article 23(2) content list, where UU Pasal 50 ayat (2) asks only that the exception be exercised in the framework of implementing statutory provisions.

Neither the necessity and proportionality test nor the essence test appears in the Indonesian text. The structural difference runs the other way too: Article 23 restricts data subject rights and the matching controller duties in one operation, while UU Pasal 50 lists exempted duties and leaves exceptions to rights in a separate provision, which is why PP Pasal 149 to 159 had to build two parallel sets and why an exception on one side does not carry to the other.

What the GDPR provides. GDPR Article 28(1) lets a controller use only processors that provide sufficient guarantees of appropriate technical and organisational measures. Article 28(3) requires a contract or other legal act binding the processor to the controller and fixes what it must contain, starting with processing only on documented instructions.

Article 28(2) bars the processor from engaging another processor without prior written authorisation, specific or general, and where the authorisation is general the processor must give notice of intended changes so the controller can object. Article 28(4) keeps the first processor fully liable to the controller for the sub-processor's performance, and Article 28(10) turns a processor that determines purposes and means into a controller for that processing.

UU Pasal 51 reaches the same allocation of responsibility, then parts company with Article 28 on two mechanisms. Ayat (6) sits where Article 28(10) sits: responsibility moves to the processor once it processes outside the order and the stated purpose, while ayat (3) keeps instructed processing inside the controller's responsibility.

The GDPR gets there by a change of status, which drags the whole controller regime along with it, including the need for the processor to hold its own lawful basis under Article 6(1). UU Pasal 51 ayat (6) shifts responsibility without saying what the processor then is. On sub-processing the two texts split over liability rather than over consent.

Article 28(2) permits a general written authorisation with a right to object, which is what makes multi-tier cloud chains workable in the EU. Neither UU Pasal 51 ayat (5) nor PP Pasal 15 ayat (2) says whether a standing authorisation counts, so that question is open in Indonesia rather than closed against it.

The liability split is real: Article 28(4) keeps the first processor fully liable to the controller for the sub-processor's performance, while PP Pasal 15 ayat (5) puts processing by the sub-processor back on the controller. The chain is not otherwise unguarded.

UU Pasal 37, applied to the processor by UU Pasal 52 and sanction-backed through UU Pasal 57 ayat (1), requires supervision of every party involved in processing under its control, and PP Pasal 15 ayat (3) and ayat (4) require the first processor to ensure the sub-processor complies and to fix an equivalent level of protection by written agreement.

What has no Indonesian counterpart is the selection standard at Article 28(1) and the mandatory contract content at Article 28(3): PP Pasal 15 ayat (4) and PP Pasal 139 ayat (2) require a written agreement but do not fix what it must say.

What the GDPR provides. The GDPR does not switch controller duties onto processors in a single clause. It names the processor inside each article that binds it: Article 29 and Article 28(3)(a) confine it to the controller's documented instructions, Article 30(2) gives it its own record of processing activities, Article 32 imposes security on controller and processor alike, and Article 33(2) requires it to notify the controller of a breach without undue delay.

Those duties bind directly, and Article 83(4)(a) exposes the processor to fines for breaching them regardless of what its contract says. Duties the GDPR keeps with the controller, such as lawful basis, transparency and answering data subject requests, never transfer; the processor only assists under Article 28(3)(e) and (f).

The destination is close and the route is not. UU Pasal 52 is one cross-reference clause switching a fixed block of controller duties onto the processor: accuracy and verification at UU Pasal 29, records of processing at UU Pasal 31, security at UU Pasal 35, confidentiality at UU Pasal 36, supervision of every party involved at UU Pasal 37, and protection against unlawful processing and unauthorised access at UU Pasal 38 and UU Pasal 39.

UU Pasal 57 ayat (1) lists Pasal 52 by number, so the block is sanction-backed and the Indonesian processor answers to the regulator and not only to its customer, which is the same exposure Article 83(4)(a) creates in the EU.

PP Pasal 140 repeats the cross-reference against the PP's own numbering, and PP Pasal 141 adds a free-standing accountability duty covering documentation, responses to the Lembaga, evidence of compliance and audits, which the GDPR asks of the controller under Article 5(2) and Article 24 and not of the processor. Two limbs do not line up.

UU Pasal 29 puts accuracy, completeness, consistency and verification on the processor, where the accuracy principle in the EU stays with the controller. And the block carries no breach duty at all: the counterpart to Article 33(2) is PP Pasal 118, which requires the processor to report a breach to the controller at the first opportunity, sits outside UU Pasal 52, and is absent from the PP Pasal 184 sanctions list.

The article-by-article technique has one property the cross-reference cannot reproduce: the EU list maintains itself, because whether a duty reaches the processor is settled inside the duty itself, where UU Pasal 52 fixes the answer as a list of article numbers that has to be amended whenever the substantive articles move. The other difference is at the boundary of obedience.

The closing subparagraph of Article 28(3), attached to point (h), obliges the processor to tell the controller at once if, in its opinion, an instruction infringes the law, and Article 28(10) states the consequence of going further, so acting on instructions is a defence with a stated limit.

UU Pasal 52 imports duties but not that exchange, and the nearest equivalent sits back at UU Pasal 51 ayat (6), which reallocates responsibility after the event rather than requiring the processor to raise the objection before it acts.

What the GDPR provides. GDPR Article 37(1) requires a controller or processor to designate a data protection officer in three cases. The first is processing carried out by a public authority or body, courts acting in a judicial capacity excepted. The second is core activities that by their nature, scope or purposes require regular and systematic monitoring of data subjects on a large scale.

The third is core activities consisting of large-scale processing of special categories under Article 9 and of criminal conviction and offence data under Article 10. The three cases are alternatives, and each names the processor as well as the controller. Article 37(5) sets the selection standard: professional qualities, in particular expert knowledge of data protection law and practice, and the ability to fulfil the Article 39 tasks.

Article 37(6) allows a staff member or a service contract, Article 37(2) allows a group of undertakings to share one officer who is easily accessible from each establishment, and Article 37(7) requires the contact details to be published and given to the supervisory authority.

The tracking is limb for limb: UU Pasal 53 ayat (1) huruf b carries the Article 37(1)(b) formula intact, with kegiatan inti and sifat, ruang lingkup, dan/atau tujuan sitting where core activities and nature, scope and/or purposes sit, huruf c carries Article 37(1)(c) down to the criminal offence category, ayat (2) follows Article 37(5) in the same order and ayat (3) is Article 37(6).

Huruf a is the first departure, because it triggers on processing for public services rather than on the identity of a public authority, so it reaches private operators running public service functions that Article 37(1)(a) would not touch, and it drops the exclusion of courts acting judicially.

The chapeau addresses controller and processor together, as Article 37(1) does, but huruf b and huruf c then speak only of kegiatan inti Pengendali Data Pribadi, so on the face of the text a processor whose own core activity is large-scale monitoring escapes the trigger that Article 37(1)(b) and (c) apply to it expressly.

The limbs are also joined by dan where Article 37(1) joins its three cases with or, which on a strict reading would demand all three triggers at once. PP Pasal 142 ayat (1) answers one of these and not the other: huruf b there ends dan/atau, which settles the alternative reading, while huruf b and huruf c still speak only of the controller's core activities, so the processor gap survives into the regulation.

The UU also leaves out Article 37(2) and Article 37(7), so nothing at statute level lets a group share one officer or requires the contact details to reach the authority. One departure runs the other way: Article 37(1)(c) joins special categories and criminal offence data with and, and huruf c writes dan/atau, which settles a reading the EU text leaves open.

What the GDPR provides. GDPR Article 39(1) gives the officer at least five tasks: informing and advising the controller, processor and staff who process; monitoring compliance with the GDPR and with internal policies, including allocation of responsibilities, awareness raising, training and audits; advising on a data protection impact assessment and monitoring its performance under Article 35; cooperating with the supervisory authority; and acting as its contact point, including for prior consultation under Article 36.

Article 39(2) requires the officer to have due regard to the risk of the processing, taking account of its nature, scope, context and purposes. Article 38 is the other half of the design and governs position rather than work.

It requires timely involvement in all data protection issues, resources and access, no instructions on how to perform the tasks, no dismissal or penalty for performing them, direct reporting to the highest management level, secrecy, and no other tasks that create a conflict of interests.

UU Pasal 54 ayat (1) is Article 39(1) in the same order with the last two limbs folded into one: huruf a is Article 39(1)(a), huruf b is Article 39(1)(b), huruf c sits where Article 39(1)(c) sits, and huruf d merges cooperation with the authority and the contact point role from Article 39(1)(d) and (e), with paling sedikit doing the work of at least in the chapeau.

Huruf c is the one limb that shifted in transposition: Article 39(1)(c) has the officer advise where requested and monitor the performance of the impact assessment, while huruf c drops the request condition and has the officer memantau kinerja of the controller and the processor, which widens the task and overlaps huruf b.

Ayat (2) is Article 39(2) carried across, with risiko, sifat, ruang lingkup, konteks and tujuan in the same sequence as risk, nature, scope, context and purposes.

What did not come across into the statute is Article 38, and that is where the EU litigation has actually been: the questions that reached the Court were whether national law may protect the officer against dismissal under Article 38(3) and whether a manager with operational duties can hold the role at all under Article 38(6).

Neither has a hook in UU Pasal 54, but only the first is missing from the regime as a whole. PP Pasal 146 goes well past resources and access.

Ayat (1) huruf a requires the PPDP to be involved in all processing activities, huruf b requires reporting access to the highest management level, huruf c requires the PPDP to operate objectively, free from intervention and independently, and huruf d requires adequate resources and the maintenance of expertise, while ayat (2) requires the controller and processor to ensure the PPDP's tasks do not produce a conflict of interests.

That answers Article 38(1), the no-instructions and direct-reporting limbs of Article 38(3), Article 38(2) and Article 38(6), so the X-FAB question has a text to be argued under. What has no counterpart is the protection against dismissal or penalty for performing the tasks in the second sentence of Article 38(3), and the secrecy duty at Article 38(5).

A PPDP removed after an unwelcome opinion still has no provision addressed to the removal, and PP Pasal 146 is itself absent from the PP Pasal 184 sanctions list, so the independence guarantees that do exist carry no administrative penalty of their own.