Software supplier checks should begin with what the service can access and what would happen if it failed. A calendar utility and an accounting platform do not deserve identical investigations. A small business can make a useful decision by checking the supplier’s identity, operating dependencies, security evidence and recovery arrangements in proportion to the consequence.
NIST’s July 2026 due-diligence guide provides a framework for that work. It is aimed at information and communications technology suppliers and distinguishes initial research from a more extensive risk assessment. The approach can be adapted without turning every small purchase into a lengthy procurement project.
Start with the proposed access
Write one sentence describing the job the software will do. Then list the data it will receive and the actions it will be allowed to take. A tool that reads public documents has a different risk profile from one that can edit customer accounts.
Include integrations. A product may store little data itself while receiving broad access to email, cloud storage or a financial system. The permission screen is part of the purchase decision.
Identify the worst plausible business interruption from a failure. Could the team continue manually for a day? Would payroll stop? Would customer data be exposed? The answer determines how much investigation is justified.
This prevents a common procurement error: spending time on a generic questionnaire while overlooking the one permission that makes the tool consequential.
Use NIST’s categories as prompts for evidence
NIST published SP 1326 on 8 July 2026. Its categories include foreign ownership, control or influence; provenance; resilience; foundational cyber practices; and supply-chain tiers.
The guide describes due diligence as an initial research activity that can inform deeper supplier assessment. It does not certify a supplier or prescribe one universal pass mark for every buyer.
For a small business, translate the categories into concrete questions. Who controls the supplier? Where do the product and important components come from? Can the service withstand disruption? What security practices are evidenced? Which other providers does it depend on?
Keep the evidence beside the answer. A vendor’s claim, an independent report and your own test are different kinds of support and should remain distinguishable.
Confirm the entity behind the product
Find the legal entity in the contract, billing terms and privacy information. Check whether those documents consistently identify the same service provider and explain the role of any affiliates.
Ownership and control can matter to continuity, legal obligations and the jurisdictions involved. Investigate the relevant facts without treating nationality as a substitute for an actual risk assessment.
NIST’s foreign-ownership category is framed around organisation-defined concerns and the ability to influence operations. It should not be reduced to a simplistic approved-country list copied without context.
If the company is being acquired or the contracting entity is changing, ask what happens to the service, data and existing terms. A familiar brand can remain visible while the underlying contractual relationship changes.
Trace the important dependencies
A supplier may rely on a cloud host, identity provider, payment processor, AI provider or specialist data service. You do not need an exhaustive map of every library to identify the dependencies that could stop the business function.
Ask which subcontractors process your data and which services are necessary for availability. Check whether the supplier publishes a relevant list and how material changes are communicated.
Two alternative products may depend on the same underlying provider. That matters if you expect one to serve as a fallback for the other.
| Dependency question | Why it matters | Useful evidence |
|---|---|---|
| Where is the service hosted? | Availability and data-location questions | Architecture or contractual information |
| Who handles identity? | A login outage can block access | Supported authentication setup |
| Which subprocessors receive data? | The data path extends beyond one vendor | Current subprocessor list |
| What can be exported? | Recovery and continuity need usable records | Sample export and documentation |
| What is the fallback? | A second interface may share the same dependency | Dependency comparison |
Treat an unanswered question as uncertainty. Do not convert it into a reassuring assumption because the website looks professional.
Read security reports for scope and date
A certification or assurance report can be useful, but the title alone does not show which product, period, systems or controls it covers. Ask for the scope relevant to the service you are buying.
Check the report date and any exclusions or customer responsibilities. A control may depend on the buyer enabling a setting or managing users in a particular way.
Avoid asking a tiny supplier for a large-enterprise report that cannot meaningfully address your actual concern. For a low-risk tool, a narrower explanation and practical test may be sufficient. For a critical service, missing evidence can be decisive.
Do not claim that a report proves the product cannot be breached. It provides evidence within a defined assessment, not a guarantee of future behaviour.
Test the customer controls you will actually use
Verify that the product supports the permissions, account management and export functions your business needs. A feature in a sales presentation is less useful than a working configuration in the relevant plan.
For example, can one user read records while another approves changes? Can a departed employee be removed promptly? Are important actions recorded in an accessible log? Can the company recover administrative access without the original founder?
Use test data and a trial environment where possible. Do not connect production customer data simply to discover whether the permission model is suitable.
Keep a short record of the test and any limitation. If a feature exists only in a more expensive plan, include that price in the comparison.
Ask how failure is handled
Resilience includes more than an uptime percentage. Ask how incidents are communicated, how data is restored and what the customer must do during an interruption.
A backup statement should identify what is backed up and how recovery is tested. Your own export may still be useful for continuity, but it is not automatically equivalent to a complete service restore.
Consider support access during an account problem. If every support route requires logging into the unavailable service, the recovery process may be awkward at exactly the wrong time.
For an important tool, run a tabletop exercise: the service is unavailable for two working days. Which obligations continue, which records are needed and who makes the decision to use a fallback?
Work through a small integration decision
Imagine a consultancy considering a tool that summarises support tickets. The tool requests read access to every mailbox in the workspace, although the intended task concerns one shared support inbox.
The first question is whether access can be narrowed. If it can, test that configuration. If it cannot, the business must decide whether the broader access is justified by the benefit and supported by adequate evidence.
Next, identify whether ticket content is sent to another provider and how long it is retained. Review the actual data path rather than stopping at the summarisation tool’s name.
The consultancy might approve a limited pilot with synthetic tickets, request a narrower integration or choose another tool. The decision follows the access and evidence, not a general judgement that all AI tools are either acceptable or unacceptable.
Record a decision instead of accumulating documents
A folder containing ten reports is not a supplier decision. Write a short assessment naming the service, intended use, data and permissions, evidence reviewed, unresolved questions and conditions of use.
Use a few clear outcomes: acceptable for the proposed use, acceptable with specific conditions, more information required, or unsuitable for this use. Avoid a numerical score that averages away a critical missing control.
Name the person responsible for each condition. “Use carefully” is not an actionable requirement. “Restrict the integration to the support inbox and review access after staff changes” is.
Keep the assessment proportional. A one-page decision can be more useful than a long questionnaire when it captures the actual dependencies and limits.
Revisit the decision when the service changes
Set review triggers tied to meaningful changes: new data categories, expanded permissions, a different subprocessor, an acquisition, a serious incident or a major increase in business reliance.
A supplier approved for public content may need another review before receiving customer records. The product name has not changed, but the consequence has.
Check that unused integrations are removed. Permissions granted for a pilot can remain active long after the team stops using the tool.
The decision record should evolve with the use. NIST’s framework helps identify what to investigate; the business must connect that evidence to its own data, obligations and tolerance for interruption.
Use an evidence date, not a permanent verdict
A supplier assessment describes the evidence available at a particular time. Record the date of important documents and tests so that a later reviewer can distinguish current support from an old statement.
For example, an export test performed before a major product migration may need to be repeated. A security report covering one service environment may not describe a newly acquired product. The reason for review is the changed dependency, not the passage of an arbitrary number of days alone.
Where evidence cannot be obtained, decide whether the uncertainty is tolerable for the proposed use. A limited pilot with public data may be reasonable even when a full connection to customer records is not. Keep that boundary in the decision record and in the actual permissions.
This also makes procurement conversations more focused. Instead of asking the vendor to declare that it is secure, ask for the specific evidence needed to resolve the outstanding decision: an export sample, a retention explanation or a description of administrative recovery.
Questions
Does a security certificate mean a supplier is safe for every use?
No. Read its scope, date and limitations, then compare the covered controls with your intended use.
How much checking does a small business need?
Match the effort to the data, permissions and consequence of failure. A critical financial system needs more evidence than a low-impact utility.
Should I investigate every subcontractor equally?
Prioritise dependencies that process important data or can interrupt the service. Deeper investigation should follow the actual risk.
When should a supplier be reviewed again?
Review when access, data, ownership, dependencies or business reliance materially changes, and after relevant incidents.
