Why this course exists
Your data team can build pipelines, models, and dashboards. What most data teams cannot do yet is answer a regulator's simplest question: "What personal data do you hold, why, and who said you could?" This 8-session course turns a data practitioner into someone who can run as a Data Protection Officer - protect the people in the data, and protect the company from the fine. We learn it by governing one company, Himalaya, from its messy first day to a board-ready program.
What data governance actually is 7 min live
Governance is not a tool, a team, or a folder of policies nobody reads. It is the exercise of authority and decision-making over data: who gets to decide, how decisions are enforced, and who is accountable when it goes wrong. Everything else - quality, security, catalogs - is a capability governance directs.
LiveGovernance vs management vs "the data team"3 min▶
People blur three different things. Data management is the doing - building pipelines, storing, modeling, serving. Data governance is the deciding - setting the rules, rights, and accountability the doing must follow. The data team is a set of people who mostly do management and, until someone insists otherwise, govern by accident.
The tell that a company has no real governance: ask "who decided we could keep this?" and you get a shrug, a Slack thread, or "that's just how the pipeline was built." Governance replaces the shrug with a name, a policy, and a paper trail.
Why this matters to you
- As a DPO you will spend far more time on decision rights and accountability than on technology. The hard part is organisational, not technical.
- Your credibility comes from being able to say who is accountable for each dataset and on what basis it is held - not from owning a fancy catalog.
Himalaya, day one. Raj (Head of Platform) says "we keep everything in Redshift, it's all governed - we have access controls." That's management, not governance. Nobody has decided what should be kept, for how long, or why. Your first job is to turn that "it's handled" into a real, defensible answer.
LiveThe DAMA wheel - governance at the hub2 min▶
The industry's standard map of data management is the DAMA-DMBOK2 wheel: eleven knowledge areas. Ten are capabilities - the work. The eleventh, Data Governance, sits at the centre because it directs and connects all the others. You don't need to master all ten to be a DPO, but you must know they exist and how governance steers each one.
Self-studyThe ten spokes, in one line each2 min read▶
| Knowledge area | What it covers · why a DPO cares |
|---|---|
| Architecture | The blueprint of how data flows. Your data maps (Session 3) live here. |
| Modeling & Design | How data is structured. Where personal fields get defined - or hidden. |
| Storage & Operations | Databases and their running. Where retention and disposal actually happen. |
| Data Security | Access, encryption, controls. Your Protection Obligation leans on this (Session 5). |
| Integration & Interoperability | Moving data between systems - every move is a potential transfer risk. |
| Document & Content | Unstructured data (PDFs, emails). Personal data hides here too. |
| Reference & Master Data | The single source of truth for "who is this customer" - key for access requests. |
| Warehousing & BI | Analytics. Where personal data quietly gets copied for reporting. |
| Metadata | Data about data - the catalog, glossary, lineage. Your visibility layer (Session 3). |
| Data Quality | Accuracy, completeness. Backs your Accuracy Obligation (Session 6). |
The DPO role, and why it's the law 7 min live
Here is the fact that surprises most data people: in Singapore, appointing a Data Protection Officer is not optional and not size-dependent. Every organisation must designate at least one DPO. In the EU it's the opposite - mandatory only in three defined situations. Knowing both, and which applies to your company, is DPO literacy step one.
LiveWhat the DPO actually does2 min▶
GDPR Article 39 gives the cleanest task list, and it maps well onto the PDPA role. A DPO's job is five verbs:
- Advise - tell the business and its staff what the law requires, before they act, not after.
- Monitor - check compliance with the law and internal policies; run awareness, training, and audits.
- Assess - advise on and track data protection impact assessments (DPIAs) for risky processing (Session 8).
- Cooperate - be the working contact for the regulator (PDPC in Singapore).
- Point - be the named contact both regulators and data subjects can reach.
When Ilsa (CRO) plans a new 8M-consumer SMS campaign, the DPO doesn't run the campaign or block it on instinct. The DPO advises ("here's the consent and DNC check you need first"), monitors that it happened, and is the person the PDPC calls if a complaint lands. Advisor and watchdog, not gatekeeper.
LiveIndependence - the part companies get wrong2 min▶
The DPO role only works if it has teeth, so the law protects its position. Under GDPR Article 38 - and as good practice everywhere - the DPO:
- Reports to the highest level of management - not buried three layers down under a manager whose project you might have to flag.
- Acts independently - no one instructs the DPO on how to do the role, and the DPO cannot be dismissed or penalised for doing it.
- Has no conflict of interest - you can't be DPO and also the person who owns the marketing database whose lawfulness you're meant to judge.
- Is properly resourced - given time, budget, and access to carry the role, not handed it as a title on top of a full-time job.
Self-studyThe DPO and the certifications1 min read▶
This course teaches the DPO body of knowledge. If you later want the paper credentials, the recognised ones are from the IAPP:
- CIPP/E - knowing the privacy law (GDPR and European data protection).
- CIPM - operationalising a privacy programme (the management side of the DPO job).
- CIPT - engineering privacy into products and systems (privacy by design).
IAPP positions CIPP/E + CIPM together as the standard training combination for the DPO role. In Singapore, the PDPC also runs its own practitioner courses. The exams and certificates stay with those official bodies - this course gets you fluent in what they test.
Personal data, PII, and the sensitive tier 6 min live
You cannot protect a category you can't define. Data people say "PII" loosely; the law is more precise, and one tier - sensitive or "prescribed" data - carries far heavier duties. Getting this ladder right is what makes your data map (Session 3) actually mean something.
LivePersonal data - broader than you think2 min▶
Under both PDPA and GDPR, personal data is any data about an identifiable individual - on its own or combined with other data the organisation has or is likely to have. That "combined with" clause is the trap: an anonymous-looking table plus one join key becomes personal data.
- PII (personally identifiable information) is the common US-flavoured term for the obvious identifiers - it is roughly a subset of "personal data," which is the legal term you should use.
- A device ID, an IP address, or an in-app behaviour trail can be personal data when it can be tied back to a person - which, in a product like Himalaya's, it usually can.
- Anonymisation (truly irreversible) takes data out of scope; pseudonymisation (reversible with a key) does not - it's still personal data.
Raj proudly shows you an "anonymised" analytics table - no names, just a consumer_id. But there's a lookup table one schema over that maps consumer_id to email. Combined, it's fully personal data, and it's been feeding a US analytics vendor for a year. That's not anonymised; that's pseudonymised, and it's in scope.
LiveThe sensitive tier - why it changes everything2 min▶
A subset of personal data is treated as far riskier because misuse causes real harm. GDPR calls it special category data (Art. 9); Singapore's breach rules turn on prescribed personal data. Either way, the practical effect is the same: heavier consent, stronger protection, and a lower bar for when a breach becomes notifiable.
- Typical members: health data, financial account details, national IDs (NRIC), login credentials, biometrics, and - under GDPR - race, religion, sexual orientation, and more.
- A breach involving this tier is much more likely to cross Singapore's "significant harm" threshold and trigger mandatory notification (Session 5).
- Consent expectations rise: you generally need clearer, more specific consent to process it.
Self-studyData subjects, controllers, and processors2 min read▶
Three roles you'll use in every session. Getting them right decides who owes which duty - critical in a B2B2C platform like Himalaya.
| Role | Meaning · Himalaya example |
|---|---|
| Data subject | The person the data is about. Himalaya's 8M end consumers, and named contacts at the 1,200 business clients. |
| Controller | Decides why and how data is processed. Often the business client - but Himalaya is a controller for its own platform data. |
| Processor | Processes on a controller's instructions. Himalaya is frequently a processor for its clients; the US analytics vendor is a processor for Himalaya. |
The controller/processor split matters because duties and liability follow the role. Part of your Session 3 mapping work is deciding, dataset by dataset, whether Himalaya is acting as controller or processor - because it's both, in different places.
Map Himalaya's data landscape and place your seat ★ 19 min · on Himalaya
Your first act as Himalaya's DPO. We don't fix anything yet - we get oriented. By the end you'll have a one-page data landscape, a first-pass sensitivity read, and a defensible answer to "where does the DPO sit?" Follow along on Himalaya; then repeat the exact steps on your own organisation for homework.
Himalaya - B2B2C SaaS, Singapore-headquartered. 1,200 business clients (the B), 8M end consumers (the C). Runs on AWS Redshift (40+ schemas) plus a CRM, a US-hosted marketing automation tool, and a support tool. Wellness-vertical clients collect health notes. Growth-first, governance-last: a near-miss export exposed consumer records for 6 days, and marketing blasts the 8M base with no DNC check. The board just made you its first DPO.
List the data stores. Write every place personal data could live: Redshift schemas, CRM, marketing tool, support tool, product modules. Don't verify yet - capture the landscape.
Tag the B-side vs C-side. Mark which stores hold business-client data (the B) and which hold end-consumer data (the C). The C-side is where your 8M data subjects live.
Flag the sensitive tier. Circle anything likely to hold health notes, NRIC/national IDs, financial account info, or credentials. For Himalaya, the wellness-client data and payment tokens get circled first.
Mark the cross-border hop. Draw the arrow from EU consumer data → Singapore warehouse → US marketing vendor. This one line is your Session 6 transfer problem; today, just make it visible.
Place the DPO seat. Decide your reporting line (to the CEO / board, per independence), and write one sentence on the conflict you must avoid (you cannot also own the marketing database). This is your position, on paper, day one.
Try it yourself - this week ◐ 30-45 min total
- Run the landscape prompt on your own organisation (or a team within it). Produce the one-page data landscape - you'll build directly on it in Session 3.
- Answer, in writing, the governance question for one real dataset you touch: who decides what happens to it, how is that enforced, and who is accountable? If any answer is "nobody / a shrug," you've found governance gap number one.
- Find out whether your organisation has appointed a DPO, and whether its business contact is public. Under PDPA, both are required.
- Locate your sensitive tier: name the one place the most damaging personal data lives. Bring it to Session 2.
- Optional, for the credential path: skim the IAPP CIPP/E and CIPM outlines to see how this course maps to them.
What this session covers
This session teaches the working content of the frameworks below. Certification exams, member-only frameworks, and legal advice 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 · A Singapore company has 4 employees and holds a little customer data. Does it need a DPO?
PDPA's DPO mandate has no size exemption. The "large-scale monitoring" test is GDPR's - a different rulebook.
2 · Where does Data Governance sit on the DAMA wheel?
Governance is the centre. It's the deciding function that steers the ten management capabilities around it.
3 · An "anonymised" table uses a consumer_id, and another table maps that id to an email. The table is...
Reversible with a key = pseudonymised = still personal data. Only truly irreversible anonymisation leaves scope.