NIS2 Post-Acquisition Compliance: The 90-Day Integration Sequence — and Why Your Registration Update Is Due in Two Weeks

The NIS2 Directive never mentions acquisitions. It sets no integration timetable, names no post-completion milestones, and offers no rule for deciding whose security policy wins when two in-scope entities merge. What it does set is a cluster of deadlines that all start running on completion day — and the tightest of them is two weeks, long before any technical integration work could plausibly begin.

That is the sequencing problem this article solves. Integration plans are normally ordered by IT convenience: identity first, then network, then applications, then policy paperwork last. Under NIS2 the legal order is close to the reverse. The registration update is due within two weeks of the change under Article 3(4), and you cannot file it until you have answered the Article 26 jurisdiction question — which makes a legal analysis, not a systems migration, the genuine Day-1 task.

This is the post-completion companion to our 20-point NIS2 due diligence checklist, which covers the pre-signing work. Here the deal is done and the clocks are already running.

Which Deals Actually Trigger This

In plain terms: NIS2 obligations attach to legal persons, not to groups or brands. So the first question is not "what did we buy" but "which legal persons now exist, and did any of them change".

Article 6(38) defines an entity as "a natural or legal person created and recognised as such under the national law of its place of establishment, which may, acting under its own name, exercise rights and be subject to obligations" [10]. That definition does the structural work here, because the three common deal structures produce three different answers.

Deal structure	What happens to the target as an entity	Registration consequence
Share purchase	The target survives as the same legal person. Its obligations were never transferred — they were always its own.	Registration stays; the submitted details change. Article 3(4) change notification applies [1].
Legal merger (target absorbed)	The target ceases to exist as a legal person. The acquirer takes over the activity.	The target’s registration falls away and the acquirer’s details change — notably its list of Member States of provision [1].
Asset purchase	No entity changes. An activity moves between legal persons.	Scope follows the activity. The buyer may newly qualify; the seller may drop out. Both may owe filings.

So the share purchase — the structure most buyers default to — is the one that leaves an existing NIS2 registration in place carrying wrong information. Nobody deregisters anything, so nobody notices a filing is due.

Plenty of deals trigger nothing here. Article 2(1) applies the Directive to Annex I or II entities that qualify as medium-sized enterprises or exceed those ceilings [11], so buying a business outside those annexes, or below the thresholds with no aggregation effect, creates no new obligation. If you have not confirmed which side of that line the target sits on, start with the NIS2 scope test rather than this sequence.

The Clocks That Decide the Sequence

Four obligations start on completion day, and they run at different speeds. Ordering the integration by anything other than these deadlines is what produces late filings.

Obligation	Legal basis	Deadline from completion
Notify changes to registered details (general in-scope entities)	Art. 3(4), second sub-paragraph	Without delay, and in any event within two weeks of the date of the change [1]
Notify changes to registry details (DNS, TLD, cloud, data centre, CDN, MSP, MSSP, marketplaces, search, social)	Art. 27(3)	Without delay, and in any event within three months of the date of the change [2]
Corrective measures for any known non-compliance	Art. 21(4)	"Without undue delay" — no fixed period [4]
Board approval of the risk-management measures	Art. 20(1)	No deadline stated; the duty exists from the moment the directors are in post [5]

Two features of this table run against the common assumption.

Digital infrastructure providers have the longer deadline, not the shorter one. Article 27(3) gives cloud providers, data centres, MSPs and marketplaces three months [2]. Article 3(4) gives manufacturers, energy companies, hospitals and transport operators two weeks [1]. The second group makes up the bulk of mid-market deal flow, so the tighter clock is the one most acquirers are on — and the one they assume does not apply to them.

The two-week clock has a prerequisite. One field you must keep current under Article 3(4) is "where applicable, a list of the Member States where they provide services falling within the scope of this Directive" [1]. That field cannot be completed until you know where the entity falls under jurisdiction. The jurisdiction review is therefore Day-1 work — not a strategic question to settle at leisure, but a data input to a filing due in a fortnight.

Days 1 to 14: Jurisdiction Review, Then Registration

In plain terms: confirm which national regulator supervises each entity you now control, then correct what is on file with them. Effort level: Low to Medium — mostly legal analysis, no engineering.

