NIS2: Who is affected? Directly, indirectly – and through the supply chain

Many organizations misjudge their risk under NIS-2. Not because they are uninformed, but because they focus only on formal thresholds: sector, size, legal definitions. In reality, exposure arises in three ways – and two of them work without a formal notification. Those who ignore this will, in a crisis, lack evidence, contractual safeguards for the supply chain, and practiced reporting channels.

The three paths of exposure

1. Directly affected: Companies formally classified as “essential” or “important.” They carry explicit obligations regarding governance, risk management, technical/organizational measures, and incident reporting.
2. Indirectly affected: Service providers and suppliers working for directly affected customers. Requirements are passed down contractually: minimum controls (e.g., phishing-resistant MFA, patch SLOs), audit and evidence rights, reporting deadlines, emergency contacts.
3. Factually affected: Companies without formal classification whose failure would block critical customer processes. At the latest during onboarding or recertification, they are required to implement the same controls – or lose contracts.

The distinction is legally relevant, but operationally secondary: in all three cases, you must demonstrate that your IT security is adequate, documented, and effective.

Why size is not the criterion

Acute exposure arises from chains of impact: if your system goes down and production, logistics, or public services of a customer fail as a result, it is not your headcount that matters, but the dependency. Typical triggers include internet-exposed interfaces, admin access to customer systems, processing of sensitive data, or operational responsibility for central platforms. In short: anyone enabling or influencing a critical function will be assessed – formally or contractually.

Indirect pressure: compliance “top-down”

Directly affected clients pass obligations down their supply chain. This is not a “nice to have,” but a survival strategy: a weakness at a service provider is a weakness in one’s own audit. Clear minimum standards are therefore expected – without vendor names, but with verifiable impact:

• Identities first: phishing-resistant MFA for privileged roles, deactivation of weak legacy protocols.
• Patch discipline: binding deadlines based on exposure (internet vs. internal), documented exceptions with compensating controls.
• Backups with proof: integrity verification and time-measured restoration.
• Reporting path & contacts: 24/7 contact, defined thresholds, log of initial notification.
• Logging: traceable logs of critical access and changes – audit-proof, purpose-bound.

Those who can deliver this pass onboarding; those who cannot are removed from shortlists – regardless of formal NIS-2 classification.

Common misconceptions – soberly refuted

• “We are too small.” – Until a major customer classifies your platform as critical. Then their rules apply immediately.
• “A certificate is enough.” – No. Certificates help, but they do not replace lived processes, audits, and evidence.
• “We will report later, once everything is clear.” – Reporting obligations require early, structured initial notifications with updates.
• “IT handles that.” – NIS-2 addresses management responsibilities. Budget, risks, and escalations are governance issues.

What makes sense now (without activism)

Start where failure is costly and create proof instead of declarations of intent:

• Risk map & responsibilities: Which services are critical for customers? Who decides during an incident? Written, approved, accessible.
• Control runbooks: One page per measure: objective, trigger, steps, owner, evidence (screens, logs, tickets).
• Supply chain tiering model: Desk review for all, remote evidence for “high,” targeted testing for “critical.” Deadlines and escalation defined contractually.
• Incident communication: Templates and contact matrices (internal/external), thresholds, out-of-band channels – rehearsed once, not just described.
• Evidence discipline: “Not documented” counts as “did not happen” in an audit. Collect, version, store centrally.

KPIs that hold up under scrutiny

• MFA coverage (phishing-resistant) for privileged roles.
• Patch SLO compliance separated by internet-exposed/internal.
• Restore time & integrity verification for two business-critical processes.
• Time to initial notification and completeness of incident first information.
• Supply chain fitness: share of critical partners with up-to-date evidence and functioning 24/7 contact.

These KPIs are not an end in themselves; every deviation requires a defined consequence (escalation, change freeze, additional review). Only then does governance become effective.

Conclusion

The question “Are we formally NIS-2?” is important – but not decisive. What matters is whether you can demonstrate that your controls are appropriate, functioning, and resiliently documented in an emergency. Directly, indirectly, or factually affected: the outcome is what counts. Those who clarify responsibilities today, write runbooks, contractually secure the supply chain, and collect evidence will not only pass the next audit – they will materially reduce the real risk of outages and follow-up costs.

FAQ about blog post