Enterprise Vendor Due Diligence Checklist for Software and AI

Introduction

Procurement wants speed. Security wants certainty. Legal wants clean terms. Engineering wants to ship.

Vendor due diligence is where those goals collide. Especially with software and AI vendors, where the biggest risks are rarely the ones in the sales deck. They live in identity flows, audit gaps, subcontractors, and what happens at 2 a.m. when something breaks.

This guide is a practical, enterprise-grade vendor due diligence checklist you can run in regulated environments like finance, healthcare, and defense. It is written for the consulting engineering leader who needs to align stakeholders, move fast, and still be able to defend the decision in an audit.

Insight: The goal is not to eliminate risk. The goal is to make risk explicit, assign owners, and price it into the relationship.

You will get:

• A software vendor due diligence checklist you can reuse
• An AI vendor security questionnaire mapping approach that keeps answers comparable
• ISO and SOC 2 reality checks with specific evidence requests
• GDPR vendor assessment essentials, including DPA terms that matter
• Incident response expectations and SLA language that does not fall apart under pressure

When this checklist matters most

Use this when any of the following are true:

• The vendor will touch regulated data (PII, PHI, card data)
• The vendor will be embedded in production workflows (auth, payments, clinical operations)
• The vendor is an AI provider or uses subprocessors for model hosting
• You need procurement, security, and legal to sign off within weeks, not quarters

In our delivery work, the fastest programs are the ones where due diligence runs like engineering. Clear scope. Evidence over statements. Short feedback loops. When we built a virtual event platform at ExpoDubai scale, the technical work was only half the risk story. The other half was operational readiness: access, logs, incident playbooks, and who answers when something goes wrong.

Scope the assessment fast

Most vendor reviews fail before the first questionnaire. The scope is fuzzy, so every stakeholder assumes worst case.

Start with a one page intake. Then pick the depth of review based on data and blast radius.

Common failure modes

• You assess the vendor, but not their subprocessors
• You ask 300 questions, then never validate the answers
• You treat ISO or SOC 2 as a pass, not a starting point
• You skip operational checks like backups and restore tests

Key Stat: A large share of enterprise security findings are operational, not cryptographic. If you do not ask about logging, access reviews, and incident drills, you will miss the issues that actually hurt.

Triage framework

Use a simple risk tiering model. It keeps procurement moving and makes security reviews defendable.

What to capture in intake

• Data types: PII, PHI, payment, credentials, model prompts
• Data flow: where data enters, where it is stored, where it leaves
• Hosting: cloud region, single tenant vs multi tenant
• Integration: SSO, SCIM, API keys, network paths
• Subprocessors: list, purpose, and data touched
• Go live timeline and rollback plan

AI specific scoping questions

AI changes the scope in subtle ways. Ask these early so you do not redo the review later.

• Are prompts and outputs stored? For how long?
• Is customer data used for training or fine tuning?
• Which model providers are involved (first party vs third party APIs)?
• What is the retrieval layer (vector database), and what is indexed?
• Can you enforce tenant isolation for embeddings and prompt logs?

If the vendor cannot answer these clearly, treat them as Tier 3 until proven otherwise.

Security questionnaire mapping

Questionnaires are necessary. They are also noisy. The trick is mapping.

Instead of accepting a vendor specific PDF, map their answers to your control framework so you can compare vendors and track gaps over time.

Map to controls, not questions

Pick a control baseline that matches your org. Common options:

• ISO 27001 Annex A
• SOC 2 Trust Services Criteria
• NIST 800 53 or NIST CSF
• CIS Controls

Then build a crosswalk so each vendor answer lands in a control bucket.

Insight: A good mapping turns a 200 question document into a 20 control conversation with clear owners.

What to ask and what good answers look like

Below is a practical set of prompts you can reuse for a software vendor due diligence checklist and an AI vendor security questionnaire.

1. Identity and access

   • Ask: Do you support SSO (SAML or OIDC)? Do you support SCIM? Can we enforce MFA for all accounts?
   • Good answer: SSO supported, SCIM supported, MFA enforced, break glass accounts controlled, admin actions logged.

2. Encryption and key management

   • Ask: Encryption at rest and in transit? Who manages keys? Any customer managed keys?
   • Good answer: TLS 1.2+ in transit, strong at rest encryption, clear KMS ownership, documented rotation.

3. Logging and monitoring

   • Ask: What security logs exist? Can customers export them? Log retention?
   • Good answer: Admin and auth logs available, export via API, retention configurable, tamper resistance.

4. Vulnerability management

   • Ask: Patch SLAs? Dependency scanning? How do you handle critical CVEs?
   • Good answer: Defined SLAs by severity, scanning in CI, emergency patch process, evidence of recent fixes.

5. AI data handling

   • Ask: Are prompts, outputs, and embeddings treated as customer data? Is training opt in?
   • Good answer: Training is opt in, retention is limited, deletion supported, clear subprocessors.

Red flags you can act on

• “We are working on SOC 2” with no timeline or scope
• “We encrypt everything” with no cipher details, no key ownership clarity
• No incident response runbooks, only a generic policy
• No way to export logs, or logs are “available upon request”
• Subprocessors list is incomplete or kept private

How we keep reviews comparable

In delivery work, we often see teams collect questionnaires that nobody can compare. A simple normalization helps:

• Store answers in a structured format (spreadsheet or ticketed controls)
• Require every answer to include an artifact link
• Track gaps as backlog items with owners and due dates

If you do only one thing, do this: map every answer to a control, and require evidence for every Tier 3 control.

