DLP in 2026: ISO 27001 for GDPR, NIS2 and DORA

It starts with a spreadsheet.

At 08:17 on a Monday, a customer success manager exports 14,000 enterprise contacts from the CRM to prepare a renewal campaign. At 08:24, the spreadsheet is attached to an email. At 08:26, the email is sent to a personal Gmail account because the employee wants to work during a train journey. At 08:31, the same file is uploaded to an unapproved AI note-taking service to “clean up duplicates.”

Nothing looks like a breach yet. There is no ransomware note, no malware beacon, no compromised admin account and no public leak. But for the CISO, compliance manager and DPO, the real question has already arrived: can the organisation prove that this movement was allowed, classified, logged, encrypted, justified and reversible?

The same scenario plays out in financial services every week. A developer tries to upload Q1_Investor_Projections_DRAFT.xlsx to a personal cloud drive because the VPN is slow. A sales manager exports a customer list to a consumer collaboration app. A support analyst pastes customer records into an unapproved AI tool. In every case, the intent may be convenience rather than malice, but the risk is the same. Sensitive data has crossed, or nearly crossed, a boundary the organisation does not control.

That is the modern Data Loss Prevention problem. DLP is no longer just an email gateway rule or an endpoint agent. In 2026, effective data loss prevention is a governed, evidence-backed control system across SaaS, cloud storage, endpoints, mobile devices, suppliers, APIs, development environments, backup exports, collaboration tools and human shortcuts.

GDPR Article 32 expects appropriate technical and organisational measures for security of processing. NIS2 Article 21 expects risk-based cybersecurity measures, including cyber hygiene, access control, asset management, supply-chain security, incident handling, encryption and effectiveness testing. DORA expects financial entities to manage ICT risk through governance, detection, response, recovery, testing, third-party oversight and auditability. ISO/IEC 27001:2022 provides the management-system backbone to make those obligations operational, measurable and auditable.

The mistake many organisations make is buying a DLP tool before defining what “loss” means. Clarysec’s approach starts earlier: classify the data, define permitted transfers, enforce the policy, monitor exceptions, prepare response evidence and connect everything to the ISMS.

As the Zenith Blueprint: An Auditor’s 30-Step Roadmap says in the Controls in Action phase, Step 19, Technological Controls I:

Data Leakage Prevention is about stopping the unauthorized or accidental release of sensitive information , whether it slips out through email, cloud uploads, portable media, or even a forgotten printout. Control 8.12 addresses the need to monitor, restrict, and respond to any data that leaves the trusted boundaries of the organization , regardless of whether it’s digital, physical, or human-driven. Zenith Blueprint

That sentence is the heart of DLP in 2026: monitor, restrict and respond.

Why DLP Is Now a Board-Level Compliance Issue

The board does not usually ask whether a DLP regex detects national ID numbers. It asks whether the organisation can protect customer trust, continue operating, avoid regulatory exposure and prove reasonable security when something goes wrong.

That is where GDPR, NIS2 and DORA converge.

GDPR applies broadly to automated personal data processing, including EU-established controllers and processors, and non-EU organisations offering goods or services to people in the EU or monitoring their behaviour. It defines personal data broadly and covers operations such as collection, storage, use, disclosure, erasure and destruction. Unauthorised disclosure of, or access to, personal data can be a personal data breach. GDPR Article 5 also makes accountability explicit: organisations must not only follow principles such as data minimisation, storage limitation, integrity and confidentiality, they must be able to demonstrate compliance.

NIS2 expands the pressure beyond privacy. It applies to many essential and important entities, including sectors such as banking, financial market infrastructures, cloud computing providers, data centre providers, managed service providers, managed security service providers, online marketplaces, search engines and social networking platforms. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, information-system security policies, incident handling, business continuity, supply-chain security, secure development, effectiveness testing, cyber hygiene, training, cryptography, access control, asset management and authentication.

