NIS2 Cloud Migration: The Two-Week Clock That Starts the Day You Cut Over

Migrating to the cloud does not pause your NIS2 obligations, and it does not create a grace period at the far end. The migration itself is a regulated event: a planned change to the network and information systems you use to deliver your service. That means it has a rulebook, a pre-implementation gate, and — the part almost nobody diaries — a registration deadline measured in weeks, not months.

This guide covers the transition window specifically: what you owe before cutover, during the outage, and in the fortnight after. If you want the steady-state question of who reports when your provider goes down, that sits in our guide to NIS2 cloud outage reporting.

Does this apply to your migration?

Two separate questions decide how much of this article is binding law for you and how much is best practice. First, are you an essential or important entity? Second, are you one of the eleven digital categories that the Implementing Regulation binds directly?

Your situation	What binds you	How to read this article
Essential or important entity in a non-digital sector (energy, health, transport, manufacturing, water, food)	Article 21 of the Directive as transposed into your national law	The Annex points cited here are the Commission’s own reading of Article 21. Use them as an interpretive reference, not as a rule that binds you directly.
One of the eleven digital categories: DNS providers, TLD registries, cloud computing providers, data centre providers, CDNs, MSPs, MSSPs, online marketplaces, search engines, social platforms, trust service providers	Article 21 and Commission Implementing Regulation (EU) 2024/2690 directly	Every Annex point below is a binding technical requirement for you.
You are migrating to a cloud provider but are not one yourself	Article 21, plus supply chain duties under Article 21(2)(d)	Your provider’s regulatory status does not transfer to you. Read the shared-responsibility section closely.
You run a SaaS product on someone else’s infrastructure	Potentially both — you may be a cloud computing service provider in your own right	Germany’s BSI has confirmed that not owning the servers does not remove you from the cloud-provider definition.

That last row catches people out. The BSI’s German-language NIS2 FAQ states that a self-contained SaaS offering falls under the cloud computing service definition in § 2 no. 4 BSIG even where the provider does not physically operate the underlying computing resources itself but obtains them from an external cloud provider, because the law does not require operator identity. That is a German reading of a German statute, not an EU-wide ruling — but the definitional logic is the same one every Member State is transposing. Migrating your SaaS onto a hyperscaler can leave you regulated as a cloud provider and dependent on one simultaneously.

Your migration is a change, and change has a named rulebook

Most migration plans treat compliance as a destination state: get the controls right in the target environment and the obligation is discharged. The regulation does not read that way. Article 21(2)(e) requires measures covering "security in network and information systems acquisition, development and maintenance", and the Implementing Regulation fills that in with a change-management regime at Annex point 6.4.

Point 6.4.1 requires entities to "apply change management procedures to control changes of network and information systems". Point 6.4.2 says those procedures apply to "releases, modifications and emergency changes of any software and hardware in operation and changes to the configuration". A platform migration is all three at once.

It is worth being precise about where this sits, because migration briefs routinely file it under Article 21(2)(a). Change management is not an Article 21(2)(a) obligation. Article 21(2)(a) covers "policies on risk analysis and information system security", and the Annex builds that out at point 2.1 as the risk management framework. Change management lives under (e). The two are connected by a single cross-reference in point 6.4.2, and that cross-reference is the most operationally significant sentence in this entire area.

The pre-implementation gate: risk-assess before you cut over

Annex point 6.4.2 requires that changes are "documented and, based on the risk assessment carried out pursuant to point 2.1, tested and assessed in view of the potential impact before being implemented".

Three words carry the weight. Before means the assessment is a gate, not a deliverable you close out in the post-migration review. Based on means it must run against your existing Article 21(2)(a) risk assessment methodology, not a bespoke migration questionnaire the cloud vendor supplied. Tested means someone has to demonstrate the change works, and ENISA’s guidance suggests doing the security impact analysis "in a separate test environment before implementation in an operational environment".

ENISA’s guidance under this point — recommendations, not binding law — is unusually concrete about what a procedure should contain: a request for change, a risk assessment, criteria for categorising and prioritising changes, "requirements for performing rollbacks", and documentation and approval of the changes. It also suggests a change advisory board that evaluates requests on risk, impact, resource requirements and business alignment, and it names the evidence an auditor would expect: test plans and results demonstrating the procedures work.

The rollback requirement deserves separate attention. Point 6.4.3 requires that where an emergency prevented the normal procedure being followed, you document the result of the change and the explanation for why the procedures could not be followed. ENISA’s guidance calls for "specific pullback plans". A migration runbook with no documented, tested rollback path is not just operationally reckless — it leaves the entity without the one artefact that turns a bad night into a documented, defensible one.

The two-week clock: your IP ranges are registration data

This is the obligation that migration programmes miss, and it is not buried in an implementing act. It is in Article 3(4) of the Directive itself.

Article 3(4) requires Member States to make essential and important entities submit "at least" a defined list of information to the competent authority. Point (b) of that list reads: "the address and up-to-date contact details, including email addresses, IP ranges and telephone numbers". The second subparagraph then requires entities to notify any changes to those details "without delay, and, in any event, within two weeks of the date of the change".

