Enterprise Software Vendor Due Diligence: 25 Checks Before You Sign

Enterprise software due diligence is not a longer feature comparison. It is the work of proving that a product, supplier and contract can support your operating model without creating an unacceptable security, data, continuity or exit risk.

I have seen polished demonstrations hide the questions that become expensive after signature: Can you export all records and attachments in a usable structure? Which controls cost extra? How does the vendor change APIs? What happens when an embedded AI provider changes? Who restores the service, by when, and against what tested evidence?

A responsible buying process answers those questions before commercial commitment. Use this enterprise software vendor due diligence checklist to turn sales claims into evidence, compare suppliers consistently and record the risks you are actually accepting.

What enterprise software vendor due diligence should achieve

The outcome is not a questionnaire marked complete. It is a defensible decision record containing:

• the business outcomes and critical scenarios the software must support;
• the data, users, systems and jurisdictions the supplier will touch;
• mandatory gates that no weighted score can override;
• evidence for security, privacy, architecture, service and financial claims;
• contract terms aligned with the actual technical service;
• known gaps, compensating controls, owners and review dates;
• a credible path to recover, change supplier or bring the capability in-house.

Do this after establishing whether the capability should be bought at all. My build, buy or extend enterprise software framework covers that earlier decision. If the current estate itself is the problem, use the legacy system modernization roadmap to decide what should be retained, replaced, replatformed or retired.

Start with risk tiering, not a 200-question form

Not every supplier needs the same investigation. A design tool used by five people is different from an ERP, payment platform or customer-data system that can stop fulfilment across several countries.

Before issuing due diligence, document the inherent risk:

1. Business criticality: What stops if the service is unavailable, wrong or withdrawn?
2. Data exposure: Will it hold personal, financial, health, employee, payment, commercial or regulated data?
3. Access: Will it have privileged access, write into systems of record, issue payments or automate decisions?
4. Concentration: Does one vendor, region, cloud or specialist become a single point of failure?
5. Change and exit difficulty: How hard would it be to migrate data, integrations, users and operating knowledge?

Use the answers to define a proportionate evidence set. High-risk software may justify independent assurance reports, architecture review, penetration-test summaries, recovery evidence and contractual audit rights. Lower-risk software can follow a shorter path. The principle is consistent: the depth of scrutiny should follow the consequence of failure, not the confidence of the salesperson.

NIST’s SP 800-161 Rev. 1, updated November 2024 treats cybersecurity supply-chain risk as a lifecycle discipline, while the CISA Secure by Demand guide gives software customers questions for evaluating manufacturers. Both reinforce a practical point: acquisition controls belong before purchase and continue after onboarding.

The 25 checks to complete before you sign

1. Business fit and operating ownership

1. Which measurable business outcomes justify the purchase? Name the process, owner, baseline and decision measure. “Digital transformation” is not an outcome.
2. Which critical scenarios have been proved? Test exceptions, reversals, approvals, cancellations, partial fulfilment, corrections and period-end work—not only the happy path.
3. What is configuration, what requires extension, and what is unavailable? Record every gap and who owns it. A workaround described during a demo is not a committed capability.
4. Who will own the product after go-live? Confirm business ownership, administration, data stewardship, security, integration support, vendor management and renewal accountability.
5. What adoption effort sits outside the licence? Include process design, data preparation, training, internal communications, support and control changes.

2. Architecture, identity and integration

6. What is the real deployment architecture? Obtain a current diagram covering hosting regions, tenancy, data stores, integrations, subprocessors and material fourth parties.
7. How are identity and access controlled? Verify SSO options, MFA, role design, privileged access, joiner-mover-leaver handling, service accounts and auditability. Confirm which controls are included in the proposed tier.
8. How mature are the APIs and events? Ask for versioning policy, authentication, rate limits, pagination, retry behaviour, idempotency, sandbox access, deprecation notice and support boundaries.
9. Which environments are available? Confirm how development, testing, training and production are separated, refreshed and protected. A production-only integration model creates avoidable release risk.
10. Can the complete data model be exported? Test records, relationships, history, audit logs, attachments, configuration and reference data. “CSV export available” is not enough if the export cannot reconstruct the service.

If custom development or integration is material, compare supplier proposals using the checks in how to compare software development quotes. The same warning applies: a low implementation figure can exclude architecture, quality assurance, environments and handover.

3. Secure development and supply-chain evidence

