Skip to main content

NIS2 for suppliers: what your customers will ask you to show

Customers covered by NIS2 pass security questions down to suppliers. See what they typically ask, which evidence to keep and how to answer honestly.

BlueNova IT is responsible for the content of this guide, and AI tools may assist with drafting and images.

Abstract 3D render of a chain of linked glass cubes passing a blue glass shield token between two glass towers

Customers that fall under NIS2 are expected to cover supply chain security in their own security measures, so they typically send suppliers a questionnaire or contract clauses covering policies, access control, incident handling, backups, updates, training and your own suppliers. Prepare one short, dated evidence pack, answer honestly and agree incident contacts in advance. This is general information, not legal advice; check the current directive and your national authority.

If you sell to a larger company, a security questionnaire with NIS2 mentioned somewhere in it can land without warning, and it can be passed to whoever looks after IT. Answering each one from scratch is slow and invites inconsistent answers. The better approach is to know which areas customers ask about, keep a small set of evidence ready and be straightforward about gaps. This guide covers that supplier-side view, from the first request to the contract clauses that may follow.

Why customers start asking their suppliers about NIS2

A supplier questionnaire is rarely about you alone. When an organisation falls under NIS2, the measures it takes shall include, at a minimum, supply chain security (Article 21), as applied in national law, so it looks at the suppliers that can reach its data or run part of its service. The questions you receive are its way of showing that it has looked.

This guide takes the supplier’s side. Whether NIS2 applies to your own company is a different question, and our guide to NIS2 for SMEs and the first steps to take covers scope and a general readiness checklist, so we do not repeat that here. BlueNova IT is not a law firm, and this is general information, not legal advice. The table shows the forms a request typically takes and what to have ready for each.

Type of requestWhat it looks likeWhat to have readyTake care with
Security questionnaireA spreadsheet or portal form with questions on policies, access, incidents, backups and suppliers.One dated evidence pack and a named person who answers.Answering from memory and contradicting an earlier answer.
Contract clauseSecurity measures, incident notification and cooperation written into the supply agreement.Your procedures, a contact sheet and a clear view of what you can actually do.Accepting a duty or deadline you cannot meet; take advice on the wording.
Evidence requestA request for a policy, a settings screenshot, a backup record or a training list.Short, dated documents that are easy to share.Sharing more than was asked, or documents that are out of date.
Information or review rightsThe customer asks to review your measures or to receive information on request.An agreed way to share evidence and a named contact.Open-ended access to your systems; agree scope and process first.
Subcontractor questionThe customer asks which of your suppliers can reach its data.A supplier list showing what each one handles.Not knowing which of your tools hold customer data.

Their obligation, not automatically yours

The NIS2 Directive, (EU) 2022/2555, places its obligations on the entities it covers. Article 21 says the measures those entities take shall include at least a list of areas, and one of them is supply chain security, including security-related aspects of the relationships with their direct suppliers and service providers. Entities are also asked to take account of the vulnerabilities specific to each direct supplier.

That does not turn every supplier into a regulated entity. The pressure reaches you through your customer’s own duties and the contracts it signs. How each Member State applies the directive depends on national law, so check the current text and your national authority rather than relying on a summary.

What a request usually looks like

A request typically arrives in one of a few forms: a questionnaire, a clause in the supply contract, a request for a specific piece of evidence, a question about your own subcontractors, or a request for information or review rights. Many customers use more than one, for example a questionnaire at onboarding and a clause at renewal.

The sender is often procurement or a security or compliance team, and the deadline can be short. It helps to agree early who owns the reply on your side, because questions about access, backups and incidents tend to need input from whoever runs IT, while contract wording needs your management and, where the stakes are high, your own adviser.

If you provide ICT services yourself

If your company provides managed IT services to other businesses, check your own position separately. Annex I of the directive lists ICT service management (business-to-business), which covers managed service providers, and ENISA has published technical guidance on the implementing rules for certain digital infrastructure and ICT service providers.

Whether any of this reaches you depends on your size, your activity and national law, and we do not assume it either way. Take the question to legal counsel or your national authority. The rest of this guide is useful in both cases, because customers typically ask similar questions whether or not you are covered yourself.

What customers typically ask, area by area

