Ask more where the dependency matters more
A supplier can improve security and resilience, but it also becomes part of the organisation’s attack surface and recovery path. Scale due diligence to what the supplier can access, change, expose or stop—not simply to the size or reputation of the provider.
Classify the supplier by criticality, data sensitivity, privilege, connectivity and ease of replacement. Set non-negotiable requirements, request current evidence in scope, place material commitments in the contract and keep an exit route that has been tested before a crisis.
Tier the dependency before sending questions
Lower dependency
No privileged connection, limited non-sensitive information, easy replacement and little effect on critical operations.
Material dependency
Business or personal data, workflow integration, meaningful outage impact or access that could affect other systems.
Critical dependency
Privileged access, highly sensitive information, safety or rights impact, essential service reliance or a difficult and lengthy exit.
Supplier security questions that change a decision
- Which customer data, credentials, systems and locations can the supplier and its subprocessors access?
- How are customer and supplier administrators authenticated, authorised, monitored and removed?
- Which secure-development, vulnerability, patching and disclosure processes apply to the product?
- What is logged, which security events are detected and how can the customer obtain relevant evidence?
- How and when will the supplier notify the customer of an incident, outage, material vulnerability or subprocessor change?
- Which recovery objectives, backup arrangements, dependencies and recent test results apply to the service?
- Where is data processed, how is it encrypted and what deletion or return evidence is available?
- Which service, security, insurance, liability, audit and cooperation commitments appear in the contract?
- How can data, configuration, logs and knowledge be exported in a usable form?
- What happens to access, data and service continuity at termination, provider failure or ownership change?
Use an evidence hierarchy
| Evidence | What it can support | What still needs checking |
|---|---|---|
| Contract and service commitments | Enforceable obligations for security, incidents, recovery, data, cooperation and exit | Definitions, exclusions, remedies, precedence and whether commitments cover the service bought |
| Independent certification or assurance report | Assessment against defined criteria during a stated period | Scope, exceptions, current validity, relevant locations, subprocessors and customer responsibilities |
| Penetration-test or security-assessment summary | Evidence that particular systems and dates were tested | Coverage, independence, severity, retest, unresolved findings and production relevance |
| Architecture, data-flow and recovery evidence | How identity, data, access, separation and restoration are intended to work | Whether implementation and operating evidence match the document |
| Questionnaire or sales statement | A route to clarification and accountable follow-up | Supporting evidence, contractual status and answers that are vague, qualified or out of scope |
A certification, large customer list or security webpage is not proof that every configuration, subprocessor and customer use is secure. Record which risks remain with the customer.
Monitor change and prepare exit
- Review triggers: Incident, material vulnerability, acquisition, financial concern, new subprocessor, data-location change, major feature or integration.
- Operating evidence: Access reviews, security notices, availability, restore exercises, service reports, unresolved findings and customer actions.
- Exit test: Export representative data and configuration, remove integration access and confirm the alternative can support the critical workflow.
- Concentration: Identify several suppliers that rely on the same identity, cloud, network or software dependency.
Current supply-chain sources
NIST SP 1326, finalised on 8 July 2026, provides a due-diligence assessment starting point for ICT suppliers. NIST SP 1305 explains how CSF 2.0 can support supplier requirements and supply-chain risk management. The NCSC supply-chain principles organise work around understanding risk, establishing control, checking arrangements and continuous improvement.
Supplier security due diligence FAQs
How many security questions should I ask a supplier?
Ask the smallest set that can change the decision or contract, scaled to criticality, access, data and substitutability. A long generic questionnaire can hide unanswered high-consequence questions.
Does a security certification make a supplier safe?
No. It can provide useful evidence within a stated scope and period. Check the service, systems, locations, exceptions and customer responsibilities covered, then assess risks that sit outside that evidence.
Should small suppliers be rejected automatically?
No. Size alone does not determine risk. A smaller supplier may provide strong evidence and responsive control, while a large provider may offer little contractual flexibility. Assess the dependency and actual safeguards.
Continue your cybersecurity decision
Use the next guide that matches the exposure, control or recovery question you still need to resolve.