11. How is software security governed? Ask how requirements, threat analysis, code review, dependency management, testing, release approval and remediation operate in the supplier’s development lifecycle.
12. How are vulnerabilities reported and fixed? Verify the disclosure channel, triage process, severity method, customer notification and remediation expectations. Ask for evidence from recent issues without requesting another customer’s confidential information.
13. What independent assurance is relevant? Review scope, period, exceptions and remediation—not just a badge. An assurance report covering corporate IT may not cover the product or hosting service you are buying.
14. What software supply-chain visibility is available? For higher-risk systems, ask how the vendor inventories components, monitors dependencies, protects build pipelines and responds to a compromised library or service. An SBOM may help, but it is evidence input, not proof that the product is secure.
15. Which security capabilities are standard? Confirm secure defaults, MFA, logging, encryption, key handling, session controls, tenant isolation and administrative audit trails, including any licence dependency.

NIST SP 800-218 defines a Secure Software Development Framework and explicitly notes that purchasers can use its common vocabulary when communicating with suppliers. Do not demand a generic “NIST compliant” answer. Select the practices relevant to your risk and ask the supplier to show how they are implemented.

4. Privacy, data location and embedded AI

16. What data enters the service and why? Map fields, files, prompts, logs, metadata, derived data and support access. Remove unnecessary data before debating controls around it.
17. Where is data stored, processed, backed up and supported? Distinguish primary hosting from replication, disaster recovery, telemetry, subprocessors and human support locations.
18. Who are the subprocessors and how can they change? Require a current list, functions, locations, notice mechanism and a practical right to assess material changes.
19. What are the retention and deletion mechanics? Confirm production, logs, caches, backups, exports and support copies. Ask how deletion is evidenced and what remains under legal retention obligations.
20. Does any AI feature use customer data? Identify the model provider, data route, retention, training or improvement use, human review, output ownership, feature controls, auditability and fallback if the model or provider changes.

For Australian organisations covered by the Privacy Act, the OAIC’s updated APP 8 guidance on cross-border disclosure says entities generally need reasonable steps to ensure an overseas recipient handles personal information consistently with the APPs and may remain accountable for that recipient’s conduct. For UK processing, the ICO’s controller-processor contract checklist covers documented instructions, confidentiality, security, subprocessors, assistance, deletion or return and audits. These are jurisdiction-specific obligations; obtain legal advice for the actual countries, roles and data involved.

5. Reliability, support and change control

21. What service level is measured, and how? Define the service boundary, exclusions, measurement source, reporting frequency and remedy. A percentage without a measurement method is marketing.
22. What recovery has been tested? Ask for recovery time and recovery point objectives, architecture, test frequency, latest test evidence, unresolved findings and customer responsibilities.
23. How are incidents communicated? Confirm severity definitions, notification triggers, channels, update cadence, post-incident reporting and named escalation paths.
24. How does the product change? Review release cadence, notice for breaking changes, API deprecation, maintenance windows, customer testing, rollback and control over optional features.
25. What happens at renewal or exit? Confirm notice periods, renewal mechanics, price-change rules, export support, transition assistance, deletion, access duration and the survival of confidentiality, audit and data obligations.

Use hard gates before weighted scoring

A weighted matrix is useful only after disqualifying options that fail mandatory requirements. Otherwise a strong feature score can mathematically compensate for an unacceptable privacy, security or continuity gap.

Typical gates include:

• mandatory legal, regulatory, residency or industry obligations;
• critical workflow and control requirements;
• identity, logging and privileged-access controls;
• minimum integration and data-portability requirements;
• acceptable recovery and incident-management evidence;
• contract rights required to operate and exit responsibly.

Score only the suppliers that pass. A practical scorecard can cover business fit, operating usability, architecture and integration, security and privacy, implementation risk, vendor viability, service and support, lifetime cost and exit feasibility. Publish the scoring definitions before demonstrations begin. Keep “unknown” separate from “does not meet”—an unanswered question is not partial compliance.

Run an evidence-based demonstration

Do not let each vendor control the demonstration. Give every shortlisted supplier the same scenario pack and representative, synthetic data. Ask them to complete end-to-end work while your process owners observe.

A useful demo script includes:

• one normal transaction from initiation to reporting;
• one exception requiring approval and correction;
• one reversal or cancellation with an audit trail;
• one integration failure and retry;
• one role or access change;
• one bulk import and reconciliation;
• one complete export of records and attachments;
• one administrative change promoted safely between environments.

Label every result as standard, configured, customised, partner-delivered, roadmap or unsupported. Require the vendor to confirm that classification in writing. This prevents a future promise from being scored as current product capability.

Ask for evidence, not absolute assurances