ISO and SOC 2 reality checks

ISO certificates and SOC 2 reports are useful. They are not proof that your specific risks are covered.

Treat them as entry points. Then request targeted evidence.

SOC 2: what to request

• SOC 2 Type II report, not Type I
• Report period that includes the last 6 to 12 months
• System description and boundaries (what is in scope)
• Complementary user entity controls (what you must do)
• Bridge letter if the report is old

Good sign: the vendor can explain scope limitations without getting defensive.

Bad sign: they refuse to share anything beyond a marketing one pager.

Insight: The fastest way to de risk a SOC 2 review is to read the scope first. Many teams skip it and argue over controls that were never audited.

ISO 27001: what to validate

• Certificate issuer and validity dates
• Statement of Applicability (SoA)
• Which sites and systems are covered
• How they handle exceptions and risk acceptance

Evidence artifacts list

Ask for artifacts that match the controls you care about. Sample list:

• Security policies: access control, encryption, secure SDLC, vendor management
• Operational evidence: access review records, change management tickets, backup and restore test logs
• Technical evidence: vulnerability scans, pen test report and remediation proof, WAF or firewall configs
• Audit evidence: SOC 2 report, ISO certificate, internal audit schedule
• AI evidence: retention settings for prompts, training opt in docs, model and subprocessor list

Pen tests: what counts as useful

A pen test PDF is not automatically evidence.

Ask:

• Was it done by an independent firm?
• What was in scope (API, mobile, infra, social engineering)?
• Were findings fixed, and can they show retest results?
• Do they run ongoing scanning between annual tests?

Good answer: they provide an executive summary plus remediation tracking.

Weak answer: they provide a generic letter with no scope or findings.

GDPR and DPA essentials

A GDPR vendor assessment is not about memorizing articles. It is about ensuring the vendor can operate as a processor without creating legal and operational chaos.

DPA terms that matter

Focus on terms that change your risk profile:

• Roles and instructions: processor acts only on documented instructions
• Subprocessors: list, notice period, and objection rights
• International transfers: SCCs and transfer impact approach
• Security measures: concrete measures, not “industry standard”
• Deletion and return: timelines, formats, and verification
• Audit rights: practical audit mechanism, not unlimited onsite access

Key Stat: If you cannot name the subprocessors and data regions, you cannot credibly answer “where does our data go?” in an audit.

Sample MSA and DPA clauses to request

These are examples to discuss with legal. They are written to be specific and testable.

What “good” looks like in practice

• DPA references a real technical architecture, not a template
• Subprocessor list is public and updated
• Data residency is explicit
• Deletion is actually tested, and they can show how

What fails in practice

• The vendor offers a DPA but cannot explain retention or deletion
• They rely on “legitimate interest” language where consent or contract is required
• They cannot support data subject requests within your timelines

If you are in healthcare or payment flows, map GDPR terms to HIPAA BAAs or PCI DSS responsibilities. Different regimes, same pattern: clear roles, clear evidence, and no hidden data flows.

GDPR meets AI

AI vendors often treat prompts as logs. That is where risk hides.

Ask directly:

• Are prompts and outputs considered personal data in your system?
• Can we disable storage of prompts and outputs?
• Can we delete by user, tenant, and time range?
• Do you use our data to improve models? Is it opt in?

If they cannot offer clear retention controls, assume your data will be retained longer than you want.

Incident response expectations and SLAs

Most contracts talk about uptime. Few talk about response quality.

That is a problem. In regulated industries, the question is not “will an incident happen?” It is “how fast will we know, and what will we get?”

Incident response checklist

Request the vendor’s incident response plan. Then validate it with specific questions.

• How do you classify severity (SEV1 to SEV4)?
• Who is on call, and what is the escalation path?
• Do you run incident drills? How often?
• Do you have a post incident review template?
• Can you share redacted examples of prior incident reports?

Example: In large scale platforms like virtual events, the difference between a rough launch and a controlled launch is often observability and escalation clarity, not just infrastructure size.

SLA and SLO terms that hold up

Use measurable commitments. Avoid vague language like “commercially reasonable.”

Minimal incident clause set

• Notification timeline (24 hours after confirmation is common for serious events)
• Update cadence and communication channels
• Root cause analysis delivery timeline (for example, 5 to 10 business days)
• Cooperation obligations (logs, forensics, customer notifications)

What to measure after go live

Due diligence is not a one time event. Set a small set of operational metrics.

• Mean time to acknowledge support tickets
• Mean time to resolve SEV1 and SEV2
• Patch latency for critical CVEs
• Access review completion rate
• Backup restore test pass rate

If you lack baseline data, treat these as hypotheses and measure them in the first 90 days.

Conclusion

Vendor due diligence is engineering work with legal consequences. If you keep it evidence based, you can move fast without gambling.

Here is a simple way to run it:

1. Scope the vendor by data and blast radius.
2. Map the questionnaire to controls.
3. Validate ISO and SOC 2 with targeted evidence.
4. Lock down GDPR and DPA terms that change your risk.
5. Put incident response and SLAs in writing.
6. Measure performance after go live.

Insight: The best outcome is not a perfect vendor. It is a contract and operating model that makes problems visible early.

Actionable next steps you can do this week:

• Create a Tier 1 to 3 intake form and require it for every purchase
• Add an evidence column to your AI vendor security questionnaire
• Standardize your DPA clause requests for subprocessors, retention, and incident notice
• Ask every vendor for one redacted incident report and one restore test record

If you do those four, your next audit conversation gets easier. Your next incident gets smaller.