DORA applies from 17 January 2025 and acts as the financial sector’s dedicated ICT resilience rulebook. For in-scope financial entities, it is treated as the sector-specific Union legal act for overlapping NIS2 purposes. DORA brings DLP into ICT risk management, incident classification, data loss affecting availability, authenticity, integrity or confidentiality, digital operational resilience testing, ICT third-party management and contractual controls.

The 2026 DLP question is not “Do we own a tool?” It is:

1. Do we know which information is sensitive?
2. Do we know where it is stored, processed and transferred?
3. Are allowed and prohibited transfer routes defined?
4. Are users trained and technically constrained?
5. Are cloud and SaaS routes governed?
6. Are logs sufficient for investigation?
7. Are alerts triaged and incidents classified quickly?
8. Are suppliers and outsourced ICT services contractually bound?
9. Can we prove that controls are operating?

ISO/IEC 27001:2022 is well suited to answer these questions because it requires context, interested-party requirements, risk assessment, risk treatment, measurable objectives, operational control, documented evidence, supplier control, internal audit, management review and continual improvement. It is not a DLP standard, but it turns DLP from an isolated technology configuration into a controlled management-system process.

The ISO 27001 Control Chain Behind Effective DLP

A credible DLP program is not built on one control. It is built on a chain.

Clarysec’s Zenith Controls: The Cross-Compliance Guide maps ISO/IEC 27002:2022 control 8.12, Data leakage prevention, as a preventive and detective control focused on confidentiality, aligned to Protect and Detect cybersecurity concepts, with information protection as the operational capability and protection/defense as the security domain. Zenith Controls

That matters because auditors expect both blocking and visibility. A preventive DLP rule with no alert review is incomplete. A logging-only approach with no enforcement for high-risk transfers is also weak.

The same guide maps ISO/IEC 27002:2022 control 5.12, Classification of information, as preventive, supporting confidentiality, integrity and availability, and aligned with Identify. It maps control 5.14, Information transfer, as preventive, supporting confidentiality, integrity and availability, and aligned with Protect, Asset Management and Information Protection.

In practical terms, the DLP control chain looks like this:

The Zenith Blueprint, Step 22, explains the dependency between asset inventory, classification and DLP:

Review your current asset inventory (5.9) to ensure it includes both physical and logical assets, owners, and classifications. Link this inventory to your classification scheme (5.12), ensuring that sensitive assets are labeled and protected appropriately. Where necessary, define retention, backup, or isolation based on classification.

This is why Clarysec rarely starts a DLP engagement by tuning rules. We start by reconciling assets, owners, data types, classification labels, transfer routes and evidence records. If the organisation cannot say which datasets are confidential, regulated, customer-owned, payment-related or business-critical, then a DLP tool can only guess.

The Three Pillars of a Modern DLP Program

A modern DLP program stands on three reinforcing pillars: know the data, govern the flow and defend the boundary. These pillars make ISO/IEC 27001:2022 practical for GDPR, NIS2 and DORA compliance.

Pillar 1: Know Your Data With Classification and Labelling

You cannot protect what you do not understand. ISO/IEC 27002:2022 controls 5.12 and 5.13 require organisations to classify information and label it according to sensitivity and handling needs. This is not a paperwork exercise. It is the foundation for automated enforcement.

For SMEs, the Data Classification and Labeling Policy states:

Confidential: Requires encryption in transit and at rest, restricted access, explicit approval for sharing, and secure destruction upon disposal. Data Classification and Labeling Policy - SME

This quote, from section “Policy Implementation Requirements,” clause 6.3.3, gives the DLP program four enforceable conditions: encryption, restricted access, sharing approval and secure disposal.

In enterprise environments, the Data Classification and Labeling Policy is even more direct. From section “Policy Implementation Requirements,” clause 6.2.6.2:

Blocking transmission (e.g., external email) for improperly labeled sensitive data Data Classification and Labeling Policy

And from section “Enforcement and Compliance,” clause 8.3.2:

