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
-
Directly affected : Companies formally classified as “essential” or “important.” They carry explicit obligations regarding governance , risk management, technical/organizational measures, and incident reporting.
-
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.
-
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
Who is affected by NIS-2 – only directly listed companies?
No. In addition to formally classified entities, service providers and suppliers are indirectly affected through contractual requirements and supply chain obligations.
What triggers NIS-2 exposure?
Common triggers include admin access to customer systems, processing of sensitive data, and critical operational dependencies.
How can a company prove adequate IT security under NIS-2?
Through measurable KPIs such as MFA coverage, patch SLO compliance, documented restore tests, and structured incident metrics.
What do customers require in the context of NIS-2?
They expect verifiable evidence, contractual audit rights, defined reporting deadlines, and established 24/7 contact channels.
What is the most common misconception about NIS-2?
“We are too small.” This assumption fails when a company’s outage disrupts critical customer operations.
