Privacy, Security and Access for Data and AI
Learn to handle personal data safely, from mapping where it goes to deciding whether it can be reused. No coding: you work on the data of Raket Parts, a fictional maker of rocket parts.
You will be able to
- map where personal data goes and who receives it
- find uses nobody declared
- check consent and honour withdrawals
- record a reuse decision with its conditions
Where does personal data go?
Map a personal data use, identify recipients and missing evidence, and route corrections to an owner.
What is nobody telling us?
Distinguish undeclared leads from evidenced uses and assign each gap to an owner.
Can we reuse it?
Check original consent evidence, honour withdrawals, minimise requested fields and document a conditional reuse decision.
Check the risk before you start
Decide whether a dpia is needed, list harms to the people affected and record controls, residual risk, its owner and the consultation decision.
Protection built in, with proof
Check that minimisation, pseudonymisation, key separation and withdrawals reach every step of a data pipeline, with evidence for each.
Small groups in shared outputs
Stop shared figures from identifying individual people.
Designing role-based access
Give each role the access it needs and no more.
Proving access and revocation
Show who really has access, and that removals took effect.
Finding personal data for rights requests
Locate everything held on one person and act on the request.
Exemptions and third-party redaction
Apply exemptions and protect other people in a disclosure.
Containing a suspected breach
Contain an incident and preserve the evidence.
Statutory reporting duties and deadlines
Know who must be told, by whom and by when.
Integration clinic: a people dashboard and a new AI tool
Bring every method together on two real cases.
Final assessment
Privacy and access decisions on an unseen case.
Privacy and Access / Module 1
Where does personal data go?
Ilse Brakenhoff must review Raket Parts' list of personal data uses. The HR declaration says pay information stays in-house, yet an interface record points to an external provider. Learn to build a record and check every claim against evidence.
Sections
Privacy and Access / Module 1 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Privacy and Access / Module 2
What is nobody telling us?
A practice list names the approved uses of customer data. Ilse finds access records, interface records and system changes the declaration did not mention. Learn which clues merit investigation and when separate sources support a finding.
This module builds on module 1. If you are new to this, start with module 1.
Sections
Privacy and Access / Module 2 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Privacy and Access / Module 3
Can we reuse it?
Esmee proposes a win-back email audience using existing marketing contacts. Ilse checks what the original permission covers, whether contacts have withdrawn and which fields are needed before any send. You will make a documented decision without assuming legal authority.
This module builds on module 2. If you are new to this, start with module 2.
Sections
Privacy and Access / Module 3 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Privacy and Access / Module 4
Check the risk before you start
Sietske wants managers alerted when sick absences pass a threshold, and a supplier offers to predict who will be absent next. Ilse Brakenhoff, IT Manager, runs the DPIA before anything is built.
This module builds on module 3. If you are new to this, start with module 3.
Sections
Privacy and Access / Module 4 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Privacy and Access / Module 5
Protection built in, with proof
Esmee's campaign data moves from the CRM to audience lists to the email tool. Ilse checks each step: is it minimal, is the key kept apart, and does a withdrawal reach the end of the line?
This module builds on module 4. If you are new to this, start with module 4.
Sections
Privacy and Access / Module 5 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Privacy and Access / Module 1 / 1.1
1.1 Recognise personal information
Section 1.1 complete
Next: 1.2 Write a useful entry
Privacy and Access / Module 1 / 1.2
1.2 Write a useful entry
Section 1.2 complete
Next: 1.3 Check what systems show
Privacy and Access / Module 1 / 1.4
1.4 Give gaps an owner
Section 1.4 complete
Next: Module 1 check
Continue to the module check Recap this section Back to module 1
Privacy and Access / Module 1 / Check
Module 1 check
Module 1 complete
Next: Module 2, What is nobody telling us?
Continue to module 2 Try it on your own question Recap module 1 Back to module 1
Privacy and Access / Module 2 / 2.1
2.1 Look beyond declarations
Section 2.1 complete
Next: 2.2 Require two sources
Privacy and Access / Module 2 / 2.2
2.2 Require two sources
Section 2.2 complete
Next: 2.3 Changes create new leads
Privacy and Access / Module 2 / 2.3
2.3 Changes create new leads
Section 2.3 complete
Next: 2.4 Turn leads into owned work
Privacy and Access / Module 2 / 2.4
2.4 Turn leads into owned work
Section 2.4 complete
Next: Module 2 check
Continue to the module check Recap this section Back to module 2
Privacy and Access / Module 2 / Check
Module 2 check
Module 2 complete
Next: Module 3, Can we reuse it?
Continue to module 3 Try it on your own question Recap module 2 Back to module 2
Privacy and Access / Module 3 / 3.1
3.1 Know the original permission
Section 3.1 complete
Next: 3.2 Withdrawn means withdrawn
Privacy and Access / Module 3 / 3.2
3.2 Withdrawn means withdrawn
Section 3.2 complete
Next: 3.3 Use the smallest field set
Privacy and Access / Module 3 / 3.3
3.3 Use the smallest field set
Section 3.3 complete
Next: 3.4 Decide and record conditions
Privacy and Access / Module 3 / 3.4
3.4 Decide and record conditions
Section 3.4 complete
Next: Module 3 check
Continue to the module check Recap this section Back to module 3
Privacy and Access / Module 3 / Check
Module 3 check
Module 3 complete
Next: Module 4, Check the risk before you start
Continue to module 4 Try it on your own question Recap module 3 Back to module 3
Privacy and Access / Module 4 / 4.2
4.2 Is a DPIA needed?
Section 4.2 complete
Next: 4.3 Harms to people, not risks to the company
Privacy and Access / Module 4 / 4.3
4.3 Harms to people, not risks to the company
Section 4.3 complete
Next: 4.4 Controls, what is left, who owns it
Privacy and Access / Module 4 / 4.4
4.4 Controls, what is left, who owns it
Section 4.4 complete
Next: Module 4 check
Continue to the module check Recap this section Back to module 4
Privacy and Access / Module 4 / Check
Module 4 check
Module 4 complete
Next: Module 5, Protection built in, with proof
Continue to module 5 Try it on your own question Recap module 4 Back to module 4
Privacy and Access / Module 5 / 5.1
5.1 A reference is not anonymous
Section 5.1 complete
Next: 5.2 Each protection, at its step
Privacy and Access / Module 5 / 5.2
5.2 Each protection, at its step
Section 5.2 complete
Next: 5.3 Does the withdrawal reach the end?
Privacy and Access / Module 5 / 5.3
5.3 Does the withdrawal reach the end?
Section 5.3 complete
Next: 5.4 Evidence that it works
Privacy and Access / Module 5 / 5.4
5.4 Evidence that it works
Section 5.4 complete
Next: Module 5 check
Continue to the module check Recap this section Back to module 5
Privacy and Access / Module 5 / Check
Module 5 check
Module 5 complete
Next: Module 6, coming later
Back to the Path Try it on your own question Recap module 5 Back to module 5
Privacy and Access / Module 1 / Recap
Recap card
1.1 Recognise personal information
Recognise personal information
- Personal data can include references linked to someone.
- Health-related absence records need additional care.
Common mistake
Watch for this. A code can still point to a person.
Privacy and Access / Module 1 / Recap
Recap card
1.2 Write a useful entry
Write a useful entry
- Describe purpose, people and data separately.
- Ask for recipient, transfer and retention evidence.
Common mistake
Watch for this. Writing a value in a register does not make it true.
Privacy and Access / Module 1 / Recap
Recap card
1.3 Check what systems show
Check what systems show
- Owner declarations must be checked against interfaces.
- Interface descriptions and batch logs answer different questions.
Common mistake
Watch for this. A repeated system code is not proof that the data stayed internal.
Privacy and Access / Module 1 / Recap
Recap card
1.4 Give gaps an owner
Give gaps an owner
- Every gap needs evidence and an owner.
- Do not count versions as people.
- Legal conclusions go to a qualified adviser.
Common mistake
Watch for this. A correction without a recipient, proof or owner is not action-ready.
Privacy and Access / Module 1 / Recap
Recap card
Module 1: Where does personal data go?
Recognise personal information
- Personal data can include references linked to someone.
- Health-related absence records need additional care.
Common mistake
Watch for this. A code can still point to a person.
Write a useful entry
- Describe purpose, people and data separately.
- Ask for recipient, transfer and retention evidence.
Common mistake
Watch for this. Writing a value in a register does not make it true.
Check what systems show
- Owner declarations must be checked against interfaces.
- Interface descriptions and batch logs answer different questions.
Common mistake
Watch for this. A repeated system code is not proof that the data stayed internal.
Give gaps an owner
- Every gap needs evidence and an owner.
- Do not count versions as people.
- Legal conclusions go to a qualified adviser.
Common mistake
Watch for this. A correction without a recipient, proof or owner is not action-ready.
Privacy and Access / Module 2 / Recap
Recap card
2.1 Look beyond declarations
Look beyond declarations
- Declarations are starting points.
- Access grants show permission, not activity.
Common mistake
Watch for this. Do not equate a GRANTED row with an actual read or misuse.
Privacy and Access / Module 2 / Recap
Recap card
2.2 Require two sources
Require two sources
- Independent sources corroborate different facts.
- Record exactly what both sources establish.
Common mistake
Watch for this. Two system records do not automatically show what the report did.
Privacy and Access / Module 2 / Recap
Recap card
2.3 Changes create new leads
Changes create new leads
- Change logs can expose new flows.
- Use payload and destination evidence before calling it a transfer.
Common mistake
Watch for this. Implemented without approval is not itself evidence of a personal data breach.
Privacy and Access / Module 2 / Recap
Recap card
2.4 Turn leads into owned work
Turn leads into owned work
- Confirm technical facts; keep unsupported uses as leads.
- Every open gap needs an owner and next proof.
Common mistake
Watch for this. Do not close a lead merely because two records exist.
Privacy and Access / Module 2 / Recap
Recap card
Module 2: What is nobody telling us?
Look beyond declarations
- Declarations are starting points.
- Access grants show permission, not activity.
Common mistake
Watch for this. Do not equate a GRANTED row with an actual read or misuse.
Require two sources
- Independent sources corroborate different facts.
- Record exactly what both sources establish.
Common mistake
Watch for this. Two system records do not automatically show what the report did.
Changes create new leads
- Change logs can expose new flows.
- Use payload and destination evidence before calling it a transfer.
Common mistake
Watch for this. Implemented without approval is not itself evidence of a personal data breach.
Turn leads into owned work
- Confirm technical facts; keep unsupported uses as leads.
- Every open gap needs an owner and next proof.
Common mistake
Watch for this. Do not close a lead merely because two records exist.
Privacy and Access / Module 3 / Recap
Recap card
3.1 Know the original permission
Know the original permission
- A notice does not create unlimited reuse rights.
- Latest consent records matter.
Common mistake
Watch for this. A legacy import is not positive permission evidence.
Privacy and Access / Module 3 / Recap
Recap card
3.2 Withdrawn means withdrawn
Withdrawn means withdrawn
- Withdrawal replaces an earlier opt-in.
- Snapshot rows are not necessarily distinct people.
Common mistake
Watch for this. Never restore withdrawn consent from an older record.
Privacy and Access / Module 3 / Recap
Recap card
3.3 Use the smallest field set
Use the smallest field set
- Use only fields needed for the stated decision.
- A planning audience is not a sending list.
Common mistake
Watch for this. Do not mistake a contact reference for a verified delivery address.
Privacy and Access / Module 3 / Recap
Recap card
3.4 Decide and record conditions
Decide and record conditions
- Check basis, purpose and current choices.
- Use the smallest necessary field set.
- Escalate legal judgements before sending.
Common mistake
Watch for this. A conditional practice review is not legal approval to send.
Privacy and Access / Module 3 / Recap
Recap card
Module 3: Can we reuse it?
Know the original permission
- A notice does not create unlimited reuse rights.
- Latest consent records matter.
Common mistake
Watch for this. A legacy import is not positive permission evidence.
Withdrawn means withdrawn
- Withdrawal replaces an earlier opt-in.
- Snapshot rows are not necessarily distinct people.
Common mistake
Watch for this. Never restore withdrawn consent from an older record.
Use the smallest field set
- Use only fields needed for the stated decision.
- A planning audience is not a sending list.
Common mistake
Watch for this. Do not mistake a contact reference for a verified delivery address.
Decide and record conditions
- Check basis, purpose and current choices.
- Use the smallest necessary field set.
- Escalate legal judgements before sending.
Common mistake
Watch for this. A conditional practice review is not legal approval to send.
Privacy and Access / Module 4 / Recap
Recap card
4.1 Before, not after
Before, not after
- A DPIA assesses risks to people before processing starts.
- Law (general): before high-risk processing. Good practice: at design.
Common mistake
The mistake. Treating the DPIA as a form for after launch.
Privacy and Access / Module 4 / Recap
Recap card
4.2 Is a DPIA needed?
Is a DPIA needed?
- Health data, monitoring and new technology point to a DPIA.
- 133 employees had a sick absence in 2025.
Common mistake
The mistake. Skipping the screening record when the answer is no.
Privacy and Access / Module 4 / Recap
Recap card
4.3 Harms to people, not risks to the company
Harms to people, not risks to the company
- Harms land on people: wrong flags, pressure, exposure.
- 85 people already hold HR access.
Common mistake
The mistake. Listing a fine as the main harm.
Privacy and Access / Module 4 / Recap
Recap card
4.4 Controls, what is left, who owns it
Controls, what is left, who owns it
- Testable controls, a residual rating and an owner per harm.
- High risk left: data protection officer, then consult before starting.
Common mistake
The mistake. Re-rating a risk instead of reducing it.
Privacy and Access / Module 4 / Recap
Recap card
Module 4: Check the risk before you start
Before, not after
- A DPIA assesses risks to people before processing starts.
- Law (general): before high-risk processing. Good practice: at design.
Common mistake
The mistake. Treating the DPIA as a form for after launch.
Is a DPIA needed?
- Health data, monitoring and new technology point to a DPIA.
- 133 employees had a sick absence in 2025.
Common mistake
The mistake. Skipping the screening record when the answer is no.
Harms to people, not risks to the company
- Harms land on people: wrong flags, pressure, exposure.
- 85 people already hold HR access.
Common mistake
The mistake. Listing a fine as the main harm.
Controls, what is left, who owns it
- Testable controls, a residual rating and an owner per harm.
- High risk left: data protection officer, then consult before starting.
Common mistake
The mistake. Re-rating a risk instead of reducing it.
Privacy and Access / Module 5 / Recap
Recap card
5.1 A reference is not anonymous
A reference is not anonymous
- Pseudonymised data is still personal data.
- 4 segment and country groups hold fewer than 5 contacts.
Common mistake
The mistake. Calling a list anonymous because it has no names.
Privacy and Access / Module 5 / Recap
Recap card
5.2 Each protection, at its step
Each protection, at its step
- Mark each protection present, absent or present without evidence.
- X-DATA has no grants recorded: not evidenced.
Common mistake
The mistake. Reading missing records as proof of no access.
Privacy and Access / Module 5 / Recap
Recap card
5.3 Does the withdrawal reach the end?
Does the withdrawal reach the end?
- 276 of 280 cases suppressed; 4 emailed after withdrawing.
- The snapshot date is not recorded.
Common mistake
The mistake. Claiming more than the send dates prove.
Privacy and Access / Module 5 / Recap
Recap card
5.4 Evidence that it works
Evidence that it works
- Dated tests: suppression before each send, access to the key.
- No purpose, no raw data kept.
Common mistake
The mistake. Filing a policy as evidence.
Privacy and Access / Module 5 / Recap
Recap card
Module 5: Protection built in, with proof
A reference is not anonymous
- Pseudonymised data is still personal data.
- 4 segment and country groups hold fewer than 5 contacts.
Common mistake
The mistake. Calling a list anonymous because it has no names.
Each protection, at its step
- Mark each protection present, absent or present without evidence.
- X-DATA has no grants recorded: not evidenced.
Common mistake
The mistake. Reading missing records as proof of no access.
Does the withdrawal reach the end?
- 276 of 280 cases suppressed; 4 emailed after withdrawing.
- The snapshot date is not recorded.
Common mistake
The mistake. Claiming more than the send dates prove.
Evidence that it works
- Dated tests: suppression before each send, access to the key.
- No purpose, no raw data kept.
Common mistake
The mistake. Filing a policy as evidence.