Update 19 August 2026. The Dutch Cybersecurity Act has been in force since August 15, 2026. For entities governed by the law, supply chain security is a duty of care. A supplier may also face chain responsibility through contractual security, reporting and evidence requirements.

Central chapter on NIS2 and the Dutch Cybersecurity Act →NIS2 GAP analysis for chain control →NIS2 audit for demonstrable operation →

The security of suppliers and chain partners is no longer a peripheral issue under NIS2. Supply chain security is explicitly part of the measures that organisations need to control cyber risks.

The recent security incident at CEVA Logistics shows why.

CEVA is an international logistics service provider that carries out activities for organisations such as bulb and the Bijenkorf. Following a security incident at CEVA, these organisations had to inform customers because personal data present at CEVA for the logistics services could have been accessible to unauthorised persons.

The systems of sphere itself were not affected according to sphere.

This is precisely the main lesson for directors, members of a Supervisory Board and Commissioners:

Your organisation doesn't need to be hacked into to be hit by a cyber incident.

Under NIS2, therefore, not only the security of the organisation itself but also the risks within the NIS should be considered. supply chain: suppliers, IT partners, cloud providers, software providers, logistics service providers and other parties on which the organisation depends.

What does NIS2 supply chain security mean?

NIS2 is a chain issue that is clearly approach cybersecurity.

Organisations today rely heavily on suppliers for, among others:

  • IT management;

  • cloud platforms;

  • software;

  • hosting;

  • salary processing;

  • data processing;

  • logistics;

  • back-up services;

  • network management;

  • SaaS platforms;

  • and other critical processes.

A security incident involving one of these parties may therefore have a direct impact on the client.

Within NIS2, therefore, organisations should take appropriate measures to secure their supply chain. This is not only about technical security, but also about the quality, reliability and resilience of suppliers and service providers.

For governance and oversight, this means, among other things, that an understanding is needed of:

  • which suppliers are business critical;

  • which suppliers have access to sensitive data or systems;

  • which dependencies exist;

  • the security requirements that have been contractually established;

  • how incidents are reported;

  • how continuity and recovery are regulated;

  • and how suppliers are established to comply effectively with their agreements.

This does not make supplier management under NIS2 a mere task of purchasing or IT.

It's part of the governance control of cyber risk.

Cyber attack on CEVA: how chain risk becomes visible

CEVA Logistics provides logistics services for other organisations. For this purpose, CEVA processes data required for storage, fillinment, shipping and delivery, among others.

Think of, for example:

  • name;

  • address;

  • postal code;

  • telephone number;

  • e-mail address;

  • order information;

  • delivery information;

  • return information.

This makes a logistics service provider not only part of the physical chain, but also part of the digital information chain.

A consumer buys from an online retailer, but data is shared with other parties to fulfil the order.

Simplified, this chain looks like this:

Consumer

Web Shop

Logistics service provider

Carrier

Consumer

The personal data moves along the chain.

If one party is affected in that chain, the impact can spread to organisations that have not entered at all technically.

That's exactly why NIS2 supply chain security is relevant.

Is the CEVA incident a supply chain attack?

In the media, this type of incident is often referred to as a supply chain attack.

Technically, some nuance is wise.

In a classic supply chain attack, a supplier is deliberately compromised and then attacked its customers.

A well-known example is:

Attacker

Software Supplier

Infected software update

Install Customers Update

Clients are compromised

CEVA has not been shown to the public that attackers have subsequently entered the systems of sphere or beehive via CEVA.

Technically, it is therefore more accurate to speak of a chain incident or Third-party compromise.

But from the point of view of governance and oversight, that difference in terminology hardly matters.

The essence remains the same:

A security incident with a supplier can cause a direct risk to your own organisation.

Therefore, supplier risk belongs to the same board-level risk discussion as continuity, privacy, fraud, reputation, compliance and financial risks.

The main question for the board: Which suppliers are we really dependent on?

Many organisations now have a supplier register.

That is useful, but a list of tens or hundreds of suppliers does not say much about the real risk.

The more important question is:

Which suppliers can hit our organisation the hardest when they are hacked or completely out of business tomorrow?

