Data Loss Prevention for ISO 27001 and SOC 2: What You Actually Need

October 5, 2026

Data loss prevention is the control most often bought before it is understood. An organisation gets told it needs DLP for ISO 27001, licenses an enterprise platform, turns on the default policies, drowns in false positives, and switches most of it off. Six months later the auditor asks what the classification scheme is, and there isn’t one.

The sequence matters. You cannot prevent the loss of data you have not classified, because the tool has no way to know what it is protecting. This article covers what the two frameworks actually require, when tooling is warranted, and what to build first.

What ISO 27001 requires

ISO 27001:2022 introduced a dedicated data leakage control, and it sits in a group:

A.8.12 Data leakage prevention. Data leakage prevention measures are applied to systems, networks and any other devices that process, store or transmit sensitive information.
A.5.12 Classification of information. Information is classified according to the organisation’s needs, based on confidentiality, integrity, availability and relevant requirements.
A.5.13 Labelling of information. An appropriate set of labelling procedures is developed and implemented.
A.5.14 Information transfer. Rules and controls are in place for transferring information within the organisation and to external parties.
A.8.10 Information deletion and A.8.11 Data masking. Deletion when no longer required, and masking in line with the access control policy.
A.8.24 Use of cryptography. Rules for the effective use of cryptography, including key management.

Read in order, A.5.12 comes before A.8.12 for a reason. Classification is the prerequisite. An auditor assessing A.8.12 will want to know which classes of information the measures protect, and that answer comes from A.5.12.

Note also that A.8.12 says “measures”, not “a DLP product”. A control that restricts where a class of data can live, enforced by configuration rather than by a scanning engine, is a data leakage prevention measure.

What SOC 2 requires

SOC 2 does not have a control named DLP. The requirements are distributed:

CC6.1. Logical access over protected information assets, which is where “who can reach this data at all” lives.
CC6.5. Disposal of physical and logical protections over data when no longer required.
CC6.7. Restricting the transmission, movement and removal of information to authorised users and processes, and protecting it during transmission. This is the closest criterion to DLP in the Common Criteria.
CC6.8. Preventing or detecting unauthorised or malicious software.

If your SOC 2 report includes the Confidentiality category, C1.1 and C1.2 apply directly: identifying and maintaining confidential information, and disposing of it. If it includes Privacy, the P-series adds collection, use, retention and disclosure requirements for personal information.

The scoping decision matters commercially. Most Australian SaaS companies get asked for Security plus Availability by their customers. Adding Confidentiality is what turns data handling from an adjacent concern into a tested one, and it is worth deciding deliberately rather than by default.

The overlap

What you build	ISO 27001	SOC 2
Classification scheme and data inventory	A.5.12, A.5.13	C1.1, CC6.1
Restrictions on where data may be stored	A.8.12, A.5.14	CC6.7
Egress controls (email, upload, removable media)	A.8.12	CC6.7
Encryption in transit and at rest	A.8.24	CC6.1, CC6.7
Retention and secure deletion	A.8.10	CC6.5, C1.2
Masking in non-production environments	A.8.11	CC6.1

Build the classification scheme first, and keep it small

Four classes is usually right. Public, Internal, Confidential, Restricted. Three works. Six does not, because people stop being able to tell the difference and start guessing.

For each class, define three things and nothing more at first: who may access it, where it may be stored, and how it may be transferred. That is the whole scheme. One page. If it does not fit on one page, people will not follow it, and a classification scheme nobody follows produces worse audit outcomes than a simple one applied consistently.

Then build the data inventory. What sensitive data do you hold, where does it live, who has access, and how long do you keep it. This is tedious and it is the single most useful artefact in a compliance programme, because it feeds your risk assessment, your access reviews, your retention schedule and your breach assessment capability. Organisations that skip it spend the rest of the project guessing.

In an Australian context, be specific about personal information, because the Privacy Act obligations attach to it regardless of what your internal scheme calls it. Tax file numbers, health information and credit information carry additional handling requirements.

When you need DLP tooling, and when you do not

