FIELDWORK · SIX WEEKS · SELF-PACED

Data Privacy Analyst — a six-week applied programme

Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute.

The platform hosts the spine — briefs, drills, sims, templates, progress — and structures the deep work. It does not host sixty hours of content. Plan roughly ten focused hours a week, most of it real work on your own organisation's data; Signify Fieldwork keeps the thread.

6 weeks~10h a week18 modules55 required steps22 drills

Progress0 of 55 required stepsSaving to this browser

Week 1 of 6 · 10 hours · 3 modules

What you hold, and what the law reaches

Privacy work starts with scope, not statute. Establish what personal data you actually hold, which regimes reach it and why, and build the inventory everything downstream depends on.

1.1

What privacy law actually regulates

3.5h

Personal data, controller and processor, and the reach of a regime that does not stop at a border.

learnRequired
Personal data is a relationship, not a column type
Read the brief~2 min
Almost every argument about privacy scope is really an argument about one question: is this personal data? Practitioners who get this wrong in either direction pay for it. Too narrow, and whole systems sit outside the programme until a regulator or a subject access request finds them. Too broad, and you spend your credibility protecting device logs nobody can tie to a person.
Personal data is a relationship, not a column type
The test is not whether a field looks like a name. It is whether a living individual can be singled out, directly or indirectly, by you or by anyone reasonably likely to try — using the means available to them, including other data they hold. That last clause is where the real work is: a row of coffee-machine badge taps is not personal data on its own, and is unambiguously personal the moment it can be joined to the badge register two tables away.
- Identifiability is contextual and it moves. A dataset that was anonymous last year may not be after a new join, a new acquisition or a new public dataset.
- Pseudonymised data is still personal data. Holding the key somewhere else is a security control, not an exit from scope.
- Truly anonymous data is out of scope entirely — which is why claims of anonymity deserve the hardest challenge in the room.
- Free-text fields are where personal data hides. A ticket description or a call note will contain more about a person than the structured schema ever declared.
Controller or processor, and why it decides everything
The party that decides why and how personal data is processed is the controller and carries the obligations. A processor acts on documented instructions. The label follows the reality of the decision-making, not the contract heading: a vendor that quietly uses your customer data to improve its own model has made itself a controller regardless of what the agreement says, and you have a problem in both directions.
Reach follows behaviour, not headquarters. Modern regimes apply where you offer goods or services to people in a territory or monitor their behaviour, so “we are not established there” settles nothing. Establish which regimes reach you before you design anything, because the answer determines which of the next five weeks' rules you are actually operating under.
Carry this into the drill
Take one system you own and find the field that is personal data only because of a join. That field is the argument you will have to win, so have the evidence ready before someone else finds it.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 1 of 6: What you hold, and what the law reaches — Privacy work starts with scope, not statute. Establish what personal data you actually hold, which regimes reach it and why, and build the inventory everything downstream depends on. - Module 1.1: What privacy law actually regulates - Today's topic: Personal data is a relationship, not a column type - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Personal data is a relationship, not a column type - Identifiability is contextual and it moves. A dataset that was anonymous last year may not be after a new join, a new acquisition or a new public dataset. - Pseudonymised data is still personal data. Holding the key somewhere else is a security control, not an exit from scope. - Truly anonymous data is out of scope entirely — which is why claims of anonymity deserve the hardest challenge in the room. - Free-text fields are where personal data hides. A ticket description or a call note will contain more about a person than the structured schema ever declared. - Controller or processor, and why it decides everything - The point I am meant to carry into practice: Take one system you own and find the field that is personal data only because of a join. That field is the argument you will have to win, so have the evidence ready before someone else finds it. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (personal-or-not): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Scoping memo for one system. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Personal, or Not? — a data-scope drill
Twelve things a system holds, one call each: personal, not personal, or personal only in context. It is the exact judgement the lesson describes, made twelve times fast enough that your instinct shows — and the ‘only in context’ answers are where most practitioners find out their instinct is generous.
Open the drill
Ticks itself when the drill records a result
applyRequired
Scoping memo for one system
Open the brief
Pick one real system you can see: a CRM, a support desk, a logging platform, an HR tool. Not the whole estate — one system, examined properly. Write the scoping memo you would send to someone who has to decide whether it is in the privacy programme.
The memo's value is in its edges. Anyone can list the obvious identifiers; you are being judged on the fields you had to think about, and on whether you said plainly which way you called them and why.
What to produce
- What the system is for, who uses it, and roughly how many people are described in it
- Clearly personal: the fields nobody would argue about
- Personal in context: the field, the join that makes it identifying, and who could reasonably make that join
- Not personal: what you excluded and the reason — including any anonymity claim and what it rests on
- Free-text and attachment fields, and what you actually found when you looked at a sample
- Your call: in scope, out of scope, or in scope for part of the data, with the one thing that would change your answer
Template · scope-memo
checkOptional
Where your own scoping is quietly convenient
Open the prompts
1. Which field did you most want to call out of scope, and would that call survive a regulator asking you to justify it in writing?
2. Who in your organisation currently believes this system holds no personal data, and what would you show them first?
3. If someone acquired your organisation tomorrow and joined their customer table to yours, which of your ‘not personal’ calls would flip?

1.2

The regulatory map without the panic

How GDPR, the US state patchwork and PDPL differ in threshold and remedy but rhyme in structure.

learnRequired
Same skeleton, different thresholds
Read the brief~2 min
Practitioners new to privacy tend to meet the regimes as a list of frightening acronyms and try to memorise the differences. That is the wrong shape for the work. The regimes differ far less in structure than they do in threshold, remedy and vocabulary, and once you can see the skeleton, a new law becomes a set of parameter changes rather than a new syllabus.
The skeleton every regime shares
- A scope test — what counts as personal data, and who is caught.
- A legitimacy requirement — you need a reason to process, whatever the local name for it.
- Transparency — you must tell people, before or at collection.
- Individual rights — access, correction, deletion, and some form of objection or opt-out.
- Accountability — records, assessments, and the ability to demonstrate all of the above.
- Onward transfer control — constraints when data goes to a processor or across a border.
- Enforcement — a supervisory authority, a penalty regime, and increasingly a private right of action.
Where they actually diverge
GDPR requires a lawful basis chosen in advance from a closed list, and treats consent as one option among six rather than the default. US state laws generally permit processing subject to disclosure and an opt-out, with heightened rules for sensitive categories and for what they call sale or sharing. PDPL and its regional peers sit closer to the GDPR shape but carry their own registration, localisation and transfer mechanics. Treat GDPR as the structural spine: build to it and the others become deltas rather than rebuilds.
One warning about the deltas. ‘Sale’ in US privacy law does not mean what a finance team means by sale, and many organisations discover they are selling data by operating an ordinary advertising pixel. Read the definitions before you conclude a rule does not apply to you.
Open the reading — Privacy360™
Carry this into the drill
Name the regimes that reach your organisation and the reason each one does. That register is the first page of everything you build for the next five weeks.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 1 of 6: What you hold, and what the law reaches — Privacy work starts with scope, not statute. Establish what personal data you actually hold, which regimes reach it and why, and build the inventory everything downstream depends on. - Module 1.2: The regulatory map without the panic - Today's topic: Same skeleton, different thresholds - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The skeleton every regime shares - A scope test — what counts as personal data, and who is caught. - A legitimacy requirement — you need a reason to process, whatever the local name for it. - Transparency — you must tell people, before or at collection. - Individual rights — access, correction, deletion, and some form of objection or opt-out. - Accountability — records, assessments, and the ability to demonstrate all of the above. - The point I am meant to carry into practice: Name the regimes that reach your organisation and the reason each one does. That register is the first page of everything you build for the next five weeks. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (term-match): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Applicable-law register with the reason each applies. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Term Match — a terminology memory game
Privacy runs on vocabulary, and the vocabulary is shared across GRC, audit and security. Pairing terms with their definitions is a five-minute check on whether you can hold a conversation with the people whose systems you are about to assess.
Open the drill
Ticks itself when the drill records a result
applyRequired
Applicable-law register with the reason each applies
Open the brief
Build the applicable-law register for your organisation. Not a summary of each law — there are better sources for that — but a register of which regimes reach you, why, and what that means for the work.
The discipline here is the reason column. ‘Because we are global’ is not a reason. ‘Because we offer services to customers in these territories and monitor behaviour through this product’ is.
What to produce
- One row per regime you conclude applies, with the trigger that brings you into scope and the evidence for it
- The regimes you considered and ruled out, with the reason — this column matters more than it looks
- For each applicable regime: the supervisory authority, the rights it grants, and the notification clock it imposes
- The two or three deltas from your GDPR baseline that would actually change an operational process
- Owner and review date — a register nobody owns is out of date within a quarter
Template · law-register

1.3

The inventory and the RoPA that stays true

3.5h

Data mapping that survives contact with reality, and why most records of processing rot within a quarter.

