Cloud services complicate compliance with the EU’s NIS2 Directive and Digital Operational Resilience Act, or DORA.

Consider a hypothetical Monday morning disruption. A financial services company loses access to a SaaS platform used in a critical workflow. The provider posts a short status update, confirms that engineers are investigating and promises further information. The customer’s compliance team needs considerably more: which services are affected, whether records remain intact, when the disruption began and whether a regulatory reporting threshold has been reached.

Your Cloud Provider Has a Security Certificate. Can It Help You Survive an Outage?

The security certificate collected during procurement cannot supply those answers. The customer needs a functioning relationship with the provider, contractual access to information and a response plan that works while the service is unavailable.

That gap between supplier assurances and operational needs is the subject of an October 22, 2026, IAPP analysis by BLB Legal partners Tamás Bereczki and Ádám Liber. They examine how standardized cloud services complicate compliance with the EU’s NIS2 Directive and Digital Operational Resilience Act, or DORA. Their concern is practical: regulated customers carry obligations that a supplier’s standard documentation may not adequately support.

For privacy teams, this problem extends beyond system availability. An outage can interrupt access to personal information, delay rights requests or expose uncertainty about backups and deletion. A new supplier or AI feature can also change who receives that information. Supplier oversight needs to connect these consequences to the service the business actually uses.

Start with the right obligations for the entity

NIS2 and DORA have related objectives, but their scope and legal structures differ. The European Commission’s NIS2 overview describes a cross-sector cybersecurity framework implemented through national law. Member States had a transposition deadline of October 17, 2024. A company assessing its obligations now needs to examine the relevant national implementation and its own classification, rather than assume the deadline created identical rules everywhere.

DORA is an EU regulation covering specified financial entities, subject to its scope provisions and exclusions. It has applied since January 17, 2025. The European Banking Authority explains that in-scope financial entities must maintain registers of contractual arrangements with ICT third-party service providers.

These frameworks need to be coordinated. DORA is a sector-specific act for the purposes of NIS2’s Article 4 in relation to relevant financial entities; the Commission’s guidance addresses how equivalent sector-specific requirements interact with NIS2. Teams should establish the applicable regime before creating duplicate reporting procedures.

A certificate is evidence about a defined scope

ISO certifications and SOC reports can provide useful assurance. Their value depends on what they cover, the period examined and the controls or exceptions described. A report about the provider’s infrastructure may leave questions about a particular product, region, acquired business or recently launched feature.

Customers should also examine the responsibilities left to them. If a service supports multifactor authentication, that does not establish that the customer enabled it for administrators. If audit logging requires a higher subscription tier, an assurance document does not establish that the current account produces the records needed for an investigation.

The assessment should connect each important control to an accountable party and usable evidence. For example, the provider may operate the backup system while the customer selects retention settings. The resulting recovery plan needs to state which records can be restored, how restoration is requested and how the customer will verify the result. “Backups available” leaves too much unresolved.

Translate supplier requirements into usable contract terms

NIS2 Article 21 includes supply-chain security among cybersecurity risk-management measures and calls for consideration of direct suppliers’ vulnerabilities and cybersecurity practices. The appropriate review is risk-based. A supplier that supports an essential operational process requires a different level of scrutiny from an easily replaced tool with limited access.

DORA Articles 28–30 establish a more detailed ICT third-party framework. Financial entities retain responsibility for their obligations. Article 30 sets baseline contractual requirements and additional provisions for ICT services supporting critical or important functions. The contract needs to address matters including service descriptions, relevant locations, data access and recovery, incident assistance and termination. The additional requirements include stronger service-level commitments, oversight rights and transition arrangements.

A standard data processing agreement may address some privacy requirements while leaving operational resilience gaps. Procurement should map the necessary obligations against the actual contract and supporting schedules. Missing provisions need a documented resolution; a sales presentation cannot amend a contract.

Audit arrangements require particular care in shared cloud environments. Providers have legitimate reasons to protect other customers’ information. DORA nevertheless imposes specific access, inspection and audit requirements for relevant arrangements, as reflected in European supervisory Q&A material. Customers need to establish how assurance and oversight rights will operate without treating either unlimited access to other tenants or a generic refusal to cooperate as acceptable.

The supplier’s incident notice must leave time to act

