Software vendor due diligence should leave a buyer able to explain why a particular development engagement can proceed, which evidence supports that choice and what must still change before signing. A supplier's reputation can open the conversation. The decision needs a narrower basis: the proposed team, the work being purchased and requirements that the buyer has agreed are mandatory.
Start with the Vendor Evidence Register. For each criterion, record an inspectable source, a named reviewer, a bounded observation and a decision. Empty evidence stays Pending. An attractive presentation cannot close a row that nobody has checked.
This guide concerns selecting a supplier for a new software development contract. It provides a working review method rather than a completed assessment of any company. Its single worked scenario is fictional. Adapt the criteria with procurement, engineering and the specialists responsible for your particular engagement.
Before requesting documents, complete this sentence: we can commission this scope only if the following condition is established. A condition might concern who controls the repository, whether the proposed lead performed the relevant work in a cited case or who will own deployment approvals. Choose requirements that have a consequence for the purchase. A preference without a stated consequence belongs in a different part of the comparison.
Describe the next engagement precisely. Selecting a discovery partner requires evidence relevant to investigation and its deliverables. Selecting a team to build and hand over a production service requires a broader delivery boundary. State the systems included, expected buyer inputs and decisions reserved for later. Otherwise one supplier may price investigation while another assumes every uncertainty has already been resolved.
Name the decision owner and the people who can assess individual criteria. Procurement may confirm the contracting entity, an engineering reviewer may inspect build instructions and a security specialist may examine access arrangements. The decision owner brings those findings together. Record when another specialist's conclusion is required; a technical interview cannot silently approve a legal or financial question.
Freeze the mandatory criteria before comparing final offers. If a requirement changes after an interview, keep the earlier version and tell every affected candidate what changed. Record why the change matters and which evidence must be reviewed again. This gives the buyer a traceable basis for comparison and gives suppliers a stable question they can actually answer.
Agree on the meaning of each decision before the first review. Accept means the inspected evidence satisfies this criterion within its stated scope. Clarify means a specific gap or inconsistency still needs an answer. Stop means the present proposal cannot proceed under an agreed mandatory condition. Pending means the criterion has not been checked. These labels describe review states, not a permanent judgment about a company.
A Stop decision can be revisited if the proposal changes and the appropriate reviewer examines the change.
Clarify needs a concrete next action; leaving it open indefinitely does not turn uncertainty into acceptance. If a deadline arrives before necessary evidence is available, the decision owner must apply the agreed selection rule. Commercial urgency is context to record, rather than evidence that a requirement has been met.
Ask for a source that can establish the specific requirement. A public case page can identify a company's described contribution. A redacted responsibility map can clarify a delivery boundary. A supervised demonstration can show behavior under stated conditions. Label each accurately, including whether it describes past work, an existing capability or a proposal for your project.
In its Secure Software Development Framework, version 1.1, the National Institute of Standards and Technology describes a framework that:
provides a common vocabulary for secure software development
That shared vocabulary helps a buyer formulate questions about development practices. Citing the framework does not prove that a supplier follows those practices. Ask which relevant practice is being discussed, what the supplier does and what evidence your reviewer can inspect. Keep the supplier's answer separate from the reviewer's observation.
A useful source reference includes a document name or controlled location, its version and the part inspected. Record the checked date as well. A report issued before a team change may remain useful background while failing to establish the current staffing claim. A screenshot detached from its environment may explain a screen without establishing who can administer the underlying service.
Agree on proportionate access. Offer a sanitized document, synthetic example or supervised review where confidential material cannot be distributed. Do not demand another customer's source code, personal records or credentials as routine qualification evidence. Record what the alternative establishes and what it cannot establish. Restricted availability and irrelevant content are different problems and should produce different follow-up questions.
Ask how a demonstration was prepared. Material assembled manually for an interview may explain an intended format. A demonstration using an existing mechanism can establish behavior in the demonstrated environment. Neither establishes performance in a buyer environment that has not been examined. Record the inputs, assistance and boundaries that matter to the criterion, without turning qualification into an unpaid implementation project.