A software vendor due diligence checklist should answer a harder question than whether the product works in a demonstration: can the buyer depend on this supplier, product, and supply chain for the intended business impact, and can it recover if that dependency fails? The review therefore spans corporate identity, product provenance, secure development, fourth parties, financial and operational resilience, customer access, data handling, contractual rights, and practical exit.
Evidence should be proportional to criticality. A design plug-in with public data does not warrant the same investigation as privileged software controlling payments or production. Classify the service first, request evidence second, test high-impact claims third, and convert unresolved risk into a decision, condition, compensating control, or rejection. A long questionnaire without a decision rule creates paperwork rather than assurance.
Scope due diligence by service criticality
Document the business processes, data classes, identities, networks, administrative privileges, jurisdictions, and downstream customers affected by the software. Estimate plausible impact from unavailability, corruption, confidentiality loss, compromised updates, abrupt supplier failure, and inability to export. Include concentration: a replaceable tool may become critical when the same provider also supplies identity, observability, and backups.
NIST's final SP 1326, published July 8, 2026, frames ICT supplier due diligence around foreign ownership, control, or influence; provenance; resilience; foundational cyber practices; and supply-chain tiers. Those components are an excellent investigation backbone, but a buyer still needs product-specific legal, privacy, operational, financial, accessibility, and exit analysis.
| Risk tier | Typical dependency | Minimum evidence | Additional validation |
|---|---|---|---|
| Low | Non-sensitive, easily replaced utility | Entity, terms, support period, data handling | Basic security review and deletion test |
| Moderate | Team workflow with internal data | Control reports, incident process, subprocessors, export | Reference checks and recovery evidence |
| High | Customer-facing or privileged system | Architecture, secure development, continuity, access, supply chain | Technical workshop, contract controls, scenario exercise |
| Critical | Safety, finance, identity, or core operations | All high-tier evidence plus viability and exit plan | Independent assurance, tested export, emergency transition rehearsal |
Verify supplier identity, ownership, and decision control
Confirm the legal contracting entity, parent relationships, operating locations, beneficial ownership where lawful and relevant, sanctions exposure, material litigation disclosures, insurance, and authority to license the product. Determine which entity employs developers, hosts the service, processes support data, signs subprocessors, and controls release signing. A familiar brand is not evidence that the contracting subsidiary owns the promised assets or can compel another group company to help during an incident.
Assess financial resilience in context rather than reducing it to one score. Review audited statements where available, funding dependence, customer concentration, recurring revenue quality, debt obligations, insurance limits, and the cost of supporting the product through the intended term. Ask how acquisition, restructuring, loss of a key cloud agreement, or a major customer departure would change service. Record leading indicators and a refresh cadence. The latest Sourcing Playbook treats economic and financial standing and resolution planning as lifecycle concerns, not one-time bid checks.
Trace product provenance and the software supply chain
Request a current architecture and build narrative: source control boundaries, code review, CI/CD trust, artifact signing, release approvals, dependency selection, vulnerability handling, and supported branches. Ask for a software bill of materials in a usable standard where the risk justifies it, but do not mistake an SBOM for assurance. The buyer needs a process to identify relevant components, correlate advisories, evaluate exploitability, receive remediation commitments, and learn when a dependency or build system changes.
Map material fourth parties, including cloud hosting, identity, payment, messaging, telemetry, support, code repositories, and offshore development partners. Determine what data and privilege each receives, where it operates, whether substitution requires notice, and whether the prime supplier's controls flow down. NIST SP 800-161 Rev. 1 emphasizes integrating cybersecurity supply-chain risk into enterprise risk management and assessments across organizational levels. A contract list is useful only when the buyer can see which dependency supports which critical service.
Test security, incident, and resilience claims
Collect assurance artifacts that match the deployed service: certification scope, independent reports, penetration-test summary and remediation status, secure-development policy, vulnerability disclosure route, encryption and key ownership, tenant isolation, privileged-access controls, logging, personnel screening where appropriate, backup design, and recovery tests. Check dates, scope exclusions, exceptions, management responses, and whether the exact product and hosting region are covered.
Run a focused evidence workshop instead of accepting generic policy packs. Trace one administrator access request from approval through revocation, one production release from source to signed artifact, one severe vulnerability from intake to customer notice, and one restoration test from backup to verified business record. The UK's NCSC supply-chain assessment guidance recommends an approach based on organizational priorities and collaboration with suppliers; practical trace tests reveal whether declared controls operate across the actual relationship.
| Vendor claim | Weak evidence | Stronger evidence | Buyer decision |
|---|---|---|---|
| Backups are tested | Policy statement | Recent restore record with scope, result, and defect closure | Confirm recovery meets business tolerance |
| Development is secure | Certification badge | Scoped assurance plus release and vulnerability trace | Accept, condition, or require control |
| Data is portable | CSV export button | Schema, metadata, attachments, identities, and timed test export | Measure usable migration effort |
| Access is removed | Termination clause | Inventory of accounts, tokens, keys, and revocation evidence | Define exit acceptance |
| Supply chain is managed | Subprocessor URL | Service-to-dependency map and change-notice process | Evaluate concentration and substitution |
Assess product continuity, supportability, and key-person risk
Identify who can operate, repair, and securely build the product if key people leave. Review support coverage, severity definitions, escalation authority, engineering access, language and time-zone constraints, release cadence, end-of-life policy, and customer communication. For bespoke software, verify repository ownership, reproducible build instructions, deployment automation, environment definitions, test assets, architectural decisions, and dependency rights. Source-code escrow may help only if deposits are current, complete, legally releasable, buildable, and usable by a capable replacement team.
Examine resilience at both supplier and service levels. A vendor can survive financially while a product is neglected; a service can be technically redundant while support depends on one specialist. Ask for product roadmap governance, succession, alternate contacts, disaster-recovery assumptions, and maximum tolerable outage alignment. Where evidence is unavailable, reduce privilege, limit data, shorten the term, add an alternate process, or select a less risky dependency.
Prove data, access, tooling, and exit readiness
Define everything needed to leave before purchase: data plus metadata and audit history, format and schema documentation, export frequency and cost, attachments, configuration, identities, encryption keys, domains, certificates, integrations, automation, runbooks, ticket history, and deletion evidence. Separate customer-owned assets from supplier background intellectual property and third-party licenses. Confirm whether contracts, reserved capacity, and specialist staff can transfer or require replacement.
Perform a test export with representative scale and reconstruct a meaningful workflow outside the product. Count manual transformations, missing relationships, unverifiable records, throttling, and supplier assistance. Test revocation by listing all human and machine access, not merely disabling a named user. The NCSC's supply-chain security guidance specifically calls for contract terms covering return and deletion of information and assets on termination or transfer. Evidence of a usable exit is more valuable than a broad promise of portability.
Turn findings into conditions and continuous monitoring
Use a decision record containing risk statement, affected service, evidence, likelihood and impact rationale, control owner, due date, residual risk, approver, and review trigger. Outcomes should be explicit: approve, approve with conditions, pilot in a constrained boundary, require remediation before production, select an alternative, or reject. Contract schedules should convert material conditions into notification, evidence, audit, remediation, assistance, or termination rights that can actually be administered.
Refresh on a risk-based calendar and on events such as acquisition, material subprocessor change, new hosting region, severe incident, certification expiry, product end-of-life notice, declining support, financial distress, or a major architecture revision. Monitor service evidence and external signals, but give the supplier a route to explain and correct. Due diligence is not a prediction that failure will never happen; it is a disciplined basis for choosing dependencies, limiting exposure, and preserving recovery options.
Software vendor due diligence takeaways
- Classify business, data, privilege, and concentration impact before requesting evidence.
- Verify the contracting entity and who controls development, hosting, support, and release signing.
- Trace material components and fourth parties to the services they can disrupt.
- Test representative controls and restoration rather than relying on policy statements.
- Treat source escrow as one conditional continuity mechanism, not an automatic solution.
- Demonstrate usable export, access revocation, knowledge transfer, and deletion before dependence deepens.
- Record residual risk and refresh diligence when the supplier or product changes.
Software vendor due diligence FAQ
Is a security certification enough due diligence?
No. Certification can provide valuable scoped assurance, but buyers must check the covered entity, product, locations, exclusions, exceptions, and date. It does not replace product fit, architecture, resilience, financial, privacy, contractual, or exit analysis.
Should every buyer request an SBOM?
Request and operationalize one when component transparency affects the risk decision. For low-risk tools, the handling cost may exceed the benefit. For critical software, define format, freshness, delivery, confidentiality, and how relevant vulnerabilities will be communicated.
How often should due diligence be repeated?
Set a cadence by criticality and add event-driven reviews. Critical dependencies may need annual deep review plus continuous signals; lower-risk tools may need renewal review. Acquisition, incidents, architecture changes, and end-of-life notices should trigger reassessment.
Conclusion
Good software vendor due diligence connects evidence to a specific dependency and decision. Investigate who controls the service, how software and suppliers enter it, whether controls operate, how failure is contained, and whether the buyer can leave with usable data and knowledge. That approach does not eliminate supplier risk; it makes the risk visible enough to accept, reduce, transfer, or avoid deliberately.