Automated classification validation using Data Loss Prevention (DLP) and discovery tools

These clauses turn classification into a control. A file marked Confidential can trigger encryption, block external transmission, require approval or generate a security alert. DLP then becomes the enforcement layer for a policy that users, systems and auditors can understand.

Pillar 2: Govern the Flow With Secure Information Transfer

Once data is classified, the organisation must govern how it moves. ISO/IEC 27002:2022 control 5.14, Information transfer, is often overlooked, but it is where many DLP failures begin.

The Zenith Blueprint frames control 5.14 as the need to govern information flow so that transfer is secure, intentional and consistent with classification and business purpose. This applies to email, secure file sharing, APIs, SaaS integrations, removable media, printed reports and supplier portals.

Remote work makes this especially important. The Remote Work Policy, section “Policy Implementation Requirements,” clause 6.3.1.3, requires employees to:

Use only approved file-sharing solutions (e.g., M365, Google Workspace with data loss prevention (DLP) controls) Remote Work Policy

For mobile and BYOD, the Mobile device and byod policy, section “Policy Implementation Requirements,” clause 6.6.4, provides concrete endpoint enforcement:

Data Loss Prevention (DLP) policies shall block unauthorized uploads, screen captures, clipboard access, or data sharing from managed applications to personal areas. Mobile device and byod policy

This matters because data does not only leave through email. It leaves through screenshots, clipboard sync, unmanaged browser profiles, personal drives, mobile share sheets, collaboration plugins and AI tools.

Cloud governance is equally important. In the SME Cloud Usage Policy-sme, section “Governance Requirements,” clause 5.5:

Shadow IT, defined as the use of unapproved cloud tools, must be treated as a policy violation and reviewed by the GM and IT provider to determine risk and required remediation. Cloud Usage Policy-sme - SME

For enterprise organisations, the Cloud Usage Policy, section “Governance Requirements,” clause 5.5, raises the monitoring bar:

The Information Security Team must routinely assess network traffic, DNS activity, and logs to detect unauthorized cloud use (shadow IT). Detected violations must be investigated promptly. Cloud Usage Policy

Shadow IT is not just an IT nuisance. Under GDPR it can become unlawful disclosure or uncontrolled processing. Under NIS2 it is a cyber hygiene and supply-chain weakness. Under DORA it can become an ICT third-party risk and incident classification issue.

Pillar 3: Defend the Boundary With DLP Technology, Policy and Awareness

ISO/IEC 27002:2022 control 8.12, Data leakage prevention, is the control most people associate with DLP. But in a mature program, it is the final line of defence, not the first.

The Zenith Blueprint explains that DLP requires a three-layered approach: technology, policy and awareness. Technology includes endpoint DLP, email security, content inspection, cloud access security, SaaS controls, browser controls, network egress filtering and alert routing. Policy defines what the tools enforce. Awareness ensures employees understand why personal email, consumer cloud storage and unapproved AI tools are not acceptable handling methods for regulated or confidential information.

The response component is just as important as prevention. The Zenith Blueprint, Step 19, states:

But DLP is not just prevention, it’s also response. If a potential leak is detected:

✓ Alerts should be triaged quickly, ✓ Logging should support forensic analysis, ✓ The incident response plan must be triggered without delay.

A DLP program that blocks events but does not triage, investigate and learn from them is not audit-ready. It is only partially deployed.

From Spreadsheet Leak to Audit-Ready Response

Return to the Monday morning spreadsheet.

In a weak program, the organisation discovers the upload three weeks later during a privacy review. Nobody knows who approved the export, whether the data was personal data, whether special-category data was involved, whether the AI tool retained the file, or whether customers must be notified.

In a Clarysec-designed program, the sequence looks different.

