ISO 27001 A.8.12: Data Leakage Prevention

ISO 27001 A.8.12 requires data leakage prevention measures on the systems, networks, and devices that handle sensitive information, so that data cannot be extracted or disclosed through the channels people use to move it. It is a Technological control (A.8) and one of the controls introduced in the 2022 revision, and teams most often get flagged on the missing data classification behind the DLP tooling: a DLP engine with nothing to tell it what is sensitive blocks nothing that matters.

What is ISO 27001 A.8.12?

ISO 27001 A.8.12 Data leakage prevention governs the measures an organization applies to systems, networks, and any device that processes, stores, or transmits sensitive information, to prevent that information from leaving through unauthorized channels. ISO/IEC 27001:2022, Annex A frames the control around detecting and preventing the unauthorized disclosure and extraction of information by individuals or systems, applied where the risk to sensitive information warrants it.

A.8.12 is one of eleven controls introduced in the 2022 revision of the standard, added to address a gap the 2013 version left open around deliberate and accidental data exfiltration. In practice the control covers the channels through which data leaves: email, web uploads, removable media, cloud sync, and endpoints, and the measures that watch and restrict those channels. The control is deliberately risk-driven and technology-neutral. It does not name a DLP product or require inspecting every byte. It asks that data leakage measures are deliberate, aimed at the information the organization has judged sensitive, and maintained rather than switched on once and left to run blind.

How do you implement A.8.12?

Implementing A.8.12 starts with classification and works outward to the channels, because a data leakage prevention control is only as good as the definition of what it is protecting:

1. Classify sensitive data first. Define the data classes that matter (customer data, source code, credentials, regulated PII, financial records) and label or tag them so a DLP engine has something to match on. This step is the foundation of A.8.12. A DLP deployment with no classification scheme behind it inspects traffic against nothing and produces noise instead of protection.
2. Identify the egress channels. Map every path sensitive data can take out of the environment: outbound email, web and browser uploads, USB and removable media, cloud storage sync (personal Google Drive, Dropbox, OneDrive), collaboration tools, and endpoint copy or print. The channels you do not map are the channels DLP does not cover.
3. Apply DLP policies to each channel. Configure detection and enforcement on the mapped channels: block or quarantine sensitive data leaving over email, restrict uploads to unsanctioned destinations, control USB write access, and inspect cloud sync. Start in monitor mode, then move high-confidence rules to block once the false-positive rate is understood.
4. Monitor, alert, and respond. Route DLP events to a queue someone reviews, with a defined response for a confirmed leak. An alert nobody triages is the same as no control, and it is the part auditors probe hardest.
5. Tune to cut false positives. DLP that fires on every message trains people to ignore it. Tune rules against real traffic, whitelist legitimate business flows, and adjust confidence thresholds so alerts stay credible and enforcement stays trusted.
6. Combine with encryption and access restriction. DLP is one layer. Pair it with encryption so intercepted data stays unreadable, covered by A.8.24 use of cryptography, and with access restriction so fewer identities can reach sensitive data in the first place. The three controls reinforce each other.

Steps 2, 3, and 4 implement meaningfully differently in cloud and on-prem environments. The two subsections below cover each.

In cloud environments

Cloud environments implement A.8.12 through the native DLP and data-protection services in the productivity and cloud platforms already in use, configured deliberately and evidenced through policy exports and event logs:

• Email DLP in Google Workspace or Microsoft Purview inspects outbound mail for classified content and blocks, quarantines, or encrypts messages that match a sensitive-data rule.
• A CASB (cloud access security broker) discovers and controls data moving to sanctioned and unsanctioned cloud applications, and is the primary control over shadow cloud sync.
• Cloud-native DLP (Microsoft Purview, Google Sensitive Data Protection, Amazon Macie) classifies and monitors data in the platform's own storage, mail, and collaboration surfaces, and produces the classification-to-policy linkage A.8.12 turns on.
• Endpoint DLP delivered through the same suite extends coverage to managed devices for copy, print, and removable-media actions without a separate agent stack.
• Tenant restrictions and upload controls limit which external destinations users can send data to from a managed browser or the corporate network.

On-prem / self-hosted

On-prem environments implement A.8.12 with the same outcomes through agents and network appliances the team runs itself. The SOC 2 data protection on-prem guide covers the data-handling and removable-media territory in depth; the shape is:

• Endpoint DLP agents on workstations and servers watch file operations, clipboard, print, and removable-media writes against the classification scheme, and log or block policy violations locally.
• Network DLP appliances inspect outbound traffic at the perimeter for classified content leaving over email, web, and file transfer, complementing the endpoint agents.
• USB and removable-media control through device-control policy restricts or read-only-locks removable storage, with hardware-encrypted drives and a media handling procedure for the writes that are permitted.
• A self-hosted classification and tagging scheme applied to file shares and databases gives the on-prem agents and appliances the same sensitivity signal a cloud DLP service derives from managed content.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.12?