learnRequired
An inventory is a maintained system, not a document
Read the brief~2 min
The record of processing is the single most useful artefact in a privacy programme and the one most likely to be quietly worthless. Most were built once, by a consultant, from a questionnaire, and describe an organisation that no longer exists. The failure is not laziness; it is that the record was designed as a document rather than as a maintained system.
What a record has to answer
- What personal data, about whom, and in what volume.
- Why — the purpose, stated specifically enough to test.
- On what basis, and where that decision is recorded.
- Who touches it: teams, processors, sub-processors.
- Where it goes, including every border it crosses.
- How long it is kept, and by what mechanism it leaves.
Why they rot, and the two habits that stop it
They rot because nothing in the organisation's ordinary operating rhythm updates them. New systems arrive through procurement, new purposes arrive through product, new processors arrive through a team's credit card, and none of those paths passes the record. The fix is not a better spreadsheet.
- Attach the record to an existing gate. Procurement approval, change management or the architecture review already stops things; adding a privacy field there costs far less than a quarterly re-survey and actually catches new processing.
- Record at the level of the processing activity, not the application. Applications get replaced; ‘we screen candidates’ survives three generations of tooling.
Expect the first honest inventory to be uncomfortable. If it does not surface at least one processing activity nobody could name an owner for, it is not finished.
Carry this into the drill
Find the gate your organisation already has — procurement, change control, architecture review — and design your record to be updated there. That single decision is what separates a living inventory from an annual fiction.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 1 of 6: What you hold, and what the law reaches — Privacy work starts with scope, not statute. Establish what personal data you actually hold, which regimes reach it and why, and build the inventory everything downstream depends on. - Module 1.3: The inventory and the RoPA that stays true - Today's topic: An inventory is a maintained system, not a document - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - What a record has to answer - What personal data, about whom, and in what volume. - Why — the purpose, stated specifically enough to test. - On what basis, and where that decision is recorded. - Who touches it: teams, processors, sub-processors. - Where it goes, including every border it crosses. - The point I am meant to carry into practice: Find the gate your organisation already has — procurement, change control, architecture review — and design your record to be updated there. That single decision is what separates a living inventory from an annual fiction. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (grc-maturity): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: RoPA for one end-to-end process. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
GRC Maturity Assessment
Before you build the inventory, get an honest read on the programme it will live in. The maturity assessment scores how the governance around you actually operates, which tells you whether your record will be maintained by a process or by you personally.
Open the drill
Ticks itself when the drill records a result
applyRequired
RoPA for one end-to-end process
Open the brief
Produce a record of processing for one end-to-end process you can actually trace — recruitment, customer onboarding, support ticketing, payroll. End to end means from the moment data arrives to the moment it is deleted, including the copies you would rather not think about.
Follow the data, not the org chart. The exports into a spreadsheet, the analytics copy, the vendor's backup and the shared drive folder are the parts a questionnaire never captures, and they are usually where the risk is.
What to produce
- The processing activity in one sentence, stated as a purpose rather than a system name
- Categories of data and of people, with rough volumes
- Every system and every copy in the flow, including exports, analytics and backups
- Processors and sub-processors, with what each one is instructed to do
- Transfers out of the jurisdiction, with the mechanism relied on
- Retention and the actual deletion mechanism — name it, or record that there is not one
- Lawful basis, and where that decision is written down
- The gate at which this record will be updated when the process changes
Template · ropa
checkRequired
Where your inventory is fiction
Open the prompts
1. Which copy of the data did you find that is not in any existing system inventory, and how did you find it?
2. For how many rows of your record could you produce evidence today, rather than a belief?
3. What is the deletion mechanism for this process — and if the honest answer is that there is none, who needs to hear that first?
4. Which part of this record will be wrong in six months, and what would have to change for it not to be?

Week 2 of 6 · 10 hours · 3 modules

Basis, notice and restraint

Every processing activity needs a reason you could defend, a description people can actually use, and a limit you actually enforce.

2.1

Choosing a lawful basis you can defend

3.5h

Consent against legitimate interest, and the assessment that is a decision record rather than a form.

learnRequired
The basis you pick constrains what you may do next
Read the brief~2 min
The lawful basis is chosen once and constrains everything afterwards, which is why it deserves more than the ten seconds it usually gets. Pick consent and you inherit a withdrawal mechanism, a record of what each person agreed to, and a hard stop the moment they change their mind. Pick legitimate interests and you inherit an assessment you must be able to produce and an objection right you must be able to honour.
The two mistakes that cost the most
- Reaching for consent by default. Consent looks respectful and is operationally brutal: it must be freely given, which it rarely is where there is a power imbalance, and it collapses the moment the person says stop — including for processing you actually needed to continue.
- Treating legitimate interests as the residual bin. It is a real basis with a real test, and an assessment written after the decision reads exactly like what it is.
The assessment is a decision record
A legitimate interests assessment has three parts, and each one is a question you could genuinely answer no to. What is the interest, stated as a business outcome rather than a platitude. Is the processing necessary for it, or would a less intrusive route work. And does the person's reasonable expectation, and the effect on them, override the interest. The third part is where honest assessments fail, and failing it on paper is far cheaper than failing it in front of a regulator.
Two further constraints worth holding. Special category data needs a second condition on top of the basis, not instead of it. And you cannot swap basis later because the first one became inconvenient — if consent is withdrawn, discovering a legitimate interest that was there all along is not a defence anyone accepts.
Carry this into the drill
Before the drill, name one processing activity in your organisation that runs on consent and probably should not, or on legitimate interests with no assessment behind it. That is the one you will write up.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 2 of 6: Basis, notice and restraint — Every processing activity needs a reason you could defend, a description people can actually use, and a limit you actually enforce. - Module 2.1: Choosing a lawful basis you can defend - Today's topic: The basis you pick constrains what you may do next - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The two mistakes that cost the most - Reaching for consent by default. Consent looks respectful and is operationally brutal: it must be freely given, which it rarely is where there is a power imbalance, and it collapses the moment the person says stop — including for processing you actually needed to continue. - Treating legitimate interests as the residual bin. It is a real basis with a real test, and an assessment written after the decision reads exactly like what it is. - The assessment is a decision record - The point I am meant to carry into practice: Before the drill, name one processing activity in your organisation that runs on consent and probably should not, or on legitimate interests with no assessment behind it. That is the one you will write up. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (calibrate-risk): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Legitimate-interest assessment for one activity. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Which Is Riskier? — a calibration drill
Choosing a basis is a calibration problem: you are weighing a business interest against an effect on a person, and most people are systematically miscalibrated about which risks are larger. This drill exposes where your instinct is sound and where a scary word is doing the work your reasoning should be.
Open the drill
Ticks itself when the drill records a result
applyRequired
Legitimate-interest assessment for one activity
Open the brief
Write a legitimate interests assessment for one real processing activity — ideally the one you named in the brief. Marketing to existing customers, fraud screening, workplace monitoring and product analytics are all good candidates because all four are genuinely arguable.
Write it as though the person it describes will read it, because in a dispute they may. If you reach a point where the honest answer is that the interest does not override, record that and say what you would change instead. An assessment that always says yes is not an assessment.
What to produce
- Purpose test: the interest, stated as a business outcome, and who benefits — you, the person, or a third party
- Necessity test: why this processing achieves it, and the less intrusive alternative you considered and rejected
- Balancing test: what the person would reasonably expect, the effect on them, and any vulnerability in the group
- The safeguards that changed your conclusion — minimisation, retention limits, opt-out, aggregation
- Your conclusion, the date, and who decided
- How objection is honoured in practice, naming the system that would have to act
Template · lia

2.2

Transparency people can use

Notices as an interface rather than a disclaimer, and the trade between readable and complete.

