- NIS2 Article 21(2)(d) makes essential and important entities manage the security of their direct suppliers. Article 21(3) tells them to look at each supplier's vulnerabilities, product quality and secure development practices. The questionnaire is how they do it.
- Questions follow the ten measures of Article 21(2): governance, risk, incidents, continuity, supply chain, secure development, testing, training, cryptography, access and MFA.
- Answer what is implemented and evidenced, not what is planned. Give dates and scope, and say "partially" when that is the truth.
- Watch the contract that follows: notification deadlines, audit rights, flow-down to your own suppliers, and liability for your customer's fines.
- Answer once, keep it current, and share one link (a trust page) instead of forty spreadsheets.
Why your customers send NIS2 questionnaires
The NIS2 Directive (EU) 2022/2555 requires essential and important entities to take security measures that include "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" (Article 21(2)(d)). Article 21(3) adds that they must take into account "the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures".
Their management body approves these measures and can be held liable for them (Article 20). So their procurement, IT and legal teams now ask every supplier the same questions. That includes suppliers who are nowhere near NIS2 scope themselves, such as a 12-person software firm, an IT service desk or a payroll bureau.
For digital providers (cloud, data centres, managed and managed security services and others) the expectations are written down in detail in the Annex of Implementing Regulation (EU) 2024/2690. Point 5.1.4 lists what their supplier contracts should cover "where appropriate". Many customers outside those sectors copy this list, so it is a good predictor of what you will be asked:
- cybersecurity requirements for the supplier;
- awareness, skills, training and certification requirements for the supplier's staff;
- background verification of the supplier's staff;
- notification "without undue delay" of incidents that present a risk to the customer;
- the right to audit, or the right to receive audit reports;
- handling of vulnerabilities that present a risk to the customer;
- rules for subcontracting, with the same security requirements flowed down;
- obligations at termination, such as returning and deleting information.
Point 5.2 also requires them to keep a register of direct suppliers with contact points and the ICT products, services and processes each one provides. That is why they ask for a security contact and a description of your service.
Check your own status too. If you are a medium-sized or larger company in an NIS2 sector (for example a managed service provider or a cloud provider), you are probably in scope yourself and have your own obligations. Our NIS2 overview and the 2024/2690 checklist cover that side.
The question themes you will see
Formats differ (an Excel sheet, a procurement portal, a standard questionnaire such as the CSA CAIQ, or a sector template), but the content maps to Article 21(2):
| Theme | Typical questions | NIS2 basis |
|---|---|---|
| Governance and policy | Do you have an approved information security policy? Who is responsible? When was it last reviewed? | 21(2)(a) |
| Risk management | Do you perform risk assessments? How often? Is there a risk treatment plan? | 21(2)(a) |
| Incident handling | Do you have an incident response plan? How fast do you notify customers? Have you had incidents in the last 12 months? | 21(2)(b) |
| Continuity | Backups (frequency, offline or immutable, restore tests), RTO and RPO, a disaster recovery plan and its last test | 21(2)(c) |
| Your suppliers | Which sub-processors and subcontractors do you use, where are they, and how do you assess them? | 21(2)(d) |
| Secure development and vulnerabilities | SDLC, code review, dependency scanning, patch timelines, coordinated vulnerability disclosure | 21(2)(e), 21(3) |
| Effectiveness | Internal audits, external penetration tests, certifications | 21(2)(f) |
| Hygiene and training | Security awareness training for all staff, phishing simulations, endpoint protection | 21(2)(g) |
| Cryptography | Encryption at rest and in transit, key management | 21(2)(h) |
| People, access and assets | Background checks, joiner/mover/leaver process, least privilege, access reviews, asset inventory | 21(2)(i) |
| Authentication | MFA for all users, admins and remote access; secured communications | 21(2)(j) |
How to answer honestly without over-promising
A questionnaire answer often ends up as a contractual representation, so a wrong "yes" can turn into a breach of contract later. Some rules that keep you safe and still win the deal:
- Separate policy, practice and proof. "We have a backup policy" is weaker, and safer, than "Daily backups, offsite and immutable, restore last tested 12 May 2026". Only claim the second if you can show it.
- Use "partially" and explain. "MFA enforced for all admin and remote access; rollout to all staff accounts completes in Q1 2027" is credible. A blanket "yes" that an auditor later disproves is not.
- State scope. Say which systems, entities and locations an answer covers. "ISO 27001 certified" for one office or one product is not the same as for the whole company.
- Avoid absolutes. Not "all vulnerabilities are patched immediately", but "critical vulnerabilities within 7 days, high within 30, per our vulnerability management procedure".
- Do not answer for your suppliers. For hosting, refer to your provider's certifications and describe what you configure: the shared responsibility split.
- "Not applicable" needs a reason. "N/A: we do not host customer data; the service runs on the customer's infrastructure."
- Roadmap items get dates and an owner, and you must then deliver them.
- One source of truth. Keep a master answer library so the same question gets the same answer for every customer, and review it at least yearly or after major changes.
- Escalate anything that sounds like a promise ("supplier shall...", "guarantee", "at all times") to whoever signs contracts.
Evidence to attach (and what not to send)
- ISO 27001 certificate and, on request, the Statement of Applicability
- SOC 2 Type II report, or a bridge letter
- Penetration test executive summary or attestation letter
- Information security policy (summary or the full top-level policy)
- Sub-processor list with locations
- Data processing agreement (GDPR Article 28)
- Incident response and BCP summaries, last test dates
- Cyber insurance certificate
- Full penetration test reports with exploitable detail
- Network diagrams with IP ranges, or firewall exports
- Your complete risk register
- Screenshots containing other customers' data or names
- Credentials, keys or configuration files, even "just for review"
Offer a call or a screen-share for anything sensitive.
Contract clauses to watch
The questionnaire is usually followed by a security addendum. These are the clauses that cause problems later:
- Incident notification within 24 hours (or "immediately"). Your customer has 24 hours to send its own early warning (NIS2 Article 23(4)(a)), so it wants your notice faster. Commit to what you can actually do, define the trigger ("incidents that affect the customer's data or services, after confirmation") and the channel, and avoid committing to "any suspected incident". The 2024/2690 Annex itself only says "without undue delay".
- Audit rights. On-site audits at any time, by anyone, at your cost, are unworkable for a small supplier. Propose: certification and reports first, a reasonable notice period, once a year unless there is an incident, confidentiality, and costs borne by the requester. Point 5.1.4(e) explicitly allows a "right to receive audit reports" as an alternative.
- Flow-down. If you must impose the same terms on your subcontractors (5.1.4(g)), check that you can. Hyperscalers will not sign your customer's addendum.
- Background checks (5.1.4(c)). Agree what is lawful in your country and proportionate to the role. Employment and privacy law limit what you can screen.
- Training and certification requirements (5.1.4(b)). Make sure "certified" does not silently mean a specific paid certification for every engineer.
- Vulnerability handling SLAs (5.1.4(f)). Align them with your real patch timelines.
- Liability and indemnities for your customer's regulatory fines. Usually uninsurable and disproportionate; cap them.
- "Comply with NIS2" as a blanket clause, when you are not an NIS2 entity. Replace it with the specific measures you agree to.
Answer once, share a link
Most questionnaires ask the same 80% of questions. The efficient set-up:
- Build a master answer set organised by the Article 21(2) themes above, with an owner and review date per answer.
- Link each answer to its evidence (policy version, certificate, test report) with an expiry date, so nothing goes stale unnoticed.
- Publish a trust page: public overview, certifications, sub-processors and a security contact, plus NDA-gated documents on request.
- Reply to a new questionnaire with the link first, and fill in only the questions the trust page does not answer. Many customers accept this, especially smaller ones.
- When a customer's questionnaire raises a genuinely new question, add the answer to the master set.
Publish your answers once with a Dazr trust page
Dazr Compliance turns your controls, policies and evidence into a shareable trust page that answers supplier security questionnaires, with expiry alerts so certificates and test reports never go out of date. Your NIS2, ISO 27001 and GDPR work feeds the same page.
FAQ
We are not covered by NIS2. Do we have to answer?
Legally, no. Commercially, usually yes: your customer is required to assess its direct suppliers under Article 21(2)(d) and 21(3) of NIS2, and an unanswered questionnaire can cost you the contract. Answer proportionately and honestly.
Can we just send our ISO 27001 certificate?
It answers a large part of most questionnaires, and many customers accept it with the Statement of Applicability. Check the certificate's scope covers the service you provide. Some questions, such as notification times, sub-processors and data locations, still need specific answers.
Should we agree to notify incidents within 24 hours?
Only if you can, and only with a clear trigger. Your customer has its own 24-hour early-warning deadline under NIS2, which is why it asks. A commitment to notify confirmed incidents affecting the customer without undue delay, and in any case within an agreed number of hours, is often a workable middle ground.
How often should we update our answers?
At least yearly, and after significant changes such as a new hosting provider, a major incident or a certification renewal. Customers often re-assess critical suppliers annually.
Related
Dit artikel in het Nederlands: NIS2-leveranciersvragenlijst beantwoorden.
Sources (as of 1 October 2026)
- Directive (EU) 2022/2555 (NIS2), Articles 20, 21 and 23.
- Commission Implementing Regulation (EU) 2024/2690, Annex points 5.1 and 5.2.
- ENISA Technical Implementation Guidance on Implementing Regulation 2024/2690, June 2025.
This guide is general information as of 1 October 2026 and is not legal advice. Have contractual commitments reviewed before you sign.