You probably do not need a DLP product yet if: your sensitive data lives in a small number of known systems, your people work from managed devices, your file sharing is through one platform, and your main risk is misdirected email.

In that situation you get most of the benefit from configuration: turn off external sharing by default in SharePoint or Google Drive, block or restrict removable media, enforce encryption at rest and in transit, use sensitivity labels, and turn on the external recipient warnings your mail platform already has. These are data leakage prevention measures, they evidence well, and they do not generate alert volume you cannot handle.

You probably do need tooling if: you have a defined class of regulated data you must demonstrate control over, you have unmanaged or BYO devices in scope, your customers or your sector require it contractually, or you need detection and reporting rather than just prevention.

If you are already on Microsoft 365 E5, Microsoft Purview is usually the path of least resistance because the classification, labelling and DLP engine are integrated with the data you already hold there. Other platforms in common use include Forcepoint, Symantec DLP and Netskope, and the cloud-native data discovery services in AWS and Azure for finding sensitive data you did not know about.

Whichever you choose, deploy in monitor mode first. Run it for a few weeks, look at what it catches, tune, and only then start blocking. A DLP rollout that blocks on day one creates a queue of angry people and gets turned off, and a control that was turned off is worse than one you never claimed.

What auditors ask to see

The classification scheme, and evidence it is applied. Labels in use, not just defined.
The data inventory, with locations, owners and retention periods.
Configuration showing the restrictions, in the tool. External sharing settings, removable media policy, encryption configuration.
DLP policies and their scope, if you have tooling, plus a sample of alerts and how they were handled.
Evidence of secure deletion at the end of a retention period, which is the half of A.8.10 and CC6.5 people forget.
Encryption standards, and key management. Who can access keys.
Non-production data handling. Whether production data is copied into test environments, and if so what masking applies. This is a very common finding and an easy one to pre-empt.
Third party transfers. Which vendors receive sensitive data, under what agreement, and how it is transferred.

The failure modes we see most

Tooling before classification. The policies end up keyed off generic patterns rather than your actual data classes, so they miss what matters and flag what does not.

Production data in test. A developer takes a database copy to debug something and it lives in a less protected environment indefinitely. Both frameworks care. Masked or synthetic test data removes the problem.

Retention that only ever accumulates. A retention schedule that specifies seven years and a system that has never deleted anything do not agree. Auditors check.

External sharing left open by default. The single highest-value configuration change in most Microsoft 365 and Google Workspace tenancies, and frequently untouched.

Classification labels defined and unused. Four labels exist in the admin console and no document carries one. Evidencing A.5.13 then becomes impossible.

Encryption claimed, not configured. “Data is encrypted at rest” is true of most managed cloud storage by default, which is fine, but you need to be able to show the setting rather than assert the vendor does it.

Australian considerations

The Notifiable Data Breaches scheme is the reason this control has teeth here. If personal information is lost or accessed without authorisation and serious harm is likely, you must notify the OAIC and the affected individuals. Your ability to assess that, and to limit it, comes directly from classification, the data inventory and egress controls. An organisation that knows exactly what was in the mailbox that got compromised has a very different notification conversation to one that does not.

Penalties for serious or repeated interferences with privacy were increased substantially in 2022, and the Privacy Act has been under reform since, so the direction of travel is toward more obligation rather than less. Building the inventory now is cheaper than building it under a deadline.

If you handle government data, the PSPF and any sector-specific classification requirements sit on top of your internal scheme rather than replacing it.

Where to start

Classification scheme on one page. Data inventory. Close default external sharing. Set retention and actually delete. Then, if your risk profile warrants it, deploy DLP tooling in monitor mode and tune it before enforcing.

Our CERTIFY compliance package covers the classification scheme, the data inventory and the control design for ISO 27001 and SOC 2, including the Confidentiality category if your customers are asking for it. If you are not sure which scope you need, get in touch and we will work through it with you.

Siege Cyber’s CERTIFY packages take Australian businesses from gap analysis to certification with a fixed scope and a fixed price, for both ISO 27001 and SOC 2. Get a Fixed-Price Quote.