Members of the European Parliament formally rebuked Europol and Frontex for processing personal data through systems that violated EU law. The findings did not allege that Europol lacked a data protection policy. Europol had one. The data was processed in unauthorised systems regardless. If the EU’s own law enforcement body cannot contain shadow IT through policy alone, the enterprise assumption that an acceptable use policy governs what tools staff actually reach for is already disproven.
What the Europol Finding Actually Means
The MEP finding was specific: personal data was processed through systems that had not been authorised under the applicable legal framework, including tools that had not been assessed for compliance with the EU Law Enforcement Directive. The systems were not black market. They were commercial SaaS products, AI-assisted tools, and collaborative platforms. The kind of tools available to any staff member with a credit card or a free-tier account.
The policy existed. Compliance did not follow. This is the structural reality of shadow IT: it is not primarily a knowledge problem or a culture problem. It is a control gap. Where technical controls do not constrain application use, policy documents do not substitute.
How Shadow IT Accumulates in Enterprise Environments
Shadow IT in 2026 is not a rogue department running an unlicensed copy of something on a local server. The accumulation happens across three vectors.
The first is SaaS proliferation. A business function identifies a tool that solves a problem faster than the approved toolchain does. Procurement friction is high. The free tier is sufficient. The tool is adopted without IT involvement and the data flows into it immediately.
The second is AI tools. The past three years have produced a generation of AI-assisted productivity tools with browser extensions, clipboard integrations, and document upload capabilities. Staff paste contract text, customer data, and internal analysis into these tools routinely. The data leaves the organisational boundary with no logging and no recovery path.
The third is personal devices used for work tasks. A manager continues a conversation on a personal phone using a messaging app not covered by corporate policy. The data is now held in an application the organisation cannot audit, cannot retrieve from, and cannot compliantly process subject access requests against.
Why DLP Alone Does Not Solve This
Data Loss Prevention tools operating at the network perimeter catch known patterns of data exfiltration through known channels. Shadow IT bypasses the premise. When an employee uploads a document to an unapproved SaaS platform from a personal device over a home network, there is no corporate network boundary to inspect at. DLP did not fail. It was never in the path.
The same applies to browser-based DLP extensions. They operate on managed devices within managed browser profiles. The moment the data reaches an unmanaged device or an unmanaged browser instance, the coverage breaks.
DLP is a relevant control for known exfiltration scenarios involving managed endpoints. It is not a control architecture for shadow IT, because shadow IT specifically routes around managed endpoints and managed channels.
What a Technical Control Architecture Actually Requires
Addressing shadow IT requires controls that are present regardless of the device or network the request originates from. This means moving the enforcement point from the endpoint to the identity and the application layer.
A Cloud Access Security Broker (CASB) places an enforcement point between users and cloud applications, providing visibility into which applications are being accessed, the ability to block unsanctioned applications, and policy enforcement on data movement between sanctioned and unsanctioned services. This operates at the application layer rather than the network layer, which makes it relevant even on unmanaged devices accessing cloud services.
SASE (Secure Access Service Edge) architectures combine network-level security with identity-based access controls delivered through a cloud-native stack. Conditional access policies enforce that access to corporate data requires a compliant, managed device, a verified identity, and a defined risk posture. A user attempting to access a corporate document from an unmanaged device using an unauthorised tool finds the access blocked at authentication, before the data is reached.
The combination of CASB, conditional access, and SASE-aligned network controls creates an architecture where the enforcement boundary is the identity, not the corporate network perimeter. This architecture constrains shadow IT because it removes the condition under which it is possible: unobserved access to corporate data from outside the policy boundary.
The DORA and NIS2 Intersection
For organisations in scope for DORA or NIS2, shadow IT is not a best practice concern. It is a regulatory liability.
DORA Article 8 requires financial entities to maintain an inventory of all ICT assets, including third-party ICT services. A SaaS tool adopted outside the procurement process is, by definition, absent from that inventory. An audit finding on DORA ICT asset management will surface shadow IT as a gap.
NIS2 Article 21 requires measures for supply chain security and the security of network and information systems. An AI tool processing operational data that was adopted without a security assessment is a supply chain security failure under that definition.
Europol’s situation was embarrassing precisely because it was visible. For enterprises, the same gap is quieter until it produces a breach, a subject access request the organisation cannot fulfil, or a regulatory audit that asks for the complete inventory of data processing activities.
The inventory will be incomplete. It always is when shadow IT is uncontrolled.
