The Security Due Diligence Framework
- Stage 1: Scope the Risk Before Reading a Single Certificate
- Stage 2: Read the SOC 2 Report, Not the Badge
- Stage 3: Verify Secure Development, Not Just Secure Hosting
- Stage 4: Trace the Software Supply Chain
- Stage 5: Follow the Data
- Stage 6: Check Who Can Get In, Including the Vendor
- Stage 7: Put Security in the Contract
- Stage 8: Re-Verify on a Schedule
Every SaaS vendor has a trust page now. A row of badges, a downloadable PDF, a paragraph about bank-grade encryption. The badges are real. What they prove is narrower than the page implies, and the distance between the two is where security due diligence lives.
The tell is the security questionnaire. Three hundred questions in a spreadsheet, answered by the vendor’s sales engineer, reviewed by nobody, filed as evidence that diligence was done. It is a ritual, and both sides know it. The vendor answers yes to everything answerable as yes. The buyer’s team skims for a no that never comes. The document proves that the document exists.
Here is the discipline that replaces it. Ask for the artifact, not the answer.
Not “are you SOC 2 compliant” but “send the full Type II report.” Not “do you follow secure development practices” but “show me the framework you map to, the last penetration test, and what you fixed.” Not “is our data encrypted” but “who holds the keys.” Every claim on a trust page has an artifact behind it or it does not, and the request for the artifact is the entire method.
This guide is the eight-stage version of that method. It extends the security stage of our broader framework for evaluating SaaS vendors into a standalone process, for the platforms where security is the decision.
The Evidence Table
Before the stages, the map. Each claim you will hear, and the artifact that proves it.
| The claim | The artifact that proves it |
|---|---|
| ”We are SOC 2 compliant” | The full SOC 2 Type II report under NDA – scope, system description, exceptions, auditor’s opinion – and a bridge letter if it is more than a year old |
| ”We follow secure development practices” | A mapping to NIST SSDF (SP 800-218) or equivalent, code review policy, static and dependency scanning in the pipeline, the most recent third-party penetration test summary and remediation status |
| ”We know what is in our software” | A software bill of materials (SBOM) and a current subprocessor list with locations |
| ”Your data is encrypted” | Encryption standards at rest and in transit, key management model, whether customer-managed keys are available, data residency options |
| ”We have strong access controls” | SSO/SAML support, MFA enforcement, role-based access control, exportable audit logs, and a written policy on vendor employee access to customer data |
| ”We will notify you of a breach” | A contractual notification window in hours, an incident response plan summary, and the date of the last tabletop exercise |
| ”We are resilient” | Recovery time and recovery point objectives in writing, backup restoration test evidence, disaster recovery test dates |
If a claim has no artifact, it is a sentence.
Stage 1: Scope the Risk Before Reading a Single Certificate
Diligence effort should follow risk, and risk follows three questions. What data will the platform hold – personal data, financial data, health data, credentials, intellectual property, or none of these? What will it integrate with – does it hold an API key to your CRM, read from your data warehouse, write to your ERP? And what is the blast radius if it is breached or simply goes dark for a week?
A team scheduling tool holding names and calendar slots warrants an afternoon. A platform holding customer PII with write access to your billing system warrants the full eight stages and a lawyer. Most buyers apply the same questionnaire to both, which means over-investigating the trivial and under-investigating the critical.
Write the classification down before opening the vendor’s trust page. It sets the bar for every stage that follows, and it stops the vendor’s polish from setting it for you.
Stage 2: Read the SOC 2 Report, Not the Badge
A SOC 2 Type II report means an independent auditor tested the vendor’s controls over a period – typically six to twelve months – against the AICPA Trust Services Criteria the vendor elected to be assessed on. That last clause is the one the badge omits. Vendors choose the scope. A clean opinion over Security alone, covering one product line, proves less than a report with two noted exceptions covering Security, Availability, and Confidentiality across the platform you are actually buying.
Request the full report under NDA. This is standard; a summary letter, a badge, or a trust-page link is not equivalent, and a serious vendor knows the difference. Then read four things. The scope: which trust criteria and which systems. The system description: does the platform described match the one you are buying, or a predecessor? The exceptions: every control the auditor found not operating effectively, and the vendor’s response. The opinion: qualified or unqualified. A report older than twelve months should come with a bridge letter stating nothing material has changed.
Type I versus Type II matters. Type I evaluates control design at a point in time; Type II evaluates operation over the observation period. A young vendor with a Type I is showing intent. It is not showing a track record. ISO 27001 certification is a reasonable complement – it audits the management system rather than the controls’ operation – and industry-specific requirements such as HIPAA, PCI DSS, or FedRAMP are non-negotiable where the data falls inside their scope.
Common Failure Mode
The buyer sees the SOC 2 badge, checks the box, and signs. Eighteen months later a breach traces to a subsidiary product that was never in the report's scope, running on infrastructure the system description did not cover. The report was accurate. It was also about something else. Nobody read the first three pages.
Stage 3: Verify Secure Development, Not Just Secure Hosting
“We are hosted on AWS” proves that AWS is secure. It says nothing about the code the vendor wrote on top of it, which is where SaaS vulnerabilities almost always live. Secure hosting is table stakes. Secure development is the question.
Ask what framework the vendor’s development process maps to. The NIST Secure Software Development Framework (SP 800-218) is the reference most mature vendors cite, and the mapping – not the claim – is the artifact. Ask about code review policy, static analysis and dependency scanning in the build pipeline, how vulnerabilities are triaged and by what deadline, and whether there is a vulnerability disclosure program or bug bounty.
Then ask for the most recent third-party penetration test: who performed it, when, what scope, and – the part that matters – what was found and what was fixed. A test summary with zero findings is less credible than one with six, all remediated. Every real system has findings. The signal is not the absence of vulnerabilities; it is the presence of a process that finds and closes them on a schedule.
Stage 4: Trace the Software Supply Chain
A SaaS product is the vendor’s code plus hundreds of third-party components plus the subcontractors who run pieces of the service. Its security is the security of all of it. Two artifacts make the chain visible.
The first is a software bill of materials – an inventory of the components inside the product. Its practical value arrives after the next widely publicized vulnerability in a common library, when the only question that matters is: are we exposed? A vendor with an SBOM answers in an hour. A vendor without one answers in a week, or never. Regulators are moving the same direction; the EU’s Cyber Resilience Act and the NIS2 directive raise expectations for supply-chain transparency in products and services sold into Europe.
The second is the subprocessor list: every third party that touches your data – hosting, email delivery, analytics, support tooling, offshore engineering – with locations. Read it for two things. Names you did not expect, which are often the most revealing. And the change process: does the contract require notice before a new subprocessor is added, with a right to object? Under GDPR, a vendor processing EU personal data owes you that notice; make it universal regardless.
Stage 5: Follow the Data
Encryption is the claim every trust page makes and almost none specify. Ask for the standards at rest and in transit, and then ask the harder question: who holds the keys? A vendor that manages its own keys can decrypt your data; that may be fine, but it should be known. If the data is sensitive, ask whether customer-managed keys are available.
Then trace the data’s life. Where does it reside, and can you choose a region? How is it isolated from other tenants – logical separation in a shared database, or something stronger? How long is it retained after you stop using a feature, or the service? How is it deleted when you leave, and will the vendor certify deletion in writing? How are backups encrypted, where are they stored, and – the question that separates policy from practice – when was a restoration from backup last tested?
Recovery objectives belong here too. A recovery time objective and a recovery point objective in writing tell you how long you will be down and how much you will lose. A vendor that cannot state them has not decided.
Stage 6: Check Who Can Get In, Including the Vendor
Access control has an external half and an internal half, and buyers reliably examine only the first.
The external half: single sign-on via SAML or OIDC so your identity provider governs access; multi-factor authentication that can be enforced rather than merely offered; role-based access control granular enough that a read-only user cannot export the customer list; and audit logs you can export to your own systems, so that access to your data leaves a trail you control.
The internal half is the question vendors least expect. Which of your employees can access my data, under what conditions, and what is logged when they do? Support engineers routinely have broad access to customer environments; that is often necessary, and it should be governed – just-in-time access, customer approval for sensitive environments, logging that you can review. A vendor with a clear answer has thought about it. A vendor who has not thought about it has an insider risk it has not measured.
Questions to Ask
Three questions cover both halves: can our identity provider enforce access, can we export the audit log, and can you show me the policy – not describe it, show it – that governs your own staff's access to our data? The third question produces the longest pause. That pause is data.
Stage 7: Put Security in the Contract
Everything the trust page says is marketing until it is a contractual obligation. The security terms that matter are few, and they are the ones the vendor’s standard paper is quietest about.
Breach notification in a defined number of hours from discovery – 72 hours is a common ceiling, and shorter is reasonable for sensitive data – with an obligation to disclose what was accessed and what you must do, and a right to terminate for a material incident. Subprocessor change notice with a right to object. An audit right, or at minimum a right to receive each new SOC 2 report and penetration test summary on request. Security-specific remedies: service credits are not a remedy for a breach. Data return and certified deletion on exit. And evidence of cyber insurance – the policy, its limits, and whether it covers third-party liability to customers like you.
These terms are not exotic and a mature vendor will have seen them before. The negotiation itself is diagnostic. A vendor who agrees readily has a security program that can bear the commitment. A vendor who resists a 72-hour notification clause is telling you how the incident would go.
Stage 8: Re-Verify on a Schedule
A vendor’s posture at signature is a snapshot, and platforms change more in a year than most buyers re-examine in five. New features widen the attack surface. Subprocessors change. An acquisition moves the data somewhere else. The engineering team that built the security program leaves.
Re-verification is a calendar, not a project. Request the new SOC 2 report each cycle and read the exceptions against last year’s – trends matter more than any single finding. Review every subprocessor change notice rather than filing it. Treat each renewal as a re-evaluation, with the diligence scoped to what has changed. And watch the signals that arrive between reviews: a security incident in the news, a change of ownership, a leadership departure on the security team. Security-rating services can supplement this with continuous external monitoring; they are useful as an early warning and insufficient as diligence.
Key Signal
The single most informative moment in security due diligence is not any document. It is the vendor's response to the request for documents. Complete, prompt, organized, and candid about the exceptions – that is a vendor with a program. Piecemeal, delayed, and defensive – that pattern is the finding, whatever the badges say.
Conclusion
SaaS security due diligence fails in one of two ways: the questionnaire ritual that verifies nothing, or the certificate reflex that verifies the wrong thing. The alternative is not more questions. It is fewer questions and the right artifacts – the full report, the framework mapping, the penetration test, the bill of materials, the subprocessor list, the key management model, the access policy, the contract terms – requested in proportion to the risk, read rather than filed, and re-requested on a schedule.
Every claim on a trust page either has an artifact behind it or it does not.
The badge is the answer. The report is the artifact. Ask for the artifact.
Related Guides
- How to Evaluate SaaS Vendors – The full eight-dimension framework this guide extends
- Technology Vendor Due Diligence Checklist – Financial, legal, and operational verification for any vendor
- How to Evaluate a Technology Partner – Evaluating custom development partners beyond the pitch
- Reference Checks for Technology Partners – A structured methodology for verifying what vendors claim
- AI Tools for Small Business – Evaluating the newest category of SaaS with the same discipline
Frequently Asked Questions
What is SaaS vendor security due diligence?
The process of verifying – with evidence, not assurances – that a SaaS vendor's security controls, development practices, supply chain, data handling, and contractual commitments match the risk of the data and processes you are entrusting to them. It replaces the security questionnaire with a request for artifacts: the SOC 2 Type II report, a penetration test summary, a software bill of materials, a subprocessor list, and contract terms with teeth.
Does a SOC 2 report mean a vendor is secure?
No. A SOC 2 Type II report means an independent auditor tested the vendor's controls over a period of months against the criteria the vendor chose to be assessed on. Read the scope – which systems and which trust criteria – the system description, and the exceptions. A clean opinion over a narrow scope proves less than a report with two exceptions over a broad one.
What is the difference between SOC 2 Type I and Type II?
Type I evaluates whether controls are suitably designed at a single point in time. Type II evaluates whether they operated effectively over an observation period, typically six to twelve months. Type II is the baseline for a platform holding sensitive data. A Type I report from a young vendor is a reasonable interim signal, not a substitute.
Should I ask a SaaS vendor for an SBOM?
Yes, for any platform that will hold regulated or business-critical data. A software bill of materials lists the third-party components in the product, which is what lets a vendor – and you – answer the question that matters after the next widely publicized vulnerability: are we exposed? A vendor that cannot produce one does not know the answer either.
What breach notification window should the contract require?
A defined number of hours from discovery – 72 hours is a common ceiling, and shorter is reasonable for sensitive data – rather than language like promptly or without undue delay. Pair it with an obligation to share what was accessed, what was done, and what you must do, and with a right to terminate for a material breach.
What if the vendor will not share their SOC 2 report?
Sharing the full report under NDA is standard practice; a summary letter or a link to a trust page is not equivalent. A vendor that refuses the full report to a serious buyer is either not audited to the standard the badge implies or is not organized enough to know what it can share. Either way, treat the refusal as a finding.
How often should SaaS vendor security be re-verified?
Annually at minimum – request the new SOC 2 report each cycle and read the exceptions against last year's – plus on every subprocessor change notice and at every renewal. A vendor's posture at signature is a snapshot, and platforms change more in a year than most buyers re-examine in five.
What if a small vendor has no SOC 2 at all?
Decide based on the data, not the size. For low-sensitivity data, a documented security program, MFA and SSO, encryption, a recent penetration test, and a clear incident plan can be enough. For regulated or business-critical data, the absence of an independent audit is a reason to wait for one or to choose a vendor that has one.