NIS2: Why It Reaches Companies Outside the EU

NIS2 raises cyber security requirements for essential and important entities across the European Union. Companies outside the EU often assume it is irrelevant to them. Two mechanisms make that assumption unreliable.

Mechanism one: offering services in the EU

Entities established outside the EU that provide in-scope services within it can fall within the regime directly, with a requirement to designate a representative in the Union. The test is where services are offered, not where the company is headquartered.

The sectoral scope is broad — energy, transport, banking, financial market infrastructure, health, water, digital infrastructure, ICT service management, public administration, space, and a further set of important sectors including digital providers, manufacturing and postal services.

Mechanism two: supply chain flow-down

This is the one that reaches most non-EU companies. In-scope entities must address security in their supply chains, including the security practices of their direct suppliers and service providers.

The practical result is that your EU customer, who is in scope, begins asking you for security commitments, evidence and contractual terms. You are not regulated; you are being contracted into equivalent obligations because your customer is.

That arrives as a lengthening security questionnaire, contract amendments and audit rights. See vendor risk scoring from the other side of the same conversation.

Management accountability

NIS2 places responsibility on management bodies: they must approve cyber security risk management measures, oversee implementation, and can be held liable for failures. Members of management bodies are also required to undergo training.

That is a governance change more than a technical one, and it is the reason NIS2 gets board attention where earlier requirements did not.

The reporting timeline

The staged timeline is demanding. An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours with an initial assessment, and a final report within one month.

The 24-hour early warning does not require a complete picture — it requires you to have noticed, decided, and communicated. Organisations without out-of-hours detection and a named decision-maker cannot meet it, and no amount of legal preparation substitutes for those two capabilities.

The measures required

The directive sets out baseline measures including risk analysis and information system security policies, incident handling, business continuity and crisis management, supply chain security, security in acquisition and development, policies to assess effectiveness, cyber hygiene and training, cryptography, human resources security and access control, and multi-factor authentication.

None of that is novel to anyone running a modern programme. The change is that it is mandatory, supervised and enforceable rather than advisory.

What a non-EU company should do

1. Determine whether you are in scope directly — services offered in the EU, in an in-scope sector
2. Ask your EU customers whether they consider you a relevant supplier under their supply chain obligations
3. Prepare the evidence they will ask for before the questionnaire arrives
4. Check your contracts for incoming amendments on incident notification timelines — your customer's 24-hour clock depends on you telling them fast
5. Confirm you can meet a 24-hour notification to your customer, because that is where the obligation lands on you

Point four is the one that catches suppliers. An EU customer with a 24-hour regulatory clock will contractually require notification from you in a fraction of that time.

Where to start

Ask your largest EU customer whether NIS2 changes what they need from you. The answer arrives eventually as a contract amendment; getting it early means preparing rather than scrambling.

Preparing the evidence pack

Whether NIS2 reaches you directly or through a customer, the same artefacts get requested. Assembling them once, in advance, converts a recurring scramble into a reusable package:

• A current risk assessment covering the services you provide
• Your incident response plan, with notification timelines to customers stated explicitly
• Evidence of testing — penetration test summaries, exercise reports
• Business continuity and recovery capability, with the last test date
• Your own supply chain position, since your customer's obligation flows through you to your subprocessors
• Access control and MFA coverage
• Encryption approach for data in transit and at rest
• Training records, including for anyone with privileged access

Most suppliers already have versions of these scattered across teams. The value is in curating one current pack and refreshing it on a schedule, rather than rebuilding it for each questionnaire.

How this differs from GDPR

Entities familiar with GDPR sometimes assume NIS2 is a variation on it. They address different things and can both apply to the same incident.

An incident encrypting a production system may require both notifications on different clocks to different authorities. Your runbook should account for that rather than treating them as one process.

GuardsArm helps suppliers prepare for customer-driven security requirements. See third-party risk management or book a scoping call.