learnRequired
A notice is tested by what a reader can predict
Read the brief~2 min
A privacy notice has two jobs and they pull against each other. It has to be complete enough to satisfy a regulator reading it as a compliance artefact, and clear enough that an ordinary person can predict what happens to their data. Most organisations resolve the tension by optimising entirely for the first reader, which produces a document that is legally defensible and practically useless.
The test that matters
After reading your notice, could a reasonable person correctly predict what you will do with their data, who else will see it, and how long you will keep it? That is the standard, and it is testable: hand the notice to someone outside the programme, ask them those three questions, and count how many they get right. It is a humbling exercise the first time.
- Layer it. A short top layer that answers the three questions, with depth behind links, beats one long document nobody finishes.
- Say what you do, not what you may do. ‘We may share your data with partners’ tells the reader nothing and quietly authorises everything — name the categories and the purpose.
- Give real retention periods. ‘As long as necessary’ is the single most common line in privacy notices and conveys no information at all.
- Put the rights where they can be exercised. A rights section with no route to a request is a description of a service you do not offer.
- Notice at the moment of collection beats notice in a footer. Just-in-time explanations at the field that surprises people do more work than any policy page.
One structural point. The notice must match the record of processing you built last week. Where they disagree, one of them is a misstatement to your customers, and the notice is usually the one that has drifted.
Carry this into the drill
Pick the one paragraph of your notice you would least like a journalist to quote. That is the paragraph you rewrite — vagueness there is not an accident.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 2 of 6: Basis, notice and restraint — Every processing activity needs a reason you could defend, a description people can actually use, and a limit you actually enforce. - Module 2.2: Transparency people can use - Today's topic: A notice is tested by what a reader can predict - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The test that matters - Layer it. A short top layer that answers the three questions, with depth behind links, beats one long document nobody finishes. - Say what you do, not what you may do. ‘We may share your data with partners’ tells the reader nothing and quietly authorises everything — name the categories and the purpose. - Give real retention periods. ‘As long as necessary’ is the single most common line in privacy notices and conveys no information at all. - Put the rights where they can be exercised. A rights section with no route to a request is a description of a service you do not offer. - Notice at the moment of collection beats notice in a footer. Just-in-time explanations at the field that surprises people do more work than any policy page. - The point I am meant to carry into practice: Pick the one paragraph of your notice you would least like a journalist to quote. That is the paragraph you rewrite — vagueness there is not an accident. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (control-statement-clinic): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: One notice section rewritten, with the rationale. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
The Control Statement Clinic — make it testable
A privacy notice claim and a control statement fail the same way: both sound reassuring and neither can be tested. This clinic trains the ear for the difference between a statement that commits to something checkable and one that merely gestures — which is exactly the edit your notice needs.
Open the drill
Ticks itself when the drill records a result
applyRequired
One notice section rewritten, with the rationale
Open the brief
Take one section of a real privacy notice — your own organisation's, ideally — and rewrite it so a reader could predict what actually happens. Sharing, retention and profiling are the sections where rewriting pays best.
Keep the original beside your version. The rationale is the deliverable as much as the rewrite: you are building the argument you will need when legal asks why the vaguer wording was safer.
What to produce
- The original text, quoted exactly
- Your rewrite, with real categories, real recipients and real periods
- A line-by-line rationale: what each change makes predictable that was not before
- The three-question test run on a colleague outside privacy, with what they answered
- Anything you could not make specific, and what you would need to find out to fix it
- Where this section now disagrees with your record of processing — and which of the two is wrong
Template · notice-rewrite

2.3

Purpose limitation, minimisation, retention

3.5h

Where privacy programmes actually fail: data kept because deleting it was never anybody's job.

learnRequired
Retention is the promise you are least likely to keep
Read the brief~2 min
Collection is exciting, deletion is nobody's project. That asymmetry is why retention is the commitment privacy programmes are least likely to keep, and why a breach involving data you should have deleted years ago is such a familiar story. Every extra year of retained data is extra breach surface, extra subject-access effort and extra discovery risk, bought for no operational benefit.
Three linked disciplines
- Purpose limitation: data collected for one purpose is not automatically available for another. The test for a new purpose is compatibility with the original, judged from the person's expectation — not from how useful the new idea is.
- Minimisation: collect what the purpose needs, not what the form builder made easy. The date-of-birth field nobody uses is a liability with no offsetting benefit.
- Storage limitation: keep it while the purpose lives, then remove it. Which requires knowing when the purpose dies — a question most schedules never actually answer.
Why schedules fail in practice
A retention schedule fails for one of three reasons, and it is worth knowing which one you have. The period is undefined, so nothing can act on it. The period is defined but no system can enforce it, so it describes an intention. Or the period exists and is enforced in the primary system while backups, exports, analytics warehouses and the shared drive keep their copies indefinitely. The third is the most common and the least visible.
Legal hold is the legitimate exception and also the usual excuse. A hold should be specific, recorded and released; a standing hold over everything is a decision not to have retention at all, and should be written down as such so somebody senior owns it.
Carry this into the drill
For your chosen system, establish whether deletion is actually possible — not planned, possible. The answer determines whether your schedule is a control or a wish.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 2 of 6: Basis, notice and restraint — Every processing activity needs a reason you could defend, a description people can actually use, and a limit you actually enforce. - Module 2.3: Purpose limitation, minimisation, retention - Today's topic: Retention is the promise you are least likely to keep - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Three linked disciplines - Purpose limitation: data collected for one purpose is not automatically available for another. The test for a new purpose is compatibility with the original, judged from the person's expectation — not from how useful the new idea is. - Minimisation: collect what the purpose needs, not what the form builder made easy. The date-of-birth field nobody uses is a liability with no offsetting benefit. - Storage limitation: keep it while the purpose lives, then remove it. Which requires knowing when the purpose dies — a question most schedules never actually answer. - Why schedules fail in practice - The point I am meant to carry into practice: For your chosen system, establish whether deletion is actually possible — not planned, possible. The answer determines whether your schedule is a control or a wish. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (keep-or-kill): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Retention schedule with the deletion mechanism named. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Keep or Kill — a retention and deletion drill
Fifteen things an organisation is still holding, and one call each: delete, keep, hold, or strip the identifiers and keep the rest. It is this module's argument made fifteen times — and the score that matters is your over-retention rate, because keeping is the error nobody ever gets blamed for until the day of an incident.
Open the drill
Ticks itself when the drill records a result
applyRequired
Retention schedule with the deletion mechanism named
Open the brief
Build a retention schedule for one system — the same one from week 1, ideally, so the artefacts compound. For each category of data, give the period, the trigger that starts the clock, and the mechanism that actually removes it.
The mechanism column is the whole point. ‘Deleted after seven years’ with no named job, script or process behind it is the kind of line that reads well until the day someone checks.
What to produce
- One row per data category, with the retention period and the legal or business reason for that period
- The trigger event that starts the clock, stated precisely enough to compute
- The deletion mechanism: the job, script, process or manual step — or an honest ‘none exists’
- Every secondary copy: backups, exports, analytics, third parties, and what happens to each
- Legal holds in force, their scope and their release condition
- The three rows you would fix first, and what fixing them requires
Template · retention
checkOptional
What you could not delete today if asked
Open the prompts
1. Which category of data could you not delete today even if a valid erasure request arrived, and why not?
2. Where does your primary system honour the schedule while a copy quietly does not?
3. If your organisation has a standing legal hold, who owns the decision to keep it — and do they know they own it?

Week 3 of 6 · 10 hours · 3 modules

Rights, and the machine that answers them

A right is only real if an ordinary week can deliver it. Build the operational machine, then repair it against real findings under two regimes.

3.1

The subject access request, end to end

3.5h

Identity verification, scope, exemptions and the clock — the request that exposes every weakness in your inventory.

learnRequired
The DSAR is an audit of your data map, sent by a stranger
Read the brief~2 min
A subject access request is an audit of your data map, submitted by a stranger, on a clock you do not control. Everything you assumed about where personal data lives gets tested at once, and the organisations that struggle are almost never struggling with the law. They are struggling because nobody can say with confidence where the data is.
The four stages, and where each one goes wrong
- Intake and verification. You must be satisfied who is asking, without turning verification into an obstacle course — and without collecting a passport scan you then have to protect. Verify proportionately to the sensitivity of what you hold.
- Scope. The request covers personal data about them, not every document that mentions them, and not the underlying business records they would like to see. Clarifying scope with the requester early is legitimate and usually welcomed.
- Search and retrieval. This is where the clock is lost. Every system in your record of processing, plus the systems that were never in it — mailboxes, ticket notes, chat, the analyst's spreadsheet.
- Review and release. Third-party data, legal privilege and genuinely exempt material get removed; everything else goes, with an explanation of what you did and why.
Two practical realities
First, the deadline is short and the extension is not automatic — it is a decision you must justify and communicate. Second, the requests that hurt are rarely from curious customers. They arrive from disgruntled former employees, from people in active litigation, and increasingly at volume from activists and automated services. Design for the hostile request and the friendly one costs you nothing.
The strategic point: every hour you invest in your inventory and retention schedule pays out here. Less data in fewer known places is the only thing that makes rights operationally cheap.
Carry this into the drill
Time a dry run. Pick a name, and find out how long it actually takes you to locate every place their data sits. That number is your real capability, regardless of what the runbook says.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 3 of 6: Rights, and the machine that answers them — A right is only real if an ordinary week can deliver it. Build the operational machine, then repair it against real findings under two regimes. - Module 3.1: The subject access request, end to end - Today's topic: The DSAR is an audit of your data map, sent by a stranger - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The four stages, and where each one goes wrong - Intake and verification. You must be satisfied who is asking, without turning verification into an obstacle course — and without collecting a passport scan you then have to protect. Verify proportionately to the sensitivity of what you hold. - Scope. The request covers personal data about them, not every document that mentions them, and not the underlying business records they would like to see. Clarifying scope with the requester early is legitimate and usually welcomed. - Search and retrieval. This is where the clock is lost. Every system in your record of processing, plus the systems that were never in it — mailboxes, ticket notes, chat, the analyst's spreadsheet. - Review and release. Third-party data, legal privilege and genuinely exempt material get removed; everything else goes, with an explanation of what you did and why. - Two practical realities - The point I am meant to carry into practice: Time a dry run. Pick a name, and find out how long it actually takes you to locate every place their data sits. That number is your real capability, regardless of what the runbook says. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (request-clock): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: DSAR runbook naming your systems and owners. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
The Request Clock — a subject-access scoping drill
One request and fifteen things the search returned: an opinion thread about her, the team’s absence sheet, privileged advice, a manager’s notebook, CCTV with eleven other faces. Disclose, redact, withhold or rule out of scope — and watch your over-disclosure rate, because releasing a third party’s data is a breach you commit while satisfying somebody else’s rights.
Open the drill
Ticks itself when the drill records a result
applyRequired
DSAR runbook naming your systems and owners
Open the brief
Write the subject access runbook for your own organisation — the document a colleague could follow while you are on leave. Generic templates are freely available and none of them names your systems, which is precisely the part that matters.
Include the timings you measured rather than the ones you hope for. A runbook that claims a two-day search when it takes nine will fail on the request that matters.
What to produce
- Intake: every channel a request can legitimately arrive on, including the ones you do not control, and who monitors each
- Verification: what you accept as proof, tiered by sensitivity, and what you refuse to collect
- The system-by-system search list, naming the system, the owner, the query and the realistic turnaround
- Scope decisions and exemptions you commonly rely on, with who approves each
- Redaction of third-party data: the rule, and a worked example from your own records
- The response pack: format, what you explain, and how it is delivered securely
- The clock: start point, internal milestones, and the extension decision — who makes it and on what grounds
Template · dsar-runbook

