Skip to main content

​
Singapore and Thailand PDPA Posture

Singapore’s Personal Data Protection Act (2012, amended 2020) and Thailand’s Personal Data Protection Act B.E. 2562 (in force since 2022) share a design: a personal-data regime with a consent requirement at collection, an access-and-correction right on roughly a 30-day clock, and — in Singapore’s case — a separate Do Not Call (DNC) register that gates outbound marketing calls, SMS, and faxes to +65 numbers. Thailand runs a consent-led regime administered by the Personal Data Protection Committee (PDPC Thailand); Singapore’s regulator is the Personal Data Protection Commission (PDPC SG). Both are deemed-consent, opt-out-flavoured regimes compared with the EU’s opt-in strictness — Singapore’s PDPA since the 2020 amendment even codifies a deemed-by-business-necessity class — but that latitude is a judgement about your facts, made by your counsel, not a default Orbit assumes. PDPA places the duty on the organisation, not the platform. Orbit never mandates your Singapore or Thailand posture — it gives you the tenant-controlled consent ledger, the suppression layer, the DNC scrub chain, the DSAR pipeline with a coded pdpa jurisdiction, and the privacy register. This page maps each PDPA obligation to the surface you already have so a PDPC questionnaire or a Thai regulator review reads the evidence from your own configuration.
This page describes Orbit’s platform controls. It is not legal advice. Which PDPA obligations apply to you — deemed consent or express, whether Singapore’s DNC register reaches your traffic, what basis fits a cross-border transfer — depends on your processing. Orbit supplies the record-keeping surfaces; the legal posture is yours. Confirm with qualified counsel.

​
The PDPA surface map

One row per obligation a Singapore or Thailand operator usually has to answer, mapped to the Orbit control that holds it and the deep page that documents it. This table mirrors “The GDPR surface map” on the GDPR posture guide — the same controls, read against a different statute. Two adjacent controls round out the map:
  • Quiet hours. No PDPA provision names them, but an SG or TH marketing program inherits the expectation from the carriers and the local marketing regimes — set the fallback window with the rest (Quiet hours configuration).
  • Voice data residency. SG and TH transfers are assessments you run on your transfer basis; the residency pin (Voice data residency) records where recordings physically live.

​
Section 2 — A worked sequence for a Singapore recipient

A tenant running SMS plus voice outbound into Singapore reads as this sequence. Each step is a tenant-owned decision Orbit enforces; none is a platform mandate. Step 1 — posture. For deemed-consent or opt-out-based SG marketing, keep unknown_marketing_policy: allow_with_logging (so the send runs and the ledger records the unbacked contact) but move consent_default_policy: deny_on_missing where you want the stricter line — for example on channels where you cannot show any consent basis. The two knobs are tenant-owned — see Consent Posture: The Unknown-Consent Policies. Step 2 — capture consent with the basis. At acquisition, record the grant with lawful_basis and a purpose string (PDPA’s consent duty turns on the disclosed purpose):
Step 3 — DNC scrub before outbound. Wire the pre-flight check into your campaign rollout so an SG-destination list scrubs against the combination of your suppression layer and the national register before the first send. The check endpoint answers source and freshness explicitly — read the source and last_synced_at fields and treat a stale row as a risk flag, not a blocker (the fail-open caveat is documented on DNC Scrubbing). The feed that refreshes the per-country rules rows carries the SG register link — see Country Rules Auto-Refresh Feeds. Step 4 — wire withdrawal to the same suppression list. STOP keywords, the consent API with opt_in: false, and the preference center all land on one list. A revoked +65 contact stays suppressed regardless of which entry point they used. Step 5 — file a DSAR with the pdpa clock. When an SG data subject asks for access or correction, file it under the coded jurisdiction so the SLA tracker applies the 30-day clock automatically:
Erasure follows the same pipeline; the proof-of-deletion certificate (see DSAR) is the receipt you hand the subject or a PDPC SG reviewer. Step 6 — file your processing activities in the privacy register. Record each SG-facing activity — purpose, data categories, recipients, transfers, retention, security measures — in the privacy register before the first DSAR arrives. An accountability review reads that register first.

​
Section 3 — A worked sequence for a Thailand recipient

Thailand’s PDPA reads closer to the EU shape — express consent at collection, a rights chapter administered by the PDPC Thailand, and explicit RoPA-class records duties (s39–41). The sequence: Step 1 — posture. Express-consent markets call for the strict line: keep unknown_marketing_policy: refuse and consent_default_policy: deny_on_missing for TH recipients, so an unbacked contact receives no marketing. Step 2 — capture consent with the basis. Record the grant explicitly per channel, lawful_basis: consent, and the purpose string your TH notice disclosed:
Step 3 — sender and scrub. The DNC chain treats national registers per jurisdiction — where a TH register feeds it, pre-flight the same way as the SG step; otherwise lean on your own suppression layer, which answers for every recipient who revoked regardless of any register. The country-rules row for TH on the channel you send is the sender-registration answer — Country Compliance Requirements documents the read; the feeds page documents why the row’s last_synced_at stayed fresh. Step 4 — DSAR on the same pdpa code. TH data subjects file under the same coded jurisdiction; the 30-day SLA clock tracks the request with or without an SG/TH split:
Step 5 — register. File the TH-facing processing activities in the privacy register separately from the SG ones — s39 RoPA-class inventory answers against the activities you filed, not against a cross-market merge. The binder reads both sets when a reviewer asks for the whole program.

​
Section 4 — What Orbit does NOT do

Boundary conditions, stated once and plainly:
  • Orbit never files with the PDPC for you. A breach notification to the Singapore PDPC (or the equivalent Thai filing) is your act — the breach register’s attestation records the judgement behind the notification, but the notification itself is yours.
  • Orbit never decides whether deemed consent applies, or which basis fits. Deemed consent, business-necessity consent, legitimate interests — the legal analysis is counsel’s. The consent ledger records the basis you assert; the judgement it captures is yours.
  • Orbit never scrubs your outbound against a register automatically in a way you cannot see. The DNC check answers source and freshness explicitly, fails open when a source is stale, and applies the gates you enabled. A failing scrub because the org toggle is off is a configuration fact, not a platform mandate — the strict-tenant rule applies to every control except the US federal voice window.
  • Nothing on this page gates sending by itself. Consent records, the suppression layer, the DSAR pipeline, and the register are the ledger. The send-time gates that exist are the ones you turned on, and each defaults open.
  • This is not legal advice. The sequence assembles Orbit’s controls; whether the assembled posture satisfies the SG or TH PDPA for your processing is a call for your counsel.