How to choose · Software procurement
How to run a security review of a SaaS vendor
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Scale the review to the data and access the vendor will have. Collect independent assurance reports, a completed security questionnaire and documentation on encryption, access control, incident response and subprocessors, then verify claims rather than accepting them. Focus on what the vendor does with your data, how it detects and reports incidents, and how you can exit with your data intact.
Who this is for: An IT, security or procurement lead who must approve a software vendor that will store or process company or customer data.
What to evaluate
Data sensitivity and scope
The depth of review should track what the vendor will hold, from public content to regulated personal data.
How to check: Classify the data and integrations in scope before sending any questionnaire.
Independent assurance
Third-party audit reports and certifications provide evidence beyond the vendor own claims.
How to check: Request the current report, read the scope and exceptions, and confirm the product you are buying is inside it.
Access and identity controls
Weak authentication and over-broad admin rights are common breach paths.
How to check: Confirm support for single sign-on, multi-factor authentication, role-based permissions and audit logs.
Encryption and data location
You need to know how data is protected in transit and at rest and where it is stored.
How to check: Ask for documentation on encryption, key management and the regions used for storage and backups.
Incident response and notification
Delays in hearing about a breach limit your ability to meet your own obligations.
How to check: Review contractual notification timelines and the vendor process for investigation and communication.
Subprocessors and supply chain
The vendor risk includes the services it depends on.
How to check: Request a subprocessor list and the process for notifying you of changes.
Exit and data return
Leaving should not mean losing or being unable to delete your data.
How to check: Confirm export formats, deletion commitments and retention of backups after termination.
Comparison
| Evidence | What it proves | Limitation |
|---|---|---|
| Independent audit report | Controls were tested over a period by an outside auditor | Scope may exclude the module you plan to use |
| Security certification | A management system meets a published standard | Does not show every control is effective daily |
| Questionnaire answers | Vendor self-assessment against your questions | Unverified and often optimistic |
| Penetration test summary | Testers probed the application | May be old or limited in scope |
| Contract security terms | Legally binding commitments | Only as good as enforcement and monitoring |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 7 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Data sensitivity and scope | |||
| Independent assurance | |||
| Access and identity controls | |||
| Encryption and data location | |||
| Incident response and notification | |||
| Subprocessors and supply chain | |||
| Exit and data return | |||
| Total (max 21) | 0 | 0 | 0 |
Questions to ask before you commit
- Which audit reports or certifications cover the exact product and regions we will use?
- How is our data separated from other customers?
- Who at the vendor can access our data, and how is that access logged and approved?
- What is your incident notification commitment and who is our contact?
- Which subprocessors handle our data and where are they located?
- How are vulnerabilities found, prioritised and fixed, and can you share a summary of your testing?
- What happens to our data and backups when the contract ends?
- Do you support single sign-on and provisioning without charging for a higher tier?
Typical trade-offs
Thorough review versus speed to deploy
- Upside
- Finds weaknesses before data is shared.
- Downside
- Delays business teams and may push them toward unsanctioned tools.
Standard questionnaire versus custom questions
- Upside
- Standard forms are quick and comparable across vendors.
- Downside
- May miss risks specific to your data or sector.
Tiered review by risk versus uniform process
- Upside
- Effort concentrates where harm would be greatest.
- Downside
- Requires clear classification and discipline to apply consistently.
Common mistakes
- Accepting a certificate without reading its scope; confirm the product and locations are covered.
- Reviewing once at purchase and never again; schedule reassessment and monitor vendor notices.
- Skipping integrations; examine what permissions the tool requests in your other systems.
- Treating the questionnaire as the end; follow up on gaps and record accepted risks with an owner.
Related questions
How much review does a low-risk tool need?
A tool that handles no sensitive data and has no privileged integrations can go through a lightweight check: confirm it supports single sign-on or strong authentication, read the privacy and security pages, and make sure the contract covers data deletion. Reserve full questionnaires and audit report analysis for vendors that touch personal, financial or confidential information.
What should I look for in an audit report?
Read the scope statement, the period covered, the system description, the list of controls tested and, above all, any exceptions or qualified opinions. Check whether the services you plan to use sit inside the boundary. Note complementary controls the vendor expects you to implement, because those become your responsibilities after signing. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
Who should be involved in the review?
Security or IT leads usually run it, but procurement, legal, the business owner and often privacy staff contribute. Legal checks data protection terms, the business owner explains data use and criticality, and security tests technical claims. Involving them early prevents a late rejection after the business has already planned a rollout. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
How often should vendors be reassessed?
Tie frequency to risk: critical vendors benefit from annual reassessment and event-driven checks after acquisitions, incidents or major product changes, while low-risk vendors can be reviewed at renewal. Keep a vendor register with data types, owners and review dates so overdue assessments are visible rather than forgotten. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Supply chain security guidance — National Cyber Security Centre, retrieved 27 October 2026
- Cybersecurity Supply Chain Risk Management Practices — NIST, retrieved 27 October 2026
Related guides
Requirements · Software procurement
SaaS contract terms to review and negotiate
Beyond price, the clauses that most affect outcomes are renewal and termination mechanics, data ownership and return, service levels and remedies, liability caps, security and breach commitments, and rules on price changes. Contract law varies by jurisdiction, so treat this as a checklist for conversation with counsel, not legal advice. Negotiate before signature, because leverage drops once data is in the system.
Comparison · Software procurement
Buy off-the-shelf software or build a custom tool
Buy when the process is common across companies, a mature product covers most of it, and speed matters. Build when the process is a source of competitive difference, existing products force awkward workarounds, and you can sustain engineering ownership over years. Hidden costs on both sides, integration and customisation for bought tools, maintenance and security for built ones, usually decide the outcome.
Problems & fixes · Software procurement
Why software implementations fail or run late and how to prevent it
Implementations falter less from technology than from unclear scope, poor data, weak ownership and underestimated change effort. Prevent trouble by defining outcomes and boundaries up front, cleaning data before migration, naming a business owner with decision authority, and planning training and adoption as seriously as configuration. When a project slips, reset scope and sequence rather than adding pressure.
Requirements · Artificial intelligence
Security and governance requirements for workflow automation
Treat the platform as a privileged system. Require single sign-on and role separation, scoped service connections instead of personal logins, secret storage you can audit, restrictions on which data may flow through it, run-log retention limits, change review for important flows, and an inventory with named owners. Without these, automations become unmanaged paths around your normal controls.
How to choose · Artificial intelligence
How to assess an AI vendor during due diligence
Assess an AI vendor on data handling, security assurance, model and subprocessor transparency, contractual protections, testing and monitoring support, and operational resilience. Request evidence rather than assertions: independent attestations, data flow diagrams, retention terms and incident commitments. Tailor depth to the risk of the use case, and revisit when features or subprocessors change.
Requirements · Business operations
Card data security requirements for merchants
Any business accepting cards must protect cardholder data under the card network security standard, validated through a questionnaire or assessment that depends on how you take payments. The less card data touches your own systems, the lighter the effort. Hosted checkout, encrypted terminals and tokenization shrink scope. Your acquirer or processor tells you which validation applies.
Requirements · Productivity and collaboration
Collaboration platform requirements for regulated record retention
Regulated organizations need collaboration platforms that can retain and preserve messages and files for required periods, place legal holds, search across content types, export in usable formats, restrict deletion, and prove integrity through audit logs. Requirements vary by sector and jurisdiction, so confirm obligations with counsel and the regulator, then translate them into testable platform capabilities.