First, the CRM export is tagged as Confidential because it contains personal data and customer commercial information. Second, the export event is logged. Third, the email gateway detects a confidential attachment going to a personal email domain and blocks it unless an approved exception exists. Fourth, the attempted upload to an unapproved cloud service triggers a cloud usage alert. Fifth, the alert is triaged against the incident response procedure. Sixth, the security team determines whether there was actual disclosure, whether the data was encrypted, whether the provider processed or retained it, whether GDPR breach criteria are met, and whether NIS2 or DORA incident thresholds apply.

The SME Logging and Monitoring Policy, section “Governance Requirements,” clause 5.4.3, tells the team exactly what should be visible:

Access logs: File access (especially for sensitive or personal data), permission changes, shared resource usage Logging and Monitoring Policy - SME

That clause is small, but decisive. If file access, permission changes and shared resource usage are not logged, the DLP investigation becomes guesswork.

Under NIS2 Article 23, significant incidents require staged reporting: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report not later than one month after the incident notification. Under DORA, Articles 17 to 19 require financial entities to detect, manage, classify, record, escalate and report major ICT-related incidents. Classification includes data loss affecting availability, authenticity, integrity or confidentiality, along with affected clients, duration, geographic spread, criticality and economic impact. Under GDPR, an unauthorised disclosure of personal data can require breach assessment and, where thresholds are met, notification.

A DLP alert is therefore not merely a security event. It can become a privacy breach assessment, a NIS2 incident workflow, a DORA ICT incident classification, a customer notification trigger and an audit evidence package.

DLP Controls for GDPR Article 32

GDPR Article 32 is often translated into a list of measures: encryption, confidentiality, integrity, availability, resilience, testing and restoration. For DLP, the key is lifecycle protection.

Personal data moves through collection, storage, use, transfer, disclosure, retention and deletion. GDPR Article 5 requires data minimisation, purpose limitation, storage limitation, integrity, confidentiality and accountability. GDPR Article 6 requires lawful basis and purpose compatibility. GDPR Article 9 demands stricter safeguards for special categories of personal data.

DLP supports these obligations when it is connected to data classification, lawful processing records and approved transfer paths.

Clarysec’s Data Masking and Pseudonymization Policy-sme, section “Purpose,” clause 1.2, supports this lifecycle approach:

These techniques are mandatory where live data is not required, including in development, analytics, and third-party service scenarios, in order to reduce the risk of exposure, misuse, or breach. Data Masking and Pseudonymization Policy-sme - SME

This is a practical GDPR Article 32 control. If developers, analysts or suppliers do not need live personal data, DLP should not be the only barrier. Masking and pseudonymisation reduce the blast radius before data ever moves.

A strong privacy-aligned DLP matrix should map personal data types to classification labels, lawful basis, approved systems, approved export methods, encryption requirements, DLP rules, retention rules and incident triggers. That matrix becomes the bridge between privacy governance and security operations.

NIS2 Cyber Hygiene and DLP Beyond the Privacy Team

NIS2 changes the DLP conversation because it frames leakage as part of cyber hygiene and resilience, not only privacy.

Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation and receive cybersecurity training. Article 21 requires appropriate and proportionate measures across policy, incident handling, continuity, supply chain, secure development, effectiveness testing, cyber hygiene, training, cryptography, HR security, access control and asset management. Article 25 encourages use of relevant European and international standards and technical specifications.

DLP contributes directly to these areas:

The Network Security Policy-sme, section “Objectives,” clause 3.4, makes the exfiltration objective explicit:

Prevent malware propagation and data exfiltration through network channels Network Security Policy-sme - SME

For NIS2, this type of objective gives auditors a direct test path: show outbound filtering, DNS monitoring, proxy logs, endpoint alerts, blocked upload attempts and investigation tickets.

The Zenith Blueprint, Step 23, adds a cloud-specific action that is now essential for NIS2-covered digital and ICT providers:

List all cloud services currently in use (5.23), including shadow IT where known. Identify who approved them and whether due diligence was performed. Develop a lightweight evaluation checklist that covers data location, access model, logging, and encryption. For future services, ensure the checklist is integrated into the procurement or IT onboarding process.