3.2

Remediating findings — GDPR

3.5h

Turning a list of gaps into a plan with severity, sequence and an owner per line.

learnRequired
Severity is about the person, not the paperwork
Read the brief~2 min
Assessments produce findings; programmes are judged on what happens next. The gap between a gap analysis and a remediation plan is where most privacy work quietly dies — a list of thirty findings with no sequence, no owners and no capacity behind it is a document that makes everyone feel assessed and changes nothing.
Severity is about the person
The instinct is to rate findings by how likely they are to attract a fine. Rate them instead by the risk to the individuals concerned: how many people, how sensitive the data, how severe the consequence if it goes wrong, and how hard it would be for them to recover. That ordering is defensible to a regulator, it is the ordering the law itself uses, and it usually produces a different top five than the fear-based one.
- Separate the finding from the fix. One finding may have a tactical containment this month and a structural fix next year; conflating them means the structural fix never gets funded.
- Sequence by dependency, not just severity. A retention fix that depends on a classification project cannot start first, however urgent it is.
- One named owner per line, and it is a person, not a department.
- Date every line, and be honest — a plan full of dates nobody believes trains the organisation to ignore your dates.
The residual position
Some findings will not be fixed this year, and saying so explicitly is stronger than letting them rot at the bottom of a list. Record the residual risk, who accepted it and for how long. Accepted risk that is written down and owned is governance; the same risk unrecorded is just an unpleasant surprise waiting for an incident.
Carry this into the drill
Rank your own findings by risk to people before you look at them again by fine exposure. Where the two orders disagree is where your programme's priorities are currently wrong.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 3 of 6: Rights, and the machine that answers them — A right is only real if an ordinary week can deliver it. Build the operational machine, then repair it against real findings under two regimes. - Module 3.2: Remediating findings — GDPR - Today's topic: Severity is about the person, not the paperwork - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Severity is about the person - Separate the finding from the fix. One finding may have a tactical containment this month and a structural fix next year; conflating them means the structural fix never gets funded. - Sequence by dependency, not just severity. A retention fix that depends on a classification project cannot start first, however urgent it is. - One named owner per line, and it is a person, not a department. - Date every line, and be honest — a plan full of dates nobody believes trains the organisation to ignore your dates. - The residual position - The point I am meant to carry into practice: Rank your own findings by risk to people before you look at them again by fine exposure. Where the two orders disagree is where your programme's priorities are currently wrong. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (gdpr-remediation): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Remediation plan for your top eight gaps. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Remediation Board: GDPR
Eight live GDPR findings, a fintech remediation board, and a budget that does not cover everything. It is the exact exercise in the lesson — severity, sequence, owners, residual — with consequences you can see, across three difficulty levels.
Open the drill
Ticks itself when the drill records a result
applyRequired
Remediation plan for your top eight gaps
Open the brief
Take your own top eight gaps — from the drill, from the inventory work, from an existing assessment — and build the remediation plan you would actually take to a steering group.
Write it so someone can be held to it. That means owners with names, dates you would defend, and an explicit line for the risks you are choosing not to fix yet.
What to produce
- One row per finding: what is wrong, and which requirement it fails
- Risk to individuals: how many, how sensitive, how severe, how recoverable — and the severity rating that follows
- Containment now versus structural fix later, separated
- Named owner, target date, and the dependency that could move it
- Effort and cost, even if rough — a plan with no cost has not been tested against reality
- Accepted residual risk: what, why, who accepted it and until when
- The one finding you would escalate this week if you could only escalate one
Template · remediation-plan

3.3

The same findings, US law

Where CCPA and CPRA diverge: sale and share, opt-out, sensitive personal information.

learnRequired
Opt-out regimes move the work, not the obligation
Read the brief~2 min
Run the same eight findings through US state privacy law and something useful happens: you see which of your privacy obligations are structural and which are local. Most of the work does not change. What changes is the mechanism, the vocabulary and, occasionally, the whole shape of a requirement.
What actually diverges
- Legitimacy. GDPR requires a basis chosen in advance; the US model generally permits processing that you have disclosed, with an opt-out. The work moves from justification to disclosure and honouring choice.
- Sale and sharing. Defined far more broadly than commercial instinct suggests — an advertising pixel or an audience match can qualify. This is the single most common place organisations discover they are non-compliant.
- Sensitive personal information. Not a prohibition with conditions, as under GDPR, but generally a right to limit its use — a different operational build entirely.
- Universal opt-out signals. A browser-level preference you must honour is an engineering requirement with no GDPR analogue.
- Enforcement. State attorneys general, cure periods that vary and are being withdrawn, and in some states a private right of action for breaches.
The trap
The trap is assuming GDPR compliance subsumes the US requirements because GDPR is ‘stricter’. It does not. A GDPR-compliant organisation can be squarely non-compliant on sale and share disclosures, on opt-out signal handling and on the notice-at-collection requirements, because those obligations have no European equivalent to inherit. Strictness is not a partial order.
The practical output of comparison work is a build decision: which controls you build once globally, and which you build per jurisdiction. Getting that split right early saves more money than any other decision in a multinational privacy programme.
Carry this into the drill
For each of your eight findings, decide whether the fix is global or jurisdictional. That column is the one your engineering team actually needs from you.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 3 of 6: Rights, and the machine that answers them — A right is only real if an ordinary week can deliver it. Build the operational machine, then repair it against real findings under two regimes. - Module 3.3: The same findings, US law - Today's topic: Opt-out regimes move the work, not the obligation - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - What actually diverges - Legitimacy. GDPR requires a basis chosen in advance; the US model generally permits processing that you have disclosed, with an opt-out. The work moves from justification to disclosure and honouring choice. - Sale and sharing. Defined far more broadly than commercial instinct suggests — an advertising pixel or an audience match can qualify. This is the single most common place organisations discover they are non-compliant. - Sensitive personal information. Not a prohibition with conditions, as under GDPR, but generally a right to limit its use — a different operational build entirely. - Universal opt-out signals. A browser-level preference you must honour is an engineering requirement with no GDPR analogue. - Enforcement. State attorneys general, cure periods that vary and are being withdrawn, and in some states a private right of action for breaches. - The point I am meant to carry into practice: For each of your eight findings, decide whether the fix is global or jurisdictional. That column is the one your engineering team actually needs from you. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (us-privacy-remediation): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: The same eight gaps, side by side under both regimes. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Remediation Board: US Privacy
The same remediation board, now under CCPA and CPRA. Running the two back to back is the point: you feel which findings translate unchanged, which need a different mechanism, and which only exist on one side of the Atlantic.
Open the drill
Ticks itself when the drill records a result
applyRequired
The same eight gaps, side by side under both regimes
Open the brief
Put your eight findings side by side under both regimes. One row per finding, one column per regime, and a verdict column that says whether the fix is the same, adapted or entirely different.
This artefact earns its keep in the room where someone asks why the US build costs extra. Make it answer that question without you present.
What to produce
- The finding, stated once and neutrally — not in either regime's vocabulary
- The GDPR requirement it fails, and the fix
- The US requirement it fails, and the fix — including any obligation with no GDPR equivalent
- Verdict: same fix, adapted fix, or separate build
- Where PDPL or another regime you registered in week 1 would add a third variant
- Your recommendation on the global-versus-local split, with the reasoning a budget holder needs
Template · jurisdiction-compare
checkRequired
What genuinely changed, and what only looked like it did
Open the prompts
1. Which obligation did you find that exists only outside the GDPR world, and would your current programme have caught it?
2. Where did you assume GDPR compliance was sufficient, and what changed your mind?
3. Which fix did you first plan per-jurisdiction and then realise should be built once, globally?
4. If your organisation runs advertising technology, do you know whether you sell or share data under US definitions — and who would you ask to find out?

Week 4 of 6 · 10 hours · 3 modules

Vendors, transfers and deals

Most personal data leaves the building. Govern the chain it travels along, the borders it crosses and the transactions that move it wholesale.