Claim	Useful evidence	What to verify
“We are secure”	Relevant assurance scope, security architecture, secure-development and vulnerability processes	Product, hosting, locations, dates, exceptions and remediation
“We are resilient”	Recovery design and recent exercise summary	Test scenario, achieved result, unresolved issues and your responsibilities
“We integrate with anything”	API documentation, sandbox and sample error handling	Coverage, limits, versioning, events, retries and deprecation
“You own your data”	Contract terms and tested full export	Format, relationships, history, attachments, configuration and timing
“AI does not train on your data”	Product-specific data terms and architecture	Prompts, files, logs, feedback, subprocessors, opt-outs and retention

Evidence has a date and a boundary. Record both. A clean report from a previous year or a different product can inform the decision, but it cannot prove today’s proposed service has no risk.

Commercial model: calculate lifetime exposure, not licence price

Compare options over the same planning horizon. Include implementation, environments, integrations, migration, internal roles, security reviews, training, support, storage, transaction or API usage, add-ons, growth, renewal increases and exit work.

Separate committed prices from estimates and variables. Model at least base, growth and adverse cases. If usage-based fees apply, show the units, data source and owner responsible for monitoring them. If a discount depends on a long term, test the cost of reduced flexibility.

Contract review should reconcile the order form, service description, data-processing terms, security schedule, SLA, support policy and online terms. If a document can change unilaterally, understand how notice, objection and termination work. Legal counsel should review material commitments; this checklist is an operating and technology framework, not legal advice.

Red flags that justify a pause

• The vendor refuses to distinguish live capability from roadmap.
• Security answers rely on certification names without scope or evidence.
• Subprocessors, hosting regions or embedded AI providers are unclear.
• Only production access is available for integration testing.
• Data can be exported only through paid professional services or an undocumented process.
• Recovery objectives are contractual, but recovery testing is not evidenced.
• The demo avoids exceptions, audit trails or administrative controls.
• Critical controls appear only after moving to a higher licence tier.
• Implementation assumptions are not written into the statement of work.
• Renewal and exit dates are shorter or more restrictive than the migration lead time.

A red flag does not always mean reject. It means stop treating the item as resolved. Record the exposure, decide whether it can be controlled, assign an owner and reflect the decision in architecture, contract and implementation planning.

The final decision pack

Before approval, produce a concise pack containing the outcome statement, risk tier, mandatory gates, scenario results, evidence register, weighted comparison, architecture and data-flow summary, implementation assumptions, lifetime-cost cases, contract deviations, residual-risk acceptances and exit plan.

Every accepted gap needs a named owner and review date. Every material supplier promise needs a durable home: the contract, order form, statement of work, security schedule or another controlled document. Meeting notes are not a reliable control.

If you want an independent review of an enterprise software shortlist, vendor response, solution architecture or implementation assumptions, book a short discussion with me. I can help structure the evaluation and identify the evidence still needed before a responsible recommendation. Scope, timeline and commercial commitments should follow a review of the actual systems, data, vendors and operating constraints.

Frequently asked questions

What is enterprise software vendor due diligence?

It is a structured assessment of whether a software product, supplier and contract can meet business requirements while keeping security, privacy, continuity, integration, cost and exit risks within acceptable limits. It should produce evidence and a decision record, not only a completed questionnaire.

When should vendor due diligence start?

Start after defining the business outcome and inherent risk, but before selecting a preferred supplier or accepting binding terms. Critical security, data, integration and exit requirements should shape the request, demonstration and contract—not be reviewed after signature.

Is SOC 2 or ISO 27001 enough to approve a vendor?

No. Independent assurance can be useful evidence, but you still need to check scope, period, exceptions and relevance to the product and service being bought. You must also assess business fit, architecture, data handling, resilience, implementation and exit.

How should an AI-enabled software vendor be assessed?

Identify the model and provider, data flows, retention, training use, subprocessors, human review, output controls, auditability, feature controls and fallback behaviour. Assess the AI feature within the wider software supply chain rather than treating it as a harmless add-on.

How often should enterprise software vendors be reassessed?

Use a cadence proportionate to risk and trigger a review when data access, integrations, ownership, hosting, subprocessors, AI models, criticality, security events or contract terms materially change. Due diligence should continue through renewal and exit.

Primary references

• NIST SP 800-161 Rev. 1 (November 2024 update) — Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-218 — Secure Software Development Framework
• CISA — Secure by Demand Guide
• CISA — Secure by Design
• OAIC — APP 8 Cross-border Disclosure Guidance
• UK ICO — Contracts Between Controllers and Processors