CNIL Practice Guide — Security of Personal Data

Published by

Commission nationale de l’informatique et des libertés (CNIL) — the French supervisory authority. We have no relationship with the CNIL and this is not an endorsement in either direction.

Type

Practice guide — 2024 edition, published 26 March 2024. 25 factsheets, 64 pages. Factsheet 1, Managing data security, stands ahead of five parts (Users · My information technology and my equipments · My control over data · Preparing for an incident · Focus). Each factsheet runs three tiers: the basic precautions, what should be avoided, and to go further. The guide closes with a factsheet-by-factsheet self-assessment of the measures (pp. 60–62), also published separately as a checklist.

Versions and language

French and English. The English PDF is marked “Version 2024”. The French PDF is marked “Version 2024*” on its title page with the footnote “*Mise à jour 2026”, and its colophon reads “Mars 2024 (mise à jour 2026)” — so the French PDF carries a 2026 update the English download does not. The 25 French factsheets are also published as individual web pages; those pages are dated March 2024, so the French PDF is the current French text. A changelog page sets out what changed between editions; as at August 2026 it itemises the March 2024 edition against the April 2023 edition and does not cover the 2026 update.

Jurisdiction

France; framed on GDPR Art. 32, which the CNIL quotes on its own page as the guide’s basis. Not binding in the UK. UK GDPR Art. 32(1) is in materially the same terms (Arts. 32(3) and 32(4) have since been amended in the UK). The operative UK yardstick is the ICO’s A guide to data security and the ICO/NCSC security outcomes — the ICO has flagged both as under review following the Data (Use and Access) Act, so check those pages for updates before you rely on them. Take the measure-level detail from here; take the legal test from the ICO.

Primary audience

The CNIL’s own list: data protection officers, chief information security officers and computer scientists, with privacy lawyers as a secondary audience. In practice: anyone who has to write, review, negotiate or evidence a schedule of technical and organisational measures.

Topic tags

security · technical and organisational measures · Art. 32 · risk analysis · cloud · artificial intelligence · APIs · mobile applications · processors and supply chain · logging · backup and continuity · incident and breach handling · encryption

Availability

Free, no registration. Both language PDFs download directly from cnil.fr; the French factsheets are readable as web pages.

Why it matters

The problem this solves is evidential rather than technical. Art. 32(1) sets an outcome — a level of security appropriate to the risk, taking account of the state of the art, the cost of implementation and the nature, scope, context and purposes of the processing — and names only four categories of measure. That is the right design, and it leaves every controller with the same difficulty: a year later, you have to show what “appropriate” meant at the time, and your own judgement is often the only record of it. A named, dated, regulator-published baseline is the cheapest way to stop that being a matter of assertion. That is what the twenty-five factsheets give you, and the three-tier structure is what makes them usable rather than aspirational — the basic precautions are the floor, “to go further” is the risk-proportionate layer you reach for when the processing warrants it, and the middle tier, what should be avoided, is the one we come across least often elsewhere. A practice the regulator has written down as one to avoid is worth more in a design review than another statement of principle.

The changelog is the second reason to know about this. Art. 32(1) makes the state of the art something you must take into account, which by definition moves, and Art. 24(1) requires you to review and update your measures where necessary and to be able to demonstrate compliance. A factsheet-by-factsheet record of what a supervisory authority changed between editions is not a legal standard and does not decide the question, but it is a dated, external reference point you can put in a review file — and it lets your annual review start from what actually changed rather than from the whole document again.

Practically, three uses. First, the measures schedule: the self-assessment at the back maps measure to factsheet, which is close to the structure an Art. 32 schedule needs anyway, and gives you a source to cite for each line rather than a set of assertions. Second, processor due diligence: Art. 28(1) requires sufficient guarantees of appropriate technical and organisational measures, and factsheet 14 (managing data processors), read with the relevant technical factsheets, gives you a questionnaire baseline with a named, dated, published source behind each line — a different conversation to have with a supplier than one built from either side’s template. Third, the parts of the estate that have moved fastest: the 2024 edition added factsheets on cloud computing, mobile applications, artificial intelligence and APIs, which is where measures schedules written before 2022 are often silent.

One boundary and one caution. The boundary: this is French guidance and it does not bind a UK controller. UK GDPR Art. 32(1) is in materially the same terms, and the ICO’s A guide to data security — with the security outcomes it publishes with the NCSC — remains the UK reference, though the ICO has flagged it as under review following the Data (Use and Access) Act. Read the CNIL guide for the measure-level detail the ICO’s outcomes deliberately leave open, not as a substitute for it. The caution: the English PDF is the March 2024 text and the French PDF carries a 2026 update, so where a point is load-bearing, check it against the current French PDF rather than the English download or the French factsheet web pages, which are dated March 2024. How much the 2026 update changed is not published, and we could not establish it — structure and length are unchanged — so treat it as a prompt to check rather than as a known divergence.

The commercial line runs both ways, and the second way is the one worth stating. A documented baseline is what lets you say yes to a project quickly and with a straight face — and the same controls are what stop the people in the dataset carrying the cost of a decision nobody wrote down. Measures that are documented, sourced and reviewed on a cadence survive a due-diligence questionnaire, a customer security review and a post-incident file with far less rework than measures that were reasonable but undocumented; and the same record is what makes a proportionate “no” defensible when a control genuinely is not warranted. None of that requires more security. It requires the same security, written down against something.

Read alongside the DSK Standard Data Protection Model, which derives measures from seven protection goals and carries its own reference-measures catalogue, and the CNIL PIA guides and software, which run the risk method and carry their own knowledge base of measures. This guide is the security-specific baseline behind them. Factsheet 24 covers the design and training of AI systems, which sits alongside the AEPD’s guidance on agentic AI from the previous issue.