← All articles

ARTICLE · DATA LEAK ACTIVE TESTING

ISO 27001 control 8.12: proving data leakage prevention

  • Compliance
  • 6 min read
  • Updated
Padlock on a grid of glowing blue and purple blocks, an image of a set of security controlsA dated test record, not a screenshot

The essentials in 30 seconds

  • Control 8.12 requires data leakage prevention measures, without prescribing a product.
  • Screenshots and rule exports show that measures exist, not that they work.
  • The strongest evidence: dated test records, per channel, using synthetic data, followed by corrective actions.

Your ISO 27001 audit is in April, 6 months from now. On the day, the auditor will open your statement of applicability, stop at control 8.12 and ask you a simple question: “How do you know it works?” If your answer comes down to three console screenshots, those 6 months are your chance to change that.

Control 8.12 in Annex A of ISO/IEC 27001:2022, entitled “data leakage prevention”, requires data leakage prevention measures to be applied to systems, networks and devices that process, store or transmit sensitive information. The auditor does not stop at “do you have DLP?”. They want to know whether you can demonstrate that it works, and the best evidence is still a dated, reproducible test record followed by corrective actions.

What ISO 27001 control 8.12 says

Control 8.12 is one of the controls introduced in the 2022 revision, which reorganised Annex A into four themes (organisational, people, physical, technological). It sits in the technological theme. Its spirit, as we read it, is simple: identify the information to protect, monitor the channels through which it can leave, and act to prevent or detect its unauthorised disclosure.

The standard and its implementation guidance (ISO/IEC 27002:2022) invite you to consider several dimensions:

  • identifying and classifying sensitive information, which links directly to control 5.12 on classification;
  • monitoring exfiltration channels: email, file transfers, removable media, cloud services, the browser;
  • preventive actions: blocking, quarantine, alerting;
  • the balance with employee privacy and applicable law: in the UK, the UK GDPR, the Data Protection Act 2018 and employment law (the ICO publishes specific guidance on monitoring workers); in the EU, the GDPR and national employment law.

An auditor will not hold the absence of a specific tool against you. They will, however, raise a control declared in the statement of applicability with no tangible element showing that it is effective.

Why configuration is not enough as evidence

In practice, many organisations arrive at the audit with screenshots of DLP rules, a classification policy and a console export. That is the baseline. But nothing in there shows that a file was actually stopped.

A rule can be active and block nothing. A connector can have lost its coverage after an update. A channel may never have been covered at all. These DLP false negatives make no noise: no alert flags what was not detected. Clause 9.1 of the standard, on monitoring, measurement, analysis and evaluation, requires you to determine how you evaluate the effectiveness of the management system. For 8.12, in our view, that means testing.

The evidence an auditor expects to find

In the table below, we separate what declares from what demonstrates. You will need both, but only the latter answers the question of effectiveness.

Type of evidence Examples What it demonstrates
Policy Data leakage prevention policy, classification rules Intent and scope
Configuration Export of DLP rules, email filters, egress controls That measures exist
Logs Alerts, blocks, incidents handled That the tool reacts to certain real events
Test records Results of replayed attack scenarios, dated, per channel That the measures block or detect what they should, on the scenarios tested
Action plan Gaps found, priority, owner, fix date, retest Continual improvement (clause 10)

Building admissible test records

A test record that is useful in an audit answers five questions: what, through which path, when, with what result, and what you did next. Here is how to build one.

Diagram · an admissible record

An admissible test record for control 8.12: five questionsTest record sheet. What: the type of synthetic data. Which path: the channel and the expected control. When: the date and the time to detection. Result: blocked, detected but not blocked, or not detected. Next: the action, the owner and the retest.TEST RECORD · CONTROL 8.12What?Which path?When?Result?Next?Type of synthetic dataChannel and expected controlDate and time to detectionAction, owner, retestBlockedDetected, not blockedNot detected

