---
title: "Software Vendor Due Diligence Checklist (2026): 25 Checks Before You Sign"
description: "A practical 2026 software vendor due diligence checklist covering delivery evidence, security, IP ownership, commercial terms, data handling and exit risk before you sign."
url: https://www.brandligo.com/blog/software-vendor-due-diligence-checklist-2026/
date: 2026-09-11
modified: 2026-09-12
author: "Junaid Abro"
image: https://www.brandligo.com/blog/wp-content/uploads/2026/09/software-vendor-due-diligence-checklist-2026.webp
categories: ["B2B Buying & Procurement Guides"]
type: post
lang: en
---

# Software Vendor Due Diligence Checklist (2026): 25 Checks Before You Sign

Software vendor due diligence should answer one question before a contract is signed: **what evidence shows this supplier can deliver, protect, support and eventually hand over what you are buying?**

A polished demo, a familiar logo or a low hourly rate is not enough. In 2026, buyers also need to test delivery risk, security practices, ownership, continuity, data handling and exit terms. NIST’s finalized 2026 C-SCRM Due Diligence Assessment Quick-Start Guide reinforces this evidence-based approach to supplier research, while the NIST Secure Software Development Framework gives buyers and software producers a common language for discussing secure development practices.

This checklist is designed for businesses evaluating a custom software development company, implementation partner, SaaS supplier or technology vendor. It complements Brandligo’s [software development company selection guide](https://www.brandligo.com/blog/choose-software-development-company/) and [software development company comparison](https://www.brandligo.com/blog/2024-top-software-development-companies/).

## Software vendor due diligence checklist at a glance

| Area | What to verify | Evidence to request |
| --- | --- | --- |
| Company legitimacy | Legal entity, ownership, operating history, delivery locations | Registration details, contractual entity, office and team information |
| Delivery capability | Relevant work, assigned team, engineering process, QA | Named team, sample artifacts, references, delivery plan |
| Security | Secure development, access controls, vulnerability handling | Policies, certifications where relevant, testing evidence, incident process |
| Commercial terms | Pricing, change control, payment triggers, hidden dependencies | Rate card, statement of work, assumptions, change-order rules |
| Ownership | Source code, data, IP, repositories, cloud accounts | Contract clauses and client-controlled access |
| Exit readiness | Transition support, exports, documentation, lock-in | Termination clause, handover plan, export format, transition obligations |

## 1. Verify the company before evaluating the proposal

### 1. Confirm the contracting legal entity

Make sure the company name on the proposal matches the legal entity that will sign the agreement and receive payment. If the sales brand, development company and billing entity are different, ask why and document the relationship.

### 2. Confirm where the work will actually be delivered

A local sales office does not necessarily mean a local engineering team. Ask where developers, project managers, QA staff and support teams are located, which time zones they work in and whether subcontractors will participate.

### 3. Check ownership and material business changes

Recent acquisitions, major restructures or dependence on a parent company can affect delivery continuity. The goal is not to reject change; it is to understand who controls the supplier and which entity is responsible if something goes wrong.

### 4. Validate references that match your project type

Do not ask only for famous client logos. Request references for projects similar in complexity, technology, regulatory exposure or operating model. Ask those references what happened after launch, not just whether the initial project was completed.

## 2. Test whether the vendor can deliver your project

![Software team reviewing an app development project during a vendor evaluation meeting](https://www.brandligo.com/blog/wp-content/uploads/2026/09/software-vendor-delivery-team-review.jpg)*Vendor delivery-team review. Photo: Mapbox/Unsplash.*

### 5. Ask for the named delivery team

Evaluate the people expected to do the work, not only senior staff presented during sales calls. Confirm roles, seniority, availability and how substitutions are handled.

### 6. Review a realistic delivery plan

The plan should identify discovery, architecture, implementation, testing, deployment and support rather than presenting one unexplained deadline. Look for assumptions and dependencies that could move the schedule.

### 7. Ask how scope changes are controlled

Most software projects change. A mature vendor should explain who approves changes, how schedule and budget impacts are estimated, and how decisions are recorded.

### 8. Examine quality assurance practices

Ask what is tested automatically, what requires manual QA, how defects are triaged, and what acceptance criteria determine whether a milestone is complete.

### 9. Request evidence of similar technical work

A portfolio screenshot is weak evidence. Better evidence includes architecture explanations, deployment patterns, integration experience, migration approaches or anonymized delivery artifacts that demonstrate the vendor has solved comparable problems.

## 3. Review security and software-supply-chain risk

![Developer reviewing code on a computer during a software security assessment](https://www.brandligo.com/blog/wp-content/uploads/2026/09/software-vendor-security-review-scaled.jpg)*Software security review. Photo: Julio Lopez/Unsplash.*

NIST’s [July 8, 2026 supplier due-diligence guidance](https://www.nist.gov/news-events/news/2026/07/nist-releases-finalized-c-scrm-due-diligence-assessment-quick-start-guide) describes due diligence as reasonable research and investigative rigor before procurement decisions. For software, security evidence should scale with the risk of the system being purchased.

### 10. Ask how secure development is built into the lifecycle

Use the [NIST Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) as a reference point. You do not need a vendor to use NIST terminology, but they should be able to explain how they prevent, detect and respond to software vulnerabilities.

### 11. Verify access-control practices

Ask how developers receive access to source code, production systems, secrets, customer data and cloud environments. Confirm whether multi-factor authentication, least-privilege access and offboarding controls are used.

### 12. Review dependency and third-party software management

Modern applications rely heavily on open-source packages and external services. Ask how dependencies are selected, updated and monitored and who is responsible when a critical vulnerability affects one of them.

### 13. Understand vulnerability reporting and remediation

Confirm how security issues are reported, prioritized and fixed. For higher-risk systems, ask whether the vendor can provide relevant security testing evidence, vulnerability disclosure information or software supply-chain artifacts.

### 14. Check incident-notification obligations

The contract should define when the supplier must notify you about a security incident affecting your systems or data, what information they must provide and who coordinates remediation.

CISA’s guidance on [choosing secure and verifiable technologies](https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies) is also useful for buyers that need a more security-focused procurement review.

## 4. Make data, IP and infrastructure ownership explicit

### 15. Define who owns newly created intellectual property

Do not assume payment automatically gives you every right you expect. The agreement should distinguish client-owned work, vendor pre-existing IP, third-party components and reusable frameworks.

### 16. Keep source code in a controlled repository

For custom software, decide who owns the GitHub, GitLab or other repository and when the buyer receives administrative access. Waiting until the final invoice to discover that the vendor controls the only current copy creates avoidable risk.

### 17. Keep critical cloud and platform accounts transferable

Domains, cloud subscriptions, app-store accounts, analytics, payment services, certificates and production credentials should not become hostage to a vendor-owned account.

### 18. Document data location, retention and deletion

Ask where project and production data is stored, who can access it, how long backups remain available and what deletion evidence can be provided at termination.

## 5. Stress-test the commercial model

### 19. Compare total cost, not only hourly rate

Include discovery, project management, QA, infrastructure, licenses, third-party tools, support, change requests and transition costs. A low development rate can still produce a higher total cost if important activities are excluded.

### 20. Define milestone acceptance before work starts

Payment triggers should map to understandable deliverables and acceptance criteria. Avoid milestones that depend only on calendar dates or vague percentages of completion.

### 21. Understand change-order pricing

Ask how new work is estimated, who approves it and whether the vendor can begin chargeable changes without written authorization.

### 22. Review service and support commitments

If the vendor will support production software, define response targets, coverage hours, severity levels, maintenance responsibilities and what is excluded from support.

## 6. Evaluate exit risk before signing

### 23. Require a practical handover path

The contract should cover source code, architecture documentation, credentials, deployment instructions, runbooks, unresolved defects and knowledge transfer. A relationship is safer when transition is possible even if nobody expects to use it.

### 24. Confirm usable data-export rights

For SaaS and hosted platforms, ask what can be exported, in which format, how long exports remain available after termination and whether additional fees apply.

### 25. Define termination and transition assistance

Know the notice period, outstanding-payment obligations, termination rights and whether the supplier must assist a replacement provider. If a mission-critical system depends on proprietary vendor technology, identify that dependency before signing rather than during an emergency migration.

## A simple evidence-based scoring method

Use a 1–5 score for each category, but score **evidence**, not sales confidence:

- **1:** no evidence or a material unresolved risk;
- **2:** verbal assurance only;
- **3:** adequate documented evidence;
- **4:** strong evidence plus relevant references or artifacts;
- **5:** strong evidence, clear contractual protection and low residual risk.

Weight categories according to the project. Security and continuity may deserve more weight for a healthcare or financial system; speed and product-discovery capability may matter more for an early-stage MVP. Do not let the scoring model hide a non-negotiable issue: a vendor can have the highest overall score and still be unsuitable if it fails a mandatory security, ownership or compliance requirement.

## Red flags that deserve a closer look

- The vendor will not identify the actual team before contract signature.
- References cannot be contacted or do not resemble your project.
- Source-code, IP or data ownership language is ambiguous.
- Production infrastructure must remain permanently in vendor-controlled accounts.
- Security answers rely only on claims such as “industry standard” without supporting evidence.
- Change requests have no approval or pricing process.
- There is no documented termination, export or handover process.
- The proposal depends on proprietary components that cannot be replaced or transferred.

## What to do after due diligence

Due diligence is not the final selection step. Use what you learned to tighten the statement of work, security requirements, acceptance criteria, ownership clauses and transition obligations. Then compare finalists on the same evidence.

If you are still building a shortlist, browse the [Brandligo company directory](https://www.brandligo.com/) and use the [software development company selection framework](https://www.brandligo.com/blog/choose-software-development-company/) to define your requirements before contacting vendors.

*Editorial note:* This checklist is general procurement guidance, not legal, cybersecurity or compliance advice. Requirements vary by jurisdiction, industry, data sensitivity and system criticality.