top of page
Nimbus-logo

Your Customer's NIS2 Obligation Is Now Your Renewal Paperwork

Kostas Tsiolas
3 days ago
6 min read

Why SMEs must now prove their security—not merely claim it—and the three questions that can determine a renewal.

Most SMEs will never face a direct NIS2 audit. Many will instead be scrutinised by a customer that does.

That is how supply chain security reaches smaller companies. Not through a regulator's letter, but through a renewal annex or a time-bound questionnaire from the customer they can least afford to lose.

In my advisory work, I have seen both sides: new security clauses entering contracts and renewals, and suppliers struggling to produce evidence for larger customers. The outcome is the same: the renewal slows, and the discussion shifts from price to proof.

This article addresses both sides: the supplier preparing the response, and the CISO or procurement lead deciding whether the response is credible.


Why this is landing now

The data explains the pressure. Verizon's 2026 Data Breach Investigations Report found that breaches involving a third party rose 60% year on year and now account for 48% of all breaches in its dataset.

Regulation turns that risk into an obligation. Under NIS2, essential and important entities must cover supply chain security in their cybersecurity risk-management measures (Article 21(2)(d)) and take into account the vulnerabilities specific to each direct supplier and the cybersecurity practices of their suppliers (Article 21(3)). Each Member State carries this into national law; in Greece it sits in Article 15 of Ν. 5160/2024.

An in-scope company cannot meet that duty on its own. It has to ask its suppliers. So the obligation travels down the chain, clause by clause, until it reaches a 20-person software house or payroll provider that was never in scope itself.


What actually arrives in the contract

The clauses I have seen fall into four groups:

  • Audit rights. The customer, or someone it appoints, may verify your controls.

  • Incident notification deadlines. You must inform the customer within a fixed number of hours of an incident that affects it.

  • MFA requirements. Often stated for all access, sometimes explicitly including administrators and remote access.

  • Flow-down. The same obligations apply to your own subcontractors, which in most SMEs includes the external IT partner.

Alongside the clauses comes the questionnaire. That is where a supplier discovers the difference between having a control and being able to prove it.

The notification clause deserves particular attention. Under NIS2 Article 23, an in-scope customer must send an early warning within 24 hours of becoming aware of a significant incident. When the incident starts at a supplier, the supplier is often the only one who knows. A late supplier notice doesn't pause the customer's problem. It compresses everything the customer has to do next, which is why tight notification deadlines are now written into supplier contracts.


Declaring versus proving

Most supplier answers are true in spirit. "Yes, we use MFA." "Access is restricted to authorised staff." "We will notify you promptly." The problem is that none of them can be verified as written.

ENISA's SME Cyber Resilience Maturity Assessment Model, published in July 2026, offers a useful standard here, even though it was built for the Cyber Resilience Act rather than supplier assurance. Its scoring rules are blunt:

  • Scores should rest on objective evidence, such as documented procedures, implemented practice or observable behaviour, rather than assumptions or informal impressions.

  • A documented process that isn't followed in day-to-day work scores Level 2, not Level 3.

  • Level 4 requires that practices are applied consistently and that evidence exists: logs, records, reports.

Apply that standard to a typical supplier questionnaire and a lot of confident "yes" answers would drop a level or two.

Verizon's data suggests the gap is real. In its 2026 analysis of third-party cloud environments, only 23% of third-party organisations fully remediated missing or improperly secured MFA on cloud accounts, and 37% of organisations had an administrator account with MFA disabled on an IaaS platform. Weak passwords and permission misconfigurations took almost eight months to reach 50% resolution.


The three questions that decide the renewal

In the questionnaires and clauses I have seen, three items give suppliers the most difficulty. Two are identity questions and one is a response question, and all three share a simple test: could you show the evidence to your customer within one working day?

1. MFA everywhere, including the accounts nobody thinks about

What the customer asks: Is MFA enforced on all access to systems that hold our data?

The typical answer: "Yes, MFA is enabled."

