Governance needs an owner and a rhythm
Every rule you have met so far quietly assumes someone is responsible for following it. That is the gap this session fills. Two things turn a good intention into working governance: a clear owner - the person accountable, usually called a Data Protection Officer - and a simple habit the organisation repeats so nothing goes stale. Get those two in place and governance stops being a project with an end date and becomes just how you run. This hour is about the who and the how-often.
What a DPO does 9 min live
A Data Protection Officer, or DPO, is simply the person accountable for data protection in an organisation. Not the person who does everything - the person who makes sure it gets done. Think of them as the hub of a wheel: policy, training, requests, the regulator, risk, and the data inventory all connect through them, even when other people do the day-to-day work.
LiveThe six things a DPO actually does3 min▶
Strip away the title and a DPO's job is six practical things:
- Set policy - decide how the organisation handles personal data, and write it down.
- Train staff - make sure everyone knows the basics, so governance is not one person's secret.
- Handle requests and complaints - when someone asks "what do you hold on me?" or complains, the DPO owns the response.
- Be the regulator's contact - the named person the PDPC or an EU authority calls.
- Advise on risk - flag when a new project or tool needs a closer look before it launches.
- Keep the data inventory - maintain the running list of what data the organisation holds, where, and why.
Notice the verb that repeats: make sure. A DPO advises and oversees - they do not personally own every dataset or do every task. Their job is to see that it happens.
LiveWho has to have a DPO?3 min▶
This is where Singapore and Europe differ in a way worth remembering:
- Singapore's PDPA: everyone. Every organisation must appoint at least one DPO and publish a way to contact them. The DPO can be an existing staff member - the office manager, the founder, whoever - it does not need to be a new hire. But the role must exist and be reachable.
- The EU's GDPR: some, not all. A DPO is mandatory only for certain organisations - public bodies, and those doing large-scale monitoring or handling sensitive data at scale. Many others appoint one anyway because it is good practice.
The plain takeaway: if you operate in Singapore, you need a named DPO today, full stop. If GDPR touches you, check whether you fall into the "must" group - and consider one regardless.
The founder who was already the DPO. A ten-person startup panicked that "appoint a DPO" meant hiring an expensive specialist. It did not. They named the operations lead - who already knew where every system lived - published her email on the website as the contact, and gave her a half-day a month for it. That satisfied the PDPA's requirement and, more importantly, gave the company one clear owner. Small teams do not need a big title; they need a real name.
Self-studyA DPO is a shield, not just a cost2 min read▶
It is tempting to see the DPO as a box to tick. In practice, having one clear owner is what stops governance falling through the cracks between departments. When a breach happens, when a customer asks for their data, when a new AI tool is being bought - there is a single person who knows the picture and can act. That is worth far more than the label. The best DPOs are not the most senior people; they are the ones who genuinely know where the data lives and are trusted to raise a hand when something looks off.
Controller vs processor, operationally 8 min live
Session 2 introduced these two roles; now let us make them about accountability - who answers for what. The controller is the organisation that decides why and how personal data is used, and it carries the most responsibility. The processor acts only on the controller's instructions, and its job is to protect the data and follow the contract. When something goes wrong, the first question a regulator asks is "who was the controller?"
LiveThe one question that tells them apart3 min▶
You do not need to memorise definitions. Ask one question: "Who decided why this data is being used, and how?"
- If you decided the purpose and the means, you are the controller - and you carry the most responsibility for getting it right.
- If you are only doing what another organisation told you to do with their data, you are the processor - your duties are to protect it and stick to the contract.
Most organisations are both, depending on the data. You are the controller of your own customer and staff records; you are a processor when you handle data on behalf of a client.
LiveWhy the split matters when things go wrong3 min▶
The controller-processor line is not academic - it decides who is on the hook. The controller answers to the regulator and to the people whose data it is. The processor answers to the controller, and must have a contract spelling out exactly what it may and may not do. If a processor goes off-script - reuses the data for its own marketing, say - it steps over the line and takes on liability it did not have before.
The shop and its payroll vendor. A retail shop collects its staff's bank details to pay salaries - the shop decided why (to pay people) and how, so the shop is the controller. It uses an outside payroll company to actually run the payments. That vendor is the processor: it only touches the data to do the job the shop hired it for, must keep it secure, and must not use those bank details for anything else. If the vendor sold the list, that would be its own serious breach - but the shop, as controller, still has to answer for choosing and overseeing it.
Governance is a habit, not a project 7 min live
Here is the idea that outlasts this whole course. Governance done once and filed away rots quietly - data moves, people leave, systems change. Governance that works is a small loop you repeat forever. Three words: Register, Review, Respond. Keep a register of what you hold, review it regularly, and respond to what comes up. Then round again.
LiveRegister, Review, Respond - what each one means3 min▶
The whole loop fits on one page:
- Register - keep a simple running list of what personal data you hold, where it lives, and why you have it. This is your map. Without it, every other move is guesswork.
- Review - look at the register on a regular rhythm (a quarter is a fine start) and ask two questions of each entry: do we still need this, and is it still safe? Delete what you do not need; fix what is not protected.
- Respond - when a person asks for their data, or a breach happens, or a new project appears, respond promptly - and feed what you learn back into the register.
That is it. A DPO owns the loop; the whole team feeds it. Do this and you will never be caught not knowing what you hold.
Find your DPO, start your register ★ 12 min · pen and paper
Two concrete artefacts that put this session to work. Neither takes long, and both are things a real DPO would want to exist.
Find the owner. Ask around: who is our DPO? If there is one, note their name and how they are published. If there is not, note who should be - the person who already knows where the data lives.
Start the register. On one page, list five kinds of personal data you hold. For each, write three things: where it lives, why you have it, and who can reach it.
Review it once. Go down your five and ask the two questions: still needed? still safe? Mark anything that fails either test.
Spot one response. Pick one entry and ask: if a customer asked us to delete this tomorrow, could we, and who would do it? That is your Respond muscle.
Three questions about the habit ★ 8 min · your next team chat
The loop only works if it is actually running. These three questions tell you honestly whether it is.
Register: "Do we have a single list of what personal data we hold?" If the honest answer is "it's in a few people's heads", that is your first task.
Review: "When did we last look at that list and clear out what we no longer need?" If nobody can remember, the rhythm has stopped.
Respond: "If someone asked for their data, or complained, who responds - and how fast?" A clear name here is a sign of a healthy habit.
Before Session 6 ◐ 20 min total
- Confirm your DPO in writing - the name, and where their contact is published. If there is not one, propose who it should be to whoever decides.
- Turn your five-line register into something the team can see - a shared doc, a pinned note - so it is not just yours.
- Put one recurring review in the calendar: a 30-minute "what data do we hold, still needed, still safe?" every quarter.
- Optional: for one dataset, sketch who is the controller and who is a processor. Notice where you are each.
- Who is our DPO - and does the rest of the team know their name?
- Where is the data we are the controller of, versus data we only process for others?
- Do we have a register at all, or is it in people's heads?
- When something needs a response, is it clear who owns it?
Where this fits on the shelf
This on-ramp distills the plain-English core of the deeper courses. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Under Singapore's PDPA, which organisations must appoint at least one DPO?
The PDPA requires every organisation to appoint at least one DPO and publish a contact. It can be existing staff - it does not need to be a new specialist hire.
2 · Your shop hires an outside payroll company to pay staff, using bank details you collected. Who is the controller?
The controller is whoever decides why and how the data is used. The shop decided; the payroll vendor only acts on instructions, so it is the processor. The controller carries the most responsibility.
3 · What is the "Register, Review, Respond" habit?
Governance is a habit, not a project. You keep a register of what you hold, review it regularly (still needed? still safe?), and respond to requests and incidents - then round again.