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 and software development company comparison.
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
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
NIST’s July 8, 2026 supplier due-diligence guidance 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 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 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 and use the software development company selection framework 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.
