The demo looks good. The team can see how the application would save time, and somebody wants to buy it before the offer expires. That is a reasonable moment to slow down just enough to ask how the service will fit into the business after the demo ends.
A vendor security review does not need to become a questionnaire nobody can interpret. Match the questions to what the provider can access, how important the service is, and what an interruption would mean. A scheduling tool with limited data and a provider administering your whole environment deserve different levels of review.
Start with access and responsibility
Ask what information the provider stores or can reach, which permissions are needed, and how administrator access is controlled. Can your company enforce its chosen sign-in protections? How is access removed when an employee or vendor technician leaves? Understand who is responsible for each task instead of assuming the contract covers it.
CISA’s Secure by Demand guidance encourages buyers to ask about the security of the product itself, not rely only on corporate compliance claims. A certificate or audit report may be useful evidence for its stated scope. It does not answer every question about how your accounts, data, and configurations will be managed.
Source: CISA Secure by Demand guide
Ask questions that lead to an operational answer
- How are security issues reported, investigated, and communicated to customers?
- Who installs updates, and what happens when a version reaches end of support?
- Which logs and audit records are available, and what does access to them cost?
- What recovery capability is included, what is excluded, and how has it been tested?
- How can we export our data and revoke access if we change providers?
- Which subcontractors or integrations handle our data or privileged access?
Clarify recovery before you need it
A provider’s availability statement does not automatically mean you have a recoverable copy of a deleted file or a way to keep working during an outage. Ask what happens if data is corrupted, an account is compromised, or the vendor itself has a service interruption. Record any gap that your company needs to address separately.
Then consider the people involved. Who calls support? Can the provider’s technical team work with your IT team? What information needs to be available outside the application if it is down? A technically good service can still create a difficult business dependency when the support route and responsibilities are unclear.
Leave room for a sensible exception
A smaller specialist provider may not answer the same way as a large cloud company. That does not automatically make it the wrong choice. Understand the risk, decide whether the benefit justifies it, and document any additional controls or review needed. The point is an informed choice, not rejecting every product that differs from a standard checklist.
RIKR can help assess the technical context around a purchase: existing identities, devices, network requirements, administration, and recovery. We are open to the right solution for the company. The recommendation should explain the tradeoffs and the work involved after the sale.
Keep the answers available
Store the decision, the responsible people, important renewal dates, and any agreed exceptions. Revisit the review when the service gains more access or becomes more important to operations. A purchase that began as a small convenience can grow into a system the whole business depends on.
Related: keeping an IT asset and service inventory
Explore RIKR managed IT support
Written by Joshua Price
Back to the blog