4.1

Processors and the accountability chain

3.5h

Data processing agreements, sub-processors, and diligence worth the hour it costs.

learnRequired
You cannot outsource accountability, only the processing
Read the brief~2 min
Most personal data an organisation is responsible for is sitting on somebody else's infrastructure. The payroll bureau, the support platform, the analytics suite, the model provider, and the four sub-processors behind each of them. You can outsource the processing; you cannot outsource the accountability, and the regulator's first question after an incident at a vendor is what diligence you did before you signed.
What the agreement has to carry
- Processing only on your documented instructions, with the subject matter, duration, nature and purpose actually specified rather than left to a schedule nobody filled in.
- Confidentiality obligations on their staff, and security measures described concretely enough to check.
- Sub-processor terms: authorisation, notice of changes, and the flow-down of the same obligations. This is the clause most often watered down and least often read.
- Assistance with rights requests, breach notification and assessments — with a timeframe. ‘Without undue delay’ from a vendor means whatever they decide it means unless you fix a number.
- Deletion or return at the end, and audit rights you would realistically exercise.
Diligence proportionate to the risk
Tier your vendors or you will spend the same effort on the payroll provider and the meeting-room booking tool. Tier on what they actually hold: volume, sensitivity, whether they can reach production data, and how hard they would be to replace in a hurry. A short, honest tiering that the business follows beats an exhaustive questionnaire that gets copied from the last one.
One recurring failure worth naming: the vendor that changes what it does with your data after contracting — typically by adding a model-training clause to its terms. Nobody in procurement re-reads terms of service. Decide now who watches for that, because ‘the update was published’ will be their defence and it is not a bad one.
Open the reading — A Privacy Program Is an Operating Model
Carry this into the drill
Pick your highest-risk processor and find out, today, whether you know their current sub-processor list. If you do not, that is the gap the rest of this module is about.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 4 of 6: Vendors, transfers and deals — Most personal data leaves the building. Govern the chain it travels along, the borders it crosses and the transactions that move it wholesale. - Module 4.1: Processors and the accountability chain - Today's topic: You cannot outsource accountability, only the processing - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - What the agreement has to carry - Processing only on your documented instructions, with the subject matter, duration, nature and purpose actually specified rather than left to a schedule nobody filled in. - Confidentiality obligations on their staff, and security measures described concretely enough to check. - Sub-processor terms: authorisation, notice of changes, and the flow-down of the same obligations. This is the clause most often watered down and least often read. - Assistance with rights requests, breach notification and assessments — with a timeframe. ‘Without undue delay’ from a vendor means whatever they decide it means unless you fix a number. - Deletion or return at the end, and audit rights you would realistically exercise. - The point I am meant to carry into practice: Pick your highest-risk processor and find out, today, whether you know their current sub-processor list. If you do not, that is the gap the rest of this module is about. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (third-party-risk): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Vendor tiering plus a DPA clause checklist. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
How ready is your data privacy function?
A structured read on how managed your third-party risk actually is, across the eight domains of a real programme. It tells you whether the tiering you are about to write will land in a functioning process or become a document you maintain alone.
Open the drill
Ticks itself when the drill records a result
applyRequired
Vendor tiering plus a DPA clause checklist
Open the brief
Produce two linked artefacts: a tiering model for your processors, and the data processing agreement checklist a procurement colleague could apply without you.
Then apply the tiering to your real vendor list, even roughly. The output that matters is the small set of vendors in your top tier — those are the relationships that deserve your actual attention this quarter.
What to produce
- The tiering criteria: volume, sensitivity, access to production, criticality, jurisdiction — with the thresholds that separate tiers
- What diligence each tier gets, before signature and on review
- The DPA clause checklist, written so a non-specialist can mark each clause present, weak or missing
- Your real vendors sorted into tiers, with the top tier named
- For each top-tier vendor: sub-processor list known or not, and breach-notification timeframe agreed or not
- Who monitors terms-of-service changes, and how they will find out
Template · vendor-tiering

4.2

International transfers

3.5h

Adequacy, standard contractual clauses, transfer impact assessments and localisation.

learnRequired
A transfer is a question about the destination's law
Read the brief~2 min
A transfer restriction is not really about geography. It is a question about the destination's law: if personal data moves somewhere the protections travelling with it can be overridden — by government access powers, by an absence of redress — then the protection you promised has quietly ended. That is why transfer work cannot be discharged by signing a standard clause and filing it.
The mechanisms, in the order you should consider them
- Adequacy: the destination has been assessed as offering equivalent protection. Cheapest route, and it can be withdrawn — which is a risk to track, not a reason to avoid it.
- Standard contractual clauses: the workhorse. They bind the importer, but they cannot bind that country's government, which is the whole reason the assessment below exists.
- Binding corporate rules: heavy, slow, and genuinely useful for large groups moving data internally at scale.
- Derogations: consent, contractual necessity and the rest. Narrow, occasional, and not a foundation for routine flows — however often they get used as one.
The transfer impact assessment
The assessment asks what the clauses cannot: in this destination, under this law, could the protections be defeated, and does anything you have done reduce that risk to acceptable? It is a genuine analysis, and it can conclude that the transfer should not proceed without additional measures — encryption where you hold the keys, pseudonymisation before export, or splitting the data so the exported portion is not identifying.
Two practical notes. Remote access counts: a support engineer in another country viewing data that never leaves your servers is a transfer. And localisation regimes are a different animal — they restrict where data may sit at all, so a mechanism that legitimises a transfer under GDPR may still leave you in breach locally. Check both directions.
Carry this into the drill
Map one real data flow that crosses a border, including remote access by support and engineering. Most organisations discover at least one flow nobody had counted.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 4 of 6: Vendors, transfers and deals — Most personal data leaves the building. Govern the chain it travels along, the borders it crosses and the transactions that move it wholesale. - Module 4.2: International transfers - Today's topic: A transfer is a question about the destination's law - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The mechanisms, in the order you should consider them - Adequacy: the destination has been assessed as offering equivalent protection. Cheapest route, and it can be withdrawn — which is a risk to track, not a reason to avoid it. - Standard contractual clauses: the workhorse. They bind the importer, but they cannot bind that country's government, which is the whole reason the assessment below exists. - Binding corporate rules: heavy, slow, and genuinely useful for large groups moving data internally at scale. - Derogations: consent, contractual necessity and the rest. Narrow, occasional, and not a foundation for routine flows — however often they get used as one. - The transfer impact assessment - The point I am meant to carry into practice: Map one real data flow that crosses a border, including remote access by support and engineering. Most organisations discover at least one flow nobody had counted. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (pdpl-remediation): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Transfer impact assessment for one real data flow. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Remediation Board: Saudi PDPL
Saudi PDPL on purpose: a regime with its own transfer and localisation mechanics that does not simply mirror GDPR. Working its findings is the fastest way to feel which of your assumptions are structural and which were European habits.
Open the drill
Ticks itself when the drill records a result
applyRequired
Transfer impact assessment for one real data flow
Open the brief
Write a transfer impact assessment for one real cross-border flow. Choose one that matters — a core platform, a support arrangement, an offshore operations team — rather than the easiest to document.
Reach an actual conclusion. An assessment that surveys the landscape and stops short of saying whether the transfer may proceed, and on what conditions, has not done its job.
What to produce
- The flow: what data, about whom, from where to where, by what route, and including any remote access
- The mechanism relied on, and why that one
- The destination's law: government access powers, available redress, and how you informed yourself
- Whether the mechanism's protections could be defeated in practice, stated plainly
- Supplementary measures in place or needed — technical, contractual, organisational
- Any localisation requirement in the destination or origin that operates independently of this analysis
- Conclusion: proceed, proceed with conditions, or stop — with the review trigger and date
Template · tia

4.3

Privacy in deals and migrations

Diligence, the data debt you inherit at close, and the migration nobody scoped as a privacy event.