For example, think of an organisation where:

  • the entire IT environment is managed by one IT service provider;

  • the primary business process depends on a single SaaS platform;

  • all client data are stored with one cloud supplier;

  • the financial administration is carried out externally;

  • one logistics service provider is responsible for almost all distribution;

  • a software provider has management rights on critical systems.

Not all suppliers deserve the same attention.

The board-level challenge is therefore mainly to provide suppliers with the necessary information. Classification and Prioritization.

Why supplier risk requires board-level attention under NIS2

NIS2 makes it clear that an organisation cannot fully outsource its cybersecurity responsibility.

An IT service provider may be responsible for technical management.

A cloud supplier may be responsible for a platform.

A logistics service provider may process personal data.

But the organisation itself remains responsible for controlling the risks arising from these dependencies.

For board members, this means that supplier risk should be part of the regular risk management.

For a Supervisory Board or Supervisory Board, it means that it is necessary to determine whether the Board has a demonstrable control over this.

A supervisor does not need to ask which firewall a supplier uses.

More relevant questions are:

  • Which suppliers can stop our primary service?

  • Which suppliers process our most sensitive information?

  • Which suppliers have access to our systems?

  • How do we assess their security levels?

  • What incident reporting periods did we agree to?

  • What do we do if a critical supplier fails for several days?

  • What risks do we consciously accept?

  • What improvements are still open?

These are the most outstanding questions for the boardroom.

What could go wrong with a supplier?

In the case of supplier risk, the first thought is often a data breach.

But the potential impact is much wider.

Confidentiality

Data may be accessed by unauthorised persons.

Examples include:

  • personal data;

  • client information;

  • financial information;

  • contracts;

  • trade secrets;

  • personnel information.

Availability

A supplier could fail.

For example, questions such as:

  • Can employees still work?

  • Can customers still order?

  • Can goods still be delivered?

  • Can salaries still be paid?

  • Can clients still be helped?

  • Can the organisation continue its primary service?

Integrity

An attacker can influence information or processes.

Remember:

  • payments;

  • orders;

  • Administrations;

  • configurations;

  • software;

  • customer information;

  • financial transactions.

All three are relevant for governance and oversight.

Cybersecurity is not just a privacy issue.

It's also a continuity, governance and corporate risk.

“But our supplier is ISO 27001 certified”

ISO 27001 certification is valuable.

But a certificate does not mean that a supplier cannot be hacked.

Certified organisations can also have security incidents.

A certification can demonstrate that an information security management system has been set up within a given scope.

That is important, but it does not relieve a client of responsibility to look critically at his own dependence.

For governance and oversight, therefore, an important distinction is:

certification gives confidence but does not replace risk assessment.

Relevant questions remain, for example:

  • the service used is within the scope of certification?

  • Which subcontractors does the supplier use?

  • how is continuity regulated?

  • What access does the supplier have to our systems?

  • when are incidents reported?

  • how is backups actually shown to be recoverable?

  • What relevant audit findings are still open?

  • What does an exit look like?

Those aren't technical details.

They're control questions.

How does a board member know whether supplier risk is adequately controlled?

A board member doesn't have to be a cybersecurity specialist.

Nor a commissioner or supervisor.

However, governance and oversight must be able to assess whether the organisation has a demonstrable control over a material risk.

This is less technical details and more about structure and evidence.

A mature organisation should be able to answer at least the following questions.

Which suppliers are business critical?

Not just a supplier list, but a clear classification.

Examples include:

  • criticism;

  • high;

  • Regular.

For example, a supplier can be considered critical when failure within a few hours has a direct impact on the primary service.

What data and systems are stored with suppliers?

The board doesn't need to know every technical detail.

But it's global.

  • where sensitive personal data are processed;

  • where primary applications run;

  • which suppliers have business sensitive information;

  • which third parties play an important role in critical processes.

What access do suppliers have?

A supplier who only supplies office supplies has a different risk profile than an IT partner with administrator rights.

Relevant questions are:

  • Does the supplier have any management rights?

  • Does the supplier have access to production environments?

  • Do permanent accounts exist?

  • do service accounts exist?

  • are access rights periodically checked?

  • is access withdrawn when it is no longer required?

