Adopting hosted software means placing business data, identities, and sometimes production workflows on infrastructure you do not operate. A vendor security review decides whether that placement is acceptable, under what conditions, and with which residual risks. It starts before procurement lock-in: you define the data and processes in scope, collect verifiable evidence about the provider’s controls, test those claims against your threat model, and only then negotiate access, logging, incident, and exit terms. The work is slower than a checkbox purchase, but it is cheaper than an unplanned disclosure, a failed customer audit, or a forced migration after a supplier incident. What follows is qualitative and conditional; duties and appetite vary by organization, sector, and data type.
Sourced factual references
Title: Vendor Security Review: Key Components And Implementation ([source](https://www.upguard.com/blog/vendor-security-review)).
Title: How To Perform SaaS Vendor Risk Assessment ([source](https://www.josys.com/article/how-to-perform-saas-vendor-risk-assessment)).
Title: The Rise of SaaS Security Reviews: What You’re Missing in Your Vendor… ([source](https://trustedsec.com/resources/business-resources/saas-security-reviews-vendor-stack)).
> **Key points** > > - Inventory data classes, users, and business impact before you send a questionnaire. > - Treat marketing language and generic attestations as leads to evidence, not as a pass. > - Withhold production access until residual risk, contract remedies, and an owner for ongoing review are written down.
Establish scope, data classes, and decision rights
A review that starts with a blank questionnaire usually ends with a blank decision. Write a short scope note first. Name the hosted function in generic terms: collaboration, ticketing, analytics, file exchange, customer messaging, finance operations, or similar. Do not treat “software as a service” as a single risk class. A tool that stores public marketing copy is not the same object as a tool that stores customer identifiers, authentication secrets, employment files, source code, or payment-related fields.
For each data class, record whether the provider will hold it, whether staff will paste it into the product, and whether the product will create derived copies such as logs, search indexes, backups, exports, or model-training artifacts. Derived copies are easy to miss and often outlive the original record. If you cannot describe the data flow in plain language, you are not ready to assess the vendor.
Identify who will use the system and with what privilege. Separate administrators from standard users. Note contractors, partners, and customer-facing accounts. Note machine identities: service accounts, webhooks, integration keys, and scheduled jobs. Machine identities frequently hold more privilege than people and are reviewed less often. Map whether the hosted system will become a system of record, a system of engagement, or a disposable viewer of data that already lives elsewhere. Portability, backup, and exit matter more when the hosted system becomes the place of truth.
Assign decision rights before evidence collection. A business owner should accept residual risk. Security should recommend controls and document gaps. Legal and privacy should see the data-flow description and the processing terms. Procurement should not complete signature while the review file is still open unless a named owner records an explicit, time-bounded waiver. Without named roles, the process either stalls or becomes theater.
Gather evidence instead of relying on questionnaires alone
Questionnaires are useful as a structured prompt. They are not evidence. Sales language describes intent; evidence describes what is implemented, who operates it, how it is tested, and what happens when it fails. Ask for artifacts that a reasonably skilled reviewer can inspect: architecture descriptions at a level that shows trust boundaries; data-flow diagrams; encryption and key-management descriptions; access-control and logging descriptions; incident and vulnerability-handling procedures; independent audit or assessment reports if they exist; and the list of subprocessors that will touch your data.
Read those artifacts against your scope note, not against the vendor’s marketing narrative. If a report covers a different product, a different data center set, or a different legal entity than the one on the order form, treat the mismatch as a finding. If the report is stale relative to a major product change, treat freshness as a condition, not as a footnote. If the vendor will not share anything beyond a one-page overview, that refusal is itself evidence; it may be acceptable for a low-impact tool and unacceptable for a system of record.
Prefer primary documents over summaries. A questionnaire answer that says “we encrypt data” is not equivalent to a description of algorithms, key ownership, rotation, and who can decrypt. A claim that “access is restricted” is not equivalent to a description of joiners, movers, leavers, privileged access, and customer-managed role models. Where the vendor uses a shared responsibility model, write down which tasks remain yours: identity configuration, logging export, data classification inside the tenant, and staff behavior.
Evaluate identity, encryption, logging, and operational security
Identity is usually the highest-leverage control in hosted software. Confirm whether your organization can require its own identity provider, phishing-resistant authentication for administrators, session controls, and a role model that matches least privilege. Confirm how local accounts are prevented or tightly governed. Confirm how API keys and integration identities are created, stored, rotated, and revoked. If the product cannot federate identity, or if it requires a shared administrator password, treat that as a design constraint, not as a future roadmap item.
Encryption should be described for data in transit and data at rest, including backups and exports. Ask who holds keys, whether you can bring or manage keys for high-sensitivity classes, and how decryption is authorized. “Encrypted” without key custody is an incomplete statement. If the vendor staff can read tenant data during support, document the path: just-in-time access, customer approval, logging, and whether support copies persist.
Logging and monitoring should answer a simple question: if an account is abused, can you reconstruct who did what, from where, and to which records? Useful logs typically include authentication events, privilege changes, data exports, configuration changes, and administrative actions. Confirm whether logs can be exported to your own monitoring function, how long they are retained, and whether they contain secrets. Confirm that you can obtain logs during an incident without waiting for a manual ticket of uncertain duration.
Operational security is the set of practices that keep the hosted service itself from becoming the incident. Qualitatively, look for a described vulnerability-handling process, change management, network segmentation between tenants, secure development practices, and staff access to production. You will rarely see internal ticket queues; you can still require a written description, independent assessment extracts, and a commitment to notify you of issues that affect your tenant. If the vendor cannot describe tenant isolation, treat multi-tenant residual risk as explicit.
Conditions: smaller providers may have strong product security and weak paperwork; larger providers may have strong paperwork and a complex shared-responsibility surface. Neither size nor polish is a control. Score the actual mechanisms against the data you plan to send.
Examine subprocessors, location, incidents, and exit
Hosted software is a supply chain, not a single box. Ask for the current subprocessor list that applies to your product and region, the function each subprocessor performs, and how you will be notified of material changes. A review that stops at the logo on the order form misses the firms that store backups, relay messages, analyze usage, or provide support tooling. If a subprocessor will receive personal data or secrets, apply a proportionate version of the same questions you asked the primary vendor.
Location and legal process matter even when you are not writing a legal opinion in the review file. Record where the primary processing, backups, support access, and logs reside, and whether you can constrain them by contract. Record whether the vendor will support your data-processing terms, deletion on request, and assistance with data-subject or customer audit requests when those duties apply to you. If the vendor’s standard terms conflict with your obligations to your own customers, that conflict is a go-live blocker unless legal accepts a specific residual.
Incidents should be described before they happen. You want a defined severity model, a notification window that is short enough to be useful, a content minimum (what happened, which tenants or records, what was accessed, what you should do), a named channel, and a cooperation duty for forensics and customer notification. “We take security seriously” is not a notification clause. Also record how you will learn about vulnerabilities in the product that are not yet a confirmed breach.
Score residual risk and lock conditions into the contract
A review that ends in “looks fine” cannot be defended. Score residual risk in business language. For each material finding, record the scenario, the affected data class, the likely impact on operations, customers, and legal duties, the compensating control you will operate, and whether the remaining risk is accepted by a named owner. Use a simple scale that your organization already understands; do not invent precision that the evidence does not support.
Separate findings you can fix with configuration from findings that require vendor change. Tenant configuration (single sign-on, logging export, role design, data retention inside the app) should be implemented before production data is loaded. Vendor-side gaps (no audit log export, unrestricted support access, missing subprocessor notice, weak deletion) belong in the contract or in a documented waiver. Roadmap promises are not controls until they ship and you re-verify.
Translate accepted conditions into the agreement or an addendum. Typical security-relevant terms, stated qualitatively, include: scope of the product and legal entity; data location constraints if required; subprocessor notice and objection rights; incident notification content and timing; audit or assessment report sharing; encryption and access commitments that match the evidence; cooperation on investigations; deletion and export; and a right to suspend or terminate if a material control fails. If procurement cannot obtain a term, record that absence next to the risk it leaves open.
Operate the review after go-live
Hosted software changes without a forklift. Features appear, subprocessors change, identity models drift, and staff turn over. The review file should name an operational owner, a re-review trigger set, and a minimum cadence proportionate to impact. Typical triggers, used conditionally, include a material product change, a new data class, a new integration, a merger or entity change at the vendor, an incident, an expired assessment report, or a significant increase in user count.
Keep the live tenant aligned with the reviewed design. That means enforcing federated identity, removing standing administrator privileges, rotating integration secrets, exporting logs to a place you control, and periodically sampling user access against the original role model. Shadow accounts and forgotten integrations are common sources of residual risk that never appear in the original questionnaire.
Track vendor-visible changes. Subscribe to the vendor’s security and status channels if they exist. Recheck the subprocessor list on a defined cycle. Re-read incident terms when you renew. If you cannot obtain fresh evidence at renewal, treat that as a finding equal to an original gap. Low-impact tools can be renewed with a short confirmation that scope and data classes have not changed. High-impact tools should not be renewed on inertia.
Finally, keep an exit rehearsal cheap. Once a year, or before a major expansion, export a sample and confirm that you can read it, that it is complete enough to rebuild elsewhere, and that deletion instructions still match the contract. An untested export is a hope. A tested export is a control. The point of the whole process is not a perfect vendor. It is a documented, proportionate decision you can still explain after the first bad day.
Run the review as a decision record, not as a ritual. Scope the data and users, collect evidence that matches the actual tenant, judge identity and operational controls against impact, follow the supply chain, write residual risk next to a name, and keep the file alive after go-live. When evidence is missing, say so and decide whether the business still wants the tool on those terms. That habit is slower than a rushed subscription and far cheaper than discovering, after adoption, that you cannot see, contain, or leave.