In practice, most migrations to a public cloud change the public IP ranges through which the service is reached. When they do, the two-week clock starts on the day the ranges change — which is cutover day, not the day the programme formally closes.

Now the counter-intuitive part. There is a second registration regime, Article 27, covering the eleven digital categories, and its change deadline is three months (Article 27(3)), with IP ranges listed at Article 27(2)(f). Practitioners routinely assume the digital-infrastructure regime is the tighter one. It is the reverse: the general population of essential and important entities is on the two-week clock, and the specialist digital registry is on three months.

Regime	Who	Deadline for notifying a change
Article 3(4)	All essential and important entities, plus domain name registration service providers	Without delay, and in any event within two weeks of the date of the change
Article 27(3)	The eleven digital categories, in the ENISA registry	Without delay, and in any event within three months of the date of the change
Germany, § 33(5) BSIG	Entities registered with the BSI	Without delay, and at the latest within two weeks from the point the entity became aware of the change

The German transposition is worth noting because it shows how much the national layer matters here. Section 33(5) BSIG runs its two weeks from the entity’s knowledge of the change rather than from the change itself, and section 33(1) no. 2 specifies public IP address ranges. That is a slightly more forgiving trigger than the Directive’s, and it will not be identical in every Member State. Confirm the wording in your own national statute before you set the diary date. If you have not registered at all yet, our entity registration guide covers the initial filing.

Cutover weekend: is planned downtime a reportable incident?

You have a four-hour maintenance window on a Saturday night. Customers cannot reach the service. Does that trigger the 24-hour early warning?

For the eleven digital categories, the answer is written down. Article 3(2) of the Implementing Regulation states that "scheduled interruptions of service and planned consequences of scheduled maintenance operations carried out by or on behalf of the relevant entities shall not be considered to be significant incidents". A planned migration window is a scheduled maintenance operation, and the downtime you announced is a planned consequence of it.

For everyone else, that sentence does not bind. And the Directive’s own definition is broader than most readers expect: Article 6(6) defines an incident as "an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems". There is no "unplanned" qualifier anywhere in it. What saves the planned window outside the digital categories is not the definition but the significance test at Article 23(3) — reporting is triggered only where an incident has caused or is capable of causing severe operational disruption or financial loss, or considerable damage to others. An announced, bounded, successfully executed window normally clears neither limb. Document the reasoning; do not assume it.

The sharper point is what the carve-out does not cover. "Planned consequences" is doing precise work in that sentence.

Cutover scenario	Inside the Article 3(2) carve-out?	Why
Announced four-hour window, service restored on schedule	Yes	Scheduled maintenance; the outage is a planned consequence
Window overruns to eighteen hours because data replication stalls	No, for the excess	An overrun is not a planned consequence of the scheduled operation
Cutover fails, rollback executed, service degraded into Monday	No	Failure and rollback are the unplanned branch, however well rehearsed
Migration completes cleanly, but a misconfigured security group exposes a storage bucket	No	A confidentiality compromise, not an availability consequence of maintenance
Provider suffers an unrelated regional outage during your window	No	Not carried out by or on behalf of you; assess it on the normal criteria

The practical consequence for the runbook: define, in advance and in writing, the point at which the migration stops being a maintenance window and becomes an incident. Give it a named owner and a clock time. Teams that decide this at 03:00 on the night decide it badly, and the 24-hour Article 23(4)(a) early warning runs from awareness, not from the point the war room agrees a label.

What actually shifts on day one — shared responsibility, honestly

The shared responsibility model is a useful engineering diagram and a poor compliance one, because it allocates control, not liability. The binding hook is Article 21(1), which attaches the duty to the network and information systems "which those entities use" — a test about use, not ownership. Recital 83 confirms the intent: the obligations should apply "regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof". Recitals are interpretive rather than binding, so treat that as the reading of Article 21(1) rather than a rule in its own right. Germany’s BSI makes the same point more bluntly in its German-language NIS2 FAQ: even where IT is fully outsourced, the entity itself remains responsible, must ensure its providers implement the NIS2 requirements and are checked regularly, and — in the BSI’s own words, translated — contracts alone are not sufficient.

Providers agree, in their own documentation. The February 2026 revision of the AWS NIS2 guidance for customers states that AWS is responsible for the security of the cloud and customers for security in the cloud, and then says plainly: "Customers are responsible for ensuring their compliance with NIS 2, including configuration, policies, and national requirements."

Treat provider documentation as a description of the provider’s position, never as a legal citation. The same AWS paper attributes customers’ supply-chain obligations to "Article 21(2)(g)". Article 21(2)(g) is basic cyber hygiene and training; supply chain security is Article 21(2)(d). The Annex reference alongside it is right and the point being made is sound — but if a hyperscaler’s compliance whitepaper mis-cites a sub-point, a vendor mapping table is not an audit trail.

What genuinely changes across the transition is which control you can still evidence yourself:

