Indonesia PDP operations runbook

This runbook covers the mechanisms supplied by @adocommercekit/id. It is not legal advice.

This runbook covers the mechanisms supplied by @adocommercekit/id. It is not legal advice. The merchant remains the personal-data controller and must have Indonesian counsel approve purposes, notices, retention periods, legal holds, processors, data-subject handling, and incident decisions before publication.

Shared responsibility

Responsibility	Adocommerce Kit / package	Host merchant
Consent evidence	Append-only purpose, notice version, action, time, and minimized evidence	Write the notice, establish the lawful basis, present it, identify the customer, and call grant/withdraw
Rights requests	Authorized submit/list/export/correction/deletion workflow	Authenticate the requester, implement Bouncer policy, verify scope, approve/reject, communicate, and retain case evidence
Portability	Minimized core customer/order JSON plus consent/request receipts	Secure delivery channel, identity verification, additional host-system data, and response deadline
Retention	Dry-run candidate plan, idempotent anonymization, and legal-hold exclusion	Set counsel-approved periods, schedule a durable job, review dry runs, place/release holds, and retain required records
WhatsApp	Rechecks purpose and notice consent before enqueue and send; redacted logs	Approved templates, pinned Graph API, recipient mapping, processor terms, and optional fallback
Incident response	Data minimization and evidence-friendly identifiers	Detection, containment, impact/legal assessment, notification, regulator/data-subject communication, and post-incident work

Required configuration

Replace the deny-all pdp.authorize callback in config/commerce_id.ts with a Bouncer-backed policy. Authorization is mandatory for every rights operation.
Version each privacy notice. Never silently reuse a notice version after changing purpose, processor, channel, retention, or material wording.
Use a production queue for retention and notification work. Inline dispatch is development/test-only.
Set a counsel-approved retention policy version and duration. Run PdpRetentionService.execute(policy, { dryRun: true }) and review customer identifiers before enabling execution.
Place legal holds before approving deletion or running retention when records must be preserved.
Do not put raw addresses, access tokens, instruction secrets, provider payloads, or message recipients in logs.

Call ConsentReceiptService.grant() only after recording an affirmative action for one named purpose and notice version.
Call withdraw() when the customer revokes the purpose. Receipts are appended; existing rows are never rewritten.
Check hasValidPurpose(customerId, purpose, noticeVersion) at the point of use. @adocommercekit/whatsapp performs this check both before enqueue and before send.
A new notice version has no inherited grant. Collect new evidence when the merchant’s legal basis requires it.

Data-subject requests

Authenticate the requester using the merchant’s normal high-assurance account or guest process.
Submit an export, correction, or deletion request with the current notice version and only the fields required to process it.
A separately authorized operator reviews the request and any fraud, tax, dispute, warranty, accounting, or legal-hold constraints.
For portability, call PdpRightsService.export(). Deliver the JSON over a secure, expiring channel; do not email it by default.
For correction, record the approved fields and call completeCorrection(). Do not overwrite immutable order or tax evidence without a separately reviewed accounting correction.
For deletion, place any required hold first. completeDeletion() returns blocked_legal_hold instead of anonymizing while a hold is active.
Record completion or rejection in the merchant case system and communicate the outcome using counsel-approved wording and deadlines.

Retention and anonymization

Treat each policy change as a new policyVersion.
Dry-run first. Compare candidates to open orders, disputes, returns, refunds, warranties, tax/accounting obligations, fraud investigations, and legal holds.
Execute in bounded batches through the durable jobs port. The (customer_id, policy_version) record makes retries idempotent.
Anonymization clears core customer and saved-address identifying fields. Host models, external processors, backups, analytics, files, support tools, and provider dashboards remain host responsibilities.
Test restoration and erasure behavior against the merchant’s backup policy. “Deleted from the primary database” must not be represented as universal erasure.

Personal-data incident: 3 × 24-hour operating clock

The host incident commander starts the clock at the legally reviewed awareness point. The statutory interpretation and recipients must be confirmed by counsel for the incident; the software does not make that determination.

0–4 hours: detect, preserve, contain

Open an incident record with UTC awareness time, reporter, systems, data classes, and initial scope.
Preserve access, queue, deployment, database, and provider audit evidence. Never copy secrets or raw personal data into chat or general issue trackers.
Revoke or rotate exposed credentials, stop the affected integration, isolate compromised accounts, and preserve a controlled forensic path.
Assign incident commander, security lead, privacy/legal lead, communications lead, and processor contacts.

4–24 hours: assess

Determine affected customers, data elements, volume, duration, access/exfiltration evidence, geography, processors, and ongoing risk.
Query by internal identifiers; export only the minimum evidence set. Keep raw addresses and message recipients out of telemetry.
Have counsel determine notification obligations, recipients, required content, and the start of the 3 × 24-hour period under applicable law and guidance.
Notify affected processors and obtain their incident timelines and containment evidence.

24–48 hours: prepare and validate

Draft regulator and data-subject notices with what happened, exposed data, timing, containment, likely impact, and concrete protective actions.
Reconcile the recipient set, avoid duplicates, validate translations, and obtain legal and executive approval.
Test delivery through an approved incident channel. Do not reuse marketing consent as the legal basis for mandatory incident communication.

48–72 hours: notify and record

Send required notices within the counsel-confirmed deadline and retain delivery evidence, failures, retries, versions, and approval timestamps.
Provide a monitored response channel and escalation path for affected people.
Record any delayed or omitted notification decision with counsel’s rationale and supporting facts.

After notification

Continue containment and recovery; notification is not closure.
Complete root-cause analysis, affected-record reconciliation, processor follow-up, credential rotation, and control fixes.
Test the correction against the original failure and add a durable regression check where appropriate.
Run a retrospective with owners and dates. Update notices, retention, incident contacts, data maps, and this runbook when the operating model changes.

Operational evidence

Archive counsel approval, native-language review, region source/license/checksum, PDP scenario results, dry-run retention evidence, legal-hold scenarios, authorized and unauthorized export tests, WhatsApp consent-withdrawal and retry evidence, and a dated incident tabletop. Sanitized artifacts must contain no credentials, instruction secrets, raw addresses, recipients, or provider payloads.

Continue

Configure WhatsApp notifications with PDP consent.
Review the broader Indonesia capability map.
Use deployment and operations for queues, logs, backups, and incident prerequisites.