What proof looks like:

  • A coverage report showing enforcement across all accounts, not a policy document. In Microsoft 365 that means the Conditional Access policies plus a sign-in or authentication methods report showing who is actually covered.

  • Explicit coverage of administrator accounts, remote access and the IT partner's accounts. These are also the accounts an attacker values most.

  • A list of every exclusion, each with an owner and a reason.

2. Who can reach our data, and how fast leavers lose it

What the customer asks: Who in your organisation has access to our systems or data, and how do you remove access when someone leaves?

The typical answer: "Only authorised staff, and access is removed when people leave."

What proof looks like:

  • A current list of named people and service accounts with access to the customer's environment or data, including guest accounts in the customer's own tenant and shared platforms.

  • The offboarding record for recent leavers, showing the date access was removed next to their last working day.

  • Evidence of a periodic access review: who reviewed, when, and what was removed.

Professional and logistics services feel this most sharply. An accounting firm, a payroll provider or a 3PL can hold standing access into customer systems while its joiner-leaver process lives in someone's inbox.

3. Incident notification within the contract deadline

What the customer asks: If you suffer an incident that affects us, who notifies us, how, and within what time?

The typical answer: "We will inform you immediately."


What proof looks like:

  • A short incident response plan naming who decides that an incident affects a customer, who notifies, and through which channel, with a backup for evenings and holidays.

  • The notification deadlines for each major customer in one place, so nobody has to search contracts during an incident.

  • A record of at least one tabletop exercise that tested the notification step against the deadline.

ENISA's model makes the same point for product security incidents: plans should be tested, even if only through simple walk-throughs or tabletop exercises.


The second clock for product makers: the Cyber Resilience Act

If your company builds software or connected devices sold in the EU, a separate obligation already applies to you directly.

Since 11 September 2026, Article 14 of the Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities and severe incidents affecting their products: an early warning within 24 hours of becoming aware, followed by a fuller notification within 72 hours. It covers products already on the market, not only new releases. The rest of the CRA, including secure-by-design requirements, technical documentation and SBOMs, applies from 11 December 2027.

Two points of scope matter:

  • The CRA covers products with digital elements. Pure SaaS generally falls outside it, although your customers' contracts will still ask the same three questions.

  • The reporting duty is yours, not your customer's. Customers will still want to know you can meet it, because a vulnerability in your product is a vulnerability in their environment.

ENISA's maturity model is a practical starting point, and it comes with a free self-scoring spreadsheet. Treat the result as a baseline, not a certificate: ENISA states that even an advanced score is not evidence of compliance.


For buyers: ask fewer questions, demand more evidence

The customer side has its own version of the problem. A long questionnaire produces a long list of self-declared answers, and very little of it gets verified.

For most SME suppliers, three evidence requests will tell you more than three hundred ticks:

  1. An MFA coverage report for every account that touches your data, including their administrators and their IT partner.

  2. The list of people with access to your systems today, and the offboarding record for the last leaver.

  3. The name of the person who notifies you, the deadline they are working to, and the date they last rehearsed it.

It is proportionate, quick for a capable supplier and hard to fake. It also matches what ENISA's model expects every organisation to do with its own suppliers: define clear cybersecurity expectations for them.


Where to start this month

  1. Collect the security clauses and questionnaires from your five largest customers, and list what each one asks you to prove.

  2. Sit down with your IT partner for an hour and answer the three questions above with evidence, not statements.

  3. Close the quickest gaps first: MFA exclusions, stale accounts, a missing notification owner.

  4. Write a one-page notification procedure and rehearse it once.

  5. If you ship software or devices, run ENISA's self-check and confirm your CRA reporting route.

The renewal is decided on evidence

Security questionnaires used to be a formality. They are becoming a commercial gate. The suppliers who get through fastest won't necessarily have the most controls. They will be the ones who can show what they have.

If one of these three answers doesn't come easily, or a customer's security annex is waiting in your inbox, get in touch. A first conversation is free, and we can work out together where your evidence gap is. Sources

 
 
 

Comments

bottom of page