Five questions, one consistent format from one campaign to the next.
  1. Map the exfiltration channels. List the paths through which data can leave the organisation: outbound email, HTTPS web traffic, DNS, personal cloud storage such as Dropbox or WeTransfer, Teams or Slack, USB devices, SaaS applications, prompts to Copilot or another AI assistant. This list becomes your coverage matrix. For each channel, note the control that is supposed to act (endpoint DLP, proxy, CASB, email gateway).
  2. Use synthetic data. Testing with real sensitive data creates the very risk you are trying to avoid. Synthetic data that mimics real patterns (numbers in the right format, documents marked with your classification labels, for example “Confidential” in Microsoft Purview™) lets you test in production without using any real business data. Your DPO will appreciate it.
  3. Replay the same scenarios over time. A one-off test proves the state of a single day. Regularly replaying the same scenarios shows a posture over time, and catches regressions after an update, a migration or a rule change. 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. To position these approaches, see the comparison of continuous validation, pentest and red team.
  4. Record the result for each scenario. For each scenario: date, channel, type of synthetic data, expected control, observed result (blocked, detected but not blocked, not detected), and time to detection on the SOC side where relevant. Enforcis gives a dated, traceable reading of each scenario in 3 states (Blocked; Detected, not blocked; Not detected). Upcoming versions will bring multi-level reporting (leadership, CISO, operations), with MITRE ATT&CK mappings and, where the correspondence is established, MITRE D3FEND, as well as SIEM integrations.
  5. Link every gap to an action. An unaddressed gap weakens the file. A gap that is ranked, assigned to someone and then retested strengthens it: it shows that the management system is running. This is what clause 10 on improvement expects.

A concrete scenario: the surveillance audit

Picture a manufacturer, certified since 2024, preparing for its surveillance audit. The auditor samples control 8.12. The CISO presents the policy, the export of the Purview rules and 3 months of scenarios replayed across 6 channels.

The results show that email correctly blocks attachments labelled “confidential”. However, uploads to personal cloud storage from an unmanaged browser went through without an alert for 4 weeks, between June and July. The file contains the fix ticket, the added rule and the successful retest.

The auditor does not raise a nonconformity. What they have in front of them is a control that is monitored and corrected. Without these records, the blind spot would have stayed invisible, and you would have been discussing screenshots.

Next step

Does your 8.12 file contain test records?

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.

8.12 checklist before the audit

  • Control 8.12 appears in the statement of applicability, with its justification.
  • Sensitive information is classified and the labels are used by the tools.
  • A channels / controls matrix exists and is up to date.
  • Tests have been run on every channel in the matrix, using synthetic data.
  • Your results are dated, retained and follow the same format.
  • Every gap has a priority, an owner, a deadline and a retest.
  • Tracking metrics are presented to top management at the management review.
  • The DPO has approved the safeguards around monitoring with regard to privacy.

Control 8.12 overlaps with other requirements. If the European directive also applies to you, our article on NIS2 and evidence of protection measures shows how to reuse the same records. For the overall framework, see the reference page on data exfiltration testing.

FAQ

Does control 8.12 require you to buy a DLP solution?

No. The standard requires measures appropriate to the risks, not a product. Native email, proxy or endpoint controls may be enough, provided you can demonstrate their effectiveness.

Can control 8.12 be excluded from the statement of applicability?

An exclusion is possible if it is justified by the risk assessment. For an organisation that processes personal data or trade secrets, that justification will be hard to defend.

What is the link between control 8.12 and control 5.12?

Control 5.12 covers the classification of information. Control 8.12 builds on it: without reliable labels or categories, your prevention rules do not know what to protect. In an audit, we recommend presenting the two together.

Can test results also be used for clause 9.1?

Yes. Clause 9.1 asks you to determine what is monitored and measured, and how. Dated test results, per channel, measure the effectiveness of control 8.12: you can include them in your metrics and present them at the management review (clause 9.3).

How your egress controls actually behave, observed scenario by scenario.

With synthetic payloads, we run controlled campaigns on the configured paths and observe how your controls actually behave, scenario by scenario.