Why NIS2 Made Your Suppliers Your Problem
For most of 2025, boards across the EU discovered an uncomfortable truth: under NIS2, the security failures of your vendors are now legally your failures too. The Network and Information Security Directive 2 (Directive EU 2022/2555) came into national force across member states through 2024 and 2025, and in 2026 the enforcement phase is real. Regulators are past the grace-period messaging and into audits, information requests, and the first meaningful fines.
The headline change most teams underestimate is Article 21(2)(d): supply-chain security is an explicit, named risk-management obligation. It is no longer enough to secure your own perimeter. You must assess and manage the security of your suppliers and service providers, including the quality of their development practices and their handling of vulnerabilities. When an incident enters through a third-party library, a managed service, or an outsourced development team, the in-scope entity carries the accountability.
This matters far beyond the EU. Gulf enterprises selling into, hosting for, or partnering with European customers are being pulled into NIS2 obligations through contracts. A bank in the GCC that provides a digital service consumed by an EU entity, or a software vendor whose product ships into European critical infrastructure, will be asked to evidence the same controls. NIS2 has become a de facto procurement standard well outside its jurisdiction.
Who Is Actually in Scope in 2026
Scope is where most confusion lives, so it is worth being precise. NIS2 splits regulated organisations into two tiers.
- ▸Essential entities include energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration, and space. These face proactive supervision and the steepest penalties.
- ▸Important entities include postal and courier services, waste management, chemicals, food, manufacturing of critical products, digital providers such as online marketplaces and cloud platforms, and research organisations. These face reactive supervision but the same substantive obligations.
The size threshold generally captures medium and large organisations, roughly 50-plus employees or turnover above ten million euro, though several categories are in scope regardless of size because of their criticality. Penalties are deliberately severe and mirror GDPR logic: up to ten million euro or two percent of global annual turnover for essential entities, and up to seven million euro or 1.4 percent for important ones. Crucially, management bodies can be held personally liable, and directors can be temporarily barred from management functions.
The trap in 2026 is the indirect obligation. Thousands of companies that are not directly named are contractually bound anyway, because their in-scope customers must manage them as supply-chain risk. If you sell software, hosting, or managed services to a regulated entity, you will be audited by proxy through their due diligence. Being ready is now a commercial prerequisite, not a compliance nicety.
Vendor Due Diligence That Survives an Audit
Due diligence under NIS2 is not a one-time questionnaire. It is a repeatable, evidence-producing process that an auditor can inspect. Use this checklist to structure it.
- ▸Build a tiered vendor inventory. Classify every supplier by the criticality of what they touch: production data, source code, customer PII, or core infrastructure. Tier-one vendors get deep scrutiny; commodity tools get a lighter touch.
- ▸Map the fourth party. Ask each critical vendor who their own subprocessors and dependencies are. NIS2 cares about the chain, not just the first link. A cloud add-on that quietly relies on an unvetted API is your exposure.
- ▸Demand evidence, not assertions. Collect current certifications (ISO 27001, SOC 2 Type II), recent penetration test summaries, and a description of their secure development lifecycle. A signed self-attestation without artefacts is a red flag.
- ▸Contract the security in. Require incident-notification timelines that align with your own NIS2 reporting duty (early warning within 24 hours, a fuller notification within 72 hours), audit rights, vulnerability-remediation SLAs, and a right to receive a Software Bill of Materials.
- ▸Require an SBOM and CVE handling. Ask how they track known vulnerabilities in dependencies, how fast they patch, and whether they can produce a component inventory. This is where DORA-regulated financial entities are already pushing hardest.
- ▸Reassess on a cadence. Tie review frequency to tier. Annual is a floor for critical vendors; a material change, breach, or acquisition triggers an immediate re-review.
- ▸Keep the paper trail. Every assessment, decision, and exception should be logged with a date and an owner. In an audit, undocumented diligence is treated as diligence that never happened.
The organisations that struggle in 2026 are the ones treating this as a spreadsheet exercise once a year. The ones that pass treat it as continuous risk management with a clear audit trail.
Building Auditable Security Into the Software Itself
Here is the deeper shift NIS2 forces on engineering teams: compliance can no longer be bolted on after the build. If security has to be evidenced, it has to be produced by the software delivery process as a by-product, not reconstructed under audit pressure.
Auditable security means specific, boring, powerful habits. Every dependency is tracked in an SBOM generated automatically on each build. The CI pipeline runs software composition analysis and static analysis, and it blocks releases on critical findings rather than merely warning. Infrastructure is defined as code so its state is reviewable and reproducible. Access is least-privilege with logged, time-bound elevation. Logs are tamper-evident and retained long enough to satisfy incident-reporting timelines. Every change is traceable from a ticket, through a reviewed pull request, to a signed artefact in production.
Done well, this also satisfies neighbouring 2026 regulation without extra work. The EU AI Act imposes documentation and risk-management duties on high-risk AI systems, DORA demands ICT third-party risk registers and resilience testing for financial entities, and GDPR still governs the personal data flowing through all of it. The same evidence pipeline feeds all four. Build the trail once, satisfy the regime many times.
How TuniCyberLabs Builds This In
TuniCyberLabs is an EU-anchored engineering company built precisely for this moment. Our parent is registered in Estonia (Tallinn) with an office in Cyprus (Limassol), so your contracts, data-processing terms, and GDPR posture sit inside the EU legal framework. Our engineering team is in Sousse, Tunisia, giving you genuine nearshore delivery: the same working hours as Europe, overlapping real-time collaboration for Gulf clients, and multilingual delivery in English, French, and Arabic, at a cost structure that offshore promises but rarely delivers cleanly.
More important is how we build. We work in four deliberate phases. We start by understanding your regulatory scope and threat model, so we know whether NIS2, DORA, or the AI Act shapes the design. We design systems where auditability is an architectural property, not an afterthought: SBOMs, least-privilege access, and traceable change flows are in the blueprint. We build and deploy secure, production-grade systems with the evidence pipeline running from day one, so security artefacts are generated automatically, not scrambled together before an audit. Then we support and evolve the system, keeping the vulnerability handling, dependency updates, and control documentation current as the regulation and the threat landscape move.
If your NIS2 obligation is really a vendor obligation, that makes us the kind of supplier that passes your customers' due diligence, and helps you produce the same evidence for yours. Custom engineering is the honest way to meet these rules, because compliance you can prove is compliance that was designed in from the first commit.