Many organisations fail here. They have an ISMS scope and a supplier register, but not a real list of SaaS tools where employees move regulated or customer data. DLP without cloud discovery is blind.

DORA ICT Risk: DLP for Financial Entities and Providers

For financial entities, DLP must fit into DORA’s ICT risk management framework.

DORA Article 5 requires an internal governance and control framework for ICT risk management. The management body remains responsible for ICT risk, policies preserving data availability, authenticity, integrity and confidentiality, clear ICT roles, digital operational resilience strategy, ICT risk tolerance, continuity and response/recovery plans, audit plans, resources, third-party policy and reporting channels.

Article 6 requires a documented ICT risk management framework covering strategies, policies, procedures, ICT protocols and tools to protect information and ICT assets. Article 9 addresses protection and prevention. Articles 11 to 14 add continuity, response, recovery, backup, restoration, data integrity checks, lessons learned, awareness training and crisis communications.

DLP fits into that framework as a protection, detection, response and testing capability.

DORA also makes third-party risk unavoidable. Articles 28 to 30 require ICT third-party risk management, registers of ICT service contracts, pre-contract due diligence, contractual requirements, audit and inspection rights, termination rights, exit strategies, service descriptions, data processing and storage locations, data access, recovery and return, incident assistance, authority cooperation, security measures and subcontracting conditions.

For a fintech or bank, DLP cannot stop at the boundary of Microsoft 365 or Google Workspace. It must cover payment processors, identity verification providers, CRM platforms, data warehouses, cloud infrastructure, outsourced support desks, managed service providers and critical SaaS integrations.

This is especially important where DORA acts as the sector-specific Union legal act for overlapping NIS2 obligations. The controls still need to exist. The reporting and supervisory route may differ.

A 90-Minute DLP Rule Sprint

Clarysec uses a practical sprint with clients that need fast progress without pretending that a full DLP program can be built in one meeting. The objective is to implement one high-value DLP control from policy to evidence.

Step 1: Pick one data type and one transfer route

Choose “customer personal data exported from CRM and sent externally by email.” Do not start with every repository, country and data type.

Step 2: Confirm classification and label

Use the classification policy to confirm that this export is Confidential. In an SME, clause 6.3.3 requires encryption, restricted access, explicit approval for sharing and secure destruction. In an enterprise, the Data Classification and Labeling Policy supports blocking transmission for improperly labelled sensitive data and automated validation using DLP and discovery tools.

Step 3: Define the allowed transfer pattern

Allowed: CRM export sent to an approved customer domain using encrypted email or an approved secure file-sharing platform, with business justification.

Not allowed: personal email, public file-sharing links, unapproved AI tools and unmanaged cloud drives.

This aligns with Zenith Blueprint, Step 22, which states:

If “Confidential” information is not permitted to leave the company without encryption, then email systems must enforce encryption policies or block external transmission.

Step 4: Configure the minimum DLP rule

Configure the email or collaboration platform to detect the confidential label, personal data pattern or export file naming convention. Start with monitoring if false positives are expected, then move to blocking for personal domains and unapproved recipients.

Step 5: Enable logging and alert routing

Ensure logs capture file access, permission changes and shared resource usage, as required by the Logging and Monitoring Policy - SME. Route alerts to the ticketing queue with severity, data type, sender, recipient, file name, action taken and reviewer.

Step 6: Test three scenarios

Test an approved encrypted transfer to a customer, a blocked personal email transfer and an alert-only upload attempt to an unapproved cloud domain.

Step 7: Preserve evidence

Save the policy clause reference, DLP rule screenshot, test results, alert ticket, reviewer decision and management approval. Add the control to the risk treatment plan and Statement of Applicability.

In ISO/IEC 27001:2022 terms, this exercise connects Clause 6.1.2 risk assessment, Clause 6.1.3 risk treatment, Clause 8 operational planning and control, Annex A information transfer, data leakage prevention, logging, monitoring, supplier and cloud controls, and Clause 9 performance evaluation.