Questionnaires differ, but many follow similar areas to those the directive names for the entities it covers. Typical questions, in the order they usually appear:

  1. Policies: is there a written security policy, and who owns it?
  2. Access: is multi-factor authentication used, and who holds administrator rights?
  3. Incidents: how are incidents handled, and who is the contact for the customer?
  4. Backups: what is copied, and when was a restore last tested?
  5. Vulnerabilities: how are known weaknesses handled and systems and devices kept up to date?
  6. People: do staff receive security training?
  7. Suppliers: which of your suppliers can reach our data?

Each customer decides what it asks, and national rules may add to the directive, so treat this as a pattern rather than a fixed list. If you want help turning these areas into everyday practice, our cybersecurity services can help with the practical side of these areas, with scope agreed per organisation.

Policies and who owns security

Many customers start here: is there a written security policy, and does a named person own it? In a small company that owner is often a director or the person who manages IT, and that is fine. The owner should be a named person and the document should be current.

A short policy that people follow is more useful than a long template nobody has read. Two or three pages covering how you protect data, who may access what, how incidents are reported and when the document is reviewed are a sound starting point. Keep the dated copy and a note of the last review as your evidence, and make sure what the document says matches what you actually do.

Access control and multi-factor authentication

Expect questions on multi-factor authentication, administrator rights and what happens when someone joins or leaves. The directive’s own list of measures includes access control policies and the use of multi-factor authentication, where appropriate (Article 21(2)(i) and (j)), so customers often ask the same of suppliers.

Useful evidence is modest: a settings export or screenshot showing multi-factor authentication, a short list of administrator accounts with an owner, and starter and leaver records. Check for shared logins and old accounts first, because those are common gaps. Our Microsoft 365 security baseline checklist covers many of these access basics.

Incident handling and reporting contacts

Customers typically want to know three things: how you would notice an incident, who decides what happens next and who they would hear from. A one-page procedure and a contact sheet answer most of it. Name a person and a deputy, because a single contact who is away leaves the customer with nobody to reach.

Be realistic about availability. Say who can be reached and when, rather than implying cover you do not have. The customer’s own reporting steps depend on hearing from you, which is why the contract section below deals with notification in more detail. Practising the procedure once, even as a short walk-through, shows you whether the contact details still work.

Backups, recovery and updates

The directive’s list of measures includes business continuity, such as backup management and disaster recovery (Article 21(2)(c)), so backups are a standard question. Answer plainly: what is backed up, where the copies are kept, who can delete them and when a restore was last tested. Keep a dated restore test record, not just a statement that backups run.

For updates, describe the routine rather than promising perfection: how operating systems and applications are updated, how devices are tracked and encrypted, and what happens when a device is lost. A device list and an update schedule are enough evidence for most questionnaires. If you are unsure where you stand, a short review of backups and devices is a sensible first piece of work.

Your own suppliers and subcontractors

Customers expect your service to depend on other providers, so they ask which ones can reach their data. List the cloud services, email, accounting, payroll and IT providers that handle customer information, and note what each one handles and who at your company owns the relationship.

Gaps often appear here: tools adopted by individual staff that nobody recorded. Build the list from your invoices, your single sign-on or admin consoles and a short conversation with each team. Then read the main terms of the important suppliers, so you can say what they commit to on security and incidents.

Build one evidence pack and answer honestly

Rather than answering each questionnaire from scratch, assemble one short evidence pack and reuse it. Most requests ask for variations of the same things, and a single, dated source keeps your answers consistent from one customer to the next.

  • One-page policies for security, access and incidents, each with an owner and a review date.
  • An administrator list, a settings export for multi-factor authentication and starter and leaver records.
  • Backup scope, a restore test record, an update routine and a device list.
  • An incident contact sheet and a supplier list.
  • Training dates and a short note of who attended.

BlueNova IT can help gather this evidence from settings, backups and access records, and can work alongside your own IT team, with scope agreed per organisation. We do not certify anyone, and the pack is not proof of compliance; it shows what you do.

What goes into a short evidence pack

Keep the pack in one place with one named owner, and keep each item short and dated. A folder of short documents is easier to share and to update than one long file, and it lets you send only what a customer asks for. Remove details that are not needed, such as other customers' names, before anything is shared.

Review it on a fixed rhythm, for example twice a year and after a significant change in tools or people. An out-of-date document can be worse than none, because it contradicts what you do today. When a customer sends a new questionnaire, update the pack with any new answer so the next reply starts further along.

Answering "not yet" without overclaiming