Obligation	Day one in the cloud	Day one after migration completes
Physical and environmental security (Annex 13)	Still yours in the legacy estate you have not yet decommissioned	Evidenced through the provider’s certifications, which you must obtain and retain
Backup and redundancy (Annex 4.2)	Two estates, two backup regimes, one recovery objective	Provider-native, but the restore test remains yours to run and document
Access control (Annex 11)	Duplicated identity planes — the highest-risk window of the whole programme	Consolidated, with the legacy plane formally revoked and evidenced
Supply chain (Article 21(2)(d), Annex 5)	The provider is now a direct supplier and enters the register on contract signature, not at go-live	Ongoing monitoring under Annex 5.1.6
Registration data (Article 3(4))	Unchanged until the ranges actually move	Two-week clock live from the date the ranges changed

The duplicated-identity row is the one to brief upwards. For the length of the migration you are operating two access-control planes, and Article 21(1) attaches the duty to the systems the entity uses — both of them, concurrently. Article 21(4) then requires an entity that finds it does not comply to take "without undue delay, all necessary, appropriate and proportionate corrective measures", which turns a gap you discover during migration planning into an obligation with its own clock. See our supply chain security guide for the supplier-register half of this.

Who owns what, and by when

Role	Owns	Deadline anchor
CISO / IT security lead	The Annex 6.4.2 pre-implementation assessment, the tested rollback plan, and the written incident-declaration trigger for the cutover window	Complete before the change is approved, not before go-live
Compliance officer	The Article 3(4) registration update, and the documented significance assessment for any downtime	Within two weeks of the IP ranges changing
Procurement / vendor management	Provider entry in the supplier register and Article 21(2)(d) contractual security terms	At contract signature, ahead of any data movement
Management body	Acceptance of the residual risk of the transition window under Annex 2.1.1	Before the change advisory decision

A workable sequence for a mid-sized migration: run the change assessment and provider due diligence together in the four to six weeks before approval; treat the approval decision as the compliance gate; and put a single calendar entry two weeks after the planned cutover date for the registration update, owned by a named person. That last one costs nothing and is the most commonly missed obligation in this entire article.

One caution on cadence: ENISA suggests reviewing change management procedures at least once every two years, but that is guidance, not law. The binding trigger in Annex point 6.4.4 is "at planned intervals and when significant incidents or significant changes to operations or risks" occur — and a cloud migration is the textbook significant change. That exact phrase appears twenty-one times across the Implementing Regulation’s Annex, in eleven of its thirteen titles. Your migration re-opens the security policy (1.1.2), roles and responsibilities (1.2.6), the risk assessment and treatment plan (2.1.4), independent reviews (2.3.4), incident-handling procedures (3.1.3), the business continuity and disaster recovery plans (4.1.4), the crisis management plan (4.3.4), supply chain policy (5.1.6), configurations (6.3.3), network security (6.7.3), segmentation (6.8.3), effectiveness assessment (7.3), access control (11.1.3), and the physical security measures (13.1.3 to 13.3.3), among others. Budget for the documentation pass; it is larger than the technical migration in calendar terms and it is where audit findings land.

Frequently asked questions

Does moving to a certified provider reduce my Article 21 obligations?
It reduces the controls you implement yourself and gives you evidence for some Annex points, particularly physical and environmental security. It does not transfer the obligation. Recital 83 applies the duties regardless of outsourcing, and the provider’s own documentation says the same.

My migration is phased over eighteen months. When does the two-week clock run?
From the date of each change to the details you registered. A phased migration that moves IP ranges in three waves creates three notification events, not one at the end. Check whether your national statute runs the clock from the change itself or, as Germany does, from your knowledge of it.

Do I need to notify the competent authority that I am migrating?
The Directive contains no general duty to pre-notify a change of infrastructure. The obligations are indirect: update your registration details when they change, and keep the change-management and risk-assessment record that supervision may later ask for. Sector-specific national rules can add more, so confirm locally.

Is a failed cutover automatically a significant incident?
No. It falls outside the scheduled-maintenance carve-out, which means it is assessed on the normal criteria — severe operational disruption or financial loss under Article 23(3), and for the eleven digital categories the thresholds in the Implementing Regulation. Outside the carve-out means assessable, not automatically reportable. Our incident classification guide walks the test.

What evidence should I keep from the migration itself?
ENISA’s examples of evidence for Annex 6.4 name the practical set: documented change management procedures, a record of the steps and result for each relevant change, test plans and results, documented pullback plans, and logs of change requests including approvals. Retain the pre-implementation risk assessment and the management-body acceptance alongside them.

Sources

• Directive (EU) 2022/2555 (NIS2), Articles 3, 6, 21, 23 and 27 — EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690, Article 3 and Annex points 2.1, 5.1, 6.1 and 6.4 — EUR-Lex
• Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0, June 2025 — ENISA
• § 33 BSIG — Registrierungspflicht — gesetze-im-internet.de
• § 30 BSIG — Risikomanagementmaßnahmen — gesetze-im-internet.de
• "NIS-2-FAQ (allgemein)", questions 2 and 21 — Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de)
• "NIS 2 Considerations for AWS Customers", February 2026 revision — Amazon Web Services (d1.awsstatic.com)

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.