3.2Processing register & obligations
The essentials in 30 seconds
- The register is the centrepiece: purpose, data, people, legal basis, recipients, retention periods, security — for each processing activity.
- Keeping it reveals anomalies: excessive retention, unnecessary collection, missing legal basis, unmanaged provider.
- Proportionate compliance: the core for everyone (register, inform, secure); DPO and impact assessment only in certain cases.
Running mini-case — Yacine builds his register
Yacine turns his inventory into a register: a simple table (customers, newsletter prospects, payroll, website) with purpose, legal basis, retention period and recipients. While filling it in, he spots two anomalies: prospects kept for years and an email provider with no contract. He fixes both before moving on to consent.
Continued from case 3.1 — Yacine moves from inventory to register.
1. The centrepiece
Following the rules is not enough, you must be able to prove it: that is the role of the processing register. For each processing activity: purpose, categories of data and data subjects, legal basis, recipients (including processors), retention periods, transfers, security measures.
Keeping it forces you to ask the right questions and reveals anomalies (excessive retention, unnecessary collection, missing legal basis).
2. Proportionate obligations
Around the register: the information duty, security, managing processors by contract, sometimes a DPO and an impact assessment.
Compliance is proportionate: an SME with simple processing does not carry the heavy obligations of a large player. But the core (knowing what data, why, on what basis, securing, informing, a basic register) broadly applies.
3. Keeping it alive
A register is alive: update it with every new processing activity, new provider or retention change.
Check your country's specific obligations (DPO, impact assessment, information) before finalising your setup.
🔎 Concrete example — 🔎 Practical example — A simple table is enough
Scaled to your activity.
Small business: a table listing a few processing activities (customers, prospects, payroll, newsletter, website)
with purpose, legal basis, retention, recipients.
→ this is not red tape, it is a sensible inventory.Result: a workable register and the right obligations identified.
Reflex: check whether a DPO is required in your case.
Section vocabulary
- Processing register
- A document recording, for each processing activity, its purpose, the data and data subjects, the legal basis, recipients, retention periods and security.
Simple example: Yacine's table: customers, prospects, payroll, website — each documented.
What it is not: a simple antivirus or an employment contract.
Reflex: one processing activity = one complete register row.
- Duty to inform
- The duty to clearly inform people about what you do with their data and about their rights (notices, privacy policy).
Simple example: Yacine adds a notice under each collection form.
What it is not: collecting without ever explaining the use.
Reflex: inform at the moment of collection.
- Processor management
- The duty to bind by contract any provider processing data on your behalf, with specific commitments.
Simple example: Yacine signs a commitment with his email provider.
What it is not: letting a provider process with no contract at all.
Reflex: no provider without a data clause.
- DPO
- Data protection officer: the contact person overseeing compliance; mandatory only in certain cases depending on the country.
Simple example: Yacine checks whether he falls into a DPO case, otherwise names an internal contact.
What it is not: believing every SME must appoint a DPO.
Reflex: check the appointment cases in your country.
- Impact assessment
- An assessment of the risks to individuals, required before processing likely to pose a high risk.
Simple example: Before wide CCTV, Yacine assesses the risk.
What it is not: launching risky processing with no assessment.
Reflex: high risk = assess before starting.
In practice — In practice — Building and keeping your register
- List all your processing activities (customer management, prospecting, payroll, website, video surveillance…) — this is the starting map.
- For each one, note: purpose, data, data subjects, legal basis, recipients/processors, retention period, security, possible transfers.
- Fix the anomalies revealed (data kept too long, excessive collection, missing legal basis, unmanaged provider).
- Adjust for proportionality and check your specific obligations (DPO, impact assessment, information) in your country.
Ready-to-say script — asking the provider for the inventory (30 s)
'For our register, send me the list of the data you process for us, where it is stored, who accesses it and how long you keep it. We will add your commitments to the contract.'
Say it to each provider: get the information missing from the register.
Copy-paste template — register row
PROCESSING: _______________
PURPOSE: _______________ | LEGAL BASIS: _______________
DATA / PEOPLE: _______________
RECIPIENTS / PROCESSORS: _______________
RETENTION: _______________ | SECURITY: _______________
TRANSFERS: _______________VSE / small budget
A 6-column spreadsheet (processing, purpose, basis, retention, recipients, security) is enough; half a day to fill in, then 15 minutes a month.
SME in Algiers
Yacine has his table reviewed by his accountant and checks the Law 18-07 rules: register, information and security scaled to his size.
Vague provider
With no answer from the provider on storage and retention: change the clause or the provider — the register cannot stay empty.
New project
Before any new file or tool: create the register row first (purpose, basis, retention), deploy second.
✓ Best practices
- Keep a register, even a simple one (a table is enough for an SME).
- Put your processors under contract.
- Scale your obligations to your size and risks (proportionality).
✗ Common pitfalls
- Believing the register is reserved for large organisations.
- Imagining you must deploy a multinational's system.
- Forgetting to put under contract the providers handling your data.
Key takeaways
- The processing register is the centrepiece: it records purpose, data, legal basis, recipients, retention periods and security for each activity.
- Keeping it forces you to ask the right questions and reveals anomalies (excessive retention, unnecessary collection, missing legal basis).
- Associated duties: inform people, secure data, bind processors by contract, sometimes DPO and impact assessment.
- Compliance is PROPORTIONATE (an SME does not carry a large player's duties); check your country's exact rules.
48h challenge — apply it tomorrow
Create your register table with 3 processing activities (customers, prospects, payroll) and fix 1 anomaly (excessive retention, missing basis, provider with no contract).
- I can cite the content of a register row.
- My table covers 3 real processing activities.
- I fixed 1 anomaly revealed by the register.
Frequently asked questions
Must a small business really keep a register and appoint a DPO?
Tell the two apart. The register is widely recommended (and often mandatory) even for small organisations — and useful in itself: it brings order and reveals anomalies. For an SME, a simple table is enough. A DPO is only mandatory in certain targeted cases (public bodies, large-scale monitoring, large-scale sensitive data). The message: proportionality — real but light duties, neither none nor a multinational's.
Where to start without drowning?
Step by step: 1) map your processing activities (already your register under construction); 2) question each activity (purpose, basis, over-collected, over-kept) and fix; 3) secure (access, passwords, backups); 4) inform (clear notices); 5) bind providers; 6) know how to handle rights; 7) document and maintain. Prioritise risk, accept progressivity, stay proportionate, rely on your authority's guides.
What is the centrepiece of data compliance?