By Olivia Dubois
·
July 25, 2026
The key point: an untracked SaaS application can undermine compliance on three fronts at once. If I cannot see the tool, I cannot include it in my registers, track access, trace an incident or prove anything during an audit.
Put simply, the article makes one point:
A few facts to keep in mind immediately:
| Framework | What it requires | What Shadow IT breaks |
|---|---|---|
| NIS2 | Inventory, access management, third-party monitoring, logging, notification | Missing assets, accounts outside SSO, poorly classified incidents |
| DORA | ICT register, provider monitoring, resilience testing, incident management | Incomplete register, contracts outside the framework, scattered logs |
| GDPR | Record of processing activities, DPA, transfers, proof of compliance | Undeclared processing, uncontrolled processors, missing evidence |
In short, this is what I take away: without continuous SaaS inventory, an up-to-date supplier register, and access and incident trails, compliance with NIS2, DORA and GDPR remains partial.
With NIS2, SaaS Shadow IT undermines control over assets, access and incidents.
NIS2 requires a complete inventory, with an owner, classification and lifecycle for each service. As soon as a SaaS application is subscribed to outside the intended process, it drops out of that inventory and escapes control. Put simply, an asset missing from the register is also missing from the NIS2 framework.
And the problem quickly goes further. Without a clear view of the tools in use, third-party and access controls no longer hold.
An unapproved SaaS application does not appear in the third-party register. It therefore bypasses security clauses, supplier assessment and the expected checks. Data may also be sent to a jurisdiction the company does not control.
On the access side, NIS2 expects MFA, least privilege and periodic reviews. If the tool remains outside SSO, accounts are often not reviewed. The result is orphaned access left open, sometimes for months.
NIS2 requires an alert within 24 hours, a notification within 72 hours and a final report within one month. [3][2][1] On paper, this is clear. In practice, if the SaaS application is not referenced and its logs are not sent to a central system, classifying an incident under NIS2 becomes difficult.
Without logs or an inventory, the incident is hard to detect. And once detected, it becomes almost impossible to document properly.
NIS2 expects evidence from the field, not just written policies. For Shadow IT, these artefacts often do not exist. A platform such as Avanoo can identify unreferenced SaaS applications and produce the material expected for a NIS2 file.
The same blind spot appears in DORA, with an even stricter requirement for operational control.
DORA takes the NIS2 logic further: to be compliant, it is not enough to see your information systems. You must also demonstrate that they can withstand disruption. Since 17 January 2025, DORA has applied to financial entities in France — banks, insurers, asset managers and payment service providers — with one central requirement: control all ICT risks, including those linked to external providers[13][14][5]. This is where SaaS Shadow IT complicates everything.
DORA requires an ICT asset inventory, with a designated owner, a criticality classification and a clear link to business functions[16][17][19][20][21]. This inventory must be updated at least once a year, as well as after any major change[16][17][21].
On paper, this is simple. In practice, a SaaS tool purchased directly by a business team often slips through the net. It appears in no register. As a result, the mapping between assets, critical functions and continuity becomes unclear. And when that mapping is incomplete, business continuity and recovery plans rest on fragile assumptions.
DORA also requires an ICT provider register and minimum contractual clauses: audit rights, continuity, data portability and incident notification[12][23]. This register must be submitted to the competent authorities at least once a year, with information about the services, data processed and related functions[12][23].
A SaaS application adopted without internal approval rarely meets these requirements. The contract does not include the DORA clauses. The provider is absent from the register. No prior assessment has been carried out. This gap between actual usage and the contractual register is what makes DORA difficult to demonstrate[7][9].
DORA sets strict deadlines for reporting major incidents: an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within 1 month[15][4][18]. Meeting these deadlines requires rapid detection, precise knowledge of the systems affected and centralised logging.
With an unreferenced SaaS application, these conditions are often not met. Events remain trapped in the provider's administration console instead of reaching the company's SIEM. Without a clear reference system or centralised logs, classifying, reporting and documenting an incident becomes a real headache. These gaps then surface in resilience tests and supervisory reviews.
DORA expects concrete evidence: a complete register, resilience tests and incident logs[6][8][10][11]. Shadow IT makes the register incomplete, hides dependencies during resilience tests and distorts incident indicators. The issue is therefore not only the absence of evidence. It is the break in the entire chain of evidence.
Avanoo can detect unreferenced SaaS applications and feed the DORA register. The same blind spot reappears under GDPR, with a direct impact on data processing.
The GDPR sets out a simple rule: know where personal data goes. When a SaaS application is adopted without approval, that data falls outside the record of processing activities, DPAs and, very often, data protection impact assessments. The problem is not the text itself. It is the lack of visibility into processing activities.
The GDPR requires organisations to keep a record of processing activities. This record lists each processing activity, its purpose, the categories of data involved and any transfers outside the EU. If a SaaS application is not referenced, it does not appear there. As a result, the legal basis, retention period and data flows remain uncontrolled.
Collaboration, sharing, automation and generative AI tools can therefore slip under the radar. The risk then directly affects the legal basis, retention and transfers. An unreferenced SaaS application creates undocumented processing. In practice, it becomes much harder to justify legally.
The GDPR requires a data processing agreement with every processor that accesses personal data. You must also verify that transfers outside the EU rely on appropriate safeguards and document the providers being used. A SaaS application adopted without internal approval meets none of these requirements: no DPA, no verification of data location, no prior provider assessment.
This is where things break down. As soon as there is a gap between personal data, the processor and contractual evidence, supervisory authorities have a clear line of enquiry during an audit.
The GDPR is built on accountability. In other words, the organisation must be able to produce compliance evidence at any time: access logs, DPIAs, DPAs, certifications, retention periods and deletion rules. With Shadow IT, this chain of evidence breaks from the outset.
Ultimately, the GDPR challenge is not only to follow the rule. It is also to be able to prove that you did so.
Avanoo can detect unreferenced SaaS applications, identify exposed personal data and generate usable audit evidence. This break in the evidence chain is what then allows a framework-by-framework comparison of how NIS2, DORA and GDPR respond to Shadow IT.
The three frameworks share the same weakness: an invisible SaaS application falls outside control, evidence and audit. Put simply, if the tool appears nowhere, it cannot be monitored either. This is where SaaS Shadow IT derails compliance.
NIS2 requires a map of assets and supplier risks. DORA requires a register of ICT assets and providers. The GDPR requires a RoPA.
| Type of Shadow IT | What it hides | Framework most exposed |
|---|---|---|
| Unreferenced SaaS | Outside the asset map and RoPA | NIS2 + GDPR |
| Personal accounts (Google Drive, WeTransfer…) | Invisible to SSO and authentication logs | GDPR |
| Free services (ChatGPT, Notion free…) | Outside the provider register | DORA |
An incomplete map does not create merely a “small gap”. It immediately weakens the entire contractual chain and access management.
An unapproved SaaS application creates a gap at three levels: contract, documentation and identity.
NIS2 requires supplier risk management across the supply chain. DORA calls for a standardised information register, with providers classified by criticality. The GDPR requires organisations to know which processors handle personal data.
With Shadow IT, this control chain breaks into pieces. The service may exist without approval, contractual evidence or a central view for security and compliance. Avanoo detects, in particular, password reuse on unreferenced SaaS applications and assigns a risk score to each application, helping teams address the most urgent cases first.
The problem takes on a different scale as soon as an incident occurs.
This is often where everything is decided. An incident on an unreferenced SaaS application can easily pass under the radar: no centralised logs, no detection, no classification.
Yet notification deadlines are tight: 24 hours for NIS2 (early warning), 4 hours for DORA (major incidents) and 72 hours for GDPR (personal data breaches).
Without visibility into the application involved, meeting these deadlines becomes impossible. And reconstructing the incident timeline for supervisory authorities? The same problem. This is therefore not only a technical issue. It is a clear break in traceability and notification.
Without centralised logs, proof of control is also unreliable.
In an audit, each framework requires concrete evidence: access logs, up-to-date inventories, supplier documentation and incident registers. With Shadow IT, this chain of evidence is almost always incomplete.
Auditors then find:
That is when the core issue becomes clear. Even when compliance practices exist in the field, they become difficult to demonstrate. The central problem is not only the absence of a tool from a register. It is the broken chain of evidence.
Having seen how Shadow IT puts each framework under pressure, let us look at what they cover in practice — and what they leave out.
The three frameworks approach SaaS Shadow IT from different angles. The key point is simple: none of them covers it from end to end.
| Framework | Main strength | Main limitation |
|---|---|---|
| NIS2 | Broad cyber governance across 18 sectors; explicit executive accountability; supply-chain security [24][25] | Less prescriptive than DORA on day-to-day operational monitoring of ICT providers |
| DORA | Highly granular on ICT third-party risk; tightly defined incident notification (T+4 hours, T+72 hours, T+1 month) [19][22][26] | Limited to the financial sector; does not apply to other organisations |
| GDPR | Strong accountability principle; obligation to demonstrate compliance for each personal data processing activity | Covers personal data only, not the organisation's entire SaaS estate |
NIS2 encourages organisations to think in terms of governance, oversight and executive supervision. This is useful for setting the framework. However, the text largely leaves each organisation to organise the continuous monitoring of SaaS applications.
DORA goes further into detail. It is the most precise framework here, especially on ICT third-party risk. But there is an obvious trap: it assumes that the organisation already knows which tools it uses. If the SaaS inventory is incomplete, undetected applications slip through the net.
The GDPR is well suited to SaaS applications processing personal data. That is where it is most useful. But it does not look at the entire SaaS estate. A collaboration, finance or even security tool can create clear operational risk without necessarily falling within the scope of personal-data processing as understood for compliance. As a result, it can remain off the radar.
Ultimately, these three frameworks complement one another. But none works properly without ongoing visibility of the SaaS estate. That is the real blind spot: not a lack of rules, but a lack of visibility into the applications used every day.
As long as some applications remain undetected, they escape NIS2 governance, the registers expected by DORA and GDPR accountability at the same time. In other words, continuous discovery of the SaaS estate is not a “nice to have”. It is the minimum required to demonstrate compliance credibly.
Without this layer of visibility, compliance remains partial. Avanoo can help map the SaaS estate and centralise the evidence needed for audits.
NIS2, DORA and GDPR do not have the same scope or control logic. Yet they all require the same thing: visibility of SaaS applications, access, third parties, incidents and evidence. Shadow IT is not simply a matter of unapproved tools. It is also a governance and evidence issue.
In practice, an invisible tool immediately breaks the compliance chain. An unlisted SaaS application falls outside the DORA register, the GDPR record of processing activities and NIS2 controls.
The challenge is therefore not to add one control after another. First, the SaaS estate must be made visible. The right starting point is a single foundation: continuous SaaS inventory, a supplier register, access traceability and incident traceability.
With this approach, continuous discovery becomes a prerequisite for audits. Avanoo helps map the SaaS estate, detect Shadow IT and centralise audit evidence.
Without continuous visibility, Shadow IT remains the blind spot for NIS2, DORA and GDPR.
::: faq
Start by making the invisible visible: map actual usage and identify gaps in your ICT asset management.
Then use a SaaS governance platform such as Avanoo to automate discovery, build a complete inventory, classify tools by criticality and establish continuous oversight. :::
::: faq
The SaaS applications most at risk are often those that remain outside the IT department's radar. This includes Shadow IT and Shadow AI.
The real problem is not only the tool itself. It is the fact that it escapes internal visibility and control. As soon as a team uses a service without approval, IT loses control over what is moving through it, who has access and how the data is stored.
The most critical cases involve tools handling sensitive data, such as:
If these services do not offer basic protections such as encryption or multi-factor authentication, the risk rises quickly.
AI tools create an even more obvious concern. Many are free, easy to access and available directly in a browser. In practice, it can take only a few clicks for an employee to paste an internal document, a code extract or confidential figures into one, without realising the consequences. :::
::: faq
During an audit, compliance cannot be demonstrated with promises. It is demonstrated with consolidated, clear and up-to-date documentation of the entire digital ecosystem: the ICT asset and supplier register, risk assessments, incident reports and evidence of testing.
Avanoo simplifies this work by automating evidence collection and the production of audit reports. At the same time, the platform provides continuous visibility into Shadow IT, dependencies and SaaS data governance. :::
Shadow AI Expert & Chief AI Officer
Olivia Dubois is Shadow AI Expert and Chief AI Officer at Avanoo. An HEC Paris graduate and former BCG consultant, she helps enterprises detect and govern Shadow AI and Shadow IT.
See how Avanoo can map your SaaS and AI landscape, reduce risk, and optimize costs. A reliable platform with dedicated human support.