What happens when the supplier fails?

This is a question of continuity.

Board members should know, for example:

  • What happens after four hours of outage?

  • What happens after 24 hours?

  • What happens after three days?

  • Is there an alternative process?

  • have any recovery arrangements been made?

  • Have these scenario scripts ever been tested?

How do we know that agreements are actually being kept?

A contract alone is not a management measure.

Therefore, for example:

  • audits;

  • Insurance reporting;

  • certifications;

  • periodic evaluations;

  • incident reports;

  • security KPIs;

  • improvement plans;

  • evidence of follow-up of findings.

Incident notification: speed counts

In case of a cyber incident with a supplier, a second problem arises almost immediately:

the client needs information.

What happened?

What data hit?

When did the incident begin?

Are our records involved?

Is the attacker still in the room?

Should we inform our customers?

Do we have a duty to report ourselves?

Can our trials continue?

If a supplier does not come forward with clear information until late, it has a direct impact on the client.

Therefore, incident reporting should not be in a general contract article alone.

In the case of critical suppliers, it must be clear:

  • where incidents are to be reported;

  • to whom;

  • the minimum information to be provided;

  • how often updates follow;

  • who is responsible for communication;

  • and what cooperation is expected in the investigation.

What does NIS2 supply chain mean for the Supervisory Board and Supervisory Board?

Cybersecurity oversight does not mean that a Supervisory Board should itself assess technical security measures.

The supervisory role lies mainly in assessing the quality of board-level control.

For example, a Supervisory Board or Supervisory Board may ask:

  • Have we identified our critical suppliers?

  • Which supplier is our biggest cyber or continuity risk at the moment?

  • Has a current risk analysis been carried out for critical suppliers?

  • Which suppliers have access to our most sensitive data?

  • Which suppliers can stop our primary service?

  • When was the last time that a supplier of such substances was tested?

  • How quickly should critical suppliers report a cyber incident?

  • How is security arrangements actually monitored?

  • What relevant shortcomings are still open?

  • Who accepts the residual risk?

Those aren't technical questions.

They're governance questions.

And that's why they belong in the boardroom.

What information is heard periodically on the board table?

A board has little use for a technical dashboard with hundreds of security events.

That gives a lot of information, but little board-level direction.

More relevant, for example:

  • number of critical suppliers;

  • high-risk suppliers;

  • open high-risk findings;

  • incidents involving suppliers;

  • critical contracts without adequate security conditions;

  • status of continuity tests;

  • suppliers without current assurance;

  • suppliers without a realistic exit plan;

  • delayed improvement measures;

  • accepted residual risks.

This is a way of actually steering governance.

What should oversight then assess?

A Supervisory Board or Supervisory Board does not need to assess each supplier individually.

The supervisory question is mainly:

Does the control system work?

For this purpose, oversight may, inter alia, assess:

  • Does a supplier policy exist?

  • Are critical suppliers identified?

  • are risks assessed in advance?

  • are agreements signed?

  • are suppliers periodically evaluated?

  • Is there an escalation in insufficient control?

  • is reported on relevant risks?

  • Are any outstanding deficiencies being detected?

  • are accepted risks explicitly made?

Where the answer to more than one of these questions is "unknown' or "unknown', that in itself is already a relevant board-level finding.

ClickFix: technically interesting, but administratively the cause is secondary

In the CEVA incident, the public has not confirmed the attack technique used by the attackers.

There is therefore no basis to say that CEVA is not ClickFix has been compromised.

ClickFix is a current attack method whereby a user is tricked through a fake CAPTCHA to perform a malicious command on the computer.

But from the boardroom, the exact technical route is not the most important question.

The board-level question is:

Is our organisation prepared for the scenario that a employee, supplier or chain partner is compromised?

Whether the first access is created by:

  • Phishing;

  • stolen credentials;

  • vulnerability;

  • ClickFix;

  • malware;

  • a misconfigured system;

the board-level consequences are similar.

The organisation shall be able to:

detect → react → communicate → recover → learn.

From cyber incident to board-level impact

A technical incident can quickly develop into a board-level problem.

Examples include:

Cyber incident at supplier