Article 26(1) sets the default: entities "shall be considered to fall under the jurisdiction of the Member State in which they are established", subject to three exceptions [3]. Point (a) puts providers of public electronic communications networks and publicly available electronic communications services under the jurisdiction of every Member State "in which they provide their services". Point (b) puts the digital infrastructure list — DNS, TLD registries, domain-name registration, cloud, data centres, CDNs, MSPs, MSSPs, online marketplaces, search engines and social platforms — under their main establishment. Point (c) puts public administration entities under the Member State that established them.

For most acquisitions the answer is establishment, and it does not move: buying a Spanish manufacturer leaves it Spanish-supervised. The review matters because of the exceptions, and because Article 26(2) defines main establishment as the Member State "where the decisions related to the cybersecurity risk-management measures are predominantly taken", falling back to where cybersecurity operations are carried out, then to the largest Union headcount [3]. Our Article 26 jurisdiction guide works through that three-tier test.

Then file. Article 3(4) requires four fields kept current: entity name; address and up-to-date contact details including email addresses, IP ranges and telephone numbers; where applicable the Annex I or II sector and subsector; and where applicable the list of Member States of provision [1]. An acquisition routinely changes the second and fourth, sometimes the third.

Check the national field list, not the Directive’s. NIS2 is a minimum-harmonisation directive and Member States have added fields. Germany’s section 33(1) BSIG requires five items: it adds the legal form and, where applicable, the commercial-register number alongside the entity’s name, and it adds the competent federal and state supervisory authorities for the registered activities [13]. Both are precisely what an acquisition changes, and neither appears in the Directive’s list. Germany also runs its two-week clock from the moment the entity "Kenntnis von der Änderung erhalten hat" — from knowledge of the change rather than the change itself, a small divergence in the entity’s favour [13].

Budget time for the mechanics too. German registration is two-stage: enrolment in the Mein Unternehmenskonto (MUK) digital service comes first, and only then registration in the BSI-Portal, which opened on 6 January 2026 for roughly 29,500 affected organisations [14]. That enrolment is per legal entity and is not instant. For the wider mechanics see our NIS2 entity registration guide.

Days 15 to 45: Policy Harmonisation and How to Resolve a Conflict

In plain terms: you now hold two sets of policies that disagree. NIS2 does not tell you which one wins. Effort level: Medium.

The folk rule in integration workstreams is "adopt the stricter standard". It is a reasonable instinct with no basis in the Directive. What NIS2 supplies instead is a proportionality test, expressed per entity.

Article 21(1) requires measures that "ensure a level of security of network and information systems appropriate to the risks posed", taking into account "the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation". It then names the assessment criteria: "When assessing the proportionality of those measures, due account shall be taken of the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact" [4].

Read as a conflict rule, three things follow. A single group standard is permissible — nothing requires bespoke per-entity policies. Levelling up to the acquirer’s standard is nearly always defensible, since a stricter measure still satisfies an appropriateness test. Levelling down is defensible only where the acquired entity’s own exposure, size and incident likelihood justify the lower control — and that reasoning must be written down, because it is the entity, not the group, that will be asked for it.

Conflict type	Test to apply	Defensible outcome
Acquirer’s control is stricter	Cost of implementation vs. the acquired entity’s risk exposure [4]	Adopt the group standard. Document the migration date; the gap before it is a known gap.
Target’s control is stricter	Was the stricter control driven by that entity’s own exposure, sector or a national requirement?	Keep it for that entity. Relaxing to the group baseline needs a recorded proportionality rationale.
Controls differ because national law differs	NIS2 is minimum harmonisation — a Member State may require more	Group baseline plus a documented national overlay. Do not harmonise the overlay away.
Entities are classified differently (essential vs important)	Art. 32 ex-ante supervision vs Art. 33 ex-post [6][7]	Same measures may serve both, but evidence readiness must be set to the essential entity’s standard.

One clock hides inside this workstream. Article 21(4) requires an entity that "finds that it does not comply with the measures provided for in paragraph 2" to take "without undue delay, all necessary, appropriate and proportionate corrective measures" [4]. Diligence findings are documented knowledge of a gap. Once the buyer controls the entity, that knowledge sits inside the entity — and the harmonisation project is the corrective measure. A slow policy workstream is not a delayed synergy; it is an open Article 21(4) exposure.

Worth watching rather than acting on: on 20 January 2026 the Commission published a "Proposal for a Directive as regards simplification measures and alignment with the Cybersecurity Act" (COM(2026) 13), whose targeted NIS2 amendments "aim to increase legal clarity by simplifying jurisdictional rules, streamlining the collection of data on ransomware attacks and facilitating the supervision of cross-border entities with ENISA’s reinforced coordinating role" [15]. It is a proposal, not law, and changes nothing today — but a group integrating entities across several Member States has a direct interest in how national divergence is eventually resolved.

