Burglars rarely force the front door when somebody has left a back window open for them. In cybersecurity, that window is increasingly likely to be a supplier – the firm that maintains your IT systems, delivers your software, or simply happens to have access to your network. The NIS2 Directive draws the obvious, if somewhat uncomfortable, conclusion: supply chain security is an integral part of an organisation’s own security, and managing third-party risk stops being a best practice and becomes a legal obligation. The statistics leave little room for doubt. According to 2025 research, 97% of organisations suffered a breach through their supply chain – despite 95% of them having increased their vendor risk management budgets over the same period. The problem, evidently, is not money but method. And method is precisely what NIS2 sets out to change.
These are high-profile examples, but it is equally important to understand the mechanisms that make such incidents possible. Most cyberattacks today are exploratory in nature. Attackers often do not have a specific target; instead, they test the defences of many systems in search of weak points. The widespread deployment of network-connected peripheral devices – frequently with poor security controls – creates additional entry points into corporate environments. The rapid development of artificial intelligence further accelerates this trend. Anthropic recently postponed the public release of a model that reportedly proved exceptionally effective at identifying security vulnerabilities. Even less capable AI models can automate and scale attack attempts. As a result, any organisation, no matter how small, can become a target simply because the cost of launching an attack is negligible. At the same time, that organisation may serve as an entry point into the systems of larger organisations with which it collaborates.
What is NIS2 in the context of supply chain security?
The NIS2 Directive (Directive (EU) 2022/2555) is the EU’s cybersecurity framework for essential and important entities – from energy and transport, through healthcare, to digital services and manufacturing. At its heart sits Article 21, which obliges these entities to implement “appropriate and proportionate” risk management measures. Among the ten minimum measures listed in Article 21(2), under letter (d), we find supply chain security, including security-related aspects of the relationships between an entity and its direct suppliers or service providers. Demonstrating NIS2 compliance therefore means demonstrating, among other things, that you have your suppliers under control.
Crucially, Article 21(3) goes a step further: organisations must take into account the vulnerabilities specific to each direct supplier, as well as the overall quality of their suppliers’ products and cybersecurity practices – including their secure development procedures. In other words, a policy on paper will not do; you need to actually know how your suppliers work.
The directive also provides a mechanism at the EU level. Under Article 22, the Cooperation Group, the European Commission, and ENISA may carry out coordinated risk assessments of critical ICT supply chains, taking into account non-technical – including geopolitical – risk factors. Organisations are required to factor the results of such assessments into their own risk management. In practice, this means a company can be impeccably organised internally and still face a non-compliance finding if it ignores warnings concerning a specific high-risk vendor.
National implementations add their own flavour. Poland, to take one instructive example, transposed NIS2 through an amendment to its National Cybersecurity System Act, in force since April 2026, with fines of up to PLN 100 million (roughly EUR 24 million) and high-risk vendor provisions that go beyond the directive itself: once a vendor is formally designated high-risk, regulated entities across all sectors must withdraw its ICT products and services from use. Germany’s implementation, in force since December 2025, took a similarly uncompromising approach to board accountability. The direction of travel across the EU is unmistakable.
Vendor risk management in practice
How does one translate these requirements into organisational routine? The starting point is systematic vendor management driven by risk rather than by contract value. A small subcontractor with administrative access to your servers poses a far greater risk than a large office-supplies vendor – even though it is the latter who sends the bigger invoices. Procurement automation, however, often means that even apparently harmless suppliers may have some degree of access to organisational systems.
In practice, a vendor risk management programme rests on a few permanent elements:
- A supplier inventory – a complete register of third parties, including what systems and data each of them can access. Most organisations conducting this mapping for the first time discover that the list is considerably longer than anyone suspected. Modern collaboration is frequently enabled through integrated systems, meaning that customers and contractors often receive some level of system access as part of routine business operations.
- Risk-based tiering – suppliers are classified by criticality of services, scope of data access, and potential impact on business continuity. The tier determines the depth of assessment and the frequency of monitoring.
- A supply chain security policy – a formal document setting out minimum security requirements for suppliers in each tier, communicated to the suppliers themselves and integrated into procurement.
- A vendor lifecycle – from pre-contract assessment, through secure onboarding and ongoing monitoring, to controlled offboarding (access revocation, return or destruction of data). The later stages deserve particular attention because they are often neglected. A supplier that passes an assessment at the start of a relationship is not guaranteed to continue applying security updates or maintaining an adequate security posture over time.
Due diligence and vendor security assessment
Vendor due diligence is the verification we perform before a supplier gains access to our systems – that is, before it is too late. What are we looking for? Evidence rather than declarations, first and foremost. Certifications such as ISO 27001 or SOC 2 reports say more than the most beautifully completed questionnaire. It is worth verifying the supplier’s incident history, the maturity of their vulnerability and patch management, and – for software vendors – their secure development practices, which Article 21(3) mentions explicitly.
Increasingly important is also the SBOM (Software Bill of Materials), the “ingredients list” of software: an inventory of the components and libraries a product is built from. When a vulnerability surfaces in a popular library, an organisation with SBOMs knows within hours which of its systems are exposed. An organisation without them finds out from the news.
One practical caveat: due diligence should be proportionate. Sending a 300-question questionnaire to every vendor is the surest way to guarantee that nobody reads the answers. For low-risk suppliers, recognised certifications will do; detailed assessment is best reserved for those on whom your security genuinely depends.
Vendor monitoring and continuous risk assessment
Here we arrive at the most important conceptual shift NIS2 forces. The traditional model – a questionnaire at onboarding, a repeat once a year, results filed in a binder – no longer suffices. A supplier that was secure in January may not be in June: an incident, a change of ownership, the loss of key personnel, or a new vulnerability in their technology stack – or simply neglecting security updates – is all it takes.
NIS2 expects continuous monitoring. In practice, this means using automated security ratings, threat intelligence feeds, and alerts on events affecting your suppliers. It also means defining the triggers for an unscheduled review: a major incident, a change in ownership structure, regulatory sanctions, or a significant expansion of the supplier’s access to your systems. Cyber resilience – resilience, not mere compliance – requires that your knowledge of a supplier’s risk be current at the moment you need it, not on the anniversary of the last questionnaire. This approach also encourages suppliers themselves to continuously monitor and improve their cybersecurity.
Contracts, SLAs, and security requirements
The contract is the only instrument you genuinely hold over a supplier – which is why NIS2 and its implementing acts place such emphasis on contractual provisions. What belongs in a contract with a critical supplier?
- Minimum security standards – ideally by reference to a recognised framework (ISO 27001, CIS Controls), with an obligation to maintain compliance throughout the term of the contract.
- Incident notification duties – with a specific deadline. Since you have 24 hours to deliver an early warning to your CSIRT (Computer Security Incident Response Team), the supplier must notify you considerably faster. “Without undue delay” is not enough; write in a number of hours.
- Audit rights – the ability to verify the supplier’s security practices, directly or through an independent third party. Without this clause, “continuous oversight” is just wishful thinking.
- Subcontractor requirements – an obligation to impose equivalent security requirements on subcontractors with access to your data or systems. In effect, this creates a pyramid of mutually monitored contractors, helping to maintain security throughout the supply chain.
- Exit rights – the ability to terminate without penalty if the supplier fails to meet security requirements or is designated a high-risk vendor.
- Security SLAs – incident response times and critical patch deployment times, as measurable and enforceable as any other service parameter.
Incident reporting in the supply chain
NIS2 introduces a three-stage model for reporting significant incidents: an early warning within 24 hours of becoming aware of the incident, a full notification within 72 hours, and a final report within a month. In the supply chain context, the operative phrase is “becoming aware”. If the incident originates at a supplier, your clock starts ticking the moment you learn of it – which is why the contract must guarantee prompt notification, and why your internal incident management process needs a “third-party incident” scenario: who receives the supplier’s notification, who assesses the impact on your organisation, who decides on reporting to the CSIRT.
Concentration risk deserves a mention here as well. If half an industry relies on the same cloud provider or IT services operator, an incident there becomes a systemic incident. Identifying single points of failure in your supply chain and preparing contingency plans is a part of risk management that regulators are asking about with increasing frequency. The MUSE ticketing-system incident mentioned earlier illustrates this risk, as does the 2023 MOVEit Transfer breach. Identifying single points of failure and preparing contingency plans is a risk-management practice that cybersecurity supervisory authorities are asking about with increasing frequency.
Managing subcontractors and ICT dependencies
A supply chain rarely ends at the first link. Your SaaS vendor relies on a cloud provider, which in turn relies on external technical support – and suddenly your data depends on a company you never knew existed. This is what is known as fourth-party risk or, in its general form, nth-party risk.
You do not manage subcontractors directly – you have no contract with them and no audit rights over them. What you can (and should) do is require your direct suppliers to run mature third-party risk management of their own and to disclose their key dependencies to you. Mapping critical ICT dependencies – at least for your most important services – is no longer a paranoid extravagance but a precondition of any honest risk assessment.
It is worth mentioning the Cyber Resilience Act in this context, as it complements NIS2 from the product side: it imposes cybersecurity requirements directly on manufacturers of digital products. In time, this means the regulator will do part of your due diligence for you – products carrying the CE mark for cybersecurity will have to meet defined standards from the design stage onwards. This is particularly important in the context of increasingly common cloud services and Internet of Things (IoT) devices, which are notorious for not being secure and frequently become attack vectors.
Governance and board accountability
NIS2 settles the question unambiguously: cybersecurity – supply chain security included – is the responsibility of management bodies, not merely of the IT department. The board approves risk management measures, oversees their implementation, and is obliged to undergo training sufficient to assess the risks involved. National implementations tend to sharpen the point further. In Poland, board members bear personal liability for compliance even where the tasks have been delegated downwards, and an individual manager’s fine can reach 300% of their monthly remuneration. Member states can also impose temporary bans on exercising managerial functions.
From a governance perspective, this means documented oversight: a designated senior-level owner of supply chain security, regular reporting of vendor risk to the board, formal approval of the policy and of decisions concerning high-risk suppliers, and – the part that tends to escape attention – evidence that all of this actually happens. When the regulator comes calling, it is the audit trail that counts, not good intentions.
NIS2, TPRM, and enterprise risk management
A common mistake is to treat NIS2 compliance as a standalone project running in parallel to “normal” risk management. Supply chain security should instead be embedded in enterprise risk management: the vendor risk register feeds the corporate risk register, failure scenarios for key suppliers feed business continuity plans, and decisions to accept or mitigate risk pass through the same governance mechanisms as any other material business risk.
There is good news for organisations with ISO 27001 already in place: a substantial portion of Article 21 is already covered. The typical gaps lie precisely in supply chain security, board accountability, and incident reporting timelines – so a gap analysis is the sensible starting point, rather than building the system from scratch. Similarly, ISO 22301 (business continuity management) provides a ready framework for the “key supplier stops working” scenario.
Technologies supporting supply chain security
With a handful of suppliers, a spreadsheet and determination will do. With dozens or hundreds, they will not. Hence the growing role of three categories of tools:
- GRC platforms integrate the supplier register with risk assessments, contractual requirements, and compliance evidence, generating reports for the board and the regulator. One source of truth instead of twelve spreadsheets in eight versions.
- TPRM tools automate the vendor assessment cycle: questionnaires, scoring, continuous monitoring, alerts on changes in risk profile. Increasingly AI-assisted – capable, for instance, of reviewing a contract for missing security clauses.
- SIEM systems monitor events across your infrastructure and can detect anomalies suggesting a supply-chain compromise – sometimes before the supplier realises it has a problem.
Best practices and common mistakes
A few regularities emerge from the experience of organisations that have already walked this path. On the side of good practice: starting with direct and critical suppliers rather than attempting to cover everything at once; making security assessment a mandatory gate in procurement; accepting recognised certifications instead of multiplying questionnaires; and measuring the programme’s effectiveness (time to detect, time to respond) rather than its activity (number of questionnaires sent).
On the side of mistakes, the perennial champion is the disconnect between procurement and security – procurement signs contracts that the security team learns about after the fact. Second place goes to compliance theatre: a programme built to satisfy the audit rather than to actually reduce risk. Recall the statistic: 97% of organisations breached through their supply chain were, for the most part, organisations that had questionnaires, policies, and binders. What they lacked was current knowledge of their suppliers.
How to prepare your organisation for NIS2 – a checklist
- Establish whether your organisation qualifies as an essential or important entity under your national implementation, and register on time where required.
- Inventory your suppliers and tier them by risk (data access, service criticality, impact on business continuity).
- Adopt a formal supply chain security policy and integrate it into procurement.
- Conduct due diligence on critical suppliers; for new suppliers, make it a precondition of onboarding.
- Review contracts with critical suppliers and fill the gaps: incident notification with a specific deadline, audit rights, subcontractor requirements, exit rights.
- Implement continuous monitoring for your highest-risk suppliers and define the triggers for an unscheduled review.
- Document the third-party incident process and rehearse it – including making the 24-hour deadline.
- Identify concentration risk and single points of failure; prepare contingency plans for irreplaceable suppliers.
- Document board oversight: policy approval, periodic reporting, board training.
- Consider a GRC or TPRM platform if the number of critical suppliers exceeds what can be managed by hand.
Summary
NIS2 moves supply chain security from the “nice to have” column into the “legal obligation with sanctions” column. In the shortest possible terms: you must know who your suppliers are and what they could break; you must vet them before granting access and keep vetting them afterwards; your contracts must give you real instruments – notification, audit, exit; and your board must consciously oversee all of it, because it is personally liable. Organisations that take these requirements seriously gain more than regulatory peace of mind: the ability to demonstrate mature vendor risk management is becoming a competitive asset in procurement, because NIS2-regulated customers are looking for partners who will not complicate their lives.
