If you run Shopify, Stripe, Google Analytics or AWS from Singapore, you are already transferring personal data overseas. That is permitted. The question is on what basis — and whether you have told anyone.
Statutory references in this article are to the Personal Data Protection Act 2012 as in force from 5 December 2025 and the Personal Data Protection Regulations 2021 as in force from 2 March 2026 (as amended by S 86/2026). If you are reading this long after the update date above, check Singapore Statutes Online for a later version.
Almost every Singapore website transfers personal data outside Singapore, usually without anyone having made a decision about it. Your e-commerce platform is hosted abroad. Your payment processor is a US company. Your analytics data goes to Google. The obligation is real, and it is also entirely satisfiable — in most cases by paperwork you already have and a disclosure you have not yet written.
This is compliance research, not legal advice. Sitetals is an independent scanner, not a law firm and not affiliated with the Personal Data Protection Commission.
Whether a specific obligation applies to your organisation is a question of fact and law. For a decision that carries risk, take advice from a Singapore-qualified practitioner.
“An organisation must not transfer any personal data to a country or territory outside Singapore except in accordance with requirements prescribed under this Act to ensure that organisations provide a standard of protection to personal data so transferred that is comparable to the protection under this Act.”
The prescribed requirements are in the Personal Data Protection Regulations 2021.
Before transferring personal data outside Singapore, a transferring organisation must take appropriate steps to ascertain whether, and to ensure that, the recipient is bound by legally enforceable obligations (in accordance with regulation 11) to provide a standard of protection at least comparable to the protection under the Act.
Two verbs matter. Ascertain — you have to find out, which means reading the agreement rather than assuming. Ensure — you have to put the obligation in place if it is not already there.
Regulation 11(1) lists four routes.
| Route | What it requires | When it fits a small operator |
|---|---|---|
| Any law reg 11(1)(a) | The recipient is already bound by law to a comparable standard | Rarely relied on alone; requires an assessment of the destination regime |
| Contract reg 11(1)(b), (2) | The contract must (a) require the recipient to provide protection at least comparable to the Act, and (b) specify the countries and territories to which the data may be transferred | The normal route. This is what a processor's data processing agreement is for |
| Binding corporate rules reg 11(1)(c), (3) | Only for recipients related to the transferring organisation; must specify the recipients, the countries and territories, and the rights and obligations | Intra-group transfers only — not a route for third-party vendors |
| Other legally binding instrument reg 11(1)(d) | Any other instrument that binds the recipient | Situational |
Regulation 11(2) has two requirements, not one. The contract must require a comparable standard of protection and specify the countries and territories to which the personal data may be transferred. A data processing agreement that promises good security but never names a destination does not satisfy the second limb on its face.
Under regulation 12, a recipient is taken to be bound by comparable legally enforceable obligations if it holds a specified certification granted or recognised under the law of the destination country.
| Recipient type | Accepted certifications |
|---|---|
| Data intermediary (a processor acting on your behalf) | APEC Privacy Recognition for Processors (PRP); APEC Cross-Border Privacy Rules (CBPR); Global Privacy Recognition for Processors; Global Cross-Border Privacy Rules |
| Any other case | APEC CBPR; Global CBPR |
The Global CBPR and Global PRP entries were added with effect from 2 March 2026.
Regulation 10(2) sets out when you are taken to have satisfied the requirement without separately establishing legally enforceable obligations:
Under regulation 10(3), an individual is not taken to have consented if:
And under regulation 10(4), nothing prevents an individual from withdrawing consent to the transfer.
For a payment processor or a hosting provider, most operators end up on the contract route under regulations 10(1) and 11 — or on a regulation 12 certification where the recipient holds one, which can be the shorter path — rather than on consent.
This is illustrative, not advice about your specific arrangements — you have to check your own agreements.
| Service | What you transfer | Usual basis to check |
|---|---|---|
| E-commerce platform (Shopify, BigCommerce) | Customer names, addresses, order history, account data | The platform's data processing agreement. Check that it imposes a comparable standard and specifies destination countries (reg 11(2)). |
| Payment processor (Stripe, PayPal, an overseas acquirer) | Name, billing address, partial card data, transaction records | Their DPA and terms. Also consider whether the transfer is necessary to provide the service the customer asked for. |
| Analytics (Google Analytics 4) | IP address, device and behavioural data tied to a persistent identifier | The Google Ads / Analytics data processing terms. The tag also raises a separate consent question under sections 13 and 14 — that one is about collection, not transfer, and the PDPA answers it differently from the EU rules. |
| Advertising (Meta, Google Ads, TikTok) | Behavioural and identifier data, sometimes hashed customer lists | Their controller/processor terms. Customer-list uploads are a disclosure and need their own basis. |
| Email platform (Mailchimp, Brevo, Klaviyo) | Email addresses, names, engagement history | Their DPA. Check the destination countries clause. |
| Cloud hosting and backups (AWS, Google Cloud, Azure) | Everything in your database, including backups | The provider's DPA plus your chosen region. Backups may land in a different region from your primary. |
| Support and chat tools | Whatever a customer types into a chat window | Their DPA. Often overlooked because it feels like a conversation, not a data flow. |
Section 20 requires you to inform individuals, on or before collection, of the purposes for which their personal data is collected, used or disclosed. Sending data to an overseas processor is a disclosure, so the purpose of that disclosure belongs in the notification.
Neither section 20 nor the Regulations require a privacy policy to name your overseas recipients, state where they are, or set out the basis you rely on. The rest of this list is good practice rather than a statutory requirement, and it is what a customer, and a regulator reading after a complaint, will expect to find:
Where you are relying on the consent route in regulation 10(2)(a), the reasonable summary in writing required by regulation 10(3)(a) has to reach the individual before they consent. A sentence buried in a policy nobody was shown does not do that. Our privacy policy checklist covers the rest of the document.
Sitetals checks whether a privacy policy is reachable at all, whether a data protection contact is published, and whether analytics or advertising tags appear in your pages' source with no consent mechanism alongside them — the transfer-related signals that are visible from outside your organisation.
Run a free PDPA scanFree scan. Full PDF report with the PDPA references and a fix list from S$68.
No. Section 26 permits transfer outside Singapore provided the prescribed requirements are met — broadly, that the recipient is bound by legally enforceable obligations to a standard comparable to the Act. There is no data-localisation requirement in the PDPA.
Often, but check both limbs of regulation 11(2). The agreement must require the recipient to provide a comparable standard of protection and specify the countries and territories to which the data may be transferred. An agreement that covers the first and is silent on the second does not meet the regulation on its face.
No. Consent is one of five situations in regulation 10(2) in which the requirement is treated as met, and it is not the usual route for vendor transfers. The contract route under regulations 10(1) and 11 is what most operators rely on. If you do rely on consent, the conditions in regulation 10(3) apply — including a reasonable written summary of the protection standard before consent is given.
Two separate questions arise, and different provisions answer them. The transfer needs a basis under section 26 and the Regulations — usually Google's data processing terms. Separately, where the tag collects personal data, that collection needs consent under sections 13 and 14. Note what section 13 says: consent may be given or deemed. The PDPA contains no cookie provision, no terminal-equipment provision and no rule that consent must be captured before a tag loads, so the analysis is not the European one; PDPC's guidance on deemed consent is what decides it. Meeting the transfer requirement does not answer the collection question, and the reverse is also true.
No. The PDPA does not work through country adequacy decisions. It asks whether the recipient is bound by legally enforceable obligations providing comparable protection, which is an assessment about the recipient and the instrument binding it, not about the country.
Yes. If personal data is stored in a location outside Singapore that is a transfer, and that includes backups and disaster-recovery copies. The data-in-transit situation in regulation 10(2)(d) does not help here: regulation 9 defines data in transit as personal data passing through Singapore on its way to another country, which is not what your own systems do when they send data abroad.