Why roles decide accountability
The GDPR does not treat every company that touches personal data the same way. It splits them into two roles with very different duties. The controller decides why and how data is used and carries the heavy accountability. The processor only acts on the controller's instructions. Get the labelling wrong and you either sign the wrong contract, accept a duty that is not yours, or - more dangerously - miss one that is. For a Singapore SaaS with a stack of cloud vendors, this is the hour that turns your vendor list into a clean map of who owes what.
Who is responsible 9 min live
Almost every duty in the GDPR is addressed to "the controller". So the first question in any data relationship is simple: who is the controller, and who is merely processing on their behalf? The answer is not about size or seniority - it is about who decides.
LiveController or processor - the deciding test3 min▶
The labels turn on one question: who decides the purposes and the means of the processing? Decide those, and you are the controller, whatever your job title or company size.
- Controller (Art 4(7)). The party that determines the purposes AND means of processing - the why and the how. Your company is the controller for your own customer data: you decided to collect it and what to do with it.
- Processor (Art 4(8)). The party that processes personal data on the controller's behalf, acting only on documented instructions. Your cloud host, your email-sending service, your payroll bureau are usually processors of your customer data.
- The heavy duties sit with the controller. Lawful basis, transparency, responding to individuals - all addressed to the controller. A processor that starts deciding purposes for itself stops being a processor and becomes a controller, with all that implies.
LiveThe Article 28 data processing agreement3 min▶
When you hand personal data to a processor, Article 28 requires a binding written contract - the data processing agreement, or DPA. It is not optional paperwork; it is the legal instrument that keeps a processor a processor.
- What it must say. The processor may process only on your documented instructions; staff are bound to confidentiality; Article 32 security measures are in place; sub-processors are controlled; the processor assists you with individuals' rights, breach notification, and DPIAs; data is deleted or returned at the end; and you may audit.
- "Sufficient guarantees". A controller must use only processors that provide sufficient guarantees they can meet the GDPR. Choosing a cheap vendor with no security posture is itself a compliance failure.
- Why leaders care. If a processor causes a breach and you had no proper DPA, the gap is yours. The DPA is how accountability flows correctly down your supply chain.
Self-studyYou are usually the controller for your customers2 min read▶
The most common labelling error a growing company makes is assuming a big-name cloud vendor is the controller because it is larger and more sophisticated. Size is irrelevant. For the personal data you collected from your own customers, you decided the purpose and the means, so you are the controller - and the cloud vendor, however large, is your processor for that data. The vendor may of course be a controller for its own separate purposes (its billing relationship with you, its own account data), which is why real relationships can carry both labels at once for different data sets. The discipline is to label per data flow, not per company. Do this once, cleanly, and the rest of the GDPR tells you exactly which duties are yours.
DPO and DPIA - when you must 8 min live
Two GDPR obligations only bite in defined situations, and leaders routinely over- or under-apply them. A Data Protection Officer is mandatory only in narrow cases. A Data Protection Impact Assessment is required only when processing is high-risk. Knowing the triggers stops you both from missing a duty and from inventing one.
LiveWhen a DPO is mandatory - and the PDPA gap3 min▶
Under the GDPR a Data Protection Officer is mandatory only in three defined cases (Art 37(1)). Outside them, appointing one is a sensible choice, not a legal requirement.
- (a) Public authorities and bodies. Rare for a private Singapore SaaS.
- (b) Large-scale regular and systematic monitoring. Where that monitoring is a core activity - think ad-tech, extensive behavioural tracking.
- (c) Large-scale special-category or criminal data. Where processing sensitive data (Art 9) or offence data (Art 10) is a core activity - think a health platform.
The contrast leaders must hold in mind: the PDPA requires every organisation in Singapore to appoint a DPO, with no threshold. So a Singapore company almost certainly has a DPO already for PDPA reasons, even where the GDPR would not compel one. Same role, different trigger.
LiveWhen a DPIA is required3 min▶
A Data Protection Impact Assessment (Art 35) is a structured look-before-you-leap: required where a type of processing is likely to result in a high risk to individuals' rights. The Regulation names three mandatory examples.
- Systematic and extensive profiling that produces legal or similarly significant effects on people - for example automated decisions that decide who gets a loan or a job.
- Large-scale processing of special-category (Art 9) or criminal-offence (Art 10) data.
- Large-scale systematic monitoring of a publicly accessible area - for example widespread camera or sensor tracking.
A DPIA is done before the high-risk processing starts, and it documents the risks and the measures that bring them down. For a leader it is a governance gate: no DPIA on a high-risk launch is a red flag, not a paperwork delay.
Lumina and its cloud vendors. Lumina (our fictional Singapore SaaS) is the controller for its customer data. Its cloud host, transactional-email service, and analytics tool are processors, each needing a DPA. Lumina's processing is ordinary B2B account data at modest scale - no core-activity monitoring, no sensitive data - so the GDPR does not force a DPO or a DPIA. But Lumina already has a DPO because the PDPA requires one. The moment Lumina adds a feature that profiles users to auto-decide pricing tiers, the DPIA question reopens.
Map Lumina's vendors ★ 12 min · pen and paper
Roles become concrete the moment you draw them. Take a real vendor list and label every relationship.
List your (or Lumina's) vendors that touch personal data: cloud host, email service, analytics, payment gateway, support desk, payroll.
For each, ask the deciding question: who determined the purpose and the means of that processing? If you did, you are the controller and the vendor is your processor.
Mark which relationships therefore need an Article 28 DPA - every controller-to-processor flow does.
Flag any vendor that decides its own purposes with your data. That one is a separate controller, and the relationship needs a different contract, not a DPA.
Do we need a DPO or a DPIA ★ 8 min · your next governance review
Two short decisions, run honestly, tell you whether either obligation bites your organisation today.
DPO test. Are we a public authority? Is large-scale regular and systematic monitoring a core activity? Is large-scale special-category or criminal data a core activity? Any yes means the GDPR mandates a DPO. If all no, note that the PDPA still requires one anyway.
DPIA test. Does any current or planned processing match the three high-risk examples - extensive profiling with significant effects, large-scale sensitive data, or large-scale monitoring of a public area?
For any DPIA "yes", note whether the assessment was actually done before the processing began. A missing DPIA on a live high-risk feature is the finding.
Record who holds the DPO role today and whether their independence and reporting line are real, not nominal.
Before session a5 ◐ 30 min total
- Finish the vendor map and mark every relationship that needs an Article 28 DPA. Keep it - a5 (breach) leans on knowing which processors must help you notify.
- Run the DPO and DPIA tests and record the answers, including the PDPA "DPO for every org" point.
- Ask your team: do we have a signed DPA with every processor that touches personal data, and does each one require processors to assist with breaches and rights?
- Optional: read GDPR Article 28 - the list of required contract terms is the checklist your DPAs should already meet.
- For each vendor, are we the controller or the processor - and does our labelling match reality per data flow?
- Do we hold a signed, GDPR-compliant Article 28 DPA with every processor, with sub-processor, audit, and assist clauses?
- Does the GDPR mandate a DPO for us, or only the PDPA - and is our current DPO independent and properly resourced?
- Does any live or planned processing trigger a mandatory DPIA, and if so was one done before launch?
- Which of our vendors give "sufficient guarantees", and how did we assess that before signing?
Official sources covered
Taught from the GDPR text and reputable comparative guidance. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Your Singapore SaaS collects customer data and stores it with a large cloud host. For that data, who is the controller?
The controller is whoever determines the purposes and means (Art 4(7)). You collected the data and decided its use, so you are the controller regardless of the vendor's size; the host processes on your behalf.
2 · Under the GDPR, when is appointing a DPO mandatory?
Article 37(1) makes a DPO mandatory only in those defined cases. "Every organisation, always" is the PDPA rule, not the GDPR - a key contrast for a Singapore company.
3 · A DPIA is required when...
Article 35 ties the DPIA to high-risk processing and names three mandatory examples. It is a before-you-launch assessment, not a response to a breach, and not required for all processing.