Gaps are common, and customers often expect some. A plain "not yet, and here is the dated plan" is a better answer than an overstatement that a customer may later test, because it shows you know where you stand. For example: restore tests are not yet scheduled, the first is planned for a named month and a named person owns it.

Avoid wording that sounds like a conclusion you cannot support, such as saying you are compliant. Describe what you do, with evidence, and leave the judgement to the customer. If an answer depends on a tool or setting you have not verified, check it before you write it down, because a wrong answer is hard to retract.

Questions about certifications and standards

Some questionnaires ask whether you hold a certification or follow a recognised standard. Answer yes or no. If you hold none, say so and describe what you have in place instead, with evidence. Avoid phrases such as "aligned with" a standard unless you can explain exactly what that means, because a customer may read it as certified.

The list of measures in Article 21(2) describes areas of practice and does not itself name a certificate for suppliers to hold, although other provisions, national rules and individual contracts may ask for more, so a request for one is usually a matter between you and the customer. If it is a contract requirement, take advice on what it commits you to before you accept it. BlueNova IT does not certify anyone and does not guarantee that a customer will accept your answers.

From a customer security request to a reusable reply
Answer once from an evidence pack, then keep it dated.
Read the steps as text

Receive, name an owner, pull evidence, answer honestly, update the pack

Contract clauses and incident notification

Questions on a form can turn into contract wording. A customer may ask you to accept clauses on security measures, incident notification and cooperation, and this is the point where an easy answer on a form becomes a duty you need to be able to meet. Read these clauses against what you actually do, not against what you would like to do.

Agree who the contact is, how you will tell them and what you can realistically commit to before an incident, not during one.

BlueNova IT is not a law firm and does not review contracts for legal effect, so wording that creates liability belongs with your own adviser. The technical side is different: contact lists, incident procedure drafts and backup and access evidence are things we can help prepare, with scope agreed per organisation.

Clauses you may be asked to accept

Typical clauses cover the security measures you maintain, notification of incidents that affect the customer, rights to receive information or to review your measures, the conditions for using subcontractors, return or deletion of data at the end of the contract and cooperation after an incident.

Not every contract has all of them, and the wording varies a great deal. Look for phrases that fix a deadline, a standard or a right of access, and check each against your real practice. If a clause asks for something you do not do today, ask whether it can be reworded, phased in or limited in scope. Raising this before signing is far easier than explaining it afterwards.

Agreeing notification contacts and timing

Customers ask how you would tell them about an incident because their own reporting steps depend on it. For a significant incident, the directive text in Article 23(4) sets out, without undue delay and in any event, three steps: an early warning within 24 hours of becoming aware, an incident notification within 72 hours of becoming aware and a final report not later than one month after that notification. Those are duties of the entity the directive covers, not of a supplier merely because it supplies that entity; if you are covered in your own right, check whether they apply to you as well.

For you, the practical question is what the contract asks. Agree a named contact on each side, the channel to use and what you will share first. Think carefully before accepting a timing you cannot realistically meet, and be honest about when your contact is available.

Proportionality and when to take advice

The directive asks entities to keep their own measures appropriate and proportionate (Article 21(1)), and it is reasonable for a request to a supplier to reflect the size of the relationship. For example, a supplier that handles little customer data and has no access to its systems can reasonably be asked for less evidence than one that runs part of the service. If a request looks out of proportion, say so politely and ask what risk the customer is trying to cover; often a shorter answer is enough.

Take advice before accepting anything that creates liability, sets a fixed deadline or gives open-ended access to your systems. Your own adviser can read the wording for legal effect. We can help you check whether the technical commitments are ones you can keep, but we do not give legal advice.

Preparing to tell a customer about an incident
Agree the contact and the route before an incident happens, not during one.
Read the steps as text

Name contacts, agree the channel and first message, check the timing, practise once

Where an IT partner can help, and where it cannot

An IT partner can help with the technical half of a supplier request and cannot take over the rest. BlueNova IT provides cybersecurity, cloud and Microsoft 365 and managed IT services, and can work alongside your own IT team, and co-managed IT is something we offer regularly. Support is in English and Spanish, Monday to Friday, 09:00-⁠18:00 CET, and scope is agreed with each organisation.

The work is practical: finding out what is really in place, tidying access and backups, drafting short procedures and helping you put the answers into a form a customer can use. The answers and the decisions stay with you. We do not offer security operations centre, managed detection or penetration testing services, and nothing here is a promise of what a customer will accept.

