GDPR for Singapore companies

Who this is relevant to

This guide is written for Singapore-headquartered technology companies with no establishment in the European Union. If you have an EU subsidiary or branch, more of the regulation applies to you and by a different route.

• —B2B SaaS companies signing their first European enterprise customer
• —Companies whose product is used by employees or customers located in Europe
• —Service providers hosting or accessing customer data that originates in the EU
• —Consumer apps and marketplaces with European users
• —Companies that have just received a European DPA, security questionnaire or transfer impact assessment

How an EU regulation reaches a company in Singapore

The GDPR is not limited to companies established in Europe. Article 3(2) extends it to companies outside the Union in two situations: where you offer goods or services to individuals who are in the EU, and where you monitor the behaviour of individuals while they are in the EU.

“Offering” means aiming at people in Europe, not merely being reachable from Europe. Pricing in euro, shipping to EU countries, translating your product into European languages, running European ad campaigns and naming European customers in marketing all point towards an offering. A Singapore website that a person in Berlin can technically load does not, by itself.

“Monitoring” covers behavioural analytics, ad tracking, profiling and scoring of people while they are physically in Europe. Product analytics that follow a user's in-app behaviour can qualify. This is the limb that catches companies who believe they only sell B2B.

There is a third route that is not about extraterritorial reach at all: your customer is subject to the GDPR and instructs you to process personal data. You are then a processor. Your obligations arrive through the contract your customer is legally required to put in place, and they are enforceable.

Direct application vs customer flow-down

It matters which of the two you are facing, because the remedies are different. A direct obligation survives the loss of any individual customer and is enforced by a European supervisory authority against you. A flow-down obligation is contractual: it is negotiated, it is enforced by your customer, and it typically blocks revenue rather than triggering a fine.

In practice many Singapore vendors are in both positions for different data: a controller for their own marketing and website analytics aimed at European prospects, and a processor for the customer data inside their product.

• —Direct (controller): you decide why and how personal data is used, covering your own users, your marketing, your analytics
• —Flow-down (processor): you handle data on documented instructions from an EU customer, under a contract with prescribed terms
• —Both at once is normal, and each role carries a different set of documents

What European customers typically ask you to produce

European buyers rarely ask “are you GDPR compliant?”. They ask for artefacts, and the deal moves at the speed you can produce them.

• —A signed data processing agreement on their paper, or a credible one on yours
• —A current subprocessor list, with a mechanism for notifying changes
• —Where personal data is stored and which countries your staff access it from
• —Your technical and organisational security measures, in writing
• —A breach notification commitment with a defined timeframe
• —A named privacy contact who can answer questions without escalation
• —Your position on international transfers, and any assessment behind it
• —Evidence that data subject requests reaching your customer can be actioned in your system

Common misconceptions

“We have no EU entity, so the GDPR cannot apply to us.”

Establishment is one route into scope, not the only one. Targeting people in the EU or monitoring their behaviour brings a non-EU company into scope directly.

“We are PDPA compliant, so we are essentially there.”

The PDPA gives you a real head start: an inventory, a named owner, breach processes. But the scope, the individual rights, the lawful basis analysis and the documentation a European buyer expects all differ. Treat the PDPA as foundation, not equivalence.

“We are B2B, so we do not process personal data.”

Business contact details, user accounts, support tickets, session recordings and product analytics are all personal data when they relate to identifiable people.

“Our cloud provider is certified, so transfers are covered.”

Your provider's certifications concern their own operations. The transfer position for data you receive is yours to establish, and your customer will ask you for it.

“Signing Standard Contractual Clauses closes the transfer question.”

Clauses are one possible mechanism, and using them generally requires an assessment of the destination. Do not promise a mechanism in a questionnaire before you have established it is the right one.

Practical checklist

1. 01Establish whether you are a controller, a processor, or both, separately for each dataset you hold
2. 02Write down which of your activities involve people located in the EU, and why
3. 03Map where EU personal data is stored and from which countries it is accessed, including by your own engineers
4. 04Prepare a data processing agreement you can offer, rather than only reacting to your customer's
5. 05Maintain a subprocessor register you can send without editing it first
6. 06Document your security measures at a level of detail a buyer's security team will accept
7. 07Define your breach detection and notification path, with a timeframe you can actually meet
8. 08Name a privacy owner internally, even if the role is part-time
9. 09Establish your transfer position before a buyer asks. Do not improvise it in a questionnaire
10. 10Check whether your website and product use cookies or device storage that require consent

The Singapore transfer question

There is no current EU adequacy decision covering Singapore. In practice this means the mechanism for any EU-origin personal data reaching your systems has to be assessed rather than assumed.

That assessment may conclude that Standard Contractual Clauses are the right route, but it may not: the answer depends on the data, the parties and the circumstances of the transfer. This is why we do not print “use SCCs” as an automatic recommendation for Singapore companies.

Singapore's Personal Data Protection Act and its Transfer Limitation Obligation already require you to think about onward transfers, so the discipline is familiar. What changes is that the assessment now has to answer a European question, and be documented in a form a European buyer's legal team will accept.

Cookies and device storage are a separate rulebook

Consent for cookies, SDKs and similar device storage comes from the ePrivacy Directive, implemented in national law, not from the GDPR itself. A Singapore company can be broadly in order on data protection and still be non-compliant on the consent banner in its EU-facing product.

Official EU sources

Every conclusion on this page traces back to the primary legal text. We link only to official EU sources.

• Regulation (EU) 2016/679 — General Data Protection Regulation · Read on EUR-Lex (CELEX 32016R0679)Verified 2026-08-17

• Directive 2002/58/EC — ePrivacy Directive · Read on EUR-Lex (CELEX 32002L0058)Verified 2026-08-17