Notification clauses should support the customer’s reporting timetable. A commitment to communicate after an investigation is complete may deliver a polished explanation too late for the customer’s initial regulatory assessment.

Under NIS2 Article 23, significant incidents generally trigger an early warning within 24 hours of awareness and an incident notification within 72 hours, subject to the directive’s specific provisions and applicable implementation. These are staged communications, not a requirement to finish every forensic task within a day.

DORA has its own reporting rules. Austria’s Financial Market Authority explains that the initial notification of a major ICT-related incident is generally due within four hours of classification as major and no later than 24 hours after awareness. Delegated Regulation 2025/301 also addresses later classification and other timing provisions. A blanket “72-hour notification” clause would obscure these differences.

The customer should negotiate early operational contact, phased updates and enough information to assess affected services, data integrity, duration and customer impact. Those are practical contracting objectives; the exact reporting obligations depend on the applicable framework and incident classification.

During an exercise, test who receives the first alert when the normal administrator is unavailable. Confirm that contact details and escalation instructions remain accessible if the affected SaaS platform also hosts the vendor register or incident playbook.

A new AI feature can change an approved relationship

A supplier may introduce an assistant, automated summarization or analytics feature after the original assessment. Enabling it can change the data recipients, processing purpose or retention pattern. The absence of an additional license fee does not establish that the feature is risk-free, and the presence of a fee does not establish adequate protection.

France’s CNIL addressed cloud roles in guidance published May 28, 2026. It distinguishes service provision, service improvement and security processing. For service improvement, the provider may be a controller, a processor or a joint controller, depending on who determines the purposes and essential means. The relationship requires an assessment of the particular processing.

The guidance is not a blanket authorization for AI training. Applying its role analysis to a training feature is a separate assessment. Teams should establish whether customer content is used, which entity decides that use, whether another provider receives it and what restrictions apply. An existing processor clause cannot resolve a provider’s independent purposes merely by retaining the same contractual label.

Technical review should then confirm the available settings: whether the feature is enabled by default, whether administrators can restrict eligible data and whether disabling it stops future processing or also affects retained copies. Material changes should reopen the approval rather than wait for the next annual questionnaire.

Two vendors may share one point of failure

A procurement list can suggest diversification while concealing a common dependency. Two SaaS services may rely on the same cloud region, identity provider or other infrastructure. In that situation, switching from one service to the other may offer little protection against the relevant outage.

The useful analysis starts with business functions. Identify the dependencies that could interrupt each function and ask which alternatives remain available if those dependencies fail together. This is more informative than counting vendor logos or assuming that a second contract creates independence.

An exit plan also needs an operational test. A business should know whether exported records include attachments, permissions and useful metadata; whether another system can read them; and which credentials or support channels are needed to obtain them. An export process available only through the failed service may be inadequate for the scenario being planned.

Maintaining an alternative can be costly, and not every service warrants duplicate infrastructure. The decision should reflect the function’s importance, acceptable downtime and feasible workarounds. Where the business accepts a limitation, its approval should identify the consequence and the conditions that would require reconsideration.

Connect the assessment to the deployed service

A supplier file becomes useful when it connects the contract, business owner, processing activities and current configuration. Reviews should reopen when a supplier changes a material dependency, introduces another recipient, moves relevant processing or alters a critical control. A renewal date alone cannot capture those events.

Captain Compliance supports the privacy and governance side of this work through data mapping, assessment workflows and AI governance. These capabilities help connect systems and vendors to owners, document reviews, assign controls and preserve the evidence behind approvals. When a cloud feature changes how personal information is used, that connection helps the right team assess the change.

The supporting records still need accurate inputs and technical validation. A privacy inventory does not automatically satisfy DORA’s prescribed register requirements, and a completed assessment does not demonstrate that a recovery process works. The organization must validate the relevant regulatory records and test its operational controls.

Service credits cannot restore a missed obligation

A supplier may offer credits when availability falls below an agreed level. Those credits can settle a contractual calculation while leaving the customer with interrupted operations, unanswered questions about personal information or a reporting deadline it could not meet.

That is the decision procurement and leadership need to confront before signing. If a provider cannot deliver the information, assistance or transition support a regulated function requires, someone must resolve that gap or decide against the arrangement. The most valuable sentence in a supplier assessment may be the one that explains why the business declined a convenient service.