Cross-Compliance Mapping: One DLP Program, Multiple Obligations

The strength of the Clarysec approach is that it avoids building separate control stacks for GDPR, NIS2, DORA, NIST and COBIT. One well-designed DLP program can satisfy multiple expectations if evidence is structured correctly.

NIST CSF 2.0 is useful as a communication layer. Its GOVERN function supports legal, regulatory and contractual requirement tracking, risk appetite, policy enforcement, roles and oversight. Its Profiles method helps organisations scope current and target posture, document gaps and implement an action plan. Its RESPOND and RECOVER functions support DLP incident containment, root-cause analysis, evidence preservation and restoration.

COBIT 2019 adds a governance lens. A COBIT-oriented auditor will ask whether DLP objectives are aligned to enterprise goals, whether ownership is clear, whether performance indicators exist, whether risk appetite is defined and whether management receives meaningful reporting.

How Auditors Will Test Your DLP Program

DLP audits are rarely about one screenshot. Different audit backgrounds produce different evidence expectations.

A strong DLP audit pack includes scope and risk statement, classification scheme, approved transfer methods, DLP rules, exception approvals, logging design, alert triage procedure, incident reporting decision tree, supplier and cloud inventory, test results and remediation records.

Common DLP Failures in 2026

The most common DLP failures are operational, not exotic.

First, classification is optional or inconsistent. Labels exist in policy, but users do not apply them, systems do not enforce them and repositories contain years of unlabelled sensitive files.

Second, DLP is deployed in alert-only mode forever. Alert-only is useful during tuning, but a high-risk personal email transfer of confidential customer data should eventually be blocked unless there is an approved exception.

Third, shadow IT is treated as an IT nuisance rather than a data protection risk. The Cloud Usage Policy and Cloud Usage Policy-sme are designed to make unapproved cloud tools visible, reviewable and remediable.

Fourth, logs are not sufficient for investigation. If the security team cannot reconstruct who accessed, shared, downloaded, uploaded or changed permissions, the organisation cannot confidently assess GDPR, NIS2 or DORA reporting obligations.

Fifth, suppliers are outside the DLP model. DORA Articles 28 to 30 make this especially dangerous for financial entities, but the problem affects every sector. Contracts should define data locations, access, recovery, return, incident assistance, security measures, subcontracting and audit rights.

Sixth, incident response does not include DLP scenarios. A misdirected email, unauthorised SaaS upload or bulk CRM export should have a playbook, severity criteria and notification decision path.

Finally, organisations forget physical and human channels. The Zenith Blueprint reminds us that DLP includes clean desk behaviour, secure shredding, locked print queues, printer audit logs and employee awareness. A DLP program that ignores paper, screenshots and conversations is incomplete.

Build a DLP Program Auditors Can Trust

If your DLP program is currently a tool configuration, 2026 is the year to turn it into a governed, evidence-backed control system.

Start with three practical actions:

1. Select your top three sensitive data types, such as customer personal data, payment data and source code.
2. Map where they move, including email, SaaS, cloud storage, endpoints, APIs, suppliers and development environments.
3. Build one enforceable DLP rule per data type, linked to policy, logging, incident response and evidence retention.

Clarysec can help you accelerate this through the Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, the Zenith Controls: The Cross-Compliance Guide Zenith Controls, and ready-to-adapt policies such as the Data Classification and Labeling Policy Data Classification and Labeling Policy, Remote Work Policy Remote Work Policy, Cloud Usage Policy Cloud Usage Policy, Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME, and Mobile device and byod policy Mobile device and byod policy.

The goal is not to stop every file from moving. The goal is to make secure movement the default, risky movement visible, prohibited movement blocked and every exception accountable.

Download the Clarysec toolkits, review your DLP evidence pack and book a readiness assessment to see whether your current controls can withstand GDPR Article 32 scrutiny, NIS2 cyber hygiene expectations and DORA ICT risk review.