ISO 27001 A.8.12: Prevent sensitive information leaving without authority

What A.8.12 requires in practice

A.8.12 asks for data leakage prevention measures on systems, networks and every other device that handles sensitive information, whether it processes, stores or transmits it. Leakage means sensitive information leaving the organisation, or reaching people who should not have it, through an unauthorised or unintended route.

In practice the organisation identifies which information is sensitive, the routes it could take out, such as email, uploads, removable media, printing, messaging and personal cloud storage, and what measures suit each route. Measures can be technical, procedural or based on awareness. They should cover the whole environment named in the control, not only one channel. The organisation also needs to decide how potential leakage is detected and what happens next.

Outputs include a defined scope of sensitive information, measures matched to routes and evidence that they work. The control does not require a particular product, and tools have limits; no tool detects every disclosure. One way Sterling's teams organise this is to start from the information and its legitimate flows, rather than from a tool.

Define the information and the transfer

Begin with information that would cause harm if disclosed without authority. Customer records, confidential designs and commercial proposals need different recognition methods and handling rules. Connect the decisions with information classification so technical rules reflect a business understanding of sensitivity.

Map relevant routes such as email, file sharing, downloads and portable storage. Identify who may send which information to which recipients and for what purpose. A rule that detects a sensitive pattern cannot by itself determine every legitimate business context. Ownership and an appropriate approval route remain necessary.

Choose an action that fits the risk

A control may warn the user, hold a transfer for review or block it. Select behaviour according to the information, destination and consequence of delay or disclosure. Explain what the user should do next. An unexplained block can encourage a different, uncontrolled transfer route rather than solve the underlying need.

Set responsibility for reviewing alerts and exceptions. Consider how authorised exports should be approved and how the decision is recorded. Limit who can override a rule and review recurring exceptions: they may reveal an unsuitable rule, an unmet business requirement or a process that is drifting away from the intended protection.

Why preventing data leakage matters to the business

Disclosure of sensitive information is often accidental: a message to the wrong recipient, a file shared too widely or a document taken home on a personal device. The consequences can include breach notification, contract penalties, loss of a client and damage to reputation that outlasts the incident. Clients who share confidential material expect the supplier to have thought about how it might escape. Leakage measures also protect the business's own trade secrets, designs and pricing. They work best when proportionate: controls that interrupt ordinary work push staff to find workarounds, while sensible ones catch real risks and educate users at the point of action. Auditors usually test the idea by following a realistic scenario from information to exit route.

How to implement A.8.12

Begin with the information and its legitimate movement, and then look at where it could leave by mistake or on purpose. Tools come after that understanding, not before it.

1. Start small: define which information is sensitive enough to need leakage protection, linking to your classification approach.
2. Map the routes it can travel, including email, file sharing, removable media, printing, messaging and uploads to external services.
3. Choose measures per route, whether blocking, warning, restricting or simply monitoring, according to the risk and the business need.
4. Set rules for sharing with suppliers and customers so that legitimate transfers have an approved route.
5. Decide how alerts are assessed, who owns the decision and when a possible leak is treated as an incident.
6. Tell users what is monitored and what to do when a warning appears, so that a blocked action becomes a prompt to use the approved route, not a reason to work around the tool.
7. Test the whole response with harmless sample data, from detection through assessment to action.

Evidence an auditor expects for A.8.12

An auditor will test whether protection exists in practice and covers realistic routes. Useful evidence includes:

• records showing which information has been designated sensitive and where it is expected to travel;
• configuration of the measures applied to the relevant systems, networks and devices;
• examples of alerts or blocked actions, with the assessment and outcome recorded;
• observation of a harmless test, such as an attempt to send marked sample data outside the organisation;
• interviews with staff about what they do when they need to share sensitive material.

A result that shows both the control working and a decision following is stronger than configuration screenshots alone.

Common nonconformities with A.8.12

Leakage findings usually concern coverage rather than the absence of any measure.

• Email is protected, but uploads to personal storage or messaging services are not considered.
• Sensitive information has never been defined, so the tool cannot be configured against anything specific.
• Alerts are generated but nobody assesses them, and no decision records whether a case was an incident.
• Suppliers receive sensitive files by an unapproved route because no approved route exists.
• Measures cover office devices but not laptops or phones used remotely, where much of the real sharing now happens, and no one has checked the gap.

Illustrative BPO example: a report sent to the wrong domain

Illustrative manufacturing example: sharing design files with a supplier

A hypothetical manufacturer needs to send a controlled drawing package to an approved supplier. A broad rule blocks all external design-file transfers, and engineers begin requesting informal exemptions. The information owner reviews the collaboration need instead of simply disabling the rule for the entire engineering team.

The organisation establishes a limited authorised route for the agreed package and recipients, with appropriate access and handling conditions. It tests that the intended supplier exchange works while unrelated exports remain restricted. The example shows how a scoped business exception can preserve control more effectively than a permanent department-wide bypass.

Address the limits of technical detection

Protection depends on coverage and visibility. A tool may not inspect every file type, application or transfer route. Understand and document material gaps, then decide whether other measures are needed. User behaviour, permissions and handling rules can reduce exposure that a technical rule cannot reliably identify.

For example, displaying information to an authorised person creates a different risk from exporting a file. Awareness and appropriate conditions of use remain relevant to screenshots or photographs. Coordinate with data masking where a task does not require full detail, and with access restrictions so unnecessary access is not created in the first place.

Monitor proportionately and test the complete response

Leakage prevention can involve inspecting communications and user activity. Identify applicable privacy, employment and other legal requirements before implementation. Restrict access to collected information and decide what needs to be retained. The fact that monitoring supports security does not make unlimited collection or disclosure appropriate.

Useful evidence includes the information and channels covered, rule rationale, authorised exceptions, test results and responses to relevant alerts. These are practical evidence choices rather than a mandatory document bundle. Tests should use safe data and authorised recipients, and should check permitted activity as well as activity expected to be stopped.

Common failures include buying a tool before defining sensitive information, leaving alerts unattended and measuring success only by block counts. Use ISMS evaluation to examine false positives, unhandled alerts and recurring workarounds. A lower alert count can mean improved behaviour, but it can also mean lost coverage.