GDPR for Singapore Companies: Scope and Obligations

Singapore’s position as the APAC headquarters for companies selling into Europe means a large share of its businesses touch European personal data without having asked whether the GDPR reaches them. It usually reaches them through Art. 3(2), and the analysis has two limbs, one significant nuance for regional service centres, and a written designation under Art. 27 that either exists or does not.

Two facts to establish before anything else. Compliance with the Personal Data Protection Act 2012 does not discharge GDPR obligations. And Singapore holds no EU adequacy decision — verified against the European Commission’s published list on 30 July 2026 — so European data reaching Singapore infrastructure needs its own transfer basis.

Key takeaways

• Art. 3(2) catches Singapore companies with no EU entity, no EU staff and no EU servers, on either a targeting test or a monitoring test. There is no turnover or volume threshold.
• A Singapore entity acting purely as a processor for an EU controller is generally not caught by Art. 3(2) directly — but it is bound through Art. 28 contract terms and the transfer rules apply regardless. The distinction changes what you must produce.
• Where Art. 3(2) applies and there is no EU establishment, Art. 27 requires a written designation of an EU representative, published in the privacy notice.
• Health data is Art. 9 special category data. For Singapore’s health-tech, medtech and clinical research sector, scope is only the entry point.
• Singapore’s PDPA transfer rules govern data leaving Singapore. They are irrelevant to data entering it from the EEA.

The two tests in Art. 3(2)

Art. 3(1) covers processing in the context of the activities of an EU establishment. Most Singapore companies have none. Art. 3(2) applies anyway where processing relates to offering goods or services to data subjects in the Union, or to monitoring their behaviour within it. The doctrine is set out in our general page on whether the GDPR applies outside the EU; what follows applies it to Singapore fact patterns.

Offering goods or services. Recital 23 rules out mere website accessibility and the accidental European customer. The question is whether you envisage offering to people in the Union. EDPB Guidelines 3/2018 list the working indicators: euro pricing or payment, EU-language content, EU delivery, country-code or .eu domains, EU customer references, advertising directed at European markets, international dialling codes. Art. 3(2)(a) applies “irrespective of whether a payment is required”, so free tiers and gated content count, and it concerns offering to natural persons — so a B2B contract with a European institution still brings the individuals whose data you process into scope.

Monitoring behaviour. Recital 24 names internet tracking and profiling. The limb is broader than cookies: behavioural analytics, retargeting, device fingerprinting, and remote monitoring of physiological or activity data from users located in the Union all qualify. It catches companies the first limb misses — a Singapore adtech or analytics vendor with no European sales but European traffic flowing through its tags.

The processor nuance that matters in Singapore

This one is routinely got wrong, and it matters disproportionately here because so many Singapore entities are regional service centres for foreign groups.

Where an EU-established controller engages a Singapore company to process on its behalf, the Singapore processor is not, by that fact alone, subject to the GDPR under Art. 3(2). The EDPB’s territorial-scope guidelines are explicit that the processor’s own processing activities must themselves relate to offering goods or services to people in the Union or monitoring them; merely providing processing services to a controller who does so is not enough to make the processor directly caught.

That does not mean nothing applies. The EU controller must impose the full Art. 28(3) terms on you by contract, and it must put a transfer mechanism in place because the data is leaving the EEA. So the practical burden is similar — Art. 28 obligations, security, sub-processor control, breach reporting to the controller, assistance with data subject rights — but the source of the obligation is contractual rather than direct, and you do not need an Art. 27 representative for that activity. Get the characterisation right before you buy anything: it determines whether you need a representative, whether you keep an Art. 30(1) controller record or an Art. 30(2) processor record, and which SCC module applies. Our page on controllers and processors sets out the test.

The trap is that most Singapore regional entities are processors for some activities and controllers for others — their own marketing, their own website analytics, their own EU-facing sales. One controller activity is enough to trigger Art. 27.

Worked examples

A Singapore telehealth platform with European users. Consultations booked by patients in Ireland or Germany, priced in euros, clinical records held in Singapore. Both limbs engage. Because the processing concerns health, Art. 9(1) applies and you need a condition under Art. 9(2) — typically Art. 9(2)(h) for the provision of health care under contract with a professional bound by secrecy, or Art. 9(2)(a) explicit consent — in addition to an Art. 6 basis. Two bases, both documented.

A Singapore medtech or SaMD company selling into Europe. CE-marked software or devices sold to European hospitals, telemetry and patient identifiers returning to Singapore. Scope follows from the offering test, and a DPIA is effectively mandatory under Art. 35(3)(b) for large-scale processing of health data. Note that if you are a device manufacturer you already designate an Authorised Representative in the Union under Art. 11 of Regulation (EU) 2017/745 — that is a separate obligation from the GDPR’s Art. 27 representative, with a different appointee and different statutory tasks. Neither satisfies the other; the point is developed in our page on GDPR for Australian companies, and it applies identically here.

