A SaaS vendor security assessment is a structured review of how a software provider protects the data and systems you entrust to it. Run it before you sign, repeat it at renewal, and match its depth to the risk the vendor creates. For a law firm, an energy operator or a healthcare-adjacent business, the process comes down to five steps: tier the vendor, request evidence, verify it, write the findings into the contract and keep watching after go-live.
TL;DR
- Assess before purchase, at renewal and when the service changes materially. Do not wait for an incident or an audit request.
- Tier every vendor by the data it touches, the access it gets and the business impact of an outage. The tier sets the depth of the review.
- Ask for artifacts, not assurances: a current SOC 2 Type II report, policies, architecture diagrams, vulnerability scan results and continuity attestations.
- Put breach notification, data deletion, subcontractor approval and audit rights in the contract.
- Reassess on a schedule and on triggers, such as a breach, an acquisition or a new integration.
Table of Contents
- What a SaaS vendor security assessment covers
- When to run an assessment
- Step 1: Classify the vendor before you send anything
- Step 2: Request the right questionnaire and evidence
- Step 3: Verify the evidence and score the risk
- Step 4: Put the findings into the contract
- Step 5: Monitor vendors and decide when to reassess
- Our perspective
- Get vendor assessments off your desk
- FAQ
- Sources
What a SaaS vendor security assessment covers
The assessment answers one question: should this vendor hold this data, with this level of access, under these terms? It looks at four areas.
- Security controls: access management, multi-factor authentication, encryption in transit and at rest, patching, logging and vulnerability management.
- Privacy and legal fit: where data is stored, who can access it, which subprocessors touch it and which regulations apply to you.
- Operational resilience: backups, disaster recovery, uptime commitments and what happens to your workflows if the service fails.
- Governance: policies, training, background checks, incident response and independent audit results.
SaaS deserves particular care because you control less than you would with infrastructure you run yourself. TechTarget notes that customers often have less control over SaaS security capabilities than over PaaS and IaaS, so the provider carries nearly all responsibility for data protection, availability and threat detection. That is exactly why you need evidence about how the provider carries it.
The assessment is also different from a questionnaire. A questionnaire is one tool inside it. The assessment includes classification, evidence review, scoring, a decision and a monitoring plan. For a broader view of the discipline, see our guide to vendor cybersecurity assessment for business leaders.
When to run an assessment
The most common mistake is assessing after the contract is signed, when your leverage is gone and the data is already flowing. The University of Texas System, which runs a formal program, asks for a vendor risk assessment at three moments:
- Before the decision to procure new software or services.
- When renewing a contract for existing software that will access, process, store or create confidential or controlled data.
- When there are significant changes to the service, such as a move from on-premises software to a cloud-based version.
The same program also shows when you can skip a full review. It does not require one if the service was assessed within the last 12 months, does not touch confidential or controlled data, is used only for published data, or has already implemented every recommendation from the prior assessment. That is a useful model for a private firm: spend effort where the data is sensitive, and keep a light path for low-risk tools.
Timing matters on the sales side too. The buyer's security review often sits between a verbal yes and a signature, and a seller's view of the security review process shows why starting early on both sides prevents deals from stalling at sign-off.
A practical trigger list for your own program:
- A new SaaS tool requested by any department, including free trials that will receive client or company data.
- Every contract renewal for a tool in a high or moderate tier.
- A vendor acquisition, a change in hosting provider or a new subprocessor.
- A new integration with your identity provider, document system or production environment.
- A public breach, regulatory action or negative audit result involving the vendor.
Step 1: Classify the vendor before you send anything
Sending a 300-question spreadsheet to every vendor wastes your time and theirs. Classify first, then match the review to the tier. The University of Wisconsin's vendor guide states that the level of review should align with the tier the vendor falls within, and that risk ratings should weigh availability, confidentiality and integrity.
Three questions drive the tier:
- What data will the vendor store, process or transmit? Client files, privileged communications, personal data, health information, payment data, source code and operational technology data sit at the top.
- What access will it have? Single sign-on, API connections, endpoint agents, and privileged credentials all raise risk.
- What happens if it fails, leaks or changes unexpectedly? A document management system that holds active matters is a different proposition from a scheduling widget.
Atlassian's published evaluation guide defines three risk levels in a way that translates well to regulated firms. High risk covers data that a law or regulation requires you to protect, data whose loss would significantly harm you, personal information, trade secrets, source code, customer data, and services whose outage would significantly disrupt operations.
A simple tiering table you can adapt:
| Tier | Typical data and access | Typical examples | Depth of review |
|---|---|---|---|
| High | Client, regulated or personal data; identity integration; core operations depend on it | Document management, billing and trust accounting, EHR, SCADA data analytics, email security | Full questionnaire, independent audit report, evidence review, contract addendum |
| Moderate | Internal business data; moderate integration; business-critical but replaceable | Project management, HR platforms, internal chat | Standard questionnaire, audit report or summary, contract review |
| Low | No sensitive data; no privileged access; minimal impact | Public content tools, design utilities | Lightweight check, standard terms |
For firms that want to turn tiers into numbers, our article on third-party risk scoring with weights, tiers and triggers shows how to build a repeatable model. Whichever method you choose, let the business requester propose a tier and let security validate it. If a tool that will hold client documents arrives labeled low risk, that mismatch is the first finding.
Step 2: Request the right questionnaire and evidence
For a high-tier vendor, ask for a defined set of documents rather than open-ended promises. Virginia Tech's IT vendor standard is a clear public example. It requires services handling high-risk data to provide a full HECVAT, an annual SOC 2 Type II report, security policies and procedures, architecture and data flow diagrams, annual business continuity and disaster recovery attestations and annual vulnerability scans. For moderate-risk services, the same standard accepts a full or lite questionnaire, and low-risk services need no evidence.
You do not have to be a university to borrow the structure. A workable request package for a high-tier SaaS vendor includes:
- A standard security questionnaire covering governance, access control, encryption, vulnerability and patch management, logging, incident response, business continuity, subprocessors, employee screening and training.
- An independent audit report, ideally SOC 2 Type II within the past 12 months, with the full report and not only the badge on the website.
- A recent penetration test summary and the vendor's remediation status for high findings.
- Architecture and data flow diagrams showing where your data lives, which subprocessors touch it and how tenants are separated.
- Policies and plans: information security policy, incident response plan, breach notification procedure and continuity plan.
- Data lifecycle details: retention, deletion on termination, backup handling and how media is destroyed. Audit-ready data destruction records are a good example of the kind of verifiable evidence an assessor should expect on this topic.
Two details deserve extra attention for U.S. regulated organizations. First, data location: the Wisconsin guide recommends limiting data storage to within the borders of the United States when possible. Second, who holds the encryption keys and how the vendor handles legal requests for data, because both affect what a third party could read.
If questionnaires are slowing your team down, read how regulated teams are cutting vendor questionnaire cycle time to hours. The goal is not fewer questions. It is faster answers, with evidence attached.
Step 3: Verify the evidence and score the risk
A completed questionnaire is a set of claims. Verification turns claims into findings.
Compare answers with audit results
Read the SOC 2 report itself. Check the audit period, the systems in scope, the trust services criteria covered, any qualified opinion and the listed exceptions. Then compare it with the questionnaire. If the vendor claims enforced multi-factor authentication everywhere and the report lists exceptions in access reviews, ask about it. Inconsistencies between questionnaire answers and independent audit results are the most useful signal an assessor has.
Also check that the report covers the product you are buying. Vendors often have several products, and an audit may cover only one environment.
Accept artifacts, not assurances
A sound rule: a control counts when you have an artifact for it, such as a policy document, a configuration screenshot, a scan report or an audit exception list. A sales engineer's verbal assurance is not evidence. Marketing pages and trust centers are a starting point, and the operational detail lives in reports and documents.
Score consistently
Use the same scale for every vendor so decisions can be compared and defended. A simple approach:
- Score each control domain from 0 (no evidence) to 4 (verified by independent evidence).
- Weight domains by the vendor's tier. Access control and encryption weigh more for a vendor that holds client files.
- Define a short list of red lines that trigger escalation regardless of the total score, such as no encryption of data at rest, no breach notification commitment, or no independent assessment of a vendor that holds regulated data.
- Record the decision as one of three outcomes: approve, approve with conditions or reject.
Conditions are where assessments create value. "Approve, provided the vendor enables SSO with MFA, remediates the two open high findings within 90 days and signs our security addendum" is a decision you can track. Our guide to vendor security due diligence walks through documenting these outcomes so they hold up in an audit or a client inquiry.
Step 4: Put the findings into the contract
Whatever the assessment finds, the contract is where you make it enforceable. The Utah State Auditor's privacy contract clauses recommend provisions that translate well to private-sector SaaS agreements:
- Compliance with federal and state data protection laws.
- Defined data protection and security measures.
- Confidentiality obligations.
- Use of data only for the purposes the contract specifies.
- Approval requirements for subcontracting.
- Breach notification within 24 hours of any verified or suspected breach.
- Data deletion, with a certificate of destruction within 14 days of contract termination.
- Liability and insurance requirements.
- Audit rights.
Those figures are one public body's recommended terms, not a universal standard, so set your own timelines with counsel based on your regulatory obligations. A law firm with client confidentiality duties, a healthcare-related business subject to HIPAA or a contractor working toward CMMC will each need different notification windows and flow-down terms. Have your attorney review the security addendum, and align it with the conditions from your assessment.
Where the vendor will not negotiate, document the residual risk and obtain a formal sign-off from the right executive. A risk that is accepted in writing is managed. A risk nobody noticed is not.
Step 5: Monitor vendors and decide when to reassess
An assessment is a snapshot. The vendor's environment changes after you sign, so your monitoring plan should combine a calendar with event triggers.
Calendar-based reviews. Tie reassessment to the tier:
- High tier: collect a new SOC 2 report, vulnerability scan summary and continuity attestation every year, and review open findings quarterly.
- Moderate tier: review the audit report or questionnaire at renewal, or roughly every two years.
- Low tier: re-confirm only if usage or data changes.
The annual evidence cycle in the Virginia Tech standard is a good reference for the high tier.
Event-based triggers. Reassess outside the calendar when:
- The vendor reports a breach, or news or regulators report one.
- The vendor is acquired, changes hosting or adds a subprocessor that touches your data.
- Your use changes, for example from storing internal files to storing client matter data.
- A new integration gives the vendor access to identity, endpoints or production systems.
- An audit report arrives with a qualified opinion or new exceptions.
Track the basics in one register. For each vendor, keep the owner, tier, data types, integrations, contract end date, last assessment date, open findings and next review date. A register that is reviewed monthly catches expiring audit reports and unowned vendors before an auditor does.
Close the loop at offboarding. When you leave a vendor, revoke access, export your data, and obtain the deletion certificate your contract requires.
For a wider look at how this fits into a security program, see our guide to security assessment for mid-market companies.
Our perspective
Most organizations we meet do not lack a vendor assessment template. They lack the time and the senior judgment to use it consistently. A managing partner or operations director signs off on dozens of SaaS tools a year, and each one touches client or operational data.
We think the answer is a repeatable program, not a heroic review of one vendor. Tier the vendor, request evidence in proportion, score on one scale, record the decision, and schedule the next review. That is the work a virtual CISO does. It gives leadership a clear view of third-party risk without adding a full-time executive.
Our approach pairs hands-on vCISO leadership with an AI-enabled platform. The advisory side sets the risk appetite, tiers and contract expectations. The platform side is designed to automate intake and reporting, so assessments move faster and the results are board-ready. For regulated teams in legal, energy and healthcare-adjacent work, that combination is designed to make vendor oversight practical to sustain.
vCISO
Get vendor assessments off your desk
CISOSafe is a Houston-based virtual CISO firm and AI-powered security platform built for regulated organizations. We help law firms, oil and gas companies, energy operators and other compliance-sensitive mid-market businesses build a vendor risk program, tier their vendors, review evidence and prepare for audits against frameworks such as SOC 2, HIPAA, PCI DSS and CMMC.
If you want a senior security leader to own this process, see our vCISO, risk assessment and compliance services or talk to us at CISOSafe about your current vendor list.
FAQ
What is the difference between a vendor security questionnaire and a vendor security assessment?
A questionnaire is a list of questions the vendor answers. An assessment is the whole process: classifying the vendor, collecting answers and independent evidence, verifying them, scoring the risk, deciding and monitoring afterward. The questionnaire feeds the assessment but does not replace it.
How long does a SaaS vendor security assessment take?
It depends on the tier and on how quickly the vendor responds. A low-risk tool can be cleared with a short check. A high-risk vendor takes longer because of evidence review and contract negotiation. The University of Texas System, for example, strives to complete requests within ten business days, which is a reasonable benchmark when the vendor cooperates.
Is a SOC 2 report enough to approve a vendor?
It is strong evidence, not a verdict. Read the audit period, scope, opinion and exceptions, and confirm it covers the product you are buying. Then combine it with the questionnaire, architecture details and contract terms that fit your own regulatory duties.
How often should I reassess a SaaS vendor?
Reassess high-tier vendors at least annually, moderate-tier vendors at renewal, and any vendor after a trigger such as a breach, an acquisition, a new subprocessor or a change in how you use the service.
Who should own vendor security assessments at a small or mid-sized firm?
Security leadership should own the process, with legal, procurement and the business owner contributing. If you have no in-house CISO, a virtual CISO can set the tiers, review the evidence and report the results to leadership.
Sources
- Vendor Risk Assessments, The University of Texas System
- Guide to Vendor Risk Assessments, University of Wisconsin
- IT Vendor Risk Management Standard, Virginia Tech
- Privacy Contract Clauses, Utah State Auditor
- How to manage third-party risk in the cloud, TechTarget
- Evaluating Cloud Vendor Security, Atlassian
- Security Review Process: A Seller's Guide
- Audit Ready Records for SOC 2 Data Destruction