You can't enforce what you can't recite
Session 1 gave you the seat. Today you get the rulebooks that come with it. A DPO who can't name the obligations they enforce is guessing - and a regulator's first question is never "do you feel compliant?" It's "which obligation applies here, and can you show me?" We learn the two texts a Singapore DPO holds in their head: the PDPA, your home law and primary reference, and the GDPR, the international mirror you use to sanity-check yourself. Same goal - protect the person, hold the organisation accountable - two different shapes.
The PDPA - 11 obligations 8 min live
Singapore's Personal Data Protection Act organises an organisation's duties into 11 Data Protection Obligations. Learn these as a set - they're the checklist you run every time Himalaya wants to do something with personal data. The PDPA is consent-centric: the default is that you need consent to collect, use, or disclose personal data, with a defined set of exceptions. That single design choice is the biggest thing separating it from the GDPR.
LiveThe consent-first model (and deemed consent)3 min▶
The PDPA's spine is consent. As a default, an organisation may only collect, use, or disclose personal data if the individual has consented, for purposes a reasonable person would consider appropriate, and after being notified of those purposes. Everything downstream leans on that consent being real.
Because pure opt-in consent isn't always practical, the PDPA also recognises deemed consent - consent inferred from the situation. If a consumer voluntarily hands over their phone number to complete a booking, they're deemed to consent to it being used for that booking. There's also deemed consent by notification for certain secondary uses. We work deemed consent hard in Session 4; for now, hold two facts.
- Consent is the default gate, not one option among several. That is the opposite of the GDPR's design, which you'll see in Part 2.
- Deemed consent is real but narrow - it is not a licence to reuse data for anything. A booking phone number is not a marketing list.
Himalaya's marketing engine. Ilsa (CRO) treats every phone number in the warehouse as a marketing list. But most of those numbers arrived through a booking or a purchase - deemed consent for that transaction, not for SMS blasts. Reusing them for marketing needs its own consent basis and a DNC check. That gap is obligation #1 (Consent) failing at scale.
LiveThe 11 obligations, in plain language3 min▶
Learn them as one list. You'll enforce every one of these on Himalaya across the next six sessions.
| Obligation | In plain language |
|---|---|
| 1 · Consent | Get consent (or a valid deemed/exception basis) before you collect, use, or disclose. |
| 2 · Purpose Limitation | Only use data for purposes a reasonable person would find appropriate, and that you notified. |
| 3 · Notification | Tell people why you're collecting their data, on or before collection. |
| 4 · Access & Correction | Let individuals see the data you hold about them and correct it if wrong. |
| 5 · Accuracy | Make a reasonable effort to keep personal data accurate and complete. |
| 6 · Protection | Protect data with reasonable security arrangements. (Session 5.) |
| 7 · Retention Limitation | Stop keeping data once the purpose is done and there's no legal need. (Session 6.) |
| 8 · Transfer Limitation | Only send data abroad to comparable protection. (Session 6, the US vendor.) |
| 9 · Data Breach Notification | Assess and notify breaches within the deadlines. (Session 5.) |
| 10 · Accountability | Have policies, be able to demonstrate compliance, and appoint a DPO. |
| 11 · Data Portability | Let individuals move their data to another organisation. Enacted 2020, not yet in force. |
Self-studyPenalties and the regulator (PDPC)2 min read▶
The obligations have teeth. The regulator is the Personal Data Protection Commission (PDPC), which investigates complaints and breaches, issues directions, and imposes financial penalties.
- Financial penalty ceiling: up to S$1 million, or 10% of the organisation's annual turnover in Singapore, whichever is higher. The turnover limb is what makes this bite for a company Himalaya's size.
- The PDPC also issues directions - stop processing, fix a control, notify affected individuals - which can be more operationally painful than the fine itself.
- Enforcement is public. Decisions are published, and the reputational cost of a named breach decision often exceeds the dollar figure.
Ilsa's line is "a fine is just cost of doing business." Do the maths on the turnover limb for a company at Himalaya's revenue and the number stops looking like a rounding error - and that's before the published decision that every prospective client will read. Your job is to make that trade-off visible before the campaign, not after the PDPC calls.
Which obligations is Himalaya breaking right now? Before you learn the GDPR, name the home-law failures. Consent (#1) - marketing blasts the 8M base with no valid marketing consent and no DNC check. Protection (#6) - the near-miss export left consumer records exposed for 6 days. Retention (#7) - "keep everything," including ex-clients' consumer data. Transfer (#8) - EU consumer data flows to a US analytics vendor with no safeguards on file. Four obligations, four live risks, all under your home law before GDPR even enters the room.
The GDPR mirror 7 min live
Himalaya has EU consumers, so the GDPR is in play - and even where it isn't, it's the benchmark the whole world checks against. The GDPR expresses its duties as 7 principles (Article 5), backed by 6 lawful bases (Article 6) and 8 data subject rights. The single most important contrast: where the PDPA is consent-centric, the GDPR gives you six co-equal bases to process data - consent is only one of them.
LiveThe 7 principles (Article 5)2 min▶
Article 5 is the GDPR in miniature. Everything else is machinery for these seven ideas.
- Lawfulness, fairness, transparency - process on a valid legal basis, don't be deceptive, tell people what you're doing.
- Purpose limitation - collect for specified purposes, don't quietly repurpose.
- Data minimisation - collect only what you need. (The PDPA has no explicit minimisation obligation - a real gap to note.)
- Accuracy - keep it correct and current.
- Storage limitation - don't keep it longer than needed (the GDPR's version of Retention Limitation).
- Integrity & confidentiality - secure it (the GDPR's version of Protection).
- Accountability - the seventh principle wraps the other six: you must be able to demonstrate compliance, not just claim it.
LiveThe 6 lawful bases (Article 6)3 min▶
This is the biggest structural difference between the two laws. Under the GDPR you need a lawful basis to process personal data - and there are six co-equal ones. Consent is just one. Picking the wrong basis, or defaulting to consent when another fits better, is a classic mistake.
| Lawful basis | When it applies |
|---|---|
| Consent | The individual gave clear, freely-given, specific agreement. |
| Contract | Processing is needed to perform a contract with the individual. |
| Legal obligation | A law requires you to process (e.g. tax, AML records). |
| Vital interests | Needed to protect someone's life. |
| Public task | Carrying out an official function in the public interest. |
| Legitimate interests | Your (or a third party's) genuine interest, balanced against the individual's rights. |
For Himalaya's EU consumers, delivering the booking they paid for runs on contract, not consent - so you don't need a consent checkbox to fulfil the order. But Ilsa's marketing to those same EU consumers needs its own basis, usually consent or a carefully documented legitimate interests assessment. Naming the right basis per activity is exactly what your Session-2 build produces.
Self-studyThe 8 data subject rights2 min read▶
The GDPR gives individuals eight rights. You don't operate these until Session 6 (lifecycle and requests), but a DPO should be able to list them cold.
| Right | What the individual can do |
|---|---|
| Informed | Be told how their data is used (privacy notice). |
| Access | Get a copy of their data and details of the processing. |
| Rectification | Have inaccurate data corrected. |
| Erasure | Have data deleted in defined circumstances ("right to be forgotten"). |
| Restriction | Freeze processing while a dispute is resolved. |
| Portability | Receive their data in a portable format and move it elsewhere. |
| Object | Object to processing, including direct marketing. |
| Automated-decision safeguards | Not be subject to solely automated decisions with legal or similar effect, without safeguards. |
The PDPA's Access & Correction obligation covers the first three ideas; its pending Portability obligation mirrors the sixth. The GDPR simply spells out more of them as named individual rights. We exercise these on Himalaya in Session 6.
PDPA vs GDPR - what a SG DPO holds in their head 5 min live
You won't carry the full text of two laws around. You'll carry the differences - the handful of places where enforcing PDPA and enforcing GDPR lead you to do genuinely different things. Get these eight contrasts fluent and you can advise Himalaya on either side of the border without reaching for the book.
LiveThe eight differences that change your day3 min▶
This is the side-by-side to memorise. Each row is a place where "just do what GDPR says" would give you the wrong answer in Singapore, or vice versa.
| Dimension | PDPA (Singapore) | GDPR (EU) |
|---|---|---|
| Consent model | Consent-centric, with defined exceptions and deemed consent | 6 co-equal lawful bases; consent is only one |
| Breach timeline | Notify PDPC within 3 calendar days after assessing it's notifiable | Notify authority within 72 hours of awareness |
| Max penalty | S$1M or 10% of SG turnover, whichever higher | €20M or 4% of global turnover, whichever higher |
| Extraterritoriality | Narrower - focused on organisations operating in Singapore | Broad - reaches offering goods/services to EU residents (Art. 3) |
| DPO mandate | Every organisation must appoint one | Only in 3 defined cases (Art. 37) |
| Portability | Enacted 2020, not yet in force | In force as a data subject right |
| Cross-border transfer | Transfer to comparable protection standard | Adequacy / SCCs / BCRs regime |
| Do Not Call registry | Unique to Singapore - check the DNC register before marketing | No DNC equivalent; ePrivacy rules instead |
Self-studySame person, two laws - which applies?2 min read▶
Both laws can apply to the same data at once. An EU consumer buying through a Himalaya client triggers the PDPA (data processed in Singapore) and the GDPR (an EU resident being offered a service). You don't pick one - you satisfy both, which in practice means holding to the stricter standard on each dimension.
- On breach, the GDPR's 72-hour clock is tighter than PDPA's - so for EU-consumer data, plan to the 72-hour standard.
- On the DPO, the PDPA already forces one, so that box is ticked regardless.
- On transfers, you'll need to satisfy both the PDPA comparable-protection standard and the GDPR transfer regime for the EU→SG→US flow (Session 6).
The practitioner rule of thumb: meet PDPA as the floor for everything, and layer GDPR's stricter requirements wherever EU residents are in the data.
Build Himalaya's obligation-to-risk map ★ 19 min · on Himalaya
Knowing the obligations is nothing until you can point them at a real company and rank what to fix first. Today you'll turn the two rulebooks into one working artifact: a map of Himalaya's processing activities, the obligation each one engages, whether the GDPR adds anything, and a risk rating that tells you where to start. This map feeds Sessions 4, 5, and 6 directly.
Himalaya - B2B2C SaaS, Singapore-headquartered, 8M end consumers and 1,200 business clients, with consumers across SG, EU and SE Asia. Live problems from Session 1: marketing blasts the 8M base with no DNC check or valid marketing consent; a near-miss export exposed consumer records for 6 days; retention is "keep everything," including ex-clients' data; and EU consumer data flows to a US analytics vendor with no safeguards. You're the DPO. Today you name which obligation each of those engages, and rank them.
List the processing activities. Write out what Himalaya actually does with personal data: onboard consumers, run bookings/payments, blast marketing, ship analytics to the US vendor, keep everything in Redshift, respond to consumer queries. Aim for 6-8 activities.
Name the PDPA obligation(s) per activity. For each activity, write which of the 11 obligations it engages. Marketing → Consent + (DNC check). US analytics feed → Transfer Limitation. Keep-everything → Retention Limitation. The near-miss → Protection + Data Breach Notification.
Add the GDPR delta. For activities touching EU consumers, note what the GDPR adds - a stricter breach clock (72h), a lawful-basis question beyond consent, the formal transfer regime, data minimisation. If GDPR adds nothing new, write "PDPA covers."
Rate current risk H / M / L. Score each activity on likelihood × harm as it stands today. Marketing with no DNC check and the undocumented US transfer should land High; a well-run booking flow might be Low.
Pick the top 3 to fix first. Rank by risk and pick three. For Himalaya these foreshadow the course: marketing/consent (Session 4), breach readiness (Session 5), and retention + transfer (Session 6). Write one line each on why it's top-3.
Try it yourself - this week ◐ 30-45 min total
- Run the obligation-to-risk prompt on your own organisation (or one team). Produce the table and pick your real top 3 - you'll reuse it as your priority list for the rest of the course.
- Write the 11 PDPA obligations from memory, then check yourself against the list. Circle the one that's enacted-but-not-in-force (Portability) so you never quote it as live.
- For one activity you own, name the PDPA obligation and the GDPR lawful basis that would apply if an EU consumer were involved. Notice whether consent is really the best basis, or whether contract or legitimate interests fits better.
- Find one place in your org where someone assumes the "72-hour rule" applies to a Singapore breach. Note the correction: PDPA is 3 calendar days after assessing notifiability.
- Optional: skim the PDPC obligations page and GDPR Articles 5 and 6 to see the primary text behind today's plain-language versions.
What this session covers
This session teaches the working content of the laws below. Full statutory text, case law, and certification exams stay with their official sources - this page makes you fluent in the body of knowledge, honestly flagged where depth lives elsewhere.
Three questions before you go 🎯 ◐ 90 seconds
1 · Himalaya has a notifiable breach. How long does the PDPA give you to notify the PDPC?
72 hours is the GDPR rule. Under the PDPA you assess within 30 days, then if notifiable you have 3 calendar days to tell the PDPC.
2 · What's the biggest structural difference between the PDPA and the GDPR on lawful processing?
The PDPA defaults to consent (with exceptions and deemed consent). The GDPR offers six co-equal bases - consent is only one of them.
3 · A client asks you to help them honour the PDPA Data Portability Obligation today. What do you say?
The obligation was legislated in the 2020 amendment but its commencement is not yet in force. Teach and plan for it; never advise it as a live duty. Re-check the PDPC site.