A hospital group or medical-tourism operator marketing to European patients. Where a Singapore provider actively markets treatment to people in the Union — European-language pages, euro price indications, EU patient coordinators — it is offering services to data subjects in the EU, and the enquiry data it collects is health data from the first message.

A CRO or clinical data-management centre. European trial sites transmitting participant data to a Singapore coordinating centre. Usually a processor or sub-processor relationship, so the analysis above applies, but the transfer question is acute and the data is special category throughout.

A regional APAC headquarters. Shared services — payroll, HR, IT support, customer success — for a group with European entities. Almost always processor for the group’s data and controller for its own. Both records are needed.

And a non-health case. A Singapore SaaS company billing forty European customers in euros, with EU VAT handled through the OSS scheme, is offering services to people in the Union. Same scope conclusion, materially lighter consequences: Art. 6 alone, and a DPIA only if Art. 35 is otherwise triggered.

Why Art. 9 changes the exercise

For Singapore’s health sector, scope is the beginning of the work rather than the end. Three consequences follow immediately:

1. A cumulative lawful basis. Art. 9(1) prohibits health data processing unless an Art. 9(2) condition applies, and that condition sits on top of the Art. 6 basis rather than replacing it. Legitimate interest is not available. Explicit consent under Art. 9(2)(a) must meet the Art. 7 standard and be a separate, unambiguous statement. See our page on special categories of data.
2. A DPIA before deployment. Art. 35(3)(b) applies to large-scale special category processing; where residual high risk remains, Art. 36 requires prior consultation with the supervisory authority. Our DPIA guide sets out the method.
3. The upper enforcement band. Art. 83(5) reaches EUR 20 million or 4% of worldwide turnover, and Art. 83(2)(g) makes the special-category nature of the data an explicit aggravating factor. See Art. 83.

What being in scope requires

The whole regulation applies to the activity: an Art. 6 basis per purpose, transparency notices under Art. 13, one-month responses to data subject access requests at no charge, erasure and objection rights, Art. 28 contracts down the sub-processor chain, an Art. 30 record of processing activities, security proportionate to risk, and breach notification within 72 hours of awareness. That last clock is materially tighter than the PDPA’s, which runs from the completion of your assessment rather than from awareness — the divergence is set out in our comparison of the PDPA and the GDPR.

The Art. 27 representative

Art. 27(1) requires a controller or processor caught by Art. 3(2), with no EU establishment, to designate a representative in the Union in writing, established in a member state where the relevant data subjects are, with the details published in the privacy notice. It is the single easiest finding a supervisory authority or a procurement lawyer can make, and the cheapest to fix. The representative is a contact point, not a liability shield and not a data protection officer. Our pages on Art. 27 and non-EU representatives and on selecting an EU representative cover the mandate and the mechanics.

The Art. 27(2)(a) exemption requires processing that is occasional, that does not include large-scale processing of Art. 9 or Art. 10 data, and that is unlikely to result in a risk to rights and freedoms — all three, simultaneously. Any recurring commercial relationship fails the first limb; any health company fails the second.

The order of work

1. Scope and role memo. Per activity: which limb of Art. 3(2), controller or processor, and whether Art. 9 data is involved. One page, and the first thing European counsel will ask to see.
2. Art. 30 record — Art. 30(1) for controller activities, Art. 30(2) for processor activities.
3. Lawful basis register, with the Art. 9(2) condition recorded separately where relevant.
4. Art. 27 designation in writing, published in the privacy notice, for controller activities.
5. DPIA for large-scale special category processing, before deployment.
6. Transfer file — module, annexes, transfer impact assessment; see Singapore–EU data transfers.
7. Tooling to keep it current: GDPR compliance software for Singapore companies.

FAQ

We only process on behalf of our European parent. Do we need an Art. 27 representative?

For that processing, generally no — a non-EU processor serving an EU controller is not usually caught by Art. 3(2) directly. But check whether you also carry out any activity of your own that targets or monitors people in the Union. Your own marketing site and its analytics are the usual culprit, and one such activity triggers Art. 27.

Does PDPA compliance cover the GDPR?

No. The PDPA is consent-centric with enumerated exceptions; the GDPR runs on six equal lawful bases plus a separate regime for special category data, and it confers individual rights the PDPA does not. Singapore holds no adequacy decision, which is the Commission’s formal position that Singapore law is not essentially equivalent.

Does the EU–Singapore Digital Trade Agreement solve the transfer problem?

No, and this is the most common misreading in the market. It is a trade instrument, not an Art. 45 adequacy decision, and it expressly preserves each party’s right to regulate the protection of personal data. The point is addressed in detail in our page on Singapore–EU data transfers.

Can a European authority act against a Singapore company?

There is no Art. 56 one-stop-shop for a controller without an EU main establishment, so any supervisory authority in whose territory affected data subjects are located may act. The more frequent consequence, however, is commercial: European procurement teams treat a missing representative, record or transfer file as a disqualifying finding.