NIS2 and Externally-Facing Controls: What It Means for UK Firms

What does NIS2 cover, and who is in scope?

NIS2 widens the sectors in scope compared with the 2016 directive and divides in-scope organisations into two classes. Article 3 distinguishes essential from important entities; the substantive risk-management duties are largely common to both, and what differs most is how closely they are supervised. Under Article 2 the directive generally applies to entities in the annexed sectors that qualify as medium-sized enterprises, or exceed the ceilings for them, under the EU SME definition in Commission Recommendation 2003/361/EC -- where a small enterprise is one under 50 staff with turnover and balance sheet at or below €10 million -- with several entity types in scope regardless of size, and member states able to bring in others.

Read the sector names as headings rather than as the scope itself. Each annex sector breaks down into subsectors and specific entity types, and "digital infrastructure" and "digital providers" in particular cover quite different populations -- the first includes internet exchange points, DNS service providers, TLD registries, cloud and data centre providers and content delivery networks; the second covers online marketplaces, search engines and social networking platforms. Whether a given business is inside one of those descriptions, and above the relevant threshold, is a legal question about a national implementation. Nobody should answer it from a table.

On penalties: this guide does not quote figures, and you should be wary of content that does without naming a jurisdiction. The directive requires member states to provide for supervisory and enforcement measures including administrative fines, but the numbers that could be applied to you sit in a specific national law. Get them from that law, or from an adviser in that country.

How does NIS2 reach a UK firm anyway?

Two routes, and it matters which one you are on, because one produces a regulator and the other produces a procurement conversation. In our experience the second is far more common for UK small and mid-sized businesses, and it is the one people are least prepared for -- partly because it arrives without the word "regulation" attached.

Route one: the EU representative requirement

Article 26 sets out which member state has jurisdiction over an in-scope entity. Most entities fall under the state where they are established. A specific group of digital providers instead falls under the state of their main establishment in the Union -- defined as where cybersecurity risk-management decisions are predominantly taken, with fallbacks if that cannot be determined. And where such an entity is not established in the EU at all but offers those services within it, Article 26(3) requires it to designate a representative in the Union, established in one of the member states where the services are offered. The entity is then considered to fall under that state's jurisdiction, which has a practical upside: it settles on one national authority rather than leaving you answerable in every country you serve. Where no representative is designated, any member state in which the entity provides services may take legal action against it.

For a UK business the honest summary is that this route is narrow but not exotic. A UK managed service provider, managed security provider, hosting company, cloud or data centre operator, CDN, DNS provider or domain registrar with EU customers should take advice on it specifically rather than assume Brexit settled the question. A UK accountancy firm or manufacturer selling into the EU almost certainly should not be worrying about Article 26(3) at all -- it should be reading route two.

Route two: inheriting obligations through the supply chain

Article 21(2)(d) requires in-scope entities to address supply-chain security, including the security-related aspects of relationships with their direct suppliers and service providers, and Article 21(3) requires them to take account of each supplier's specific vulnerabilities and the overall quality of its security practices. An in-scope EU entity discharging that duty has one practical lever over a UK supplier, and it is the contract.

So this route does not feel like regulation. It feels like: a security schedule appearing in a renewal; a questionnaire with sixty questions and a two-week deadline; a request for evidence of patching timescales; a notification clause requiring you to tell the customer about incidents within a window shorter than you have ever committed to; a demand to disclose subcontractors; an audit right you did not previously grant. The legal obligation is your customer's. The work lands on you, and unlike regulation you can negotiate it -- which is a reason to read it properly rather than sign it quickly.

Two things make this route cheaper to service. Answer once: build a single, maintained security overview document you can send to any customer, rather than composing a fresh answer each time. And make sure the externally visible part of your estate actually supports what the document says, because that is the half a customer can check without asking you.

That figure is the reason the order matters: fix the external picture, then write the questionnaire answers. A supplier assessment that finds a high-severity exposure on a hostname the supplier did not mention is not a scoring problem, it is a credibility problem -- and it is the kind of thing an EU customer's own supply-chain diligence is increasingly configured to look for.

Which NIS2 measures are externally observable?

Article 21(2) lists ten categories of minimum measure that in-scope entities must implement on an all-hazards basis. The table below maps each against the only question this guide is qualified to answer: how much of it can be seen, and evidenced, from outside your perimeter. The "no" and "barely" rows are the important ones -- they are what an external tool cannot do for you, and they are the majority.

Vulnerability handling and disclosure

