The essentials in 30 seconds
- Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of measures.
- A configuration audit is not enough: you need to try to reproduce a leak.
- What convinces: a history of campaigns, dated actions and retests.
On 15 October 2025, the ICO, the UK’s data protection regulator, fined Capita £14 million (£8 million for Capita plc, £6 million for Capita Pension Solutions) after a 2023 cyber attack in which the personal data of 6.6 million people was stolen. Under Articles 5(1)(f) and 32 of the UK GDPR, it found, among other things, that a high-priority security alert was raised within ten minutes of the intrusion, but that Capita took 58 hours to respond appropriately, against a target of one hour. It is this point that strikes us most: controls existed, but they did not do what was expected of them. For a DPO, that is the whole issue behind point (1)(d).
Article 32 of the EU GDPR, whose paragraphs 1 and 2 are carried over unchanged into the UK GDPR, requires the controller and the processor to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Its point (1)(d) goes further: it requires a process for regularly testing, assessing and evaluating the effectiveness of these measures. In plain terms, you will need to show that your controls work.
In many compliance registers, point (d) remains the poor relation. You will find encryption, access management and backup. You will find far less about how anyone checks that all of this still holds 6 months later. Yet that is precisely the gap the ICO pointed to at Capita: systems processing millions of records had been penetration tested once, when they were commissioned, and never again.
204
nationally significant cyber incidents handled by the UK’s NCSC in one year, against 89 the previous year.
Source: NCSC, Annual Review 2025, period from 1 September 2024 to 31 August 2025.
GDPR Article 32: what the text actually says
Paragraph 1 of Article 32 lists, “inter alia as appropriate”, four families of 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 of 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.
Paragraph 2 specifies that the assessment of the appropriate level of security takes account of the risks presented by processing, in particular destruction, loss, alteration, unauthorised disclosure of or access to data. Unauthorised disclosure is data leakage. If your testing process ignores it, a piece is missing from your demonstration.
Why a configuration audit is not enough
A rule can be active and block nothing. An agent can be installed on your Windows workstations but out of sync. TLS inspection may exclude, for good compatibility reasons, the very domain an attacker would use. None of this is visible on an admin console. It becomes visible when you try to get data out, and that is our job. We explain this mechanism in our article on DLP false negatives and rules that fail silently.
The most defensible position, in our view, is therefore simple: for the risk of unauthorised disclosure, testing effectiveness means attempting, in a controlled way, to reproduce a leak, and observing what is blocked, detected or goes unnoticed.
Building a testing process in the spirit of point (d)
- Start from processing activities, not tools. The record of processing activities (Article 30) already lists the categories of data and their sensitivity. Use it to choose what to test first: health data, HR data, banking data, customer files.
- Define the exfiltration channels to cover. A credible process covers at least:
- outbound email (Outlook, Gmail) and attachments;
- the web, including encrypted traffic;
- removable media and the workstation;
- personal cloud storage (Dropbox, WeTransfer), collaboration tools and SaaS applications;
- less closely monitored network channels, such as DNS resolution.
- Use synthetic data. Testing with real personal data to check the protection of personal data would be self-defeating, and one more processing activity to justify. Decoys (synthetic social security numbers in a valid format, synthetic IBANs, marked documents) are designed to trigger the same rules, without using any real business data. Our article on synthetic data for testing in production explains how to build them.
- Set a frequency and triggers. “Regularly” translates into a baseline cadence suited to the scope, supplemented by tests triggered by changes: a migration to Microsoft 365, a new agent version, a proxy overhaul, the arrival of Slack or Teams. It is often after such changes that controls degrade. Upcoming versions will let you schedule periodic replays, or replays triggered by a change, depending on how critical the scope is and how fresh the evidence needs to be.
- Analyse and decide. The text strings three verbs together: test, assess, evaluate. Each campaign must therefore produce a decision: what gets fixed, in what order, and who does it. With Enforcis, each scenario ends in one of 3 states (Blocked; Detected, not blocked; Not detected), with dated, traceable results; upcoming versions will bring contextualised, prioritised recommendations, validated by retest. Someone on your team still makes the call. Without a decision behind it, you will just have one more report in a folder.
Diagram · the point (d) loop
What a DPO can show
The DPO is not there to run the tests. However, during an ICO investigation, an inspection by an EU supervisory authority or an internal audit, you are often the one presenting the file.
| Item | Insufficient | Demonstrable |
|---|---|---|
| Process | “We audit our security” | Dated document: scope, frequency, owner, success criteria |
| Scope | “DLP is deployed” | List of channels and data categories tested, linked to the record |
| Results | Generic annual report | Result per scenario: blocked, detected, not detected |
| Follow-up | Recommendations with no deadline | Prioritised actions, owners, closure dates |
| Trend | No history | Posture measured over several campaigns, with retests after fixes |
This last point matters, and Enforcis applies it. A series of measurements over time shows that the organisation is managing its security, in line with the accountability principle (Article 5(2) and Article 24). A single result, even a good one, proves little.
A concrete scenario: the mid-sized company that thought it was covered
Picture an 800-employee mid-sized services company, with a shared DPO and no dedicated CISO. Its email DLP blocks messages containing social security numbers. The record says so, and the DPO believes it. In March, the internal team’s first campaign with synthetic data confirms it for email sent from Outlook. But the same file, uploaded from the browser to a personal Dropbox (MITRE ATT&CK technique T1567.002), gets through without an alert. The DPO now has a precise finding, a priority action and, in April, a retest showing that this path is now closed for the scenario tested.
Next step
Would your point (d) process stand up to an inspection?
A 30-minute demo: a full campaign across the 8 channels we test, on our demo environment. The POC shows, on site, how the solution behaves in your environment, on one simple scenario in a synthetic environment. What actually leaves through your channels is what the pilot shows you.
Checklist for your next compliance committee
- Does the point (d) testing process exist in writing, with a named owner?
- Does it explicitly cover the risk of unauthorised disclosure?
- Do the tests use synthetic data only?
- Do the channels covered match actual usage (cloud, SaaS, browser, AI assistants such as Copilot)?
- Does each campaign lead to prioritised, dated actions?
- Do you have a history that shows a trend?
- Does an infrastructure change trigger a retest?
The same reasoning applies to other texts: for the entities concerned, NIS2 also pushes towards proof that measures work.
FAQ
What should a testing process compliant with point (1)(d) contain?
A dated document, with a named owner, a scope, a frequency and success criteria. The scope links the channels tested (Outlook, Dropbox, USB drive, DNS) to the data categories in the record. Each campaign gives a result per scenario: blocked, detected, not detected. Then come prioritised actions, with an owner and a closure date, followed by retests. That is the history you present to the ICO, or to an EU supervisory authority, in the event of an investigation.
How does the record of processing activities help you choose what to test?
The Article 30 record already lists your data categories and their sensitivity. Use it to choose what to test first: health, HR, banking data, customer files. For each category, then list the plausible exfiltration channels, from Gmail to WeTransfer by way of DNS, and build decoys in the same format, such as a synthetic UK National Insurance number or US Social Security number in a valid format. To set the cadence, see continuous validation, pentest or red team.
Is the processor also concerned?
Yes. Article 32 expressly covers both the controller and the processor, and the ICO enforces it against processors: in March 2025, it fined Advanced, a software provider processing data on behalf of NHS and social care organisations, £3.07 million after a 2022 ransomware attack (gaps in multi-factor authentication, no comprehensive vulnerability scanning, inadequate patch management). The controller has every interest in asking its processors for evidence of their own tests.
What should you take from the Capita fine for point (d)?
That the ICO looks at the effectiveness of measures as much as at their existence. In its October 2025 decision, it noted that a high-priority alert took 58 hours to receive an appropriate response, and that some systems had only been penetration tested once, when commissioned. A regular test that checks what your controls actually detect addresses exactly this kind of finding.