What cloud provider due diligence under NIS2 requires from you
A NIS2 entity must assess its cloud provider before the contract is signed and keep assessing it for as long as the relationship lasts. The duty to manage risk under Article 21 stays with your organization even when the provider runs the infrastructure, so a provider's own security posture does not discharge your obligation. A customer questionnaire, a contract clause or a national authority's information request can now ask for this assessment in writing, and your answer needs to show who checked what, when, and what was decided as a result. The depth of the assessment depends on several factors: your sector and whether you are an essential or important entity, which workloads you move to the cloud, the terms of the contract, and the provider's own status. Cloud computing service providers fall within the scope of Commission Implementing Regulation (EU) 2024/2690, and NIS2 defines a cloud computing service in Article 6(30) as a digital service enabling on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources. Confirm with your national authority and sector counsel whether the provider's services and your own classification bring the assessment under additional sector rules.
No NIS2 certificate exists that you can accept in place of this assessment. Supervisors oversee compliance through inspections, security audits, scans and information requests, so a provider's general attestation or certificate is one input among several, and you must explain how it maps to the workloads you actually run. Ask the provider which of its services fall in scope, whether it has notified its own national authority as a relevant entity, and how it documents its incident thresholds for cloud services. Start with a written inventory of the workloads, data and identity dependencies you are moving, then record your assessment of each criterion against that inventory. Keep the record current, because reassessment is required at planned intervals and after significant changes or incidents.
Which provider facts to verify first
Before you sign or renew with a cloud provider, four facts shape your NIS2 position: the provider's own status, the incident thresholds it applies, how locked in you would be, and what evidence it will hand you. Confirm each in writing, because your management body remains accountable for the outcome whatever the provider's marketing says.
The provider's own NIS2 status
Ask whether the provider is an essential or important entity in its own right under NIS2 or the transposition law of the Member State where it is established. Cloud computing service providers fall within the Implementing Regulation's technical requirements, so a provider in scope should be able to explain which Article 21 measures it operates and how it reports to its competent authority. A clear, dated answer naming the authority is a good sign. A vague reference to being "NIS2 ready" is not. Note that a provider certificate does not prove NIS2 compliance.
Incident thresholds for cloud services
For cloud computing services, an incident is significant if a service is completely unavailable for more than 30 minutes, or limited for more than 5% or more than 1 million EU users (whichever is smaller) for over one hour. Ask the provider how it measures these thresholds, how quickly it notifies customers, and what it will report about incidents affecting your tenancy. Your own reporting clock under Article 23 depends on the timeliness of this information, so confirm notification terms in the contract.
Diversification and lock-in position
The Implementing Regulation requires supplier selection to weigh the ability to diversify supply and limit vendor lock-in. Ask which services depend on proprietary APIs, managed databases or region-specific features, and whether workloads can run on another provider or on your own infrastructure. A good answer names the portability tools, documented export formats and any egress costs. Ask for an estimate of migration effort from the provider and check it against your own exit plan.
Audit reports and evidence shared
Ask which independent audit reports, certifications and attestations the provider will share, their scope, the period covered and the exceptions noted. Also ask whether it will grant your auditors or competent authority access, and how it delivers SLA performance reports so you can monitor them at planned intervals. A good answer provides current reports under a non-disclosure agreement and states which of your controls the provider does not cover. Reports prove the provider's controls, not yours.
Who owns which duties in a cloud deployment
Your organization owns its NIS2 controls. The management body approves the Article 21 measures and carries accountability for them, and the compliance team decides how each cloud duty is met, documents it and keeps the evidence current. Outsourcing can prepare the work, but it does not move ownership of the decisions or the risk.
- Configuration: Set the baseline for cloud accounts, network boundaries and workloads, and approve exceptions in writing.
- Identity and access: Decide who may administer tenants, require strong authentication for privileged roles, and review access on a planned cycle.
- Logging and backups: Define which logs are retained, who reviews them, and how backup copies, configuration data and restoration tests are kept and checked.
- Incident notification: Own the decision to report under the Article 23 timelines, and confirm the provider's notification duties in the contract match your own deadlines.
- Contract management and reassessment: Review SLA reports, review supplier-related incidents, and reassess the provider at planned intervals and after significant changes.
Confirm with your legal team which of these decisions your board has formally delegated, and keep that delegation on record.
The cloud provider delivers the services named in the contract and is responsible for the security of the underlying infrastructure it operates. Its own NIS2 status, incident thresholds and certifications are inputs to your due diligence, not substitutes for your own controls. What the provider does for you depends entirely on the service model and the written terms.
- Configuration: Maintain the physical and platform layer, and document which configuration settings the customer can change and which the provider manages.
- Identity and access: Operate the provider's own staff access controls and the identity services it supplies, and state how its staff are vetted and trained.
- Logging and backups: Provide the logs and backup features it has agreed to deliver, and state retention periods and where copies are stored.
- Incident notification: Notify you of incidents affecting its services within the contractual window, with enough detail for your own reporting decisions.
- Contract management and reassessment: Supply SLA reports, audit reports or evidence the contract grants, and disclose subcontractors and exit assistance terms.
Check the shared responsibility matrix in the provider's documentation against your contract, because gaps between the two are where incidents are usually lost.
An independent auditor, assessor or certification body tests controls and issues any report or certificate. Neither your implementation partner nor the cloud provider can issue those documents on your behalf. NIS2 does not create a certificate, so assessments are typically used as evidence for supervisors, customers and internal governance rather than as a legal attestation.
- Configuration and access: Sample configuration baselines, privileged accounts and change records to test whether controls operate as documented.
- Logging and backups: Test that logs are retained and reviewed, and that restoration works within the recovery times the entity has set.
- Incident notification: Review the incident process and sample past events to check that reporting followed the defined timelines.
- Contract management and reassessment: Check that supplier reassessments happened, that audit reports relied upon are current, and that scope covers the cloud services in use.
- Scope limits: Confirm which provider reports cover which services, and whether a report covers the period you need.
Before engaging an assessor, ask what scope and period their report will cover and whether it can be shared with your supervisor.
Which cloud sourcing model fits your risk profile
This table compares a single hyperscale provider, a multi-provider or multi-region design, and a self-hosted deployment in your own data center or dedicated private cloud. Read each row against your own risk assessment, because Implementing Regulation (EU) 2024/2690 expects the ability to diversify supply and limit vendor lock-in to be considered and documented. No model is automatically compliant; the right choice is the one you can justify and evidence.
| Model | What it improves | What it makes harder to evidence | Lock-in exposure | When it fits |
|---|---|---|---|---|
| Single hyperscale provider | Mature managed services, provider-run physical security and resilience, fast provisioning, and a single contract to oversee | Provider-side controls you cannot inspect directly, reliance on the provider's audit reports, and shared-responsibility boundaries that must be mapped line by line | High, through proprietary managed services, data gravity and egress costs | Lower-criticality workloads where the risk assessment accepts concentration and the exit plan is tested |
| Multi-provider or multi-region design | Reduces dependence on one provider or one geography, and gives options if a region or provider fails | Two sets of provider status, incident thresholds and audit reports to track, plus cross-provider identity, logging and backup consistency | Medium to high, since portability is often limited by provider-specific services unless the design avoids them | Significant or critical services where continuity requirements and the supplier risk assessment call for diversification |
| Self-hosted in your own data center or dedicated private cloud | Direct control over configuration, logging, backup location and access paths, and fewer third-party dependencies in the core stack | You must produce the evidence yourself, including physical security, hardware lifecycle and capacity records, which an assessor will test directly | Low to medium, depending on the hardware and virtualization stack and on any external hosting partner | Sensitive workloads, sovereignty constraints, or organizations with mature infrastructure teams and a documented capacity plan |
| Hybrid of private and public cloud | Keeps critical data and control planes under your control while using public capacity for peaks or less sensitive workloads | Clear data flow mapping, consistent policy across two environments, and separate evidence sets for each side | Medium, concentrated where workloads depend on provider-specific services | Organizations that must keep some systems on premises but need elastic capacity for others |
How incident thresholds shape your contract terms
For a cloud provider, the NIS2 significance test is the yardstick your contract should measure against. An incident is significant when a service is completely unavailable for more than 30 minutes, or limited for more than 5% or more than 1 million of its EU users, whichever is smaller, for over one hour. Translate that into the contract: write a notification clause that obliges the provider to tell you about any event that could meet either limb, with a deadline short enough for you to meet your own 24-hour early warning under Article 23. Do not rely on the provider's public status page to decide this. Ask the provider to state in the contract how it counts affected EU users, since a percentage threshold is meaningless if the provider cannot tell you how many users a degraded region serves.
The second step is to test whether the provider can measure what the thresholds require. Ask how availability is calculated for each service you buy, whether partial degradation is counted at the service, region or tenant level, and how long the provider takes to confirm an outage's start and end time. Request the SLA reports for the services in scope, and check that they show the duration, scope and user impact of each event rather than only a monthly uptime percentage. Schedule a review of these reports at planned intervals and after any significant incident, and record which events you judged to be supplier-related incidents and why. Those review records are part of the evidence an authority will ask for.
Finally, be clear about what the provider's reporting does not do. The provider may have its own obligations as a cloud computing service provider, but those do not replace your duty to decide whether an incident is significant for your entity and to report it under Article 23. Your management body should assume that a provider's notice arrives late or describes the event narrowly, and your incident process should start its own clock from the moment you learn of a possible impact on your services. Confirm with the provider who will be your contact at 2 a.m., what information they will supply within the first hours, and how they will support follow-up questions during the one-month final report.
How the due diligence cycle runs from selection to exit
The sequence turns a cloud provider choice into a documented, reviewed and exit-ready relationship that the management body can account for. Each step leaves a record that a supervisor or auditor can test. The cycle repeats after material changes or incidents, not only at contract renewal.
Scope the cloud services and data
Start by listing each cloud service you plan to use, the systems and data it will hold or process, and which of your NIS2-relevant services depend on it. Assign an owner in your organization for each service, usually the business or platform lead, with the security function reviewing the list. The output is a scoped inventory that names services, data classes, locations where practical, and dependent processes. Confirm the inventory before any evidence is requested, because every later step depends on it.
Collect the provider's evidence and audit reports
Request the provider's independent audit reports, certifications and security documentation that cover the services in scope, and ask how the provider's own NIS2 status and significant incident thresholds apply to its cloud computing services. Check report dates, the period covered, the scope boundary and any exceptions. Ask the provider which parts of the shared responsibility model remain with you. The output is an evidence register that records each document, its issuer, its scope and the gaps you still need to close.
Assess selection criteria and lock-in
Score the provider against the supplier selection criteria your supply chain policy sets, covering cybersecurity practices, ability to meet your security specifications, resilience, and whether you can diversify or move away without unacceptable disruption. Document how multi-region or multi-provider options, data portability and dependence on proprietary services affect your exposure. Where a single provider carries critical services, record the mitigation you accept. The output is a signed assessment record that names the decision maker and the residual risks.
Negotiate the contract clauses
Agree the contract terms that the implementing regulation expects where they are appropriate: cybersecurity requirements, staff training and background checks, incident notification without undue delay, audit rights or access to audit reports, vulnerability handling, subcontracting rules and exit obligations. Have legal counsel and your security lead review each clause against the assessment record. The output is an executed contract with a clause map that links each requirement to the section that contains it.
Onboard with documented configuration
Before production use, deploy the services according to a documented baseline that covers identity and access controls, logging, encryption settings, network boundaries and the backup design. Include backups of configuration data and data in the cloud environment, with recovery times and retention periods set by your backup plan. Test restoration into a controlled environment. The output is a configuration baseline, a backup and restoration test record, and a sign-off showing who accepted the service for production.
Monitor SLA reports and supplier incidents
Once the service runs, review the provider's SLA reports on a regular schedule and compare reported availability and performance against what your contract and your incident thresholds require. Review each supplier-related incident, including how the provider notified you and whether the notification met the contract timing. Feed results into your own incident register so that reporting duties toward authorities can be assessed. The output is a monitoring log with dated reviews, exceptions raised and actions assigned.
Reassess at planned intervals and after changes
Repeat the assessment at intervals your supplier policy sets, and also after a significant change in the provider's services, its ownership or its locations, and after any significant incident involving the provider. Re-check audit reports, contract performance and the lock-in position. The output is a dated reassessment note that states whether the provider remains acceptable, what changed, and which contract or configuration actions follow.
Plan the exit and test it
Document how you would move data and services away from the provider, including the exit obligations in the contract, data export formats, the order of migration, and the backups you would use if the provider fails. Test the parts you can test, such as data export and restoration to an alternative environment, and record the results. Confirm with the provider how it deletes or returns data at termination. The output is a tested exit plan with recorded results and named owners, which feeds back into the next assessment cycle.
What usually weakens cloud due diligence and how to prevent it
Cloud due diligence under NIS2 tends to fail in the gaps between a provider's documents and what your entity actually does. The cards below cover the failures we see most often, what each does to your obligations, and the check that closes it. Each one is a decision your management body can ask about before a regulator does.
Certificate treated as proof
A provider's certificate or audit report shows that someone tested certain controls at a point in time. It does not show that the provider meets NIS2 obligations, that its incident thresholds match yours, or that it covers the services you actually use. Treating it as proof leaves you unable to explain your own supplier decision. Ask which services, regions and controls the report covers, check its period, and record which gaps you accepted and why.
Backups missing configuration
Many cloud backup plans copy data volumes but not the infrastructure definitions, identity settings, network rules or the cloud-environment copies that restoring a service depends on. Under the implementing regulation, backup plans must cover complete and accurate copies, configuration data and data in cloud environments, stored away from the main system's network and site. Test a full restore into an empty account or region, then compare what came back with what was lost.
Exit terms never tested
Exit clauses often promise data return on termination but never state the format, the timeline, the deletion proof or the support available during migration. Lock-in grows quietly through proprietary services and egress costs. The implementing regulation expects you to weigh the ability to diversify and limit vendor lock-in. Run a tabletop exit for one critical workload, export its data and configuration, and confirm another platform can run it.
SLA reports nobody reviews
Providers publish availability and performance reports, but many entities never assign anyone to read them. Without a defined review, a pattern of degraded service or repeated supplier-related incidents goes unnoticed until it becomes a reportable event. The implementing regulation requires you to monitor supplier SLA reports and review supplier-related incidents. Assign an owner, set a monthly review, and log each finding with the action taken.
Reassessment only at renewal
Many entities review a cloud provider when the contract comes up for renewal and nowhere else. Architecture changes, new regions, acquired subsidiaries, provider ownership changes and significant incidents can all alter the risk while the contract stays the same. The implementing regulation calls for reassessment at planned intervals and after significant changes or incidents. Write those triggers into your supplier procedure so that a change in scope reopens the file automatically.
Unwritten shared responsibility
Providers describe a shared responsibility model, but the split between provider and customer often lives only in marketing material. Identity configuration, encryption key management, logging retention and patching of customer-deployed software frequently stay with the entity, yet teams assume the provider handles them. Map each control in your risk assessment to a named owner, write that split into the contract or an annex, and review it when services change.
Questions buyers ask about cloud provider due diligence
Can a NIS2 entity rely on its cloud provider's certification?
Partly. A certificate or audit report from the provider shows that an independent assessor tested certain controls on a certain scope at a certain date, but it does not transfer your obligations. NIS2 creates no certificate of compliance, so your national authority will ask what you did to assess the provider, how you monitor it and what you do when it fails. Implementing Regulation (EU) 2024/2690 expects you to weigh cybersecurity practices, the ability to meet your security specifications and the ability to diversify supply, and to check whether the provider's audit reports cover the services you actually use. Read the scope statement of each report and confirm which shared responsibility controls sit with you.
What does a cloud provider due diligence assessment cost in internal effort?
No supplied fact gives a price or hours for this work, so treat any figure you see elsewhere with caution. The internal effort is driven by the number of cloud services in scope, how many of them hold regulated or essential-service data, how many accounts or regions you use, and how much of the provider's documentation you must review yourself. Expect recurring effort for reviewing SLA reports, incident summaries and reassessments, not only a one-time review. When you request a quote for outside help, ask which deliverables are included, who reviews the provider's audit reports, how evidence is handed over and what happens if the provider's documents do not cover your scope.
How long does it take to set up cloud provider due diligence?
The timeline depends on how many providers you use, how mature your supplier inventory is and whether your contracts already include the clauses you need. No supplied fact gives a duration, so confirm the schedule against your own environment. A practical sequence is to inventory cloud services and dependencies, classify them by impact, collect the provider's NIS2 position and audit reports, compare them with your requirements, and then negotiate contract changes where gaps exist. Renegotiation is often the slowest step because it depends on the provider's willingness to accept changes.
What does the work need from management and engineering teams?
Management must approve the supplier policy, accept the risks that remain and make sure the assessment is resourced, because the management body can be held liable for infringements of the Article 21 measures under Article 20(1). Engineering teams must document architecture, identify which services depend on which provider, define recovery objectives, and confirm which controls they operate themselves, such as identity configuration, encryption keys, logging and backups. Procurement and legal teams own the contract and exit terms. Agree on these roles in writing before the work starts so that no control falls between teams.
Can we do cloud provider due diligence in-house?
Yes, many entities do it in-house, provided they have people who can read audit reports, understand shared responsibility models and test their own configurations. The work becomes harder when several providers are involved, when reports use different scopes and dates, or when the team lacks cloud security depth. Keep in mind that the entity remains accountable regardless of who prepares the material. An outside firm can prepare evidence, review configurations and draft exit plans, but it cannot make the risk decisions or issue an assurance report on your behalf.
What does a cloud exit obligation require in practice?
Implementing Regulation (EU) 2024/2690 asks that contracts, where appropriate, include exit obligations, and that your supplier policy addresses the ability to limit vendor lock-in. In practice, you need a documented exit plan for each critical cloud service: the data and configuration you must be able to export, the formats, the expected time to move, the alternative platforms or diversified capacity, and the steps for deleting data at the provider afterward. Test parts of the plan, at least by restoring a backup copy outside the provider. Confirm with the provider which export tools, notice periods and data deletion terms its contract actually includes.
Must the cloud provider be registered or named to the authority?
The supplied facts do not establish a general duty for a NIS2 entity to register or name its cloud providers to the national authority, so confirm this with your competent authority and national transposition law. Separately, the cloud provider has its own NIS2 status: NIS2 covers cloud computing service providers, and the provider must meet the incident thresholds in the implementing regulation. Ask the provider whether it is in scope in its Member State and how it will notify you of significant incidents affecting your services. Do not assume that a provider's registration fulfils your own obligations.
When is outside help worth buying for cloud provider due diligence?
Outside help is worth considering when your cloud estate is large, spans several providers or regions, or supports essential services where a gap would be costly to defend before a supervisor. It is also useful when you need an exit plan tested, backups in cloud environments verified or contract clauses drafted against the implementing regulation. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares systems and evidence for assessments. It does not audit providers or issue reports, and the work is usually fixed-scope, with scope and deliverables agreed in writing before work starts.
How DeployOpen prepares cloud evidence for your NIS2 assessment
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For cloud provider due diligence under NIS2, we help you assemble the evidence that shows how your cloud estate is configured, backed up, monitored and exited, while your management body keeps ownership of the decisions and the provider assessment.
How we scope
- The written scope lists which cloud accounts, regions, workloads and self-hosted platforms the provider review covers.
- We record which provider duties you are relying on, such as incident notification and audit reports, and which remain with your team.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure backups of cloud-hosted configuration data and data copies, with access controls, retention periods and restoration tests.
- We set up logging and monitoring so your team can review provider SLA reports and supplier-related incidents.
- We document exit paths, including how workloads and data move if you change or leave a cloud provider.
How we hand over
- You receive documented configurations, runbooks, test results and an evidence index mapped to your scope.
- We walk your security and compliance staff through the evidence so they can answer provider and supervisor questions.
- Independent auditors and certification bodies issue any reports or certificates. DeployOpen prepares systems and evidence only.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover periodic reviews of provider reports and reassessments after significant changes or incidents.
- Ask us to confirm in writing which cloud platform capabilities and provider features apply to your environment before relying on them.
