What controls should an SME require from its software providers?

Start by understanding what each provider could affect

An SME does not need to treat all its technology providers as if they posed the same level of risk. A tool that handles public information does not present the same scenario as a service with access to customer data, user accounts, or systems essential to operations.

The first step is to maintain a straightforward inventory of software, cloud services, and managed service providers. For each one, it is useful to record its purpose, what information it processes, who has access, whether it connects to other systems, and what business dependency an interruption would create. The review should also consider subcontractors and relevant software components when the provider can identify them.

This approach is consistent with the supply chain risk management promoted by NIST: identifying, assessing, and mitigating risks throughout the life cycle of technology products and services. For a small business, it may be enough to assign a practical category—for example, low, medium, or high—and briefly explain the reason.

Assess specific controls, not just general statements

A security questionnaire can be a useful starting point, but the answers should make it possible to understand how the service is protected in practice. The SME can request information proportionate to the provider’s importance on the following points:

• Access and accounts: use of individual accounts, stronger authentication where available, and removal of permissions when someone no longer needs access.
• Data protection: what data is collected, where it is hosted, who can view it, and what measures are applied to protect it during storage and transmission.
• Updates and vulnerabilities: how flaws are detected and fixed, how relevant vulnerabilities are communicated, and what channels are available for reporting a problem.
• Development and components: what secure development practices the provider uses and, if relevant to the risk, what information it can provide about software components or dependencies.
• Service continuity: what mechanisms and procedures it provides for maintaining or restoring the service in the event of an interruption.

Evidence may take different forms: technical documentation, policies, relevant reports or certifications, explanations from the provider, or contractual commitments. No document, on its own, proves that the service is risk-free. What matters is that the information addresses the SME’s specific exposure and can be reviewed if the product or its terms change.

Clarify how incidents and changes are handled

Before entering into a contract, the company should ask how and through which channel the provider reports an incident that could affect its data or systems. It is also useful to clarify what information the provider can share, how it will cooperate with the investigation, and who the points of contact will be for both parties.

It is also useful to understand how the provider notifies customers about changes that could alter the risk: significant service changes, new subcontractors, changes in the location or processing of data, or material changes to security measures. Not all of these changes will have the same impact; the SME can focus on those that affect its operations or applicable obligations.

Notification, cooperation, and timing requirements should be made clear in the contract where appropriate. Legal requirements depend on the jurisdiction, sector, type of data, and service: NIST and CISA references from the United States are U.S. frameworks and resources, not general obligations for SMEs in other countries.

Put expectations and service termination in writing

Depending on the service and applicable regulations, the contract or its security addenda can specify what information is processed, what controls are expected, how access is managed, how incidents are reported, and what assistance the provider will offer in the event of a vulnerability or interruption. It is also reasonable to specify what happens to data and credentials when the relationship ends.

The exit process should cover the return or deletion of data, revocation of access, and, where appropriate, confirmation that the agreed actions have been completed. If information needs to be retained for legal, operational, or backup purposes, the terms and limits should be reviewed with the provider. The specific wording requires consideration of the jurisdiction and type of service; this guide is not a substitute for legal analysis.

Review risk throughout the relationship

The assessment does not end when the contract is signed. The SME can set a review frequency based on the provider’s criticality and bring the review forward if incidents, relevant vulnerabilities, service changes, or changes in technological dependency occur. To avoid purely bureaucratic controls, each review should record what changed, what evidence was consulted, and who must resolve outstanding issues.

A tracking sheet can include four basic details: provider and service, risk level and justification, outstanding controls or commitments, and the person responsible for reviewing them. This allows a company with limited resources to focus its attention on providers with greater access to information or essential systems, without turning a voluntary framework into a supposed universal legal obligation.