GDPR Article 32: The Technical Measures You Can Actually Evidence

Article 32 is the only article in the GDPR that asks for outcomes rather than paperwork, and it is the one most organisations answer with a checklist. The text does not give you a list of controls to install. It gives you four examples, a risk test, and an obligation to keep testing whether any of it works. That is a harder ask than it sounds, because "appropriate to the risk" cannot be satisfied by asserting that you did something. It has to be demonstrated with an artefact that names a system, a date and a result. This guide is about the decision procedure Article 32 actually requires, the evidence an assessor will ask for and you probably cannot produce today, the parts of encryption that auditors pull on first, and the arithmetic that connects your log retention to the seventy-two-hour clock in Article 33.

What the article actually says, before anyone paraphrases it

Article 32(1) requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account four things: the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk of varying likelihood and severity for the rights and freedoms of natural persons. It then lists, "including inter alia as appropriate", four measures:

• (a) the pseudonymisation and encryption of personal data;
• (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
• (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
• (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

Four words in that sentence carry the whole obligation. Inter alia means the list is not exhaustive, so "we did all four" is not a defence. As appropriate means each measure is conditional on the risk assessment. Ongoing in (b) rules out a point-in-time project. And regularly in (d) rules out the one penetration test you ran for a customer's security questionnaire in 2023.

Paragraph 2 names the threat classes the assessment must consider: accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. Note what is absent from that list - there is nothing about attackers specifically. A misconfigured backup job that overwrites a table is inside the scope of Article 32 exactly as much as a ransomware crew is, and an organisation that has built its whole security story around external attackers has answered half the paragraph.

Paragraph 3 says adherence to an approved code of conduct under Article 40 or a certification mechanism under Article 42 may be used as an element by which to demonstrate compliance. That word "element" is doing real work. A certificate is evidence of a process; it is not a defence that the measures were appropriate to your risk. The supervisory authority will still ask what you did about the specific data you hold. Paragraph 4 is the one everybody skips: you must ensure that anyone acting under your authority who has access to personal data does not process it except on your instructions. Your own administrators are in scope, which makes privileged access a compliance question and not only an operational one.

"Appropriate to the risk" is a decision procedure, not an adjective

Every organisation says its measures are appropriate. Almost none can show the reasoning that produced the choice, which is the actual deliverable. The procedure that survives an assessor's question - why this control and not a stronger one - has four steps, and all four have to be written down before the answer is needed, not reconstructed afterwards.

1. Classify the data, not the system

Article 32 attaches to personal data, so the unit of analysis is a data set with a classification, not a server with a label. A workable four-band scheme:

The classification has a second use that most schemes miss: it makes aggregation visible. A table of Band 3 fields is unremarkable. The same table joined to a marketing preference and a location history becomes a profile of a person's movements, which belongs in Band 2 in effect even though no field in it does. Assessors find this argument persuasive in both directions - they will accept a lower measure set for genuinely Band 3 data, and they will reject a Band 3 label on what is functionally a profile.

2. State the risk in the terms paragraph 2 uses

For each data set, four questions with a written answer: what would destruction look like here, what would loss look like, what would unauthorised alteration break, and who could disclose or access it. The value of writing it in those four words is that the answers point at different controls. Destruction and loss are availability problems answered by backup and restore testing. Alteration is an integrity problem answered by access control, change logging and checksums. Disclosure and access are confidentiality problems answered by encryption, minimisation and monitoring. A risk register organised by "high / medium / low" collapses all four into one word and therefore drives one control.

3. Choose the measure set and record the reasoning at the time

This is where the file that saves you gets created: one row per data set, with the measures selected, the measures rejected and the reason, the residual risk, the owner and the date. "We chose not to encrypt this column because the application queries it on every page load without an index on the token, the measured latency penalty was 40 ms at p95 against a 120 ms budget, and the record is Band 3 with no financial identifier" is a defensible sentence. "We follow best practice" is not, because the moment the question is asked, the best practice of the day is whatever the assessor read last week.

4. Put a re-baselining date against every row

"State of the art" is a moving reference, which means an Article 32 decision expires. TLS 1.0 was defensible in 2014 and is a finding in 2026. Password hashing with a fast general-purpose hash was defensible once and is now a documented failure. Write the review date into the register - annual for Band 1 and 2, biennial for Band 3 - and treat the review itself as a control that can fail. An organisation with a 2022 register and no review date has a document, not a process.

The evidence problem: a measure nobody can produce is a measure that does not exist

The failure mode in nearly every audit is not a missing control. It is a control that exists and cannot be shown. The firewall rule is in place, the backup runs, the access review happened - and nobody can produce a dated artefact proving it, so the assessor records an absence and the organisation spends three weeks reconstructing history from memory. Five artefact types cover almost everything Article 32 asks for:

• Configuration export with a date and a system name. Not a screenshot of a policy page; the actual setting, from the actual account, with the export timestamp visible.
• Log sample. A real query result from the log platform showing the events the control claims to generate, for a named user, on a named day.
• Timed test result. Start time, end time, method, outcome, and who ran it. "Restore tested" is not an artefact; "restored the orders database to 14:32 on 12 September in 3 h 40 m, row count matched within 0.02%, integrity check passed" is.
• Signed approval. For every deliberate exception, with a name and a date and an expiry. Exceptions are normal; undocumented exceptions are findings.
• Ticket history. The unglamorous one that closes most gaps, because it shows the control operates continuously rather than having been switched on the week before the audit.

Two rules make this sustainable. First, the artefact collection runs on a calendar with an owner, not on demand, because on-demand collection is always late and always filtered. Second, the artefact must be readable by someone who does not work in your environment: a configuration export with no system name, or a log sample with internal hostnames and no legend, is evidence to you and noise to an assessor.

Encryption: the part assessors pull on is the key, not the algorithm

Article 32(1)(a) names encryption, and almost every organisation ticks it. The question that follows is not which cipher. It is who holds the key, and what an operator with database access can read.

Three tests separate a real encryption control from a ticked box. First, key separation: if the key is stored in the same account, the same backup set or the same repository as the ciphertext, then a single compromise yields both, and the control has protected you against exactly one threat - a stolen disk - which is rarely the threat that materialises. Second, the insider test: can a database administrator, or anyone who can run a query, read a Band 1 field without a second approval? If yes, the encryption is at the storage layer only, and your privileged access control is carrying the entire confidentiality obligation. Third, field-level decisions: full-disk and volume encryption protect against physical loss; they do nothing about an application vulnerability that returns rows, which is the mechanism in most of the breach reports you have read. Encrypting the specific identifiers that make a record personal - national ID, payment token, health marker - is what changes the blast radius of an injection flaw.

Two operational consequences follow that rarely appear in compliance guidance. Crypto-agility: you need to know, in advance, which algorithm and key length each store uses, where the key lives, how rotation works, and how long re-encryption of the archive would take. An organisation that has never rotated a key discovers during an incident that rotation is a six-month project. Crypto-shredding: destroying the key is a legitimate way to make data unreadable at end of life, and it stops working the moment the key is shared across tenants, datasets or backup generations. If you plan to rely on it for deletion obligations, the key hierarchy has to be per-subject or per-dataset from the start, and retrofitting it is not a configuration change.

Backups inherit both the encryption and the problem. An encrypted backup whose key is escrowed in the same vault as the production key is encrypted in the way a locked door with the key taped to it is locked. And a restore test that has never been timed is not evidence under 32(1)(c), which is the next but one section.

Pseudonymisation, and the threshold that changes your obligations

Pseudonymisation is the first measure named in Article 32(1)(a), ahead of encryption, and it is the one most often confused with anonymisation. The legal position is settled: pseudonymised data remains personal data, because the link between the pseudonym and the individual exists somewhere and can be re-established. Recital 26 ties the test to the means reasonably likely to be used by the controller or another person, and the practical version of that test is three questions about the data you actually hold.

• Is the linkage table in the same environment? A hashed customer ID with the mapping stored in the same warehouse is a pseudonym with a lookup table one join away.
• Do the remaining fields re-identify by combination? Postcode, birth month, sex and a purchase date are enough to single out a large share of a population in most national statistics. Remove the identifier and you have removed the easy join, not the identification.
• Is the population small enough that a single attribute is unique? In a table of 400 employees, department plus tenure plus salary band identifies individuals without any name field at all.

Pseudonymisation is still worth doing, and Article 32 is explicit that it is a security measure rather than a way out of the regulation. It reduces the population that can read the data usefully, it lowers the risk classification of a test environment, and under Article 83(2)(d) the measures you implemented under Articles 25 and 32 are an explicit mitigating factor when a fine is calculated. What it does not do is take the dataset outside the GDPR, and a data protection impact assessment built on the assumption that it does will not survive contact with a supervisory authority.

Access control you can evidence, rather than assert

Article 32(4) makes this a legal obligation rather than an operational preference: anyone acting under your authority must process personal data only on your instructions. That is a statement about the behaviour of insiders, and the controls that evidence it are unglamorous.

Least privilege is a process, not a policy. The number that matters is not how many roles you defined. It is how many accounts hold access that no current task requires, and how you know. A quarterly review that a line manager signs in eleven minutes for forty accounts is not a control; it is a record of a signature. Reviews that work are small, differential and evidenced: here are the accounts whose access changed since last quarter, here is what each one used, here is the access removed and by whom.

The joiner-mover-leaver arithmetic. An organisation of 150 people with two joiners and two leavers a month generates 48 identity events a year, and each event touches an average of three to five systems in a typical mid-market estate - say 200 access changes annually. Every one is an opportunity for residual access: the leaver whose VPN account survives, the mover who keeps the old department's shared mailbox, the contractor whose account was disabled but whose API token was not. The control that catches these is a reconciliation between the HR system of record and the identity provider, run monthly, with the exceptions listed and closed. That reconciliation is the artefact.

Privileged and non-human accounts. Your privileged account census should be reviewable in one screen: named humans with administrative rights, the break-glass accounts, the service accounts and what each one can reach. Service accounts are where this falls apart, because they accumulate permissions, rarely have an owner, and usually outlive the application that needed them. An unowned service account with read access to a Band 1 table is precisely the insider risk Article 32(4) is aimed at, and it will not appear in any joiner-mover-leaver process.

MFA, and which kind. The distinction that matters in 2026 is phishing-resistant versus phishable. Push notifications and SMS codes are defeated by real-time relay; passkeys and hardware-backed credentials are not. If your Band 1 administrative access is protected by a phishable factor, the honest register entry says so, with the compensating control and the migration date.

Logging: the measure that decides whether Articles 33 and 34 are possible at all

Article 32(1)(b) requires confidentiality, integrity, availability and resilience, and none of those can be demonstrated without records of who did what. But logging earns its place in this article for a second reason that compliance pages rarely connect: Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a breach, and the notification has to describe the nature of the breach, the categories and approximate number of data subjects and records concerned. You cannot write that sentence from perimeter logs. You write it from access logs on the data store.

That produces two pieces of arithmetic worth doing before your next audit.

The most common finding here is not a missing log. It is an access log with no reader and a retention period chosen by a storage budget rather than by the detection arithmetic. The fix is not exotic: forward the events that matter into storage you control, set the retention from your measured detection time, and write the number into the register next to the data set it protects.

Resilience and restore: 32(1)(c) is a timed test, not a backup policy

Paragraph 1(c) asks for the ability to restore availability and access to personal data in a timely manner after a physical or technical incident. "Ability" and "timely" are both testable, and both are usually untested. A backup job that reports success tells you that bytes were written. It does not tell you that the data can be read, that the application can start against it, or how long either takes.

What the evidence looks like: a restore performed on a named system, into an isolated environment, timed end to end, with an integrity check on the result, signed by the person who ran it, on a date inside the last twelve months. Add the number that actually matters to the business - the interval between incident and restored service, not between incident and restored file. For a Band 1 system, run it twice a year, and include the case that hurts: the complete loss of the primary environment, not a single deleted record.

Three things go wrong often enough to plan for. Immutability: if the backup target is writable by the credentials an attacker has, the backup is inside the blast radius, which is why ransomware operators delete shadow copies first. Restore integrity: restoring a database that fails its own consistency checks is a discovery best made in a test window. Dependency restore: the database comes back in forty minutes and the service stays down for a day because the secrets, certificates or configuration that the application needs were never in the backup set. Test the service, not the artefact.

Article 32(1)(d): what counts as a test, and how often

"A process for regularly testing, assessing and evaluating the effectiveness" is a higher bar than most programmes meet, because an automated scan is not a test of effectiveness. A scanner proves that certain known patterns were absent from the response at a point in time. It does not prove that a user cannot read another user's invoice, that a refund cannot be issued twice, that an administrator cannot export the table they are not supposed to see. Those require a human with two accounts and a hypothesis.

If you need outside testers, the scope and authorisation have to be in writing before anyone touches a system - our penetration testing practice and the penetration testing guide both start from that, and a secure code review is often the cheaper way to test the authorisation logic that a black-box test can only sample. Where the estate is mostly cloud, a cloud security assessment covers the configuration half that scanning misses.

Article 28 flow-down: your processor's Article 32 posture is your exposure

Article 28(1) requires a controller to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures, and Article 32(1) applies to processors directly. In practice this means your Article 32 file is incomplete without the evidence of everyone who touches the data, and that most organisations hold a signed data processing agreement and nothing else.

Six clauses decide whether the agreement is worth the paper. The sub-processor list with a change-notification window - because a processor that can add a sub-processor without telling you has moved your data somewhere you have not assessed. A breach notification window shorter than 72 hours: ask for 24, because your clock started when you became aware and the processor's clock is not yours. Audit rights that produce artefacts, not an annual summary email. Deletion and return on termination, with the backup residue addressed - the standard clause is silent on the copies that live for another ninety days. The transfer mechanism and its assessment. And the one question that reveals most: what evidence will you give me annually, unprompted? If the answer is a trust-centre URL that has not changed in two years, you have a marketing page, not a control.

Then hold it to the same logic you apply to yourself. A processor's SOC 2 report covers their processes and their scope, and your data may sit in a region, a product or a support path outside that scope. The scope note is the part to read, and it is the part that is usually a footnote.

The fine arithmetic: Article 32 sits in the lower tier, which is not the comfort it sounds like

Almost every commercial page implies that a security failure carries the headline number. Read Article 83 and the structure is explicit. Paragraph 4 sets fines of up to 10 million euro, or 2 per cent of total worldwide annual turnover, whichever is higher, for infringements of the obligations in Articles 25 to 39 - and Article 32 is in that range. Paragraph 5 reserves 20 million euro or 4 per cent for the basic principles and lawful bases in Articles 5, 6, 7 and 9, data subject rights under Articles 12 to 22, and transfers under Articles 44 to 49.

So a pure Article 32 failure is a 2 per cent matter, and the 4 per cent headlines you remember are mostly transfers or principles: the Irish regulator's 1.2 billion euro decision against Meta in May 2023 concerned international transfers, not security of processing. That distinction cuts both ways, and the second way is the one that matters operationally.

• A security failure rarely stays an Article 32 failure. A breach usually also engages Article 5(1)(f), integrity and confidentiality, which is in the 4 per cent band, and often Article 33 if notification was late.
• Paragraph 2 decides the number. Article 83(2)(d) makes the technical and organisational measures you implemented under Articles 25 and 32 an explicit mitigating factor, and 83(2)(a) counts the number of data subjects affected. The same breach is a different fine depending on what you can show you had done.
• The corrective powers cost more than the fine. Article 58(2) lets a supervisory authority order compliance, impose a temporary or definitive limitation on processing, or suspend data flows. For a company whose product is data processing, a processing ban is the existential outcome and the fine is the line item next to it.
• Article 82 compensation runs separately, claim by claim, and does not need a supervisory decision first.

Which produces the practical conclusion: the reason to build an evidence file is not the theoretical maximum. It is that you will be arguing about 83(2) factors in a room where the only thing that helps is a dated artefact, and that the difference between a documented measure set and an undocumented one is the difference between negligence and a control that failed.

Where GDPR stops and NIS2 and DORA start

If you are in scope for the newer EU regimes, Article 32 is not the only measure set you owe, and the three overlap enough that building three programmes is a waste. NIS2, Directive (EU) 2022/2555, required transposition by 17 October 2024 and sets ten minimum measure areas in Article 21(2): risk-analysis policies, incident handling, business continuity and backup management, supply chain security, security in acquisition and development including vulnerability handling, policies to assess effectiveness, cyber hygiene and training, cryptography policy, human resources security and access control, and multi-factor authentication and secured communications. Implementing Regulation (EU) 2024/2690 applies directly to cloud, data centre, managed service and managed security providers from 7 November 2024, so for those providers the technical requirements bind regardless of national delays.

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to banks, insurers, asset managers, payment institutions and crypto-asset service providers. It is a regulation rather than a directive, so it binds identically in every member state, and it adds two obligations that GDPR and NIS2 do not have in the same form: a register of every ICT third-party contractual arrangement, and advanced testing including threat-led penetration testing for significant entities.

The efficient structure is one control set with three evidence mappings, because the overlap is large: access control, cryptography, logging, backup and restore, supply chain and testing appear in all three. What differs is the reporting clock - 72 hours under GDPR Article 33, an early warning within 24 hours plus a notification within 72 under NIS2 Article 23, and the DORA incident-reporting timelines with their own initial-notification window - and the governance artefacts. Build the control once, map the evidence three ways, and keep one incident timeline that satisfies the shortest clock.

Nine failure modes that show up in audit after audit

1. No data inventory, therefore no scope. The assessment is built on the systems people remembered. Band 1 data in a marketing tool, a support desk or a spreadsheet is outside every control you designed.
2. Encrypted, with the key beside the ciphertext. The control exists on paper and protects against one threat.
3. Retention shorter than detection time. The logs needed for the Article 33 notification expire before anyone knows there is a notification to write.
4. Testing that is a scan. Quarterly scanner output filed as evidence of 32(1)(d), with no authorisation test, no restore test and no control test.
5. A DPA with no sub-processor list and no notification window. Your data has moved and the agreement permits it.
6. Restore never timed. Backups verified by a job status, not by a restore into a clean environment.
7. Access reviews signed, not performed. The artefact proves a signature and nothing about access.
8. No DPIA on the processing that needed one. Article 35 is a separate obligation, and its absence is usually read as evidence that the risk assessment behind Article 32 was shallow too.
9. Processor evidence collected once. A PDF from 2023 accepted as the current state of a vendor's controls.

A ninety-day build order

For an organisation starting from a policy and a folder of screenshots, this sequence produces the most defensible file per week of effort.

Ninety days is realistic for a mid-market estate only if the inventory step is done properly and the rest is scoped to Band 1 and Band 2. Trying to cover everything in one pass is how organisations end up with a beautiful register for the systems nobody worried about and nothing for the database that holds the customer records.

The short version

Article 32 asks for a level of security appropriate to the risk, evidenced, and tested regularly. The four lettered measures are examples, not a checklist, and "as appropriate" makes each one conditional on an assessment you have to be able to show. Classify the data, state the risk in the terms paragraph 2 uses, record which measures you chose and which you rejected and why, and put a review date against the row so the "state of the art" clause cannot quietly expire. Encrypt where it changes the blast radius, and treat key separation - not the cipher - as the control an auditor will test. Pseudonymise, but do not pretend it is anonymisation. Log the data stores, not just the perimeter, and set retention from your detection time rather than your storage budget. Prove 32(1)(c) with a timed restore and 32(1)(d) with tests that assert authorisation rather than merely scanning. Read your processors' scope notes, and ask what evidence arrives without being requested. Then keep the artefacts on a calendar, because the argument you will actually have is about Article 83(2) factors, and in that argument the only thing that helps is a dated document with a system name on it.

If you want the technical half built and evidenced rather than described - the testing programme, the encryption design, the logging and the restore discipline - that is what our penetration testing, vulnerability assessment, security hardening and web security audit engagements produce, and the incident response plan guide covers the ninety-six hours after the control fails. You can ask for a scoping call without committing to anything, and the Italian treatment of this topic is at compliance sicurezza GDPR, PCI-DSS e ISO 27001.