The inventory everything else reads from
Almost every GDPR task you have learned - answering a DSAR, mapping transfers, responding to a breach - starts with the same question: what data do we hold, and where? The record of processing is where that lives. It is the least glamorous artifact and the most load-bearing: build it once and every other obligation gets faster. The DPIA is its forward-looking cousin: before you launch something risky, you assess the risk on paper first.
The record of processing 7 min live
A record of processing (often called a ROPA) is a structured list: for each processing activity, what data, why, who gets it, where it goes, and how long you keep it. Both controllers and processors must keep one.
LiveThe "small company is exempt" myth3 min▶
Article 30(5) seems to exempt organisations with fewer than 250 employees - and teams stop reading there. But the exemption falls away if any one of three things is true, and one almost always is:
- the processing is likely to result in a risk to people's rights; or
- the processing is not occasional (i.e. it is regular, routine - which a customer database is); or
- it includes special-category or criminal data.
Because "not occasional" catches any regular business processing, the exemption almost never applies to a real operating company. Treat records as required, and the exemption as a rare edge case.
LiveWhy the ROPA pays for itself3 min▶
- DSARs get fast: "where does this person's data live" is answered by the ROPA, not by asking around.
- Transfers get visible: the transfers column is your cross-border map from session a6/b6.
- Breaches get scoped: when something leaks, the ROPA tells you what was in the affected system and whose data it held.
- It is the accountability evidence: Article 5(2) says you must be able to demonstrate compliance - the ROPA is a large part of that demonstration.
Lumina builds its ROPA. Lumina, well under 250 employees, assumed it was exempt - until it hit the "not occasional" carve-out (its processing is continuous). It built a ROPA with rows for accounts, billing, support, and analytics. The first payoff came a week later: a DSAR that used to mean a scramble was answered by reading four rows.
When you need a DPIA 8 min live
A DPIA is a structured risk assessment you run before starting a high-risk processing activity. The trick is knowing when it is required - the GDPR gives a general test plus three clear examples.
LiveThe trigger test3 min▶
- General rule: a DPIA is required where processing is likely to result in a high risk to people's rights and freedoms - especially with new technologies.
- Three mandatory examples (Art 35(3)): systematic and extensive profiling by automated means with legal or similarly significant effects; large-scale processing of special-category or criminal data; large-scale systematic monitoring of a publicly accessible area.
- Timing: before you start the processing. A DPIA done after launch is just documentation of a risk you already took.
- What it contains: a description of the processing, an assessment of necessity and proportionality, the risks to individuals, and the measures to mitigate them.
Self-studyThe DPIA as a design tool, not a form2 min read▶
It is tempting to treat the DPIA as a compliance form you fill in to get sign-off. Done well, it is a design tool that changes what you build. Because it forces you to state the risk to individuals and the measures that reduce it before you ship, it surfaces the "do we even need to collect that?" question at the point where the answer is still cheap to act on. A profiling feature that looked fine in a product spec often looks different once a DPIA makes you write down what happens to someone the model gets wrong. For a Singapore company, the DPIA also doubles as useful evidence under the PDPA's accountability expectations - the same assessment that satisfies Article 35 shows you thought about risk before processing, which is exactly what a regulator on either side wants to see. Run it early, let it change the design, and keep it.
Draft Lumina's records + a DPIA call ★ 10 min · pen and paper
Build the two artifacts on the running case.
Three ROPA rows. For Lumina's accounts, analytics, and support, fill the fields: purpose, data categories, recipients, transfers, retention, lawful basis.
Check the exemption. Confirm Lumina cannot rely on the under-250 exemption (its processing is "not occasional"). Write the one-line reason.
The DPIA call. Lumina plans a feature that profiles users to auto-decide their pricing tier. Run the trigger test - does it need a DPIA? (Automated profiling with a significant effect - yes.)
Sketch the DPIA. In four lines: the processing, its necessity, the risk to a mis-profiled user, and one mitigation (e.g. a human-review option).
Before session b6 ◐ 40 min total
- Start your real record of processing - one row per major activity, with all six fields. Even a spreadsheet beats nothing.
- Confirm whether the Article 30 small-org exemption applies to you (almost certainly not - "not occasional").
- Identify one planned or recent feature that would need a DPIA under the trigger test, and note whether one was done.
- Read: GDPR Articles 30 and 35 - records and the impact assessment.
Official sources covered
Taught from the GDPR text. This page covers ~80% of the working content on records and DPIAs.
Three questions before you go 🎯 ◐ 90 seconds
1 · Your company has 40 employees. Are you exempt from keeping a record of processing?
Article 30(5)'s under-250 exemption is cancelled by any of three carve-outs; "not occasional" (regular processing) catches nearly every operating business, so records are effectively required.
2 · A DPIA is required when processing is...
Article 35: a DPIA is needed for high-risk processing, with three mandatory examples including systematic extensive profiling with significant effects and large-scale special-category data.
3 · When should a DPIA be carried out?
A DPIA is done before the high-risk processing begins, so it can actually change the design. Done after launch, it merely records a risk already taken.