By Tanguy Duthion
·
June 13, 2026
I can sum up the topic in one sentence: the same SaaS application can create three problems at once - personal data, service interruption, and a regulatory gap.
If I had to get straight to the point, I would keep the following in mind:
The simple point to remember: DORA mainly governs resilience and ICT third parties, GDPR governs personal data, and NIS2 governs the security of networks and systems.
In practical terms, I do not run three separate programmes. I set up one SaaS register, one incident triage process, and one supplier review, then add the requirements specific to each text.
Quick comparison:
| Framework | What it primarily covers | Who is in scope | Incident deadline |
|---|---|---|---|
| DORA | Digital resilience | Financial entities | 4 hours / 24 hours maximum |
| GDPR | Personal data | Any organisation that processes it | 72 hours |
| NIS2 | Information-system security | Entities and providers covered by the text | 24 hours |
My central idea: for a SaaS application in production, I always ask three questions:
This three-part view makes it possible to know what to log, what to test, what to include in the contract, and whom to notify in the event of an incident.
The starting point is not the same for each framework.
DORA applies to the financial entities listed in Article 2(1) [1]. As soon as they rely on SaaS for a regulated activity, the provider enters the ICT perimeter and becomes a third-party ICT service provider subject to stricter clauses. Put simply: the SaaS contract is no longer just a purchasing document. It becomes both a legal and an operational control point. In some cases, providers may even be designated as critical ICT third-party providers (CTPPs) and come under direct European supervision [3].
GDPR follows a different logic. It applies whenever personal data is processed, regardless of the sector. A CRM, HR tool, ticketing platform, or collaboration suite used in France may therefore trigger GDPR obligations: legal basis, data-subject rights, a processor agreement, and, where necessary, notification of personal-data breaches to the CNIL. GDPR scope is therefore determined data point by data point, not only at sector level.
NIS2 targets essential and important entities in the listed sectors, according to their size and criticality [4][7]. Cloud, data-centre, and DNS service providers may be directly in scope, including when they provide services in France without being established there. In finance, DORA takes precedence over NIS2 for requirements it already covers, notably ICT incident management, third parties, and governance [5][6].
In practice, the same SaaS application used by a bank may fall under GDPR, DORA, and NIS2 at the same time. This means, very concretely:
This is where many organisations run into the same wall: they have the tools, but not always the overall view. Without a complete SaaS inventory, including Shadow IT, it becomes difficult to map the scope, centralise contracts, and monitor risk.
Once the scope has been established, the next topic is incident and continuity management.
Three frameworks, three ways of naming a SaaS risk that may be the same in the field.
Under DORA, an ICT incident is an unplanned event that compromises the security of a system or service and affects its availability, authenticity, integrity, or confidentiality [13]. Under NIS2, an incident is significant if it can cause a serious operational disruption, substantial financial loss, or considerable damage [8][11]. Under GDPR, a breach is a security incident that leads to the destruction, loss, alteration, unauthorised disclosure of, or access to personal data [19][20]. The decisive point is simple: the risk to the rights and freedoms of individuals [19].
In a SaaS context, classification depends not only on the incident itself. It also depends on the data affected and the concrete effect on the business. A ransomware attack on a SaaS application used by a bank could therefore fit all three categories at once: a major ICT incident under DORA, a significant incident under NIS2, and a GDPR breach if customer data is encrypted or exfiltrated [17][18][19]. Conversely, a configuration error exposing contact records in a SaaS CRM primarily falls under GDPR. DORA and NIS2 only come into play if the operational impact exceeds their thresholds.
The notification deadlines illustrate this multi-layered logic. DORA requires an initial notification within 4 hours of classifying the incident as major, and no later than 24 hours after detection. An intermediate report must then be submitted within 72 hours, followed by a final report within one month [12][14][15]. NIS2 follows a similar pattern: an early warning within 24 hours, a complete notification within 72 hours, and a final report within one month [8][11][16]. GDPR, for its part, requires notification to the CNIL within 72 hours of becoming aware of the breach, unless it is unlikely to create a risk for individuals [19].
| Framework | Incident type | Initial deadline | Recipient (France) |
|---|---|---|---|
| DORA | Major ICT incident | 4 hours after classification / 24 hours maximum | ACPR / AMF |
| NIS2 | Significant incident | 24 hours (early warning) | ANSSI |
| GDPR | Personal-data breach | 72 hours | CNIL |
But deadlines are only part of the topic. The real dividing line is business continuity.
On this point, DORA goes furthest. The text requires documented continuity and recovery plans, defined RTO/RPO for critical SaaS applications, and regular tests, including simulations of a provider outage [10][12][13]. In other words, having a plan on a shelf is not enough. You must be able to show that it holds up when a provider fails.
NIS2 also expects concrete preparation. Essential and important entities must plan for failure scenarios involving their SaaS providers, with fallback procedures [9][11]. In plain terms: if the service stops tomorrow morning, what do you do in the following hour?
GDPR is less prescriptive about pure operational continuity, but it still requires appropriate technical and organisational measures to ensure the confidentiality, integrity, availability, and resilience of processing systems and services. In a SaaS environment, this means, very concretely, backups, restores, and a continuity plan [19][21].
Ultimately, all three frameworks encourage the same management reflex: link every critical SaaS application to a criticality level, clear RTO/RPO, and a recovery plan. Without this link, it becomes difficult to manage supplier dependencies and keep the service running when an incident strikes.
Once the incident has been managed, the risk often shifts to the contract and supplier monitoring. This is precisely where the three frameworks differ most clearly.
DORA is the strictest on supplier contracts. The regulation requires a very precise framework for critical third-party ICT providers. This includes service levels (SLAs) with measurable RTO/RPO, broad audit and inspection rights, geographical data location, tested exit plans, and defined assistance in the event of an incident. The idea is simple: make the dependency on a SaaS application verifiable at any time, without having to renegotiate in an emergency at the worst possible moment.
GDPR, for its part, requires a data processing agreement with any processor that processes personal data on behalf of the controller. This contract must specify the nature of the processing, the security measures applied, the conditions for further processing by subprocessors, and audit rights. In practice, this applies to a large proportion of SaaS applications handling personal data.
NIS2 follows a risk-based logic. Essential and important entities must assess the security of their providers and require contractual guarantees proportionate to their criticality. In other words, NIS2 requires a supplier risk assessment and safeguards adjusted to that risk.
The main difference concerns three levers: audit, exit, and the level of contractual constraint.
| Dimension | DORA | NIS2 | GDPR |
|---|---|---|---|
| Contractual detail | High | Medium (risk-based) | Medium (mandatory data processing agreement) |
| Audit rights | Broad and contractually defined | Required for compliance | Provided for in the data processing agreement |
| Exit plans | Mandatory for critical services | Expected according to risk and criticality | Not specified |
In practice, weak SaaS management remains one of the most frequent audit failure points. The issue is therefore not only signing the right contract at the start. You also need to maintain it over time: tool inventory, application criticality, exit clauses, and supplier monitoring.
Continuous monitoring of the SaaS estate then becomes an operational prerequisite for maintaining control over these three regulatory areas.
After the supplier contract has been signed, SaaS risk moves into daily use: logs, access, and governance. All three frameworks seek traceability. But they do not require the same level of detail or the same degree of formality. On a critical SaaS application, this changes everything: without reliable records, it becomes much harder to investigate, correct an incident, and prove compliance.
DORA is the most specific framework. The ICT risk-management RTS require organisations to define in writing the events to log, retention periods, log protection measures, and how logs are used to identify anomalies and support incident investigations[22][23]. ICT incident logs must be retained for at least five years[23]. For access, DORA requires least privilege, multifactor authentication (MFA), and a documented periodic review of permissions. Privileged accounts are also subject to enhanced monitoring[24][27].
GDPR does not provide for a dedicated logging obligation. In practice, its accountability principle and security requirements nevertheless encourage organisations to record sensitive operations and technical interventions. The CNIL recommends logging creations, views, shares, modifications, and deletions, with the actor, date, time, and data reference. The recommended period ranges from six months to one year, and may extend to three years where justified[30][31].
NIS2 covers at least network traffic, changes to accounts and permissions, access, authentication, and privileged activity[29]. ENISA recommends linking these logs to identity and access management, or IAM, processes so that you know who grants or changes access, when, and for which scope[28].
The contrast is clear on three topics: what must be logged, how long logs must be retained, and who must review access.
| Dimension | DORA | GDPR | NIS2 |
|---|---|---|---|
| Logging | Yes, formalised by the RTS | Indirectly, through accountability and security | Yes, for essential and important entities |
| Retention | At least five years for ICT incidents[23] | Six months to one year, up to three years if justified[30][31] | According to risk assessment and investigation needs |
| Privileged accounts | Monitoring and logging mandatory | Access limited to what is necessary | Logging and regular review of administrative activity |
| MFA | Required | Appropriate security measure | Not explicitly imposed |
Beyond the records themselves, the sensitive point is simple: who approves, who checks, and how often?
Governance exists precisely to connect logs, access, and supplier monitoring within one control system. DORA imposes formalised responsibilities, an annual review, and independent audits[22][32]. GDPR requires the DPO to be involved in decisions affecting personal-data processing, particularly logging, monitoring, and access control. NIS2, for its part, reinforces the accountability of the board, which must approve security policies and monitor their effectiveness[26].
In practice, doing all this manually quickly becomes unsustainable. Automation is therefore needed to centralise access rights, identify inactive accounts, and produce audit evidence without spending weeks on it.
This table places the key differences between DORA, GDPR, and NIS2 side by side for a SaaS application already in production. The aim is simple: see, in a practical case, what each text requires on contracts, incidents, access, traceability, and recovery. The differences are most visible in three areas: level of constraint, incident management, and compliance evidence.
| Dimension | DORA | GDPR | NIS2 |
|---|---|---|---|
| Scope | EU financial entities (banks, insurers, investment firms) and their ICT providers, including SaaS applications supporting critical functions [23][36] | Any organisation processing personal data about people in the EU; common for HR, CRM, and collaboration tools [2] | Essential and important entities in defined sectors, as well as certain ICT providers supporting them [8][40] |
| Incidents and continuity | The most structured: classification, initial notification, mandatory resilience tests, and defined reporting deadlines [23][34][36] | Focused on data breaches: notification to the CNIL within 72 hours where there is a risk; the SaaS processor alerts without delay [2][41] | Significant incident: initial warning within 24 hours, follow-up report within 72 hours, final report within one month; continuity measures mandatory [11][8] |
| SaaS third-party monitoring | The most prescriptive: contractual audit rights, exit clauses, data location, and guaranteed continuity [23][39][42] | Mandatory Article 28 contract [2][41] | Security of critical providers: assessment, contractual security clauses, and periodic reassessment [33][40] |
| Logging and governance | Formalised logging of access and ICT operations; incident retention for at least five years; independent audits and documented responsibilities [22][23][38] | Logging of access and security events; time-limited retention; GDPR governance focused on processing compliance [2] | Centralised, immutable logs; retention according to risk and investigation needs; MFA and documented access-rights management [33][35][37] |
In practice, the same SaaS application may fall under all three frameworks. You therefore need to read this table dimension by dimension, not as a simple comparison between texts.
Take a very concrete example: an HR tool used by a French bank. This SaaS application may simultaneously fall under DORA, GDPR, and NIS2. In this situation, the right approach is to apply the strictest requirement for each topic.
In other words, it is not enough to have a clean GDPR contract if DORA additionally requires audit rights, exit clauses, and continuity guarantees. For SaaS third parties and the traceability of critical financial functions, DORA imposes the tightest framework.
After comparing the requirements, you need to move to execution without repeating the same controls two or three times. DORA, GDPR, and NIS2 are easier to manage with a shared process foundation and then a framework-specific variation.
The SaaS inventory is the starting point. It should cover the owner, provider, contract, data, hosting, integrations, subprocessors, and criticality level. This register feeds the GDPR processing register, the DORA mapping of ICT contracts, and the NIS2 inventory of critical providers [43][47][48][51].
Without this foundation, things quickly become disorganised. Classification becomes unclear, access management varies from one team to another, and notifications are sent using criteria that are not aligned. A platform such as Avanoo can automate this discovery, including Shadow IT, from identity logs, expense data, and browser extensions [44][49][50].
Once this foundation is in place, the priority shifts to supplier prioritisation. The idea is simple: classify each provider by risk level - standard, important, or critical - and match each level with due diligence, contractual clauses, and review frequency. The same logic applies to access: least privilege, MFA on sensitive systems, periodic access-rights reviews, and rapid removal of inactive accounts [25][45][46].
Next, think operationally. In the event of a gap or incident, one playbook is better than three procedures that contradict one another. This playbook should cover triage, containment, escalation, notification, and coordination with the SaaS provider. Triage must answer one very practical question immediately: does this affect personal data, a critical function, or both?
Also centralise logs, reports, continuity tests, and access reviews in a single repository, organised by framework [51][52]. In other words, there should be one place to find evidence, not a treasure hunt across several tools.
The table below shows the order of execution.
| Priority | Control | Frameworks covered | First concrete step |
|---|---|---|---|
| 1 | SaaS inventory | DORA, NIS2, GDPR | Automated discovery + Shadow IT detection |
| 2 | Supplier classification | DORA, NIS2, GDPR | Criticality levels + contractual qualification |
| 3 | Incident playbook | DORA, NIS2, GDPR | Triage criteria + notification thresholds |
| 4 | Access and logging | DORA, NIS2, GDPR | MFA + periodic access-rights review + structured logs |
| 5 | Continuity and recovery testing | DORA, NIS2 | Regular continuity and recovery tests |
Once the scope and control differences are clear, it is useful to look at what each framework contributes, in practice, to SaaS risk management.
DORA goes furthest on third-party risk. It is the most precise framework on this point. In return, it only covers the financial sector and comes with a heavy documentation burden.
NIS2 has a broader scope and puts leaders on the front line. This is a strength, because risk management does not remain confined to IT. However, the text goes into less detail than DORA on the clauses to include in contracts.
GDPR remains unavoidable as soon as a SaaS application processes personal data. Its rules on processing and data protection are clear. But it does not address business continuity or non-personal data.
The table below shows, simply, what each framework contributes - and where it stops - for a SaaS application already in production.
| Framework | Main strengths for SaaS risk | Main limits for SaaS risk |
|---|---|---|
| DORA | Highly granular on third-party risk; requires audit rights and exit plans | Limited to the financial sector; high documentation burden |
| NIS2 | Broad sector coverage; explicit leadership accountability | Less detail on contractual clauses; transposition varies between Member States |
| GDPR | Strongest protection for personal data; applies to any organisation processing that data through SaaS | Does not cover operational resilience or non-personal data |
These differences then provide a basis for defining SaaS controls in concrete terms.
The same SaaS tool may fall within the scope of all three texts at once. DORA, GDPR, and NIS2 complement one another: each addresses one aspect of SaaS risk. They rely on common foundations, but their scopes and requirements are not identical.
The right reflex is to manage everything through one system. The idea is simple: avoid silos. In practice, start with a single SaaS register, enriched with the right attributes - criticality, data processed, and supplier dependencies. This foundation can then feed all three frameworks without starting from scratch each time.
Implementation comes down to four actions: map all SaaS in use, including Shadow IT; classify the data and criticality level of each application; document supplier dependencies and contracts; and align governance with clear roles between the CISO, DPO, ICT risk manager, and leadership. Avanoo can automate SaaS discovery, classification, and risk monitoring.
Here are the priorities to address first:
| Priority action | Relevant framework(s) | Expected result |
|---|---|---|
| Map | DORA / NIS2 / GDPR | Complete register |
| Classify | GDPR / NIS2 | Sensitive-data map |
| Document | DORA / GDPR / NIS2 | Up-to-date supplier register |
| Govern | DORA / NIS2 | Clear responsibilities |
One repository, one management system, three requirements covered. The goal is not to build three separate programmes, but to build one SaaS risk-management programme that can cover all three frameworks over time.
::: faq
Look closely at three things: the nature of the SaaS application, your organisation's sector, and the data processed.
The same tool may fall within the scope of all three texts at once. :::
::: faq
From the outset, alert the person or team responsible for qualifying the incident as major. The deadline starts running from that classification. In practical terms, this is what makes it possible to begin notifying the authorities within the deadlines set by DORA and NIS2, such as four hours for DORA and 24 hours for NIS2.
At the same time, bring the crisis-management leads together without delay. In practice, this mainly involves IT, compliance, risk management, and legal teams. Each has a specific role, and the earlier they are mobilised, the clearer the response becomes. :::
::: faq
Prioritise SaaS applications based on a business impact analysis. The idea is simple: start with the ones whose outage would cause the greatest operational damage.
In practice, look first at services whose interruption would significantly affect:
Classification must be based on concrete criteria, not a general impression. Use factual elements such as the type of data processed, operational criticality, hosting location, and level of dependence on the provider.
Another point not to overlook is SaaS identified through Shadow IT or Shadow AI. If these tools process sensitive data, they must enter the register so they can be assessed and brought into compliance. In other words, even a tool that is not very visible today can become a serious issue if it handles sensitive information. :::
Co-fondateur & CEO
Tanguy Duthion is co-founder and CEO of Avanoo. Previously at Google and Asana, he founded Avanoo to help organizations regain control over their SaaS and AI usage.
See how Avanoo can map your SaaS and AI landscape, reduce risk, and optimize costs. A reliable platform with dedicated human support.
