NIS2 supplier assurance is not achieved by collecting signed security questionnaires. An organisation needs to show that it understands the dependencies supporting important services, varies requirements according to risk, makes them enforceable and can respond when an incident starts outside its own network. The central artefact is therefore not a vendor score. It is a functioning decision system: who may accept risk, which signals change the assessment and how response is initiated.
The NIS2 Directive requires cybersecurity risk-management measures to address supply-chain security, including relationships between an entity and its direct suppliers or service providers. It is also a directive implemented through national law. Before designing controls, establish the relevant jurisdiction, entity scope, sector, size criteria and the role of each company in the group. A reference to the EU text does not replace analysis of national implementing law or the competent authority's requirements.
Scope the service before assessing the supplier
An accounts-payable vendor list is not a dependency map. Start with business and technical services, then identify third parties able to affect their availability, confidentiality, integrity or authenticity. This includes cloud and network providers, but also identity services, source repositories, update channels, support centres, payment processors, DNS, cryptographic key services and contractors with privileged access.
Record, for each dependency, the service it supports, data and privileges involved, processing region, relevant subcontractors, substitutability, expected recovery time and accountable business owner. Contract value is a poor proxy for criticality. A small component distributed automatically across every endpoint can create more exposure than an expensive auxiliary system.
The map also needs a concentration view. Several products may rely on the same operator, software library, identity provider or distribution channel while appearing independent in procurement records. Risk owners need to see shared failure points and the practical ability to exit, not merely a collection of contracts.
Tier risk by access and impact
Sending the same questionnaire to every supplier produces paperwork rather than control. Assign a risk tier using observable properties first: production access, data type, ability to introduce code or updates, dependency of a critical service, substitutability and concentration. Then choose the depth of due diligence.
For a low-risk supplier, evidence of basic practices and a named contact may be enough. A higher tier calls for evidence about vulnerability management, secure development, access control, resilience, backups, subcontractors and incident response. Certification can contribute evidence, but it does not automatically establish that its scope covers the service being purchased, the current processing location and every material dependency.
An assessment must end in a decision: approve; require a remediation plan with an owner and deadline; reduce access; apply a compensating control on the buyer's side; or decline the service. A supplier's failure to answer is itself risk information and should not remain hidden indefinitely behind an “in progress” status.
Turn requirements into enforceable obligations
The contract should support response, not repeat generic security promises. For a critical service, it should address incident and vulnerability notification, availability of contacts, the information delivered in successive updates, preservation and sharing of evidence, subcontractor change, continuity, and return or deletion of data at exit.
Contractual notification windows should be derived from the customer's own obligations. Article 23 of NIS2 establishes staged reporting for significant incidents: an early warning without undue delay and, where applicable, within 24 hours of becoming aware; an incident notification within 72 hours; and generally a final report within one month. Whether those duties apply depends on incident qualification and national law. The supplier therefore needs to provide useful initial facts early enough for the customer to make its own assessment. Merely copying “72 hours” into the contract may leave the customer no time to act.
Audit rights should be proportionate and usable. Not every organisation will conduct an on-site inspection, but it may need current assurance reports, test results, certification scope, evidence that a critical weakness was fixed and confirmation of agreed remediation. The agreement should state what happens when corrective action is not completed.
Maintain a continuous evidence flow
An onboarding assessment becomes stale when service ownership, architecture, subcontractors or threats change. Define a reassessment cycle for higher-risk providers and events that trigger review: a material incident, a change in data location, an acquisition, new privileged access, changed service terms, an expiring certificate or repeated failure against an agreed service level.
Evidence needs an owner, validity date and connection to a specific control. A PDF stored in a repository does not show whether a gap was found or who accepted it. The exception register should record the risk, compensating control, approver and expiry date. At expiry, the exception returns for decision rather than silently becoming permanent.
Automated signals—such as SSO integration status, active service accounts or the date of the last recovery test—can make the picture more current. They do not replace a discussion about architectural change or a business impact assessment.
Rehearse an incident that starts at a supplier
The response plan needs a scenario in which the organisation does not control the source system and receives incomplete information. An exercise should test who contacts the provider, who assesses impact, how credentials and integrations are isolated, who starts the alternative process, and who decides on regulatory and customer communications.
Agree the first information set in advance: detection time, suspected start time, affected services and data, indicators of compromise, containment actions, time of the next update and the person able to make decisions. Do not wait for a complete root-cause analysis before protecting your own environment.
After an exercise or real event, update the dependency map, supplier assessment, contractual terms and technical safeguards. If the lessons remain only in the security team's report, supplier management has not closed the control loop.
Give leadership decisions, not questionnaire counts
Leadership needs to see whether critical services have mapped dependencies, unresolved risks above tolerance, expiring evidence, concentration without a tested exit option, overdue remediation and the outcome of exercises. “Percentage of suppliers assessed” can be a supporting measure, but without criticality it rewards easy, low-value reviews.
Accountability must be explicit. Procurement enforces entry to the process and commercial terms; security owns assessment methods and control expectations; the service owner accepts business risk; legal tests enforceability; and continuity teams validate workarounds and exit. The management body should approve risk tolerance and receive exceptions that cannot be resolved operationally.
Maturity does not mean owning more forms. It means being able to identify affected services quickly, make a controlled decision and present a coherent evidence trail from risk identification through response.
Sources
Cybersecurity
DORA in Practice: Operational Resilience Beyond Checkbox Compliance
DORA is not a policy-production project. It requires a financial entity to demonstrate how it protects critical or important functions, responds to...
Cybersecurity
Third-Party Cyber Risk Playbook After DBIR 2025
A supplier questionnaire is not a security control. At most, it records what a provider was willing and able to declare on a particular day. A third-party...