Gathering evidence from your own systems

An IT partner can pull evidence from the systems you already run: a multi-factor authentication settings export, a list of administrators, a backup scope and restore record, a device list and an update routine. It can also tidy what it finds, such as old accounts and shared logins, so the evidence reflects a better position than the one you started from.

It can help draft the short procedures customers ask for and answer the technical questions on a form. What it cannot do is decide what is acceptable for your business, so keep the answers and the sign-off with your management. For related background, see our guide to a security audit, a vulnerability scan and a penetration test.

What BlueNova IT does not do

BlueNova IT cannot certify your compliance or guarantee that a customer will accept your answers, and does not try. We do not give legal advice, review contracts for legal effect, or decide whether NIS2 applies to you. We also do not hold out an evidence pack as proof that any directive is satisfied.

Those questions go to your own legal counsel or your national authority. What we can do is help you check that the technical statements you make are accurate and backed by records.

Official sources to check

Rules and guidance change, so go to the source rather than a summary, ours included. Start with the text of Directive (EU) 2022/2555 on EUR-Lex, then the European Commission’s NIS2 page and the ENISA announcement of its technical implementation guidance.

National law decides how the directive applies where you operate, so also check the law of the Member State where you operate and your own national cybersecurity authority. This guide is general information, not legal advice.

Most of the work is preparation. Know the areas customers ask about, keep one short, dated evidence pack, answer honestly and agree incident contacts in advance, so a request becomes a routine task rather than a scramble. Scope and obligations depend on national law, and this guide is general information, so check the current directive and your national authority. If you would like to talk through what a customer has asked of you, BlueNova IT can discuss what support fits.

Frequently asked questions

Do small suppliers have to comply with NIS2?
The directive places its obligations on the entities it covers, which under the directive's size rules generally means medium-sized and large organisations in the listed sectors, with some exceptions and variations in national law. A small supplier may not be covered directly, but a customer that is covered must address supply chain security, so it will probably ask you questions. Confirm your own position with legal counsel or your national authority; see our NIS2 guide for a way to organise the question.
What do customers usually ask suppliers under NIS2?
Typically about policies and who owns security, access control and multi-factor authentication, how incidents are handled and who to contact, backups and restore tests, updates and vulnerabilities, staff training, and your own suppliers. Each customer decides its own questions, so treat this as a common pattern rather than a fixed list.
Do we need a security certification to answer a NIS2 supplier questionnaire?
The directive's list of measures describes areas of practice rather than naming a certificate for suppliers to hold, although national rules and individual contracts may ask for more. A request for a certificate is usually a matter between you and the customer. If you do not hold one, say so plainly and describe what you have in place, and do not imply a certification you do not have. Check the contract wording and take advice before accepting a requirement.
How quickly must a supplier report an incident to a customer?
The directive sets timelines for the covered entity's own reports on significant incidents: without undue delay and in any event, an early warning within 24 hours of becoming aware, an incident notification within 72 hours of becoming aware and a final report not later than one month after that notification. These are duties of the covered entity, not of a supplier merely because it supplies that entity. What a supplier owes a customer is normally set by the contract. Agree a realistic route and contact in advance, and take advice before accepting a specific deadline.
Can an IT provider make us NIS2 compliant?
An IT provider cannot decide on your behalf that you are compliant, and BlueNova IT does not certify or guarantee compliance. An IT partner can help gather evidence, tidy access and backups and draft short procedures, but whether you are covered and what you must do are questions for legal counsel or your national authority.
What is a supplier security questionnaire?
A list of questions a customer sends to understand how you protect its data and services, usually covering policies, access, incidents, backups and subcontractors. Preparing one short evidence pack lets you answer most of them accurately and consistently.
What are the compliance requirements for vendors under NIS2?
The directive sets measures for the entities it covers, including supply chain security, rather than a separate list of requirements for vendors. What is asked of a vendor usually comes through the customer's questionnaire and contract, so it varies. Check the customer's wording, and confirm your own position with legal counsel or your national authority.
What does a NIS2 incident report contain?
For a significant incident, the directive describes main steps for the covered entity, among them: an early warning that indicates whether unlawful or malicious acts are suspected and whether there may be cross-border impact, an incident notification that updates it with an initial assessment of severity and impact, and a final report with a detailed description, the likely threat type or root cause and the mitigation measures. These are duties of the covered entity; check the current text and your national authority.