learnRequired
At close you acquire their breaches too
Read the brief~2 min
At close you acquire their data, their processing and their breaches. Privacy diligence is routinely the thinnest workstream in a transaction and one of the most expensive to get wrong: regulators have shown they will pursue an acquirer for the target's pre-acquisition failures, and the marketing database that made the target attractive may be unusable if the consent behind it does not permit your use.
What to ask for, and what the answers tell you
- Their record of processing. Its absence is itself a finding, and a reliable indicator of everything else you will discover.
- Consent and basis records for any marketing database being valued — the asset may not transfer usefully.
- Incident history, including incidents assessed as not notifiable, and the assessments behind those calls.
- Processor agreements, sub-processor lists and any transfer mechanisms in place.
- Open regulatory correspondence, complaints and rights requests in flight.
- Retention practice — in a target that has never deleted anything, you are buying twenty years of breach surface.
Migration is a privacy event
The integration afterwards carries risk that diligence does not cover. Merging two customer bases can create a new purpose the original notices never described; migrating to your platform can silently extend retention to your longer period; and the intermediate copies made during a migration have a way of persisting for years. Scope the migration as processing in its own right, with its own assessment.
The same discipline applies to internal change. A platform consolidation or a warehouse rebuild is a migration with all the same failure modes and none of the deal-team attention.
Carry this into the drill
Look at your own change backlog for a migration or consolidation nobody has assessed as processing. That is the one to raise.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 4 of 6: Vendors, transfers and deals — Most personal data leaves the building. Govern the chain it travels along, the borders it crosses and the transactions that move it wholesale. - Module 4.3: Privacy in deals and migrations - Today's topic: At close you acquire their breaches too - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - What to ask for, and what the answers tell you - Their record of processing. Its absence is itself a finding, and a reliable indicator of everything else you will discover. - Consent and basis records for any marketing database being valued — the asset may not transfer usefully. - Incident history, including incidents assessed as not notifiable, and the assessments behind those calls. - Processor agreements, sub-processor lists and any transfer mechanisms in place. - Open regulatory correspondence, complaints and rights requests in flight. - The point I am meant to carry into practice: Look at your own change backlog for a migration or consolidation nobody has assessed as processing. That is the one to raise. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (acquisition-dossier): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Privacy diligence request list. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
The Acquisition Dossier — 7-day M&A diligence sim
Seven business days of diligence, a $1.4B target and more review actions than time allows. The transferable skill is exactly the one this module needs: deciding what to examine when you cannot examine everything, and living with what you chose to skip.
Open the drill
Ticks itself when the drill records a result
applyRequired
Privacy diligence request list
Open the brief
Build the privacy diligence request list you would hand to a deal team — or, if no transaction is plausible, aim it at an internal migration in your own backlog.
Order it by what would change the price or stop the deal. A request list that treats every item as equally urgent will be answered in whatever order suits the target.
What to produce
- The request list, ordered by materiality, with what each item is evidence of
- Red flags: the findings that would change valuation or require a specific indemnity
- Questions you would ask in a management meeting rather than in writing, and why
- Day-one obligations if the deal completes — notices, registrations, records, agreements
- The integration risks: new purposes created by merging, retention extended by migration, intermediate copies
- What you would accept not knowing, given the timetable — and how you would price that ignorance
Template · diligence-list
checkOptional
The migration in your own backlog nobody has assessed
Open the prompts
1. Which migration or consolidation in your own organisation has never been assessed as processing in its own right?
2. If your organisation were acquired tomorrow, which finding in your own estate would you least want the acquirer's diligence to surface?
3. Where would your intermediate copies from the last migration be today, and who could confirm that?

Week 5 of 6 · 10 hours · 3 modules

Assessments, AI and automated decisions

Where privacy work is currently least mature and most needed: assessing designs before they ship, and governing systems that decide about people.

5.1

The assessment that changes the design

3.5h

Trigger, scope, and the difference between a DPIA and a form filed after the decision.

learnRequired
A DPIA that changes nothing was written too late
Read the brief~2 min
A data protection impact assessment is supposed to be a design instrument. In most organisations it has become a form completed after the design is finished, to record that an assessment happened. The difference is not effort or template quality; it is timing. An assessment that arrives after the architecture is fixed can only document risk, because every recommendation it might make is now a rework request nobody will fund.
When one is actually required
- Systematic and extensive automated evaluation of people, including profiling, where decisions have significant effect.
- Large-scale processing of special category data — health, biometrics, beliefs, and the rest.
- Systematic monitoring of publicly accessible areas.
- Plus, in practice: new technology, data matching, invisible processing, and vulnerable subjects. If two or more of these are present, assume you need one.
What separates a real assessment from a form
Three things. It is done early enough that the answer can change the design. It states the risk to the individual in concrete terms — not ‘privacy risk: medium’ but ‘a person wrongly flagged loses account access for up to six days and has no route to challenge it’. And it records what was rejected, not just what was chosen, so a reviewer can see the alternatives were genuinely considered.
The AI overlay makes the timing point sharper. Where a system makes or materially informs decisions about people, you are increasingly assessing against two regimes at once: the privacy assessment and a risk classification under AI rules. They ask overlapping but non-identical questions, and the classification often determines obligations — documentation, human oversight, transparency — that are far cheaper to build in than to retrofit.
If the assessment concludes high residual risk that you cannot mitigate, the obligation is to consult the supervisory authority before proceeding. That outcome is rare, and an organisation whose assessments have never once come close to it is probably not assessing honestly.
Carry this into the drill
Before the drill, pick the use case in your organisation you would least like to defend, and note at what point in its life an assessment could still have changed it.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 5 of 6: Assessments, AI and automated decisions — Where privacy work is currently least mature and most needed: assessing designs before they ship, and governing systems that decide about people. - Module 5.1: The assessment that changes the design - Today's topic: A DPIA that changes nothing was written too late - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - When one is actually required - Systematic and extensive automated evaluation of people, including profiling, where decisions have significant effect. - Large-scale processing of special category data — health, biometrics, beliefs, and the rest. - Systematic monitoring of publicly accessible areas. - Plus, in practice: new technology, data matching, invisible processing, and vulnerable subjects. If two or more of these are present, assume you need one. - What separates a real assessment from a form - The point I am meant to carry into practice: Before the drill, pick the use case in your organisation you would least like to defend, and note at what point in its life an assessment could still have changed it. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (eu-ai-act-sorter, eu-ai-act-readiness): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: DPIA for one genuinely high-risk use case. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Classify the Use Case — EU AI Act Sorter
Sorting real systems into prohibited, high-risk, limited and minimal is the classification call that now sits alongside every privacy assessment of an AI system. Getting it wrong sets the obligations for the whole build, so it is worth being calibrated before you do it for real.
Open the drill
Ticks itself when the drill records a result
playOptionalTicks itself
Are you EU AI Act-ready?
Optional, and worth the seven minutes if AI systems are in your estate: a structured readiness read across classification, documentation and oversight, so you know which gaps are yours before you write an assessment that assumes they are not.
Open the drill
Ticks itself when the drill records a result
applyRequired
DPIA for one genuinely high-risk use case
Open the brief
Write a data protection impact assessment for one genuinely high-risk use case in your organisation. Profiling, monitoring, automated eligibility decisions, biometrics or a model trained on customer data are all fair game.
State the risks to people in specific, concrete terms and reach a real conclusion. If the honest answer is that the design should change, write that — that is the assessment doing its job, and it is far cheaper now than after launch.
What to produce
- The processing described in plain language, with a data flow a non-specialist could follow
- Necessity and proportionality: why this, and what less intrusive option you rejected and why
- Risks to individuals, each stated concretely — what happens to a person when it goes wrong, how likely, how severe
- Consultation: whose views you sought, including the affected people or their representatives where feasible
- Measures that reduce each risk, and the residual position after them
- Where this sits under AI risk classification, if applicable, and what obligations that triggers
- Conclusion, sign-off, review trigger — and whether prior consultation is required
Template · dpia

5.2

AI governance where it meets privacy

3.5h

Intake gates, automated decision-making and the transparency owed to someone a model has ruled on.

learnRequired
The gate is cheaper than the recall
Read the brief~2 min
AI governance and privacy overlap heavily but are not the same discipline, and privacy teams get handed the whole problem because they are the only function already used to assessing systems before they ship. Know which parts are genuinely yours: personal data in training, decisions about people, transparency, rights over model outputs, and the transfers involved in using someone else's model.
The gate is cheaper than the recall
The highest-leverage privacy control over AI is an intake gate: a short, mandatory step where a proposed use case is described, classified and routed before development starts. Not an approval committee that meets monthly and becomes a queue — a gate with clear criteria, most cases cleared quickly, and only the genuinely risky ones escalated.
- What data trains it, and did the people it describes have any expectation of that use? Training on customer data collected for service delivery is the most common quiet failure.
- Does it decide about people, or materially inform someone who does? That distinction sets your transparency and oversight obligations.
- Can a person get a meaningful explanation, and challenge the outcome to a human with authority to change it?
- Where does the inference run, who else sees the prompt, and does that constitute a transfer or a disclosure to a processor?
- What happens to input data afterwards — retained, logged, used for improvement? This is the clause vendors change most often.
Solely automated decisions
Decisions producing legal or similarly significant effects, taken with no meaningful human involvement, carry specific restrictions and rights. The word doing the work is ‘meaningful’. A human who rubber-stamps a model's output without the authority, information or time to disagree is not meaningful involvement, and designing that person's role honestly is one of the most valuable things a privacy practitioner can insist on.
Open the reading — Your AI Agents Are Employees Now. Audit Them Like It.
Carry this into the drill
Draft the three questions your intake gate would ask that would have caught the last AI use case that surprised you.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 5 of 6: Assessments, AI and automated decisions — Where privacy work is currently least mature and most needed: assessing designs before they ship, and governing systems that decide about people. - Module 5.2: AI governance where it meets privacy - Today's topic: The gate is cheaper than the recall - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The gate is cheaper than the recall - What data trains it, and did the people it describes have any expectation of that use? Training on customer data collected for service delivery is the most common quiet failure. - Does it decide about people, or materially inform someone who does? That distinction sets your transparency and oversight obligations. - Can a person get a meaningful explanation, and challenge the outcome to a human with authority to change it? - Where does the inference run, who else sees the prompt, and does that constitute a transfer or a disclosure to a processor? - What happens to input data afterwards — retained, logged, used for improvement? This is the clause vendors change most often. - The point I am meant to carry into practice: Draft the three questions your intake gate would ask that would have caught the last AI use case that surprised you. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (ai-use-case-gate, confidently-wrong): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Intake-gate criteria for AI proposals. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
The Use-Case Gate — an AI governance committee sim
Eight AI proposals, one committee agenda, and the choice between approve, reject and conditional. It is the gate from the lesson run at speed — and the conditional approvals are where you find out whether your conditions are specific enough to be enforced.
Open the drill
Ticks itself when the drill records a result
playOptionalTicks itself
Confidently Wrong — naming the AI failure mode
Optional and short: naming the failure mode when a model is confidently wrong. Useful here because the transparency you owe a person depends on understanding how the system fails, not just how it works.
Open the drill
Ticks itself when the drill records a result
applyRequired
Intake-gate criteria for AI proposals
Open the brief
Write the intake-gate criteria for AI proposals in your organisation — the questions asked, the thresholds that escalate, and what happens at each outcome.
Design it to be fast for the ordinary case. A gate that takes three weeks for a low-risk internal tool will be routed around within a month, and you will lose visibility of everything.
What to produce
- The intake questions, short enough that a product manager will actually answer them
- Classification thresholds: what makes a case low, elevated or high-risk, stated so two people reach the same answer
- The route for each class: cleared, conditions, full assessment, or refused
- Standard conditions you would attach — written specifically enough to verify later
- Human involvement: what counts as meaningful in your organisation, and the authority that person needs
- Vendor questions for externally hosted models: training use, retention, sub-processors, location
- Who owns the gate, and how a case that skipped it gets caught
Template · ai-gate

