Does NIS2 apply to our cloud, data center or CDN service?
A customer or regulator is asking for NIS2 evidence, and the first question is whether your cloud computing, data center or content delivery network service falls under the Directive at all. Cloud computing, data center and CDN providers are in scope as digital infrastructure under Annex I of NIS2, and the binding technical rules for their Article 21(2) measures come from Commission Implementing Regulation (EU) 2024/2690. The answer for your organization depends on three things: whether your service matches the statutory definitions, which Member State is your main establishment in the Union, and how that Member State's transposition law applies. Read the definitions in NIS2 Article 6 against your actual service catalog, not your marketing description.
The definitions matter because they draw lines that are easy to misread. A cloud computing service is defined by on-demand administration, broad remote access and a scalable, elastic pool of shareable resources. A data center service covers structures dedicated to centralized accommodation, interconnection and operation of IT and network equipment, with the power and environmental infrastructure around them. Recital 35 excludes in-house corporate data centers that an entity owns and operates for its own purposes, but a data center service sold to others can be in scope even when it is not sold as cloud. Confirm with counsel which of your offerings meet each definition, and record the reasoning, because a supervisor will ask for it.
NIS2 creates no certificate of compliance. Your organization owns its controls, and the national competent authority or an independent auditor assesses them through inspections, audits, scans and information requests. Ask your counsel or national authority to confirm the transposition law and registration duty that apply to you, and plan to prepare the evidence for each measure before a customer or regulator asks. Implementation partners can prepare systems and documentation, but only an independent assessor or the authority can issue findings about your compliance.
Which of our services are in scope?
NIS2 defines a cloud computing service as a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources, including where those resources are spread across several locations (Article 6(30)). Infrastructure-as-a-service and platform-as-a-service offerings sold to customers usually fit this wording when customers provision compute, storage or networking themselves and the pool can scale. The definition is about the function, not the marketing label, so a managed hosting product with fixed capacity may fall outside it.
- On-demand provisioning: Confirm whether customers can create and release resources without contacting your staff.
- Shared, scalable pool: Check whether resources are pooled across tenants and can grow or shrink.
- Remote broad access: Establish whether customers reach the service over networks rather than on-site.
- Dedicated hosting: Fixed, single-tenant capacity set up per customer may need a separate analysis.
- Multi-location resources: Distribution across sites still counts under the definition.
Confirm with counsel and, where the position is unclear, the national competent authority of your main establishment how these criteria apply to each product in your catalog.
Software-as-a-service is not named separately in the definition, so whether a SaaS product is a cloud computing service depends on whether the customer gets the on-demand, scalable, remotely accessed resource pool described in Article 6(30) or simply uses an application. A SaaS provider that runs its own application on shared infrastructure should review the definition for each product, because the answer can differ between a multi-tenant application that scales its own compute and a single-purpose tool. Whether a SaaS company is in scope at all is a separate question covered by the sector and size rules.
- Application versus resource access: Customers using an end-user application alone may not receive the resource pool the definition describes.
- Scalable infrastructure: Check whether the platform itself allocates shareable compute for customers.
- Product-by-product review: One company can operate products on both sides of the line.
- Bundled services: A managed service wrapped around a cloud platform may change the analysis.
- Sector overlap: Online platforms and managed services have their own definitions, so review those too.
Ask counsel to document the reasoning for each product line so the position can be shown to a supervisor.
NIS2 defines a data centre service as one that covers structures dedicated to the centralized accommodation, interconnection and operation of IT and network equipment providing data storage, processing and transport, including all facilities and infrastructure for power distribution and environmental control (Article 6(31)). Colocation providers that rent racks, power, cooling and cross-connects to customers usually match this description. Recital 35 adds that data centre services can be in scope even when they are not offered as cloud computing, so a colocation business does not need to run a cloud platform to fall under the definition.
- Dedicated structures: Facilities built or operated to host IT and network equipment are the core case.
- Interconnection: Cross-connect, meet-me room and carrier interconnection services fall within the wording.
- Power and environmental control: Power distribution and cooling infrastructure are named in the definition.
- Customer-owned equipment: Hosting third-party servers is the typical trigger.
- Partial services: Confirm whether a single service, such as remote hands only, changes the picture.
Confirm with counsel how the definition applies to each site and contract type, and check the national transposition law for any additional criteria.
Recital 35 states that the term data centre service should not apply to in-house corporate data centres owned and operated by the entity for its own purposes. An organization that runs its own data center only for its internal systems, with no third parties hosted there, is therefore likely outside the data centre service definition for that facility. The exclusion turns on ownership, operation and purpose. If the same facility begins hosting outside customers or affiliates as a service, the analysis changes, and the organization should reassess before offering that service.
- Owned and operated by the entity: Both ownership and day-to-day operation should sit with the organization itself.
- Own purposes only: Hosting for unrelated customers removes the exclusion for that use.
- Group entities: Confirm how affiliates and subsidiaries using the facility are treated under national law.
- Outsourced operation: A third-party operator running the facility may not fit the in-house wording.
- Other obligations: The entity may still fall under NIS2 in its own sector, even if this facility is excluded.
Confirm the boundary with counsel, and record the purposes for which the facility is used so the exclusion can be justified.
NIS2 defines a content delivery network as a network of geographically distributed servers that ensures high availability, accessibility or fast delivery of digital content and services to internet users on behalf of content and service providers (Article 6(32)). A provider that operates such a network for customers, delivering their content and services to end users, matches the definition. An organization that uses a CDN only for its own websites and applications is in a different position, because the definition is framed around delivery on behalf of content and service providers.
- Geographic distribution: Servers spread across locations to speed up or secure delivery.
- On behalf of others: Delivery sold or provided to third-party content owners is the core case.
- Availability and speed: The purpose of the network is high availability, accessibility or fast delivery.
- Self-use: A company's own CDN for its own properties may fall outside the wording.
- Mixed models: Providers offering both delivery and security features should review each product separately.
Confirm with counsel and the national authority how the definition applies to your edge network and to any services bundled with it.
When a cloud, data center or CDN incident becomes significant
NIS2 sets separate significance thresholds for cloud and CDN providers and for data center providers. Each criterion translates into a specific detection and measurement need, because the reporting clock only starts once you can show that a threshold was crossed.
Complete unavailability over 30 minutes
For cloud computing and CDN providers, a service that is completely unavailable for more than 30 minutes is significant. Monitoring must therefore measure full outages per service, not just host health. Probes should run from several EU locations, and the outage start time must be recorded from the first failed check, so you can establish when the 30-minute window opened. Confirm with your counsel how your national authority reads "completely unavailable" for partially degraded services.
Limited availability for users and time
A cloud or CDN incident is also significant when availability is limited for more than 5% or more than 1 million EU users, whichever is smaller, for over one hour. Detection needs per-tenant and per-region user counts, so you can calculate the affected share and the lower of the two figures. Without user-level telemetry, you cannot prove the threshold was or was not met, and assessors will ask how you did the calculation.
Data center complete unavailability
For data center service providers, complete unavailability of a data center service is significant. Monitoring should cover power, cooling and network feeds to each facility, plus the service endpoints customers consume. Keep a per-facility service dependency map, so an alarm at a power distribution unit can be traced to the customer services it takes down. Record the time of each state change in a single time-synchronized log to support the reporting timeline.
Limited data center availability over one hour
Limited availability of a data center service for more than one hour is a separate significance criterion from complete unavailability. Partial failures, such as one of two power paths or a degraded cooling zone, must be detected and timed as partial outages. Define in your runbook which degradations count as limited availability, and record the affected customers and capacity so you can explain the impact in the notification.
Compromised physical access
Compromised physical access to a data center is significant on its own, with no duration threshold. Controls include badge and turnstile logs, camera coverage at entry points, mantrap alarms and tamper sensors on cabinets. Review whether access logs are retained and protected from the same events they record, and test that an alert reaches the security operations team outside business hours.
Evidence for the reporting timeline
The early warning, notification and final report all depend on a timeline that an assessor can reconstruct. Keep a time-stamped incident record that captures detection, the moment each threshold was crossed, the affected users or facilities, and the decisions taken. Confirm the exact content and deadlines of each report with your competent authority and the implementing rules, because the reporting clock depends on when you became aware of a significant incident.
What Implementing Regulation 2024/2690 asks cloud and data center providers to evidence
Implementing Regulation (EU) 2024/2690 sets the technical and methodological requirements for the Article 21(2) measures that cloud, data center and CDN providers must meet. The areas below are the ones that most often shape the evidence a supervisor will ask to see. Confirm the exact requirement wording in the regulation itself and use ENISA's guidance to shape the evidence you collect.
Risk management and policy
Providers must run a documented risk assessment that covers their cloud, data center or CDN services, and they must maintain policies that follow from it. Supervisors will look for a risk register tied to specific services, a named owner for each risk, and evidence that the register changes after incidents, audits and major platform changes. Check that the policy set covers every service you sell, not only the core platform.
Access control and identity
The regulation expects control over who can reach management planes, tenant data and physical infrastructure. In practice this means role-based access, strong authentication for administrators, periodic access reviews and prompt removal of leavers. Test whether your identity provider logs can answer the question of who changed a configuration, from which account and when, because that answer is what an assessor asks for first.
Business continuity and backups
Cloud, data center and CDN providers must show how services keep running during disruption and how they recover. Keep tested recovery procedures, documented recovery objectives per service, and restore records from real exercises rather than plans alone. Because the significant incident thresholds in Article 7 and Article 8 turn on availability, continuity evidence is also incident evidence.
Physical and environmental security
For data center providers, physical access and environmental controls are part of the technical requirements, and compromised physical access is itself a significant incident. Evidence includes access logs for facilities, visitor controls, power and cooling monitoring, and maintenance records. Confirm which physical controls sit with your landlord or colocation partner and which you must evidence yourself.
Cryptography and key management
The regulation asks providers to protect data in transit and at rest using appropriate cryptographic measures and to manage keys across their lifecycle. Document which algorithms and protocols you use, where keys are generated and stored, who can use them, and how keys are rotated or revoked. Ask your hardware and software vendors to confirm their default cryptographic settings in writing.
Supply chain and supplier oversight
Cloud and data center providers depend on hardware vendors, network carriers, software components and subcontracted operators. The regulation expects you to assess these suppliers, set security requirements in contracts and track their vulnerabilities. Keep a current supplier inventory with security criteria, contract clauses and records of reviews, since a supervisor may ask how a compromised supplier would reach your services.
How the path to readiness and supervision runs
The sequence moves a cloud, data center or CDN provider from confirming that NIS2 applies to it, through registration and a gap assessment against Implementing Regulation (EU) 2024/2690 and Article 21, to tested evidence that a supervisor or independent auditor can review. Each phase closes with a named output that feeds the next.
Confirm scope and jurisdiction
Start by establishing whether the service falls within the cloud computing, data center or CDN definitions, whether any part is an in-house corporate data center excluded under Recital 35, and whether the entity is essential or important. Then identify the Member State of main establishment under Article 26, since that state's authority supervises the provider. Legal counsel usually owns the classification, with management signing it off. The output is a written scope memo naming the services in scope, the classification, and the competent authority.
Register with the national authority
Providers in these categories must submit registration information to their national authority, which Member States had to require by 17 January 2025 under Article 27(2). Confirm the exact submission route, data fields and update obligations with the competent authority in your Member State, since these are set nationally. Compliance or legal staff own the filing, and the registry confirmation or submission record is the evidence that this step is closed.
Run a gap assessment against 2024/2690 and Article 21
Map your current controls against the technical and methodological requirements of Implementing Regulation (EU) 2024/2690 and the ten minimum measures in Article 21(2). Use ENISA's non-binding technical implementation guidance for examples of evidence and framework mappings, and record which requirements are met, partly met or missing. Security leadership owns the assessment, with platform engineering supplying the technical facts. The output is a gap register with an owner, a remediation action and a priority for each open item.
Remediate and collect evidence
Close the priority gaps in configuration, access control, logging, backup, physical security, change management and supplier management, then gather proof that each control operates as described. Evidence typically includes approved policies, configuration baselines, access reviews, test records and management approvals. An implementation partner can prepare systems and evidence, but the provider owns each control. The output is an evidence library indexed to each requirement in the gap register.
Test incident handling and significance thresholds
Confirm that monitoring and the incident response process can detect an event, judge whether it is significant under the thresholds for cloud, CDN and data center services in Articles 7, 8, 9 and 10, and produce the Article 23 early warning, notification and final report within the required windows. Run a tabletop or technical exercise against a realistic availability or physical access scenario, using a clearly labeled hypothetical. The output is an exercise report listing gaps and the fixes assigned to each owner.
Hold the pre-review and assemble the file
Before any supervisory inspection, security audit or independent assessment, review the evidence library against the gap register and confirm each record is current, approved and traceable to its requirement. Management should review the governance record under Article 20, including its approval of the Article 21 measures and completion of training. The output is a review-ready file that a supervisor can navigate without assistance from the provider's engineers.
Respond to supervisory or audit review
Supervision follows the provider's Member State rules. Competent authorities may use inspections, security audits, security scans and information requests, and NIS2 itself creates no certificate of compliance. Where a provider commissions an independent auditor or assessor, that party issues any report, and DeployOpen-style implementation partners only prepare systems and evidence. Ask the authority or auditor for the scope, timing and evidence list in writing before the review. The output is documented responses, remediation records and closure of each finding raised.
Which Member State supervises a provider that serves the EU
For cloud, data center and CDN providers, the Member State of main establishment decides which national authority supervises you, not the number of countries where your customers sit. Article 26(1)(b) of NIS2 places these providers under the Member State where they have their main establishment in the Union. A provider headquartered in one EU country and serving customers in twenty others is generally supervised by the first country, and the other Member States do not run parallel supervision for the same obligations. Non-EU providers offering services in the Union must identify where their main establishment sits under the same rule, and the decision affects which national law, supervisor and incident channel they deal with.
Groups with several EU offices should not assume the registered seat or the largest office is the main establishment. Confirm the question against the text of Article 26 and against your actual decision-making: where the decisions on cybersecurity risk measures are taken, and where operations are carried out. Document that analysis in a written memo approved by the management body, and revisit it after reorganizations, new data center regions or changes in who runs security. Article 27(2) also required Member States to collect registration information from cloud, data center and CDN providers by 17 January 2025, so check that your registration reflects the same main establishment you have documented and that your contact details are current.
National transposition laws may add rules on top of the Directive, including registration procedures, supervisory practice and local reporting channels, so confirm the position with the authority in the Member State you have identified. The Commission's proposal COM(2026) 13 of 20 January 2026 would amend NIS2, but it remains a proposal that the European Parliament and the Council must still approve, so do not plan around its terms as settled law. Ask your counsel or the relevant national authority which version of the rules applies to your entity today.
What must be in place before a supervisor or auditor looks
A supervisor reviewing a cloud, data center or CDN provider will ask for proof that the program exists and runs, not just policies on file. The cards below cover the records that connect governance, service scope, incident reporting, suppliers, physical security and availability, and each one lists how to check it internally before anyone outside looks.
Management body approval of measures
Article 20 expects the management body to approve the Article 21 risk-management measures and oversee their implementation. Keep the signed approval, the date it was given, and the minutes showing the board reviewed the risk assessment and residual risk. Check internally that the approver named in the minutes is the same body that carries liability under the directive, and that the approved version matches what operations actually runs.
Asset and service inventory
Providers in this sector must know which cloud services, data center facilities, CDN points of presence and supporting systems fall within scope, and which EU users or customers depend on each one. Without a current inventory, incident thresholds and availability figures cannot be measured. Check internally by comparing the inventory against live cloud accounts, facility records and DNS or edge configuration, and confirm each service has a named owner.
Documented incident response and reporting clock
Significant incidents trigger the early warning, notification and final report under Article 23, and the thresholds for cloud, CDN and data center services are set in the implementing regulation. Teams need a written procedure that maps outage duration and user impact to a decision, with named roles for who declares the incident. Check internally with a tabletop exercise that starts a timer on a simulated outage and records whether each reporting step is met.
Evidence of supplier controls
Providers rely on hardware vendors, network carriers, colocation operators and software suppliers, and their supervisor will expect proof that those dependencies are assessed and contractually bound. Keep the supplier register, security assessments, contract clauses on incident notification and the review dates. Check internally by sampling three critical suppliers and confirming each has a current assessment and a contract clause that lets you meet your own reporting deadlines.
Physical access logs
For data center services, compromised physical access is a significant incident in its own right, so physical controls must produce records a reviewer can test. Keep badge and visitor logs, escort records, camera retention settings and periodic access reviews for each facility. Check internally by selecting a recent date, reconciling badge events against the authorized access list, and confirming that removed staff and contractors no longer have active credentials.
Backup and availability records
Supervisors measure availability against the thresholds, so providers need records of uptime, failover tests and backup restoration. Keep monitoring history for each service, backup job logs, and the results of restore tests with recovery times. Check internally by restoring one representative backup to an isolated environment and comparing the recovery time with the availability commitments you have made to customers.
Who owns the controls and who prepares the evidence
Your organization remains the entity in scope under NIS2, so it owns the Article 21 risk-management measures, the risk decisions behind them and the duty to report incidents. The management body must approve these measures and oversee them, and it carries personal responsibility for infringements. Outside help can prepare material, but it cannot take those decisions on the organization's behalf.
- Management approval: The management body approves the risk-management measures, accepts residual risk and oversees how they are carried out.
- Risk and policy ownership: Internal owners set risk tolerances, sign off policies and decide which controls apply to which services.
- Reporting decisions: Your incident response team decides whether an incident is significant and makes the early warning, notification and final report submissions.
- Supplier accountability: You remain responsible for the security of your own supply chain, including any implementation partner and any cloud or colocation provider you use.
- Operating the controls: Staff run the platforms day to day, review access, respond to alerts and keep records current.
Before engaging anyone, confirm which named individuals hold each of these responsibilities and how the management body will receive evidence of them.
An implementation partner such as DeployOpen prepares the systems, configurations and evidence that support your controls. Work typically happens inside your own cloud accounts, data centers or private networks, on self-hosted open-source platforms. The partner does not decide your risk appetite, does not sign policies on your behalf and does not issue any report, attestation or certificate. NIS2 creates no certificate of compliance, so the output is material you can show to your supervisor or your independent assessor.
- Platform preparation: Installing, hardening, backing up and upgrading self-hosted platforms within your infrastructure.
- Configuration and evidence: Producing configuration baselines, access records, logging setups and test results that map to your controls.
- Documentation: Writing runbooks, architecture records and procedures that your staff must be able to operate and maintain.
- Security testing: Running tests against your systems and reporting the findings to you, with remediation tracked by your team.
- Operational support: Providing support or retainers for upgrades and continuous testing where agreed in writing.
Confirm in the written scope exactly which controls the partner prepares, which remain with your staff and who receives each deliverable.
National competent authorities supervise NIS2 compliance through inspections, security audits, security scans, information requests and administrative fines. Where a certification body or independent auditor is engaged for a voluntary framework used alongside NIS2, that party tests your controls and issues its own findings. Neither role is performed by your implementation partner, and the partner's work does not pre-judge their conclusions.
- Supervisory inspection: The authority examines evidence, may run security scans and can request information.
- Independent assessment: An auditor tests the design and operation of controls against a chosen framework and issues any report.
- Findings and enforcement: Only the authority or auditor determines findings, and the authority decides on enforcement measures.
- Independence boundary: The party that built or configured a system should not be the party that assesses it.
- Evidence access: Auditors need to see the underlying records, not only summaries prepared for them.
Ask your supervisor or chosen assessor early which evidence they expect and whether they accept material prepared by an outside partner.
Common mistakes that delay NIS2 readiness for cloud providers
Cloud, data center and CDN providers often lose time on the same few questions: whether a service is in scope at all, whether the entity has registered, how outages are classed, and what proof of compliance exists. Each mistake below is easy to make and expensive to correct once supervisors start asking for evidence.
Misreading the in-house exclusion
The data centre definition excludes in-house corporate data centres that an entity owns and operates for its own purposes. Organizations often assume that any facility they run is excluded, even when they host or sell capacity to third parties. Recital 35 also notes that data centre services can be in scope without being offered as a cloud computing service. Document each facility, who it serves and whether any external customer uses it, then have counsel confirm the classification in writing.
Missing the registration step
Providers of cloud, data center, CDN and managed services must submit registration information to the national authority. Member States had to require this by 17 January 2025, and the obligation attaches to the Member State of main establishment. Teams that treat NIS2 as a security project often miss it entirely, and the gap surfaces only when a supervisor checks the registry. Confirm your main establishment, name the responsible contact and file in the right jurisdiction before the technical program is declared ready.
Treating availability thresholds as monitoring only
The significant incident thresholds for cloud, CDN and data center services turn on how long a service is unavailable and how many EU users are affected. Teams often wire alerts to these numbers and stop there. The reporting clock, the decision to notify and the evidence of how impact was measured belong to incident response and governance. Write the threshold calculation into the incident procedure, test it in an exercise and record who makes the significance call and when.
Assuming a certificate exists
NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Buyers who ask for a NIS2 certificate are asking for something the law does not issue. Build an evidence file that shows how each Article 21 measure and each Implementing Regulation requirement is met, and ask any auditor or consultant to state clearly which parts they can attest to and which they only prepare.
NIS2 cloud and data center questions buyers ask
Is an in-house data center covered by NIS2?
Generally no, if the data center is owned and operated by the entity for its own purposes. Recital 35 says the data center service category should not apply to in-house corporate data centers. Article 6(31) defines a data center service as a structure dedicated to the centralized accommodation, interconnection and operation of IT and network equipment, with the power distribution and environmental control that supports it. The deciding question is who the capacity serves. A bank running servers for its own operations sits outside the category, while a company that hosts equipment for other customers is a provider and may be in scope. Recital 35 also notes that data center services can be in scope even where they are not offered as cloud computing. The entity may still be covered under its own Annex I or II sector, so check that too. Confirm the boundary with your national competent authority, because the national transposition law applies.
Which authority supervises a cloud provider serving customers in several EU countries?
The Member State where the provider has its main establishment in the Union supervises it under Article 26(1)(b). Cloud computing, data center, CDN and managed service providers all follow this rule, so a provider headquartered in one country is generally handled by that country's authority even when its customers sit in many others. Article 26 sets out how the main establishment is determined, and the test should be confirmed against the text and with the authority concerned. Article 27 also required these providers to submit registration information, with a Member State deadline of 17 January 2025. Other Member States can still raise questions or request information about services they receive, so keep customer and market records organized for each country where you operate.
Does NIS2 issue a certificate for cloud and data center providers?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. Customers often ask for a third-party attestation instead, such as an ISO/IEC 27001 certificate or a SOC 2 report. Those are voluntary schemes, and an accredited certification body or an independent auditor issues them. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Ask each customer exactly which document they require, because a certificate may support your Article 21 position without replacing the authority's own assessment.
What does NIS2 compliance require from a cloud provider's team?
The work spans governance, technical controls and evidence. Expect to cover these parts:
- Management body approval and oversight of the Article 21 risk-management measures.
- The technical and methodological requirements in Implementing Regulation (EU) 2024/2690, which apply to cloud, data center and CDN providers, read alongside the non-binding ENISA guidance published in June 2025.
- Documented evidence for each control, including configuration records, access reviews, logs, backup and recovery tests and physical access records.
- An incident process that can detect and classify significant incidents and meet the Article 23 reporting timelines.
The team also needs named control owners, an accurate asset inventory and a schedule for keeping evidence current. Start with a gap analysis against the implementing regulation so the scope of effort is set by real findings, not assumptions.
Can our team run NIS2 readiness in-house without an outside partner?
Yes. NIS2 does not require outside consultants, and the organization owns its controls and remains accountable for them. Outside help is usually considered where the team lacks time or specific skills, such as hardening cloud control planes, building log pipelines, testing backup restoration or running a reporting exercise. Costs fall into a few groups: internal staff time, which recurs; tooling and infrastructure, which is largely one-time plus upkeep; and fees for an independent auditor, if you want an attestation. DeployOpen plans, implements and documents self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks under a fixed scope agreed in writing. Ask any provider for a written scope listing deliverables, responsibilities and the evidence handed over.
When does a cloud or CDN outage become a reportable NIS2 incident?
For cloud computing, CDN, managed and managed security service providers, an incident is significant if a service is completely unavailable for more than 30 minutes. It is also significant if the service is limited for more than one hour and affects more than 5% of EU users or more than 1 million EU users, whichever is smaller. Data center service providers face a different test under Article 8: complete unavailability of a data center service, limited availability for more than one hour, or compromised physical access to a data center is significant. Build monitoring that measures user impact in these terms, not only uptime, and confirm how the thresholds apply to your service model with the implementing regulation and your authority.
How could the 2026 NIS2 proposal change scope for cloud providers?
On 20 January 2026 the Commission proposed targeted amendments to NIS2 in COM(2026) 13, including a new small mid-cap category. The proposal must still be approved by the European Parliament and the Council, so current obligations stay in force until any change is adopted and transposed. The Commission also must review how NIS2 works by 17 October 2027 and every 36 months after that under Article 40. Until then, plan on the existing text. Track the proposal as it moves through the legislative process, and check with counsel or your authority how any change would affect your size, sector and service model. Building a program that can be scaled up or down is a practical way to absorb such changes.
How DeployOpen prepares cloud and data center evidence
DeployOpen starts every NIS2 cloud, data center or CDN engagement with a written scope. That document names the services in question, the environments they run in, the Article 21 measures and Implementing Regulation (EU) 2024/2690 requirements each system is expected to meet, and the people who own each control. Scope is agreed in writing before work starts, and it is fixed: deliverables and timelines are stated in the same document. The organization decides what is in scope and owns its controls. DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor or certification body can do that, and the readiness work is shaped around what that assessor will test.
Implementation takes place in the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks. DeployOpen deploys and configures self-hosted open-source platforms there, then hardens them against a documented baseline. Typical work includes identity and access settings, logging and monitoring pipelines that can support the significant incident thresholds in Articles 7 to 10 and Article 8 of NIS2, backup and restore procedures tested against recovery targets the client sets, and configuration records kept under change control. Ask any partner to show which settings were changed from defaults and why, because a supervisor will ask the same question.
The output is an evidence pack: architecture and configuration records, hardening baselines, backup test results, access review records, change logs and runbooks, arranged by the requirement they support. Its purpose is to let the organization answer a supervisor's information request or an auditor's sample without reconstructing history. Before engaging, confirm three things in writing: who keeps the evidence current after handover, which parts depend on the client's own physical data center or provider contracts, and what recurring support or testing is priced separately from the fixed-scope build. The ENISA technical implementation guidance gives examples of evidence that can anchor that list.