Personal data may be affected

Operational disturbance

Informing customers

Possible reporting obligation

Media attention

Reputation damage

Financial impact

Management and oversight questions

Cybersecurity is therefore not a separate IT risk.

It hits:

  • continuity;

  • compliance;

  • privacy;

  • reputation;

  • finance;

  • liability;

  • Governance.

Checklist NIS2 supply chain for board, RvT and RvC

For example, periodically use the checklist below when discussing information security, continuity or risk management.

Critical suppliers

☐ We know which suppliers are business critical.

☐ Critical suppliers are demonstrably classified.

☐ We know which primary processes depend on these suppliers.

☐ We know relevant dependencies of subcontractors and subprocessors.

Data and access

☐ We know which suppliers process sensitive or special data.

☐ We know which suppliers have access to critical systems.

☐ Suppliers' management and administrator rights are transparent.

☐ Access rights shall be periodically assessed.

☐ No longer necessary access shall be withdrawn in good time.

Risk assessment

☐ For critical suppliers, an up-to-date risk analysis has been carried out.

☐ Cybersecurity risk risks are assessed before contracting.

☐ risks shall be re-evaluated in the event of major changes or incidents.

☐ An owner is designated for each relevant supplier risk.

☐ Rest risks are explicitly assessed and accepted.

Contractual arrangements

☐ Security obligations are laid down in concrete terms.

☐ If the information is not available, please provide the following information:

☐ Privacy and processing arrangements are up to date.

☐ Audit or information rights are established.

☐ Agreements concerning sub-suppliers are present.

☐ Exit and portability are contractually regulated.

Continuity

☐ For critical suppliers, what is the meaning of failure has been determined.

☐ RTO and RPO have been established where relevant.

☐ Alternative processes or emergency scenario debt instruments exist.

☐ Backup and recovery are tested demonstrably.

☐ We know what happens at 4 hours, 24 hours and 72 hours of outage.

Assurance and oversight

☐ Relevant certifications shall be checked for scope and validity.

☐ Critical suppliers provide periodic assurance or other evidence.

☐ Important findings are demonstrably monitored.

☐ Management reports periodically on supplier risk.

☐ Serious shortcomings are escalated to governance.

Incident management

☐ Critical suppliers know who to warn with us.

☐ Our organisation knows who decides internally in case of a supplier incident.

☐ Reporting obligations and communication routes are pre-defined.

☐ Supplier incidents are included in incident exercises.

☐ After an incident, evaluation and improvement takes place.

Board-level assurance

☐ Supply chain risk is part of the periodic cyber risk reporting.

☐ Critical suppliers and main dependencies are known to the board.

☐ Tangible supplier risks are reported to RvT or RvC.

☐ It's been clearly established who owns risk.

☐ Open deficiencies in critical suppliers have an owner and deadline.

☐ Recoverable risks are demonstrably accepted at the appropriate level.

Five questions any board member can ask tomorrow

Anyone who wants to put the subject directly on the agenda can start with five simple questions:

1. Which suppliers are our biggest cyber or continuity risk?

2. Which of these suppliers have access to our most critical data or systems?

3. What happens to our services when one of them fails for 24 hours?

4. How quickly should they inform us when they have a cyber incident themselves?

5. How do we know that the agreed security measures actually work?

If these questions cannot be answered easily, this is a good reason to re-evaluate supplier management.

Summary: NIS2 supply chain requires demonstrable board-level control

The incident at CEVA shows above all that information security does not end at the borders of its own organisation.

Your suppliers are part of your risk profile.

Their systems process your data.

Their employees can have access to your environment.

Their continuity can determine your service.

And their security incident may eventually affect your customers, reputation and board-level responsibility.

For directors and supervisors, therefore, the most important question is not how an attacker technically entered CEVA.

The more important question is:

Do we know which suppliers can touch us and have we been able to find out what we do when that happens?

That's the core of adulthood. NIS2 supply chain security.

Not every attack can be prevented.

But dependencies can be made visible, responsibilities can be defined, suppliers can be assessed and organisations can prepare for the moment when an important chain partner is affected.

And that is precisely where the responsibility for governance and oversight lies.