Evidence for A.8.12 is paired: the classification scheme and DLP configuration showing the control exists, plus the alert and response records showing it operates. Many teams collect the policy exports and alert logs through an automated evidence pipeline, the approach covered in GRC engineering, so the operating record builds up between audits without manual export runs.

How does A.8.12 map to SOC 2?

A.8.12 is a Partial overlap with SOC 2 CC6.7. SOC 2 has no dedicated data leakage prevention criterion, so the overlap runs through CC6.7's Restricts the Ability to Perform Transmission Point of Focus, which names data loss prevention processes and technologies as one way to restrict who can transmit, move, or remove information. An organization with an existing SOC 2 program can reuse that evidence toward A.8.12, but the ISO control expects the classification-to-channel coverage to be documented more explicitly than CC6.7 requires on its own.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including how much of an existing SOC 2 program transfers. Because A.8.12 is a Partial map, plan to extend the CC6.7 evidence with an explicit classification scheme and per-channel DLP coverage rather than assume the SOC 2 record satisfies the ISO control unchanged.

Related controls

A.8.12 belongs with the other data-handling controls the 2022 revision added to the Technological theme. A.8.10 information deletion governs removing data that is no longer needed, reducing what DLP has to protect in the first place, and A.8.11 data masking limits exposure of sensitive fields in non-production environments so there is less classified data to leak. A.5.34 privacy and protection of PII is a frequent driver of the classification decisions A.8.12 depends on, and A.8.24 use of cryptography provides the encryption that keeps leaked data unreadable. All fall within the framework covered by the ISO 27001 certification guide.

Part of Truvo's control-by-control ISO 27001:2022 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you want a second set of eyes on how data leakage prevention and its classification foundation are designed and evidenced as part of an effective security program, Truvo runs scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.12?

ISO 27001 A.8.12 is the Annex A control titled Data leakage prevention, in the Technological theme of ISO/IEC 27001:2022. It requires data leakage prevention measures on the systems, networks, and devices that handle sensitive information, to detect and prevent unauthorized disclosure or extraction of that information. It covers the egress channels data leaves through, including email, web uploads, removable media, cloud sync, and endpoints, applied where the risk to sensitive data warrants it.

What evidence satisfies A.8.12?

A.8.12 evidence is paired: the artifacts showing the control exists plus the records showing it operates. Auditors expect a data classification scheme and labelling records, a DLP policy and per-channel configuration export, egress-channel control configuration for email, USB, web, and cloud sync, DLP alert and incident response logs, and tuning records. The classification scheme is the artifact most teams are missing, and it is what demonstrates the DLP is protecting defined sensitive data rather than running blind.

Is A.8.12 new in ISO 27001:2022?

Yes. Data leakage prevention is one of eleven controls introduced in the 2022 revision of the standard. The 2013 version had no dedicated DLP control, and A.8.12 was added to address deliberate and accidental data exfiltration through channels such as email, web uploads, cloud sync, and removable media. Because it is new, teams migrating from the 2013 version usually have to build this control rather than remap existing evidence.

Why does data classification come before DLP in A.8.12?

A DLP engine can only block what it can recognize as sensitive, and that recognition comes from a classification scheme. Without defined data classes and labels, DLP policies match on generic patterns or nothing, producing noise instead of protection. A.8.12 implementations that start by classifying customer data, source code, credentials, and regulated PII give the tooling a precise signal, which is why classification is the first implementation step and the evidence auditors ask for first.

How do you implement A.8.12 in the cloud versus on-prem?

Cloud implementations use the productivity suite's native services: email DLP in Google Workspace or Microsoft Purview, a CASB for cloud sync and shadow IT, cloud-native DLP for classification, and suite-delivered endpoint DLP. On-prem implementations reach the same outcomes with endpoint DLP agents on managed devices, network DLP appliances at the perimeter, USB and removable-media device control, and a self-hosted classification and tagging scheme on file shares and databases. The channels covered are the same; the tooling and the evidence look different.

How does A.8.12 map to SOC 2 CC6.7?

A.8.12 maps to SOC 2 CC6.7 as a Partial overlap. SOC 2 has no dedicated DLP criterion, so the overlap runs through CC6.7's Restricts the Ability to Perform Transmission Point of Focus, which names data loss prevention as one way to control who can transmit, move, or remove information. Evidence produced for CC6.7, including the DLP policy, configuration, and alert logs, is reusable toward A.8.12, but the ISO control expects the classification and per-channel coverage documented more explicitly, so plan to extend rather than reuse unchanged.