Article 21(2)(e) is the measure with the clearest external component, because a known vulnerability on an internet-reachable service is observable by everyone at once -- you, your customers, and whoever is scanning the internet indiscriminately this week. Two halves matter. The first is handling: a documented route from "a CVE affects something we expose" to "it is patched or mitigated", with a timescale attached and a record of having met it. The second is disclosure, which UK firms more often lack: a published, monitored way for an outsider to tell you about a vulnerability. NIS2 takes coordinated disclosure seriously enough to build institutions around it -- Article 12 requires each member state to designate a coordinator CSIRT to act as trusted intermediary between reporters and vendors, to allow anonymous reporting, and requires ENISA to maintain a European vulnerability database covering publicly known vulnerabilities in ICT products and services. A security.txt file and a monitored mailbox are the cheap version of participating in that world, and they cost an afternoon.

Cryptography, in the sense an outsider can check

Article 21(2)(h) covers policies on the use of cryptography and, where appropriate, encryption. Most of the internal side -- data at rest, key management, storage -- is invisible externally. The transport side is entirely visible: TLS versions and cipher suites offered, certificate validity and expiry, hostname match, chain trust, whether plain HTTP redirects, and whether HSTS is set. The usual failure is not the main website -- it is the forgotten hostnames. An expired or self-signed certificate on a staging host, a mail gateway or an appliance login page is the normal shape of this finding, and it is a certificate hygiene problem rather than a cryptography-policy problem.

Authentication surface, not MFA enforcement

Article 21(2)(j) covers the use of multi-factor or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems. Be precise about what an external view contributes here, because it is easy to overclaim: whether a given login actually enforces a second factor is generally not determinable from outside without credentials, and nobody should be testing it with somebody else's. What is determinable is the shape of the authentication surface -- which login pages, VPN and remote-access endpoints and administrative panels are reachable from the internet at all. That enumeration is usually the more valuable output, because the exposures that hurt are on the interfaces nobody remembered publishing rather than on the one the security policy was written about.

The measures no external view touches

Stated plainly, because vendors are vague about it: business continuity, backup management and crisis management (21(2)(c)) are entirely invisible from outside. So is staff training (21(2)(g), in part), and so are internal access control and human resources security (21(2)(i), in part). Incident handling (21(2)(b)) is process, not posture. If you are building a compliance programme, external monitoring is one input to about four of ten categories, plus a measurement instrument for effectiveness under 21(2)(f). Anyone selling it as more than that is selling you something else.

What are the NIS2 incident reporting timelines?

Article 23 requires in-scope entities to notify significant incidents to their competent authority or CSIRT in stages. An incident is significant, broadly, where it has caused or is capable of causing severe operational disruption of services or financial loss to the entity, or where it has affected or is capable of affecting others by causing considerable material or non-material damage. The staging is the part worth internalising.

Three observations for anyone who has to live with this, whether under a national NIS2 law or under a customer contract that borrows its windows.

• The clock starts at awareness. Twenty-four hours from becoming aware, not from the incident occurring. That puts the weight on detection and on whoever first notices knowing that a clock has started. An engineer who spots something odd at 17:00 on a Friday needs to know the escalation route without looking it up.
• The early warning is deliberately thin. It is an alarm, including whether malicious action is suspected and whether there could be cross-border impact. Waiting until you understand the incident in order to file a better early warning is how the 24-hour window gets missed.
• The 72-hour notification is an evidence problem. It needs an initial assessment of severity and impact, which means somebody has to reconstruct what was exposed, since when, and to whom -- at speed. Historical records of your external estate help here in a way nothing else does, because the question "was that host reachable last Tuesday" has an answer only if something was looking.

If you are on the supply-chain route, read any customer notification clause against these timings. Clauses drafted to help a customer meet a 24-hour duty often ask the supplier for notification in twelve hours or fewer. That may be perfectly reasonable, but it is a commitment about your out-of-hours staffing, not a box to tick.

How does this interact with the UK NIS Regulations 2018?

The two regimes share an ancestor and a philosophy and differ in almost every detail. The table is the short version.

The UK side is moving. The government has introduced the Cyber Security and Resilience (Network and Information Systems) Bill to reform the 2018 Regulations; the government's own summary of the bill describes bringing further entities into scope, including data centres, managed service providers and designated critical suppliers, strengthening the existing regulators, adding a faster initial incident notification, and taking powers to update the regime by secondary legislation. Treat it as direction of travel, not as current law: until it passes, the 2018 Regulations as amended are the UK position, and the bill's final shape can change in Parliament.

For a UK firm the useful conclusion is that the two regimes reward the same underlying work. Both are outcome-focused rather than prescriptive. Both expect an organisation to know what it operates, manage the risk in it, handle vulnerabilities to a timescale, and report incidents promptly. A UK supplier that builds a defensible external-exposure practice now is not doing it twice: it is the same evidence whether the person asking is a UK regulator, an EU customer's procurement team, or an insurer.