5.3

Auditing a model for privacy

Testing what a model does with personal data, rather than how accurate it is.

learnRequired
Ask what it was trained on, then ask how you know
Read the brief~2 min
Auditing a model for privacy is not auditing it for accuracy. The questions are about data: what went in, what it retains, what it emits, and whether a person could exercise their rights over any of it. Accuracy matters to the privacy question only where inaccuracy causes harm to an individual — which, for anything making decisions about people, it usually does.
The questions that produce findings
- What was it trained on, and how do you know? ‘The vendor says so’ is an answer you should write down as such.
- Does personal data persist in the model or only in the training set? Memorisation and extraction are real, and ‘the model does not store data’ is a claim, not a fact.
- What happens to inputs at inference — logged, retained, used for improvement, visible to the vendor's staff?
- Can you honour erasure? If a person's data is in the training set, what would deletion actually require, and has anyone costed it?
- Can you explain an individual outcome to the person it affected, in terms they can act on?
- Is the output itself personal data? An inference about someone is their personal data, including one that is wrong.
Evidence, not assurance
The discipline that transfers directly from control testing: ask for evidence rather than assurance, and rate what you get. A model card, a data sheet, a retention setting you can see in a console, a contractual commitment with a number in it — these are evidence. A sales engineer's confident answer on a call is not, and the gap between the two is where your findings live.
Write findings with severity based on effect on people, exactly as in week 3. The temptation with AI work is to write an essay about model risk; resist it. Findings, severity, owners, dates.
Carry this into the drill
For one model in your estate, try to establish what it was trained on and what evidence supports that. How far you get is the finding.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 5 of 6: Assessments, AI and automated decisions — Where privacy work is currently least mature and most needed: assessing designs before they ship, and governing systems that decide about people. - Module 5.3: Auditing a model for privacy - Today's topic: Ask what it was trained on, then ask how you know - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The questions that produce findings - What was it trained on, and how do you know? ‘The vendor says so’ is an answer you should write down as such. - Does personal data persist in the model or only in the training set? Memorisation and extraction are real, and ‘the model does not store data’ is a claim, not a fact. - What happens to inputs at inference — logged, retained, used for improvement, visible to the vendor's staff? - Can you honour erasure? If a person's data is in the training set, what would deletion actually require, and has anyone costed it? - Can you explain an individual outcome to the person it affected, in terms they can act on? - The point I am meant to carry into practice: For one model in your estate, try to establish what it was trained on and what evidence supports that. How far you get is the finding. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (ai-risk-audit): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Model review notes with findings and severity. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
Auditing the Machine
The lead auditor's chair on an AI loan-decisioning model: scope it, risk-rank it, test it and write it up. It is this module's deliverable rehearsed end to end, on a system where the consequences for individuals are unambiguous.
Open the drill
Ticks itself when the drill records a result
applyRequired
Model review notes with findings and severity
Open the brief
Review one model or AI-enabled feature in your own organisation and write it up as findings. A vendor-hosted assistant, a scoring model, a triage classifier — whatever is genuinely in use.
Where you cannot get an answer, that is a finding in itself: record what you asked, who you asked and what came back. Unanswerable questions about a system deciding on people are the point, not a gap in your write-up.
What to produce
- The system, its purpose, and what it decides or informs
- Training data: what, whose, and the evidence behind the answer
- Inference-time data handling: logging, retention, vendor access, location
- Rights: access, erasure, objection, explanation — whether each is possible, and what it would take
- Human involvement, and whether it is meaningful by your week-5 definition
- Findings with severity rated on effect on individuals, each with an owner and a date
- The questions you could not get answered, and who owes you the answer
Template · model-review
checkOptional
The model in your organisation you would fail
Open the prompts
1. Which model in your organisation would fail this review today, and what would it fail on first?
2. For your most-used AI vendor, do you know whether your inputs train their model — and where is that written down?
3. If a person asked you to explain a decision this system made about them, what could you actually tell them?

Week 6 of 6 · 10 hours · 3 modules

Incidents, regulators and the close

The week everything is tested: assess a breach against risk to people, notify with a record behind it, then prove the whole method on one capstone.

6.1

Breach assessment and the clock

Risk to individuals, the seventy-two hour question, and why the first hour decides the record.

learnRequired
The clock starts at awareness, and awareness is a decision
Read the brief~2 min
A personal data breach is not only a hack. It is any security failure leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data — which includes the email to the wrong distribution list, the misconfigured bucket, the laptop in a taxi and the ransomware that encrypted data you had no backup for. Availability breaches count, and that surprises people every single time.
The clock starts at awareness, and awareness is a decision
The notification clock runs from when you become aware, and awareness means having a reasonable degree of certainty that a security incident has led to personal data being compromised. A short investigation to establish that is legitimate. Stretching that investigation because the clock has not started yet is not, and the timeline you produce afterwards will show which one you did. Log the moment you were told, the moment you concluded, and what happened in between.
The assessment is about risk to people
- What data, how sensitive, and can the people be identified from what was exposed?
- How many, and are any of them vulnerable?
- What is the realistic consequence: fraud, discrimination, identity theft, distress, physical safety?
- Was it recoverable — encrypted with keys you hold, retrieved before it was read, contained within a trusted party?
- The conclusion drives everything: no risk means record it and stop; risk means notify the authority; high risk means tell the individuals too.
Record the ones you decide not to notify with the same rigour as the ones you do. ‘We assessed and concluded no risk to individuals, here is the reasoning’ is a defensible position. ‘We did not think it was serious’ is not, and the difference between the two is entirely in whether you wrote it down at the time.
The first hour decides the record. Someone must be responsible for starting the log, and that log — with timestamps, decisions and who made them — becomes the primary evidence of how you behaved. Reconstructing it three weeks later is both obvious and unconvincing.
Carry this into the drill
Find out who, at 3am on a Saturday, would start the log at your organisation. If the answer is unclear, that is the finding this module exists to surface.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 6 of 6: Incidents, regulators and the close — The week everything is tested: assess a breach against risk to people, notify with a record behind it, then prove the whole method on one capstone. - Module 6.1: Breach assessment and the clock - Today's topic: The clock starts at awareness, and awareness is a decision - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The clock starts at awareness, and awareness is a decision - The assessment is about risk to people - What data, how sensitive, and can the people be identified from what was exposed? - How many, and are any of them vulnerable? - What is the realistic consequence: fraud, discrimination, identity theft, distress, physical safety? - Was it recoverable — encrypted with keys you hold, retrieved before it was read, contained within a trusted party? - The point I am meant to carry into practice: Find out who, at 3am on a Saturday, would start the log at your organisation. If the answer is unclear, that is the finding this module exists to surface. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (breach-tabletop): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Breach assessment decision record. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
The Breach Room — a C-suite tabletop
A major breach run from the board's chair, with the decisions arriving faster than the facts. It is the pressure the lesson describes — assessing risk to people while incomplete, on a clock — and it shows you which decisions you would defer that cannot be deferred.
Open the drill
Ticks itself when the drill records a result
applyRequired
Breach assessment decision record
Open the brief
Write the breach assessment decision record for a plausible scenario in your own environment. Use a real system and a realistic failure — a misdirected export, an exposed storage bucket, a compromised vendor account.
Write it as the contemporaneous record, in the tense and detail you would use on the day. This is a rehearsal of the artefact, and the artefact is what you will be judged on.
What to produce
- Timeline: when it happened, when you were told, when you concluded awareness — with the investigation in between
- What happened, factually, separating what you know from what you believe
- Data and people affected: categories, sensitivity, numbers, any vulnerable groups
- Risk assessment against realistic consequences for those people
- Containment and recovery actions, with times
- Your notification decision — authority, individuals, both or neither — and the reasoning behind it
- Who decided, when, and what would have changed the decision
Template · breach-record

