Ask about outcomes, not badges
A software purchase transfers more than a licence fee. It can create a long-term dependency on the supplier's architecture, security practices, support model and ability to respond when conditions change. A short security questionnaire completed at the end of procurement rarely provides enough insight.
Certifications can be useful evidence, but they do not describe every product, deployment or operating decision. Ask the supplier to explain how security is built into the service and what the customer must configure or operate.
CISA's Secure by Demand guidance encourages buyers to make security an explicit part of procurement. Its companion Secure by Design principles place greater responsibility on technology providers for customer security outcomes, transparency and executive accountability.
Product and access controls
Clarify how identities are managed. Does the product support single sign-on, multi-factor authentication and role-based access? Are strong controls available on the proposed plan, or only as a paid add-on? Can administrators review access and export audit history?
Ask which settings are secure by default. A feature that exists but is disabled for convenience may offer little practical protection. Understand how privileged support access is approved, monitored and revoked.
Development and vulnerability management
Ask how the supplier applies secure development practices across design, implementation, testing, release and operation. NIST's Secure Software Development Framework provides a useful common vocabulary for this discussion.
Request the vulnerability disclosure process, typical remediation approach and notification policy. Determine whether supported versions receive security fixes and how long support lasts. For material software, ask what evidence can be shared without requiring the supplier to expose sensitive internal details.
Data and service boundaries
Document which data the service processes, where it is stored, how it is encrypted and which subprocessors are involved. Confirm retention, deletion, backup and export arrangements. If personal information may leave South Africa, examine the transfer mechanism and contractual protection with appropriate legal advice.
Understand tenant separation and recovery. Ask how the supplier tests restoration and how recovery objectives align with your operating needs. A service-level percentage does not answer how your data will be restored after a serious incident.
Incident responsibilities
The contract should define notification channels, escalation paths, investigation cooperation and the information the supplier will provide. Ask how incidents are classified and how lessons lead to product changes. Confirm who communicates with affected users and regulators where required.
Exit and concentration risk
A dependable procurement decision includes the end of the relationship. Test whether data can be exported in a usable format. Identify proprietary integrations, identity dependencies and migration support. Consider what happens if the provider changes ownership, pricing, product direction or regional availability.
Match evidence to consequence
A low-risk productivity tool does not require the same review as a platform processing financial, health or customer identity data. Use a risk tier to decide the depth of evidence, assurance and contractual control.
The aim is not to eliminate supplier risk. It is to make responsibility, evidence and trade-offs visible before the organisation becomes dependent on the product.
Algoza can help structure technical due diligence, architecture review and supplier questions for business-critical software decisions.