Days 30 to 90: Technical Alignment, and the Scope Trap Inside It

In plain terms: merging the two IT estates is the step most likely to change the regulatory position, and it is normally run by people who never see the compliance analysis. Effort level: High.

Three consequences deserve to be on the integration risk log before the migration runbook is signed off.

Merging onto group IT can remove a scope argument. Recital 16 records that Member States "are able to take into account the degree of independence an entity enjoys in relation to its partner or linked enterprises", specifically independence "in terms of the network and information systems that that entity uses in the provision of its services" [12]. Two cautions are essential. This is a recital — interpretive, non-binding — and it is a Member State option, so it exists only where a Member State has taken it up. Where it has, the argument rests on facts a systems migration destroys. Recital 16 also closes by noting it "leaves unaffected the obligations laid down in this Directive of partner and linked enterprises which fall within the scope of this Directive" [12]. Our guide to NIS2 subsidiary compliance covers group structure in more depth.

Centralising security decisions can move the regulator. For Article 26(1)(b) entities only, main establishment tracks where cybersecurity risk-management decisions are predominantly taken [3]. Handing decision rights to a group CISO in another Member State is a regulatory act as well as an organisational one.

Reclassification changes the supervision model, not the label. Under Article 3(1)(a) an Annex I entity exceeding the medium-sized ceilings is essential; everything else in Annex I or II is important [1]. Where group aggregation carries an Annex I target across that line, supervision changes character. Article 32(2) lets authorities subject essential entities to on-site inspections and off-site supervision "including random checks", regular and targeted audits, ad hoc audits and security scans, with no trigger required [6]. Article 33(1) reaches important entities only "when provided with evidence, indication or information" of alleged non-compliance, through ex post measures [7]. An entity previously reachable only after something went wrong becomes checkable at any time — the strongest practical reason to front-load the evidence set rather than leave it to the end of integration. Article 32(7)(c) adds that authorities must take due account of "any relevant previous infringements by the entity concerned" [6]; in a share purchase the legal person is unchanged, so its enforcement history comes with it.

The Reporting Chain: Who Files, and From When

In plain terms: incident reporting stays per legal entity throughout integration, and the most common failure is a runbook pointing at people who have left. Effort level: Low, and it is the cheapest item on this list to get right.

Because obligations attach to the legal person [10], a group with three separately established in-scope entities files three times, each on its own awareness clock. Neither integration nor a shared security operations centre consolidates that. Article 23(1) also requires entities to report "inter alia, any information enabling the CSIRT or, where applicable, the competent authority to determine any cross-border impact of the incident", and confirms that "the mere act of notification shall not subject the notifying entity to increased liability" [9].

The integration-specific risk is a handover gap. In the first 90 days the acquired entity’s escalation path often still names a departed CISO, a decommissioned mailbox, or a provider whose contract ended at completion. Re-testing it is an afternoon’s work with a 24-hour deadline attached to getting it wrong. Where each national filing goes is covered in our guide to CSIRT reporting portals across the 27 Member States, and the multi-country question in cross-border incident notification.

Who Owns Each Step

The same sequence reads differently depending on the chair you sit in.

Step	Owner	Board / C-suite involvement	Effort
Jurisdiction review (Days 1-5)	Legal / Compliance	Informed	Low
Registration update (Days 5-14)	Compliance Officer	Informed	Low
Policy harmonisation (Days 15-45)	CISO with Legal	Approves under Art. 20(1) [5]	Medium
Technical controls alignment (Days 30-90)	CISO / IT integration lead	Informed of scope consequences	High
Reporting-chain update (Days 1-30)	Security operations	Informed	Low
Board approval of measures	Management body	Owns it — cannot be delegated away [5]	Low

The last row is the one that gets deferred. Article 20(1) requires management bodies to approve the entity’s Article 21 measures, oversee implementation, and provides that they "can be held liable for infringements by the entities of that Article" [5]. Directors appointed at completion inherit that duty over measures they have never seen. Our guide to Article 20 management liability sets out what approval has to look like in practice.

The 90-Day Evidence Checklist

By Day 90 an entity should be able to produce these on request. This is a gap-analysis frame: for each line, record current state, required state, and the work to close it.

