Data has a lifespan - govern all of it
Himalaya keeps everything forever. Ex-clients churned two years ago and their end-consumer records still sit in the warehouse. Meanwhile EU consumer data flows EU → Singapore warehouse → a US marketing vendor with no safeguards on file. Collecting data lawfully (Sessions 2 and 4) was only the start. Today we govern data across its whole life: keep it accurate, retain it only as long as needed, transfer it across borders with protection, and answer the individuals who exercise their rights.
Accuracy and retention 7 min live
Two obligations that pull in opposite directions and both get ignored. Accuracy says keep data correct while you hold it. Retention Limitation says stop holding it once you no longer need it. Between them sits the discipline most data teams skip entirely: a written retention schedule.
LiveAccuracy Obligation - correct enough for the decision2 min▶
The PDPA Accuracy Obligation requires you to make a reasonable effort to ensure personal data is accurate and complete - especially when it will be used to make a decision that affects the individual, or disclosed to another organisation. The bar scales with the stakes: a marketing nickname needs less rigour than an address used to send a legal notice.
- Accuracy is not "perfect data always." It's reasonable effort proportionate to how the data is used.
- The riskier the decision or the disclosure, the more effort you owe - verification, refresh cycles, source-of-truth discipline.
- This is where Session 7's data-quality capability plugs in: quality controls are how you operationalise Accuracy.
Himalaya's warehouse holds three different addresses for the same consumer across three modules, and marketing picks whichever it joins first. When a wellness client uses that address to route a health-related notice, the wrong one goes out. That's an Accuracy failure with real harm - and the fix is a source-of-truth rule, not more data.
LiveRetention Limitation - build a schedule3 min▶
The Retention Limitation obligation says: cease to retain personal data, or remove the means of associating it with an individual, as soon as it's no longer needed for any business or legal purpose. Not "when convenient." Not "when storage runs out." When the need ends.
The DPO artifact that turns this into practice is a retention schedule: for each data category, three things -
- Retention period - how long you keep it (e.g. "7 years after last transaction").
- Trigger - the event that starts the clock (contract end, last activity, account closure).
- Disposal method - how it's destroyed or de-identified when the period lapses.
Legal purposes can justify longer holds - tax records, statutory limitation periods. "We might want it someday for analytics" is not a legal purpose.
Himalaya has no schedule, so Raj's default is infinite. Ex-clients who churned two years ago still have full end-consumer records in Redshift - data Himalaya has no purpose to hold and no consent to keep. Your schedule sets "client offboarding + 90 days → purge or de-identify," and suddenly there's a trigger and a disposal step where there was only "keep everything."
Self-studyDisposal methods and the "keep everything" anti-pattern2 min read▶
Ceasing retention has to be real, not a hidden copy. Common defensible methods:
| Method | What it means · when to use |
|---|---|
| Secure deletion | Hard-delete from the store and its backups on their cycle. The default for data past its period. |
| De-identification / anonymisation | Strip and irreversibly break the link to the individual - then it leaves scope and can stay for analytics. |
| Aggregation | Keep only counts and rollups, not row-level personal data. Useful for long-run metrics. |
| Physical destruction | For media / paper - shred, wipe, or destroy the device. |
The "keep everything" anti-pattern is seductive to data teams: storage is cheap, and you never know what a model might want. But every extra row is extra breach surface, extra DSAR scope, and - past its purpose - a standing Retention breach. Himalaya's warehouse is the textbook case: ex-client consumer data with no purpose, no consent, and no clock. Governance says the cheapest data to protect is the data you no longer hold.
Cross-border transfer 7 min live
Personal data doesn't stop being protected when it crosses a border. Both rulebooks say the same thing in different words: if you send data overseas, the protection has to travel with it. Himalaya's EU → SG → US flow crosses two borders with nothing on file - the transfer problem you flagged on day one is now yours to fix.
LivePDPA Transfer Limitation - comparable protection2 min▶
The PDPA Transfer Limitation obligation says you may transfer personal data overseas only if the receiving party is bound to a standard of protection comparable to the PDPA. You don't get to assume the destination is safe - you have to make it so.
- The usual mechanism is contract - clauses that bind the overseas recipient to PDPA-comparable protection.
- Other routes: binding corporate rules for intra-group transfers, or the recipient being in a jurisdiction / certification already deemed comparable.
- The obligation follows the data even when a processor moves it on your behalf - you stay accountable.
Himalaya's SG → US hop to the marketing vendor has no clause on file. Under the Transfer Limitation, that's an unlawful transfer running daily. The fix isn't stopping the vendor - it's a data processing addendum that binds them to comparable protection, plus recording it so you can prove it.
LiveGDPR mirror - adequacy, SCCs, BCRs, derogations3 min▶
Because Himalaya's data starts with EU consumers, the GDPR transfer regime (Arts. 44-49) also applies to the EU → SG hop. GDPR is stricter and more codified, but the logic mirrors PDPA - protection must travel. The transfer tools, in rough order of preference:
- Adequacy decision (Art. 45) - the EU has ruled the destination country's protection adequate. Cleanest route where it exists.
- Standard Contractual Clauses (SCCs) (Art. 46) - EU-approved model contract clauses. The workhorse for transfers to non-adequate countries.
- Binding Corporate Rules (BCRs) (Art. 47) - approved intra-group rules for multinationals.
- Derogations (Art. 49) - narrow exceptions (explicit consent, contract necessity) - for occasional, not systematic, transfers.
Self-studyHimalaya's US vendor - what safeguard is needed2 min read▶
Walk the EU → SG → US flow hop by hop and name the safeguard each needs:
| Hop | Rulebook · safeguard to put in place |
|---|---|
| EU consumer → SG warehouse | GDPR (Arts. 44-49). Needs SCCs (or adequacy, if Singapore is deemed adequate for the flow) binding Himalaya SG to EU-level protection. |
| SG warehouse → US vendor | PDPA Transfer Limitation. Needs a contract binding the US vendor to PDPA-comparable protection. If EU data is included, GDPR SCCs apply to this onward hop too. |
The durable DPO artifact is a transfer register: one row per flow recording what data, from where, to whom, in which country, and under which safeguard. When a regulator or a client asks "how is our data protected overseas?", the register is your one-line answer instead of a scramble. We build Himalaya's first row in the build-along.
Individual rights: access, correction, portability 6 min live
Governance isn't only about the company's duties - individuals have rights, and answering them is a core DPO workflow. A person can ask what you hold on them, ask you to fix it, and (in some regimes) ask for a portable copy. Get the request-handling routine right and a DSAR is routine; get it wrong and it becomes a complaint.
LiveAccess & Correction Obligation2 min▶
The PDPA Access & Correction Obligation gives an individual two rights, and gives you two duties:
- Access - on request, provide the person the personal data you hold about them and information on how it has been used or disclosed in the year before the request. That "how it was used" part surprises people - it's not just a data dump.
- Correction - on request, correct an error or omission, and (unless it's clearly unnecessary) send the corrected data to other organisations you disclosed it to.
There are limited exceptions (e.g. where access would reveal another person's data), but the default posture is: answer it, within a reasonable time, at a reasonable fee if any.
A Himalaya end consumer emails "send me everything you have on me and fix my old address." Tom in Customer Success forwards it to you. The Access duty means you retrieve their record across all 40+ schemas and report who you shared it with in the past year - which is exactly why the transfer register and the data map from Session 3 make this answerable instead of terrifying.
LiveData Portability - enacted, not yet in force2 min▶
Honesty flag, teach this carefully. Singapore's PDPA Data Portability Obligation was enacted in the 2020 amendment - it is on the statute books - but it is not yet in force, pending the supporting regulations. So the correct thing to tell a Himalaya stakeholder today is: it's coming, prepare for it, but you cannot yet be compelled to comply with it in Singapore.
- When in force, it will let an individual ask you to transmit their data to another organisation in a commonly used machine-readable format.
- Contrast with GDPR Article 20, which is in force: EU data subjects already have a portability right today. So for Himalaya's EU consumers, portability is live under GDPR even while it's pending in Singapore.
- Practical DPO stance: build your data map so a portable export is feasible - you'll need it for GDPR now and PDPA soon.
Self-studyHandling a rights request end to end2 min read▶
Turn the workflow diagram into a written procedure your whole team can follow:
| Step | What you actually do |
|---|---|
| Receive | Log the request in one place, timestamp it, and start the response clock. Every intake channel (email, support tool, form) routes here. |
| Verify identity | Confirm the requester is the data subject (or an authorised agent) before disclosing anything - proportionate to the sensitivity. |
| Retrieve | Pull the personal data across all systems, plus the prior-year usage/disclosure log for an access request. This is where your data map earns its keep. |
| Respond | Provide access / make the correction / explain any refusal, within the required timeline, and record what you did. |
Watch the clock and the exceptions. A late or ignored request is a common route to a PDPC complaint - and "we couldn't find the data" is not a defence, it's an admission that your data map (Session 3) has a hole.
Build Himalaya's retention schedule and transfer register ★ 19 min · on Himalaya
Three concrete artifacts every DPO carries: a retention schedule, a transfer register, and a DSAR procedure. We draft the first rows for Himalaya together. Follow along; then repeat on your own organisation for homework.
Himalaya - keeps everything forever (ex-client consumer data still in Redshift), pushes EU consumer data EU → SG warehouse → US marketing vendor with no safeguards on file, and has no written procedure for when a consumer asks what data it holds. Today you give the lifecycle a clock, a gate, and a front door.
Pick data categories. List the handful that matter: end-consumer profile, purchase history, health notes (wellness clients), payment tokens, ex-client consumer data, marketing contact list. These are your retention-schedule rows.
Set period + trigger + disposal for each. For every category write the retention period, the trigger that starts the clock, and the disposal method. Example: ex-client consumer data → "client offboarding + 90 days" → secure deletion.
Build a transfer register row. For the EU → SG → US flow, record: data category, source, destination + country, and the safeguard on each hop (GDPR SCCs on EU → SG; PDPA-comparable contract on SG → US).
Draft a DSAR response procedure. Write the four steps - receive, verify identity, retrieve (data + prior-year usage log), respond within timeline - as a checklist Tom and Customer Success can actually run.
Flag portability honestly. Note on the procedure: portability is live for EU consumers (GDPR Art. 20) but pending in Singapore (PDPA, enacted 2020, not yet in force). Prepare the export path anyway.
Try it yourself - this week ◐ 30-45 min total
- Build a retention schedule for your own organisation's top 5 data categories - period, trigger, disposal method for each. Circle any category that's currently "kept forever."
- Draw your cross-border flows and start a transfer register: for each hop, name the destination country and the safeguard (or write "MISSING" - that's a finding).
- Write your DSAR procedure as a one-page checklist and pressure-test it: if an access request landed today, could you retrieve the data and the prior-year usage log?
- Check the live status of the PDPA Data Portability Obligation on pdpc.gov.sg before you next advise on it - it's designed to come into force, so confirm the date each time.
- Find one dataset your team keeps "just in case" and write the sentence that justifies it - business or legal purpose. If you can't, you've found a Retention gap.
What this session covers
This session teaches the working content of the obligations below. Certification exams and legal advice on specific matters stay with their official sources - this page makes you fluent in the body of knowledge, honestly flagged where a right is pending or depth lives elsewhere.
Three questions before you go 🎯 ◐ 90 seconds
1 · A Himalaya consumer asks Himalaya to send their data to a competitor platform. Under PDPA in Singapore today, must Himalaya comply?
PDPA's Data Portability Obligation is legislated but not yet in force, pending regulations. It's live under GDPR Art. 20 for EU consumers - but the question asked about PDPA in Singapore.
2 · Ex-clients churned two years ago; their end-consumer records still sit in the warehouse. What does Retention Limitation require?
Retention Limitation says cease to retain once data is no longer needed for any business or legal purpose. "Might be useful" is not a purpose.
3 · Himalaya sends personal data from its SG warehouse to a US vendor. What does the Transfer Limitation require?
Overseas transfer is allowed only if the recipient is bound to PDPA-comparable protection, usually via contract. Accountability travels with the data.