6.2

Notification, regulators and evidence

2.5h

What a regulator asks for, and what accountability evidence looks like when it is real.

learnRequired
You are judged on the decision record, not the outcome
Read the brief~2 min
You are judged on the decision record, not the outcome. Two organisations can suffer the same breach and be treated entirely differently, and the variable is rarely the technical sophistication of the attack. It is whether they can show what they knew, when they knew it, what they decided and why.
Notifying the authority
- Describe the nature of the breach, the categories and approximate numbers of people and records — approximate is acceptable, silence is not.
- Give the likely consequences and the measures taken or proposed, including mitigation for the people affected.
- Name a contact who can actually answer follow-up questions.
- Phased notification is permitted where you do not yet have everything. Use it rather than waiting, and say what is still outstanding.
Notifying individuals
Where the risk to people is high, they get told directly, in clear language, with what happened, what it means for them and what they should do. The instinct to soften is strong and counterproductive: a notice that leaves people unsure whether they are affected generates more anger, more complaints and more regulatory attention than a blunt one. Say what you would want said to you.
Accountability evidence, in the cold light of an inquiry
Afterwards, a regulator asks for the artefacts you have spent five weeks building: the record of processing, the retention schedule, the assessments, the processor agreements, the training records, the previous incidents and how their actions were closed. This is the moment the programme's paperwork either holds or does not. Note what an inquiry never accepts: documents dated after the incident, policies with no evidence of operation, and assessments that were never revisited when the processing changed.
Sector overlays run in parallel and on different clocks — securities disclosure, financial services rules, health regulators, contractual notification to customers. Map them before you need them, because the day of an incident is a bad day to discover you had a four-day clock running alongside a seventy-two-hour one.
Carry this into the drill
List every notification clock that could run simultaneously for your organisation. Most practitioners find at least one they had not counted.
Go deeper — with your own AICopy-paste prompt
The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.
You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Data Privacy Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners who own privacy work or are moving into it: analysts, GRC generalists picking privacy up, and DPO-track people who need the operating side rather than a recital of the statute. - Week 6 of 6: Incidents, regulators and the close — The week everything is tested: assess a breach against risk to people, notify with a record behind it, then prove the whole method on one capstone. - Module 6.2: Notification, regulators and evidence - Today's topic: You are judged on the decision record, not the outcome - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Notifying the authority - Describe the nature of the breach, the categories and approximate numbers of people and records — approximate is acceptable, silence is not. - Give the likely consequences and the measures taken or proposed, including mitigation for the people affected. - Name a contact who can actually answer follow-up questions. - Phased notification is permitted where you do not yet have everything. Use it rather than waiting, and say what is still outstanding. - Notifying individuals - The point I am meant to carry into practice: List every notification clock that could run simultaneously for your organisation. Most practitioners find at least one they had not counted. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (disclosure-window, regulators-interview): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Notification pack and the decision log behind it. Ask what my process is, then outline what mine should contain and what would make it weak.
Yours to edit — changes stay in this box
playRequiredTicks itself
The Disclosure Window — SEC Item 1.05 simulation
A four-business-day disclosure clock starting at 3:47am, with twelve checkpoints and materiality decisions that cannot wait for certainty. It is the parallel-clock problem from the lesson made concrete, in the regime where getting it wrong is most visible.
Open the drill
Ticks itself when the drill records a result
playOptionalTicks itself
The Regulator’s Interview — SEC enforcement deposition sim
Optional: the enforcement deposition. Worth doing once, because it shows how contemporaneous records — or their absence — read when someone hostile is reading them back to you.
Open the drill
Ticks itself when the drill records a result
applyRequired
Notification pack and the decision log behind it
Open the brief
Build the notification pack for the scenario you assessed: the authority notification, the individual notice, and the decision log that sits behind both.
Draft the individual notice for a real person, not a legal reviewer. Then read it aloud. If it takes more than one pass to understand whether you are affected and what to do, rewrite it.
What to produce
- Authority notification covering nature, categories, numbers, consequences, measures and contact
- What is still unknown, and when you will provide it — the phased position
- Individual notice in plain language: what happened, what it means for you, what to do now, where to get help
- The decision log: who decided to notify, on what information, at what time
- Every parallel clock that applies, with its deadline and owner
- The accountability evidence you would hand over, and the one item in that list you could not currently produce
Template · notification-pack

6.3

Capstone and close

4.5h

One business area, assessed end to end with everything you have built, and a plan for what you do next.

applyRequired
Capstone: a privacy programme assessment for one business area
Open the brief
One business area, assessed end to end, using everything you have built. Pick something with real personal data and real stakes — a customer-facing product line, HR, a support operation — and produce the assessment you would actually put in front of the people accountable for it.
This is not a new exercise so much as an integration. Your inventory, applicable-law register, retention schedule, vendor tiering, transfer assessment and any AI review of that area all feed it. The work is in reconciling them into one coherent position — including where they contradict each other, because they will.
Finish with a single page for an executive. If the one-pager cannot be understood without the appendices, it is not finished.
What to produce
- Scope: the business area, its processing activities, and what you deliberately excluded
- Current state: inventory, lawful bases, notices, retention, processors, transfers — with evidence, not assertion
- Gaps, each rated by risk to individuals, with the evidence behind the rating
- A prioritised plan: containment now, structural fixes sequenced, owners and dates
- Residual risk you recommend accepting, with who should accept it and for how long
- The one-page executive summary: the position in one paragraph, the three things that matter, the decision you are asking for
- What you would do differently if you ran this assessment again
Template · capstone
playOptionalTicks itself
The War Room — an incident-command sim
Optional, and a good last exercise: command of a live incident with a finite team across recovery, customers and the regulator. After six weeks of building the artefacts, it is worth feeling once more what it is like when they are all being used at once.
Open the drill
Ticks itself when the drill records a result
playOptionalTicks itself
How ready is your data privacy function?
Optional. Run the department assessment on the function you actually work in, and compare where it lands against what this programme has asked you to build.
Open the drill
Ticks itself when the drill records a result
checkRequired
Reflection and personal development plan
Open the prompts
1. Which of the six weeks' artefacts turned out to be load-bearing for the capstone, and which did you barely open?
2. Where did two of your own artefacts contradict each other, and which one was wrong?
3. What is the single change to your organisation's privacy programme you would now argue for first, and who has the authority to make it?
4. What did you find you could not do — a skill, an access, a relationship — and what is the smallest next step toward it?
5. Three months from now, which of these artefacts will still be maintained, and what would have to be true for the others to survive?

Finish it, and it is on the record

When every required step is done, a printable completion certificate appears on your profile — self-attested, honest about what it is, and yours to keep. Apply and Check steps are yours to mark; Play steps tick themselves when a drill records a result.

Open your profile

Data Privacy Analyst — a six-week applied programme

What you hold, and what the law reaches

What privacy law actually regulates

Personal data is a relationship, not a column type

Controller or processor, and why it decides everything

What to produce

The regulatory map without the panic

The skeleton every regime shares

Where they actually diverge

What to produce

The inventory and the RoPA that stays true

What a record has to answer

Why they rot, and the two habits that stop it

What to produce

Basis, notice and restraint

Choosing a lawful basis you can defend

The two mistakes that cost the most

The assessment is a decision record

What to produce

Transparency people can use

The test that matters

What to produce

Purpose limitation, minimisation, retention

Three linked disciplines

Why schedules fail in practice

What to produce

Rights, and the machine that answers them

The subject access request, end to end

The four stages, and where each one goes wrong

Two practical realities

What to produce

Remediating findings — GDPR

Severity is about the person

The residual position

What to produce

The same findings, US law

What actually diverges

The trap

What to produce

Vendors, transfers and deals

Processors and the accountability chain

What the agreement has to carry

Diligence proportionate to the risk

What to produce

International transfers

The mechanisms, in the order you should consider them

The transfer impact assessment

What to produce

Privacy in deals and migrations

What to ask for, and what the answers tell you

Migration is a privacy event

What to produce

Assessments, AI and automated decisions

The assessment that changes the design

When one is actually required

What separates a real assessment from a form

What to produce

AI governance where it meets privacy

The gate is cheaper than the recall

Solely automated decisions

What to produce

Auditing a model for privacy

The questions that produce findings

Evidence, not assurance

What to produce

Incidents, regulators and the close

Breach assessment and the clock

The clock starts at awareness, and awareness is a decision

The assessment is about risk to people

What to produce

Notification, regulators and evidence

Notifying the authority

Notifying individuals

Accountability evidence, in the cold light of an inquiry

What to produce

Capstone and close

What to produce

Finish it, and it is on the record