The NIS2 supply chain audit checklist: 31 questions and the evidence each one wants

Why the audit exists at all

NIS2 puts supply chain security inside the mandatory risk-management measures. Article 21(2)(d) requires entities in scope to address security in supplier relationships, and Article 21(3) tells them to take into account each supplier's specific vulnerabilities and overall security quality. Article 24 lets member states require the use of certified products, and Articles 32 and 33 give supervisors the power to inspect. The chain of consequence is short: a supervisor inspects a hospital group, the hospital group has to show how it assessed its AI vendor, and the hospital group sends you a questionnaire.

That is why the questions feel disproportionate to your contract value. They are not scaled to your revenue. They are scaled to the customer's exposure under Article 23 incident reporting and to the personal liability that Article 20 places on its management bodies.

Block 1: governance and accountability (questions 1 to 5)

1. Who in your organisation owns information security, by name and role, and to whom do they report? Evidence: an org chart extract plus the security policy signature page.
2. Which management body approved your security policy, and when was it last reviewed? Evidence: minutes or a signed approval record dated within twelve months.
3. Do you fall in scope of NIS2 yourself, and as an essential or important entity? Evidence: a one-page scoping memo naming the sector annex and the member state of your main establishment.
4. Which certifications do you hold, with scope statements? Evidence: ISO/IEC 27001 certificate with the statement of applicability scope, or SOC 2 Type II report, not a logo on a website.
5. How does your management body receive security training and how often? Evidence: attendance record for the last cycle, since Article 20(2) makes this an explicit duty for your customers too.

Question 3 is where AI vendors lose credibility fastest. Many are out of NIS2 scope themselves and answer as if that ends the conversation. It does not. The customer's duty under Article 21(2)(d) applies whether or not you are regulated, so answer with the scoping memo and then move on to the substance.

Block 2: risk management and asset control (questions 6 to 11)

1. Describe your risk assessment methodology and show the last output. Evidence: a risk register extract with owners, ratings and review dates.
2. How do you inventory assets, including models, datasets and inference endpoints? Evidence: asset inventory schema and a redacted sample.
3. Which third parties process customer data on your behalf? Evidence: a subprocessor list with country, purpose and legal basis.
4. How do you assess your own suppliers? Evidence: your supplier security standard and the last two completed assessments, redacted.
5. What is your change management process for model and infrastructure changes? Evidence: a change record for a recent production change, showing approval and rollback.
6. How do you handle end of support for components you ship? Evidence: a published support period statement, which also serves your Cyber Resilience Act obligations.

Question 7 is the one that separates AI vendors from ordinary software vendors. Auditors increasingly ask for models and training datasets to appear in the asset inventory as first-class assets, with an owner and a classification. If your inventory stops at servers and repositories, add the model layer before the next questionnaire arrives.

Block 3: technical controls (questions 12 to 19)

1. How is customer data encrypted in transit and at rest, with algorithms and key lengths? Evidence: a cryptography standard plus a configuration extract.
2. Who holds the encryption keys, and can the customer hold their own? Evidence: a key management description naming the KMS or HSM and the customer-managed key option.
3. How is access to production granted, reviewed and revoked? Evidence: the last quarterly access review and a leaver record.
4. Is multi-factor authentication enforced for all administrative access? Evidence: an identity provider policy screenshot with enforcement scope.
5. How do you segment customer environments from each other? Evidence: a network or tenancy diagram naming the isolation boundary.
6. How are vulnerabilities detected and how fast are they patched, by severity? Evidence: a patch SLA and the last three months of measured performance.
7. Do you produce a software bill of materials for what you ship? Evidence: a build-generated SBOM in CycloneDX or SPDX format.
8. How do you log and monitor access to customer data, and how long are logs retained? Evidence: a logging standard with retention periods and a sample record schema.

Question 18 is where measured numbers beat promises. A patch SLA with no measured performance behind it reads as an aspiration. Three months of actual median and worst-case times, even imperfect ones, reads as a working process.

Block 4: incident handling and reporting (questions 20 to 25)

1. Describe your incident response process and its severity classification. Evidence: the incident response plan with the classification table.
2. Within how many hours will you notify us of an incident affecting our data or service? Evidence: a contractual notification clause, not a policy statement.
3. Can you support our 24 hour early warning and 72 hour notification duties under Article 23? Evidence: a written commitment naming both windows and the contact route.
4. Who is the named contact during an incident, and what is the out-of-hours route? Evidence: a contact card with a monitored channel and an escalation ladder.
5. When did you last test the plan, and what changed afterwards? Evidence: a tabletop exercise report with actions closed.
6. Have you had a reportable incident in the last 24 months, and what did you learn? Evidence: a short factual summary. Silence reads worse than a handled incident.

Questions 21 and 22 are the two that actually block signature. The customer has to file an early warning within 24 hours of becoming aware of a significant incident and a fuller notification within 72 hours. If your contract promises notification without undue delay, you have handed them a gap they cannot explain to a supervisor. Commit to a number, and make it small enough to leave them working time.

Block 5: continuity, data location and exit (questions 26 to 31)

1. What are the recovery time and recovery point objectives for our service? Evidence: RTO and RPO figures in the service description, plus the last restore test result.
2. Where is our data stored and processed, by country and legal entity? Evidence: a data location table covering primary, backup and support access.
3. Can any personnel outside the EU or EEA access our data, and under what controls? Evidence: a support access model with jurisdiction and approval flow.
4. How do we get our data back, in what format, and how long does it take? Evidence: an export specification with formats and a tested timeline.
5. What happens to our data and models if the contract ends or you cease trading? Evidence: an exit plan, plus escrow or a documented self-host path where relevant.
6. How do you demonstrate compliance on an ongoing basis rather than once? Evidence: an audit right in the contract and a cadence for reports and attestations.

The answers that fail

• We are ISO 27001 certified, with no scope statement. A certificate whose scope excludes the product under audit answers nothing.
• We notify without undue delay. Unusable against a 24 hour duty.
• Our cloud provider handles that. Correct for infrastructure, irrelevant for your configuration, your access model and your logs.
• Data stays in the EU, while support engineers connect from outside it. Support access is data access, and auditors now ask directly.
• We can share that under NDA later. Late evidence is treated as absent evidence in a scored assessment.
• A marketing PDF instead of a control document. If it has a hero image, it is not evidence.

Build the pack once

Every one of these 31 questions is answered by one of roughly a dozen documents. Assemble them once, keep them versioned with review dates, and answer future questionnaires by mapping rather than writing. The same pack covers your Cyber Resilience Act documentation, the technical documentation an AI Act review will ask for later, and the DORA register entries your financial customers need. Different regulations, one evidence base.

The vendors that win regulated deals are not the most secure ones. They are the ones whose evidence arrives complete, dated and signed.