• A written jurisdiction determination for each acquired entity, with the Article 26 limb relied on
• Proof of the registration change filing, with its date, against the Article 3(4) two-week deadline (or Article 27(3) where applicable)
• The national field set actually submitted, checked against the transposing statute rather than the Directive
• A policy reconciliation record: which standard applies to which entity, and the proportionality reasoning wherever the group did not simply level up
• An Article 21(4) corrective-measures log, opened on the diligence findings and dated from completion
• A re-tested incident escalation path per legal entity, with named current contacts
• Minuted board approval of the Article 21 measures by each entity’s management body
• An updated classification assessment where aggregation may have moved an entity between important and essential

Frequently Asked Questions

Does the acquirer inherit the target’s NIS2 obligations?
In a share purchase there is nothing to inherit. Obligations attach to the legal person under Article 6(38) [10], and that person is unchanged — it simply has a new owner. In a legal merger the target ceases to exist and the activity, with its obligations, continues in the absorbing entity.

We acquired on the 1st and only discovered the registration duty on the 20th. Are we late?
Under the Directive’s own wording, yes — Article 3(4) runs "within two weeks of the date of the change" [1]. National transposition may be more forgiving: Germany’s section 33(5) BSIG runs the same two weeks from the entity’s knowledge of the change rather than from the change itself [13]. Check the transposing statute, file immediately, and record when and how the change came to the entity’s attention.

Can we run one group-wide NIS2 policy set instead of one per entity?
Yes. Nothing requires per-entity documents, and Article 21(1)’s proportionality test is satisfied by a group standard that is appropriate to each entity’s risks [4]. What cannot be group-level is the evidence that each entity’s management body approved it, and the reasoning wherever an entity operates below the group baseline.

Our acquisition pushed a subsidiary from important to essential. What actually changes?
The supervision model, and the fine ceiling. Essential entities are subject to Article 32 powers including random checks and regular audits with no trigger; important entities face Article 33 ex post measures only once an authority has evidence or an indication of non-compliance [6][7]. Article 34 also sets a higher ceiling for essential entities — a maximum of at least EUR 10 000 000 or 2 % of worldwide annual turnover, against EUR 7 000 000 or 1,4 % for important entities, in both cases whichever is higher [8]. The Article 21 measures themselves do not change, but the odds of being asked to evidence them rise sharply.

Should we delay the IT integration to preserve a scope argument?
Possibly, but take advice before relying on it. The independence consideration in Recital 16 is non-binding and a Member State option, so it may not exist in your jurisdiction [12]. Treat it as a factor to check early, not a strategy to build the plan around.

Before Day 90

NIS2 does not reward the integration sequence that feels natural. The legal deadlines sit on analysis and paperwork, while the expensive engineering work carries no deadline of its own — only the open-ended Article 21(4) duty to correct what you already know is wrong. Groups that run the jurisdiction review in week one and file inside two weeks find the rest manageable. Groups that treat registration as an afterthought discover the deadline retrospectively, and by then the only answer left is a late filing with a documented reason.

One structural point deserves the last word: every obligation here is owed by a legal person, so each acquisition multiplies the work rather than absorbing it. That is a resourcing question, and it is better answered before the next deal than after it.

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.

Sources

1. Directive (EU) 2022/2555, Article 3 — Essential and important entities
2. Directive (EU) 2022/2555, Article 27 — Registry of entities
3. Directive (EU) 2022/2555, Article 26 — Jurisdiction and territoriality
4. Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures
5. Directive (EU) 2022/2555, Article 20 — Governance
6. Directive (EU) 2022/2555, Article 32 — Supervisory and enforcement measures in relation to essential entities
7. Directive (EU) 2022/2555, Article 33 — Supervisory and enforcement measures in relation to important entities
8. Directive (EU) 2022/2555, Article 34 — General conditions for imposing administrative fines
9. Directive (EU) 2022/2555, Article 23 — Reporting obligations
10. Directive (EU) 2022/2555, Article 6 — Definitions
11. Directive (EU) 2022/2555, Article 2 — Scope
12. Directive (EU) 2022/2555, Recital 16 (Preamble, recitals 11 to 20)
13. Section 33 BSIG — Registrierungspflicht, Bundesamt für Justiz (gesetze-im-internet.de)
14. Bundesamt für Sicherheit in der Informationstechnik, "Zweiter Schritt zur NIS-2-Registrierung: BSI-Portal ab sofort freigeschaltet", press release, 6 January 2026 (bsi.bund.de)
15. European Commission, Proposal for a Directive as regards simplification measures and alignment with the Cybersecurity Act, COM(2026) 13, 20 January 2026