- Security teams ask for the same six things; collect them before the review starts
- The packet: SOC 2 report (or equivalent), DPA, data-flow diagram, access scopes, insurance, deletion terms
- Read-only access scopes matter more than certifications
- A complete day-one packet saves weeks of back-and-forth
Before approving a new SaaS platform, IT security teams almost always ask for the same six things: a SOC 2 (or equivalent) report, a signed data processing agreement, a data-flow diagram, the exact access scopes each integration requires, proof of cyber-liability insurance, and a written commitment to delete your data after a proof of concept. If you’re the person championing the purchase, you can save weeks by collecting all six from the vendor before your security team ever sees the request.
That preparation matters because in most mid-market software purchases, the security review (not the product evaluation) is now the slowest step. Product fit gets decided in a demo or two. Security sign-off can sit in a queue for weeks, and every missing document restarts the clock. This guide walks through what a SaaS vendor security review actually covers, what to request from the vendor up front, and gives you a software procurement security checklist you can reuse for every purchase.
What do IT security teams actually ask in a SaaS vendor security review?
Security teams ask a predictable set of questions organized around one concern: what happens to our data if we connect this platform. Certifications matter, but reviewers spend most of their time on specifics: what data flows where, who can access it, and how it gets deleted. The recurring asks:
- SOC 2 report or equivalent evidence. A SOC 2 Type II report is the default request. If a vendor doesn’t have one yet, reviewers will accept substitutes (a recent third-party penetration test summary, a completed CAIQ or SIG questionnaire, and detailed written security documentation), but they will weigh the gap in their risk rating.
- A data processing agreement (DPA). Especially where personal data (employee names, emails, sign-in activity) is involved. The DPA defines the vendor as a processor, lists subprocessors, and sets breach-notification and deletion obligations.
- A data-flow diagram. Reviewers want to see, on one page, what data enters the platform, where it’s stored, which third parties touch it, and how it leaves.
- Integration access scopes. If the platform connects to your identity provider, ERP, or e-signature system, the reviewer will ask for the exact OAuth scopes or API permissions requested, and whether they are read-only.
- Cyber-liability insurance. A certificate of insurance showing cyber coverage, so there’s financial recourse if the vendor suffers a breach involving your data.
- Data deletion after a POC. A written answer to “if we trial this and walk away, when is our data gone, and how do we know?”
What documents should you request from the vendor up front?
Ask the vendor for a complete security documentation package in your first or second call, before the security review begins rather than after it stalls. A prepared vendor can turn this around in days; an unprepared one is itself a signal. Request:
- The SOC 2 report (usually shared under NDA), or the vendor’s current audit status and timeline if certification is in progress.
- A pre-filled security questionnaire: CAIQ or SIG. This answers most standard questions in your security team’s own vocabulary and can shortcut your internal SaaS security questionnaire almost entirely.
- The DPA template, including the current subprocessor list. Send it to legal in parallel with the security review rather than after it.
- A penetration test summary. The executive summary letter, not the full report, is usually enough.
- An encryption and data-retention summary: encryption in transit and at rest, retention periods, and deletion timelines.
- A certificate of insurance showing cyber-liability coverage.
Bundle these into a single folder and attach them to your internal request. Reviewers move fastest when everything is in front of them on day one.
How do you answer the data-flow question?
The data-flow question is answered with a diagram plus a one-paragraph inventory: what categories of data the platform ingests, where each is stored, which subprocessors process it, and how long it’s retained. If the vendor can’t produce this, build the inventory yourself from their documentation, because your security team will ask for it regardless.
For a contract and spend management platform, the honest inventory typically includes contract documents, vendor and cost data, employee directory information from your identity provider, and application sign-in metadata. For each category, your reviewer will want three facts: where it lives (which cloud, which region), how it’s encrypted, and who else touches it. Pay particular attention to the subprocessor list: every third party on it inherits access to some slice of your data, and your security team will check that each one is bound by its own data processing agreement.
Why do access scopes matter more than certifications?
Access scopes matter more because they define the actual blast radius: a certified vendor with broad write access to your identity provider is a bigger risk than an uncertified vendor with narrow read-only access. Security reviewers know this, which is why “is it really read-only?” is one of the most common questions asked on vendor calls.
When a platform connects to systems like Microsoft Entra, Okta, Google Workspace, or your ERP, get the precise permission list in writing:
- Which scopes are requested at connection time: the actual OAuth scope names, not a marketing summary.
- Whether any scope allows writes, and if so, to what, and whether it’s optional.
- Who grants consent: many IdP integrations require tenant-admin consent, so your identity team needs to be in the loop early.
- How disconnection works: what happens to synced data and stored tokens when you revoke access.
A vendor built on read-only integrations can answer these in minutes. Treat hesitation here as a genuine red flag in your vendor security assessment.
What extra questions come up when the platform uses AI?
If the platform uses AI (and most contract-intelligence tools now do), expect three additional questions: which AI providers act as subprocessors, whether your data is used to train models, and whether the vendor will sign an AI addendum to the DPA. Legal teams increasingly redline contracts to add AI-specific terms, so surfacing this early prevents a late-stage stall.
Concretely, ask the vendor: which model providers appear on the subprocessor list; whether customer data is excluded from model training; whether AI outputs (extracted contract terms, flagged clauses) are reviewed or confirmable by a human before they change anything; and whether AI processing happens in the same region as the rest of your data. Get the answers in writing. A reviewer will not accept “the AI is secure” as an answer, and neither should you.
How do you protect your data during and after a POC?
Before a proof of concept starts, agree in writing on three things: what data goes in, who at the vendor can access it, and when and how it will be deleted if you don’t buy. The deletion commitment is the one buyers most often forget to get in writing, and the one security teams most often ask about after the fact.
- Scope the input data. You can run a meaningful trial of a contract management platform with a subset of contracts and a single read-only integration. You rarely need production-wide access on day one.
- Set the deletion clock. A specific timeline (“deleted within 30 days of termination”) beats a vague assurance. Ask what deletion covers: databases, file storage, backups, and stored OAuth tokens.
- Ask for confirmation. A short written deletion attestation at the end of a failed POC closes the loop for your security team’s records.
A software procurement security checklist you can copy
Run this software procurement security checklist for any new SaaS purchase:
- Request the vendor’s security documentation package: SOC 2 report or audit status, pre-filled CAIQ/SIG, pen test summary, encryption and retention summary.
- Get the DPA template and subprocessor list; route to legal in parallel, and raise an AI addendum if the platform uses AI.
- Obtain a data-flow diagram and a plain-language data inventory.
- Get the exact integration scopes in writing and confirm which are read-only; loop in your identity-provider admin for consent requirements.
- Collect a certificate of insurance showing cyber-liability coverage.
- Agree POC terms in writing: data scope, access, deletion timeline, and deletion confirmation.
- Package everything into one folder and submit it with your internal security request.
- After purchase, store the review artifacts alongside the vendor’s contract so the next renewal or re-assessment starts from a record, not a scavenger hunt. A contract management system is the natural home for them.
How License Logic prepares for this review
License Logic goes through this exact review with its own buyers, so it maintains a ready security documentation package (a public security overview, a DPA, a pre-filled CAIQ available on request, and completion of custom vendor questionnaires within two business days), and its integrations with identity providers and ERP systems follow a read-only access model. The current details, including encryption, data retention, deletion timelines, and the full subprocessor list, are published on the License Logic security page, and pricing is public, which helps when your request also needs a budget owner’s sign-off.
Frequently asked questions
What does a “read-only integration” actually mean?
It means the platform’s credentials can retrieve data from the connected system but cannot create, modify, or delete anything in it. Verify the claim by reviewing the actual OAuth scopes or API permissions requested at connection time. The consent screen and the vendor’s documentation should match, and any write scope should be explicitly justified and ideally optional.
What happens to our data after a POC?
Whatever the contract says, which is why you set deletion terms before the POC starts. Ask for a specific deletion window after termination, confirm it covers databases, file storage, backups, and stored integration tokens, and request a written deletion confirmation when the trial ends.
Is a completed security questionnaire enough, or do we need the SOC 2 report?
For lower-risk purchases, many security teams accept a completed CAIQ or SIG plus a pen test summary and a DPA. For platforms handling contracts, spend, or employee data, most will still want the SOC 2 report, or a clear timeline plus compensating evidence if the vendor’s audit is in progress. Your security team sets the bar; your job is to bring them everything that exists.
What is an AI addendum, and when do we need one?
An AI addendum is contract language added to a DPA or MSA that governs how the vendor’s AI features handle your data: typically excluding your data from model training, naming the AI subprocessors, and requiring human confirmation before AI-driven changes take effect. Ask for it whenever the platform processes your documents or data with AI, which for modern contract tools is nearly always.
How long does a SaaS vendor security review usually take?
Anywhere from a few days to several weeks, depending on the sensitivity of the data involved and how complete the vendor’s documentation is when the review starts. The single biggest factor you control is submitting a complete package on day one. Missing documents don’t just add days, they send the request back to the end of the queue.