The average company now runs dozens of SaaS products, and each one holds a copy of something valuable: customer records, financial data, source code, employee information. SaaS vendor security has become the discipline of deciding which of those companies deserve that access, and on what terms. Most teams still make the decision on price and features, then discover the security question only when a customer, an insurer or a regulator asks it. This guide covers how to vet vendors properly without turning procurement into a six week ordeal.
The short answer
Vendor security assessment is the process of establishing, before you sign, what data a supplier will hold, how they protect it, what independent evidence supports their claims, and what happens when something goes wrong. Do it in three tiers based on data sensitivity, ask for evidence rather than assurances, put the commitments in the contract, and review the relationship annually rather than never.
Key takeaways
-
Almost half of breaches now involve a third party, so your supplier list is part of your attack surface whether you manage it or not.
-
Tier your assessment by data sensitivity. A design tool and a payroll platform do not deserve the same scrutiny.
-
Ask for evidence: an audit report, a recent independent test summary, a subprocessor list, and written breach notification commitments.
-
Integration permissions matter as much as the vendor itself, because connected apps hold standing access that outlives the person who approved them.
-
Reassess annually and after any vendor security incident. A point in time review ages badly.
Why third party risk stopped being a formality
For most of the last decade, vendor security reviews were a compliance ritual. A spreadsheet went out, a spreadsheet came back, and nobody read it again. That worked while suppliers were peripheral. It stopped working when suppliers became the infrastructure.
Verizon’s 2026 Data Breach Investigations Report found third party involvement in roughly 48 percent of breaches, a sharp rise on the previous edition. The same report identified exploitation of software vulnerabilities as the leading initial access route, overtaking stolen credentials for the first time, while noting that only around a quarter of known critical vulnerabilities were fully remediated during the year. Put those findings together and the picture is uncomfortable: attackers are getting in through unpatched software, and increasingly it is not your software.
The financial stakes rose too. IBM’s 2026 Cost of a Data Breach study, published at the end of July, put the global average breach cost at a record 4.99 million dollars, with United States organizations averaging 11.5 million. Detection, escalation and lost business accounted for most of the increase, and the mean time to identify and contain a breach reached 247 days. A supplier breach does not produce a smaller bill because the fault sat elsewhere. You still notify customers, still investigate, still absorb the churn.
The pattern that should worry any operations lead is the integration compromise. In August 2025 a widely used sales chat and lead capture product had its authentication tokens stolen, and attackers used those tokens to query the connected customer relationship platforms of hundreds of downstream companies over a ten day window. The victims included several large and well resourced technology firms. None of them were breached in the conventional sense. They had simply clicked “connect” on a tool that later failed, and the connection kept working for the attacker exactly as designed.
Tier your vendors before you assess them
The most common mistake is applying the same process to everything, which produces a heavy review that teams route around. Sort suppliers into three tiers on the day someone requests them.
Tier one: critical
These hold regulated data, customer records, financial data or production credentials, or their downtime stops your business. Identity providers, cloud infrastructure, payroll, the CRM, billing, anything with write access to production. Tier one gets a full assessment: audit report, independent testing evidence, architecture and data flow review, contractual security terms, and named ownership internally. Expect this to take a couple of weeks and plan for it in the buying timeline rather than discovering it at signature.
Tier two: important
These process business data that is confidential but not regulated, or support a significant workflow: project management, analytics, marketing automation, support desks, document collaboration. Tier two gets a lighter review. Confirm the certification status, check data residency and retention, read the subprocessor list, verify the breach notification commitment, and record who owns the relationship. A focused thirty minute review by someone who knows what to look for is worth more than a hundred question spreadsheet nobody scores.
Tier three: low risk
These touch no sensitive data and would cause inconvenience rather than damage if compromised: a stock image library, a font service, a scheduling link. Tier three needs a register entry and a rule that they never receive customer data. The point of naming this tier is to protect the other two from process fatigue. If everything is critical, nothing gets a real review.
The evidence to ask for, and what each one proves
Assurances are easy to give. Evidence is not. Ask for these six items and read them rather than filing them.
Two of these deserve extra attention. A SOC 2 report has a scope section, and vendors occasionally certify a mature legacy product while selling you a newer one outside that boundary. Read the scope, not the badge. And a penetration test summary should name a methodology such as OWASP application testing guidance or NIST SP 800 115, describe the type of test performed, and confirm that findings were remediated and retested. A one page letter with a logo and no methodology tells you almost nothing.
Questions that actually surface problems
Long questionnaires produce long answers and little insight. These questions have a high hit rate because they are hard to answer vaguely.
-
Which subprocessors receive our data, and how will we be told when that list changes?
-
Where is our data stored and backed up, in which countries, and can we require a specific region?
-
When was the platform last independently penetration tested, by whom, and can we see a summary?
-
What is your committed breach notification window in hours, and is it in the contract or only in the policy?
-
How do your own staff access customer data, is that access logged, and can we see our own audit log?
-
What authentication options do you offer, and is single sign on included in our tier or priced as an upgrade?
-
What is the retention period after cancellation, and how do we export our data in a usable format?
-
Which components of your product use AI, which model providers process our data, and is that data used for training?
That last question has become essential and is frequently answered badly. Many products added AI features quickly, and the data path to a model provider is often not reflected in the subprocessor list at all. Ask it explicitly, and ask for the answer in writing.
A note on the single sign on question: charging extra for the security feature that most reduces account takeover risk is a pricing decision that shifts risk onto you. It is not automatically a reason to walk away, but it belongs in the negotiation, and it is one of the few security items where commercial leverage genuinely works.
The integration layer is where most people lose control
Vendor assessment usually stops at the contract. The bigger exposure often arrives afterwards, when someone connects the new tool to systems that were assessed years ago.
Every “connect your account” button creates a durable authorization: a token granting an external application programmatic access to your data, frequently with broader permissions than the feature requires. Those tokens survive password changes. They do not expire when the employee who approved them leaves. They rarely appear in any asset inventory, and most organizations cannot produce a list of them on request.
Build the practice around four habits:
-
Maintain a register of every connected application, listing who approved it, which systems it reaches, what scopes it holds, and when it was last reviewed.
-
Restrict who can authorize new integrations in your identity provider and major platforms, so connections require a decision rather than a click.
-
Review the register quarterly and revoke anything unused, unrecognized or unowned. This takes under an hour once the register exists.
-
Rotate tokens and credentials after any supplier security incident, not only after your own, and treat a vendor breach notice as a trigger for review across the whole stack.
Browser extensions deserve the same treatment. An extension with permission to read page content on your business systems can read every record the signed in user can see, and extensions change ownership more often than people realize.
Put the security commitments in the contract
A questionnaire answer is a marketing statement. A contractual term is enforceable. When your leverage is highest, which is before signature, secure these clauses:
-
Specify a breach notification window in hours, counted from the vendor becoming aware rather than from the completion of their investigation.
-
Require notice before adding subprocessors, with a right to object.
-
Commit to data location, and require consent before moving data to a new region.
-
Include audit or evidence rights, at minimum the right to receive current audit reports and testing summaries annually.
-
Define deletion obligations at termination, with a certificate of destruction and a defined timeframe.
-
Set out data export rights in a machine readable format, so leaving is possible in practice and not just in principle.
-
Address AI processing explicitly, including whether your data may be used to train models.
Small vendors will push back on some of these, and reasonable compromise is fine. What matters is that the conversation happens while you still have a choice, because renegotiating a security term at renewal, after two years of dependency, rarely goes your way.
The mirror image: you are somebody’s vendor too
Every process described above is being run against your company by your own customers. Mid market and enterprise buyers now include a security review as a standard stage, and industry benchmarking through 2026 consistently puts the added time at roughly two to six weeks. That delay is usually caused by unprepared answers rather than weak security, and it lands at the worst possible moment, after verbal agreement and before signature.
The requests are predictable, which means they can be prepared in advance. Buyers ask for a current audit report, evidence of independent testing within the last twelve months, a completed questionnaire, a subprocessor list, a data processing agreement, and remediation evidence for anything that testing found. Assembling that once, into a single trust folder, converts a recurring fire drill into a fifteen minute task.
Testing evidence is the item most often missing. Automated scanning finds published vulnerabilities in known software, which is necessary and cheap, but it does not find broken access control, flawed business logic, or the chain of three moderate issues that together expose a customer database. Those require a human. Commissioning Penetration Testing Services produces both the security outcome and the artifact procurement teams ask for, and having the report ready before the questionnaire arrives is what keeps deals moving.
How to judge testing quality, in your vendors and your own suppliers
Because a test summary is now a standard piece of evidence, it pays to know what separates a real engagement from a formality. Apply the same criteria whether you are reading a vendor’s report or buying a test yourself.
-
Confirm the work is manual and human led, with automation used for coverage rather than as the whole engagement.
-
Check that a recognized methodology is named, and that the scope covers authenticated user roles and APIs rather than only the public marketing site.
-
Look for exploitation detail in findings, describing what an attacker could actually reach, not just a severity label copied from a scanner.
-
Verify that retesting after remediation is included, since an unverified fix is not evidence.
-
Confirm the deliverables include an attestation letter suitable for sharing with customers, alongside the technical report.
-
Ask about the seniority of the testers assigned, because the individuals doing the work vary more than company marketing suggests.
Comparing a shortlist before taking briefing calls is worth an hour, and published roundups of the Top Penetration Testing Companies are a reasonable orientation to how providers differ on methodology, reporting depth and pricing model. Scope precisely when you buy, because unscoped systems are unassessed systems, and the gap between the two is where incidents happen.
A vendor review process that people will actually follow
The process fails for one reason more than any other: no named owner. Vendor risk that belongs to everybody belongs to nobody. Assign it, even part time, and give that person authority to say no.
Warning signs worth acting on
-
Confirm nothing important is missing when a vendor cannot say where data is stored, since vagueness here usually means several places at once.
-
Treat resistance to a contractual breach notification window as a meaningful signal about how an incident would be handled.
-
Question any test report with no methodology, no dates and no remediation status, because it is likely a scan.
-
Note when single sign on and audit logs sit behind an enterprise tier that costs several times your intended spend.
-
Look closely when a status page shows no incidents at all, since mature vendors have incidents and publish them.
-
Escalate when the security contact is a sales representative who promises to check and never returns with written answers.
None of these is automatically disqualifying. A young company may genuinely lack a SOC 2 report while running a tight operation, and a candid explanation with a roadmap is often a better sign than a polished document. Judge the honesty of the answer alongside its content.
Frequently asked questions
How long should a vendor security review take? A tier three tool should take minutes and a tier two review under two hours. Tier one deserves one to two weeks, which is why tiering exists: it concentrates the effort where the data actually is, instead of spreading it evenly and thinly.
We are a twenty person company. Is this overkill? Scale the process, not the principle. A twenty person company can maintain a vendor register in a spreadsheet, ask six questions before signing, and review integrations quarterly. That is perhaps three hours a quarter and it prevents the most common failures.
What if a vendor has no SOC 2 or ISO certification? That is common among early stage products and not disqualifying on its own. Compensate by asking for testing evidence, restricting the data they receive, avoiding production access, and setting a review date. Record the decision and the reasoning so the risk is accepted deliberately.
How often should we reassess existing vendors? Annually for tiers one and two, plus an immediate review after any publicly disclosed incident at that vendor or at one of its subprocessors. Renewal dates are a convenient trigger, since commercial leverage is highest at the same moment.
Who should own vendor security in a company without a security team? Usually operations or finance, since they already see every contract and renewal, with technical input from engineering for tier one decisions. What matters most is that one named person owns the register and has authority to block a purchase.
Does a security questionnaire actually reduce risk? Only if someone scores the answers and acts on them. A questionnaire that is sent, returned and filed changes nothing. Six questions that get read beat two hundred that do not.
Are AI features a separate category of risk? They warrant a separate question rather than a separate process. Ask which model providers receive your data, whether it is retained or used for training, and whether those providers appear on the subprocessor list. Many products added AI capability faster than they updated their documentation.
Closing thought
Vendor security is not about achieving certainty, which is unavailable. It is about knowing what you have exposed and to whom, having evidence rather than assurances behind the important relationships, and being able to answer quickly when a supplier announces an incident at four in the afternoon. Companies that maintain a register, tier their reviews and revisit connections quarterly are not more cautious than their competitors. They are simply able to answer the question when it arrives, from a customer, an auditor or an attacker.
Publishing notes (for the editor, remove before publication)
Meta title: SaaS Vendor Security: How to Vet Tools Before You Sign (54 characters)
Meta description: Nearly half of breaches now involve a third party. A practical SaaS vendor security process: how to tier suppliers, what evidence to demand, and what to sign. (156 characters)
Suggested slug: saas-vendor-security
Word count: approximately 3,105 words (body only)
External links (exactly two, both intentional)
No other external links appear in this article, and sources named in the body are deliberately not hyperlinked. Please do not add citation links during formatting.
Suggested internal links for the host site (editor to insert 2 to 4 where they fit)
-
Anywhere the article mentions procurement or purchasing workflow, link to an existing post on vendor management, procurement or operations.
-
In the tiering section, link to any existing content on data classification or information governance.
-
In the integration layer section, link to existing content on your platform’s integrations, API or permissions model.
-
In the closing section, link to any existing security, trust or compliance page.
Data sources named in the body (attributed in text only)
-
Verizon 2026 Data Breach Investigations Report
-
IBM Cost of a Data Breach Report 2026, released 29 July 2026
Image briefs
-
Featured image, filename saas-vendor-security-tiers.webp. Three tier pyramid showing critical, important and low risk vendors, with the assessment depth and typical examples beside each tier. Alt text: “Diagram showing how to tier SaaS vendors by data sensitivity for security assessment”.
-
Section image under “The evidence to ask for”, filename vendor-security-evidence-checklist.webp. Six item checklist card showing each evidence type and the one thing it proves. Alt text: “Checklist of security evidence to request from a SaaS vendor before signing”.
-
Section image under “The integration layer”, filename oauth-integration-sprawl.webp. Hub and spoke diagram of a core business system with connected third party apps, highlighting standing token access and the review cycle. Alt text: “Diagram showing how connected app integrations create standing access to business data”.
