B2B Vendor Security Review Checklist: Buyers and Sellers

A vendor security review is a simple trade. The buyer wants to know a vendor will keep their data safe. The seller wants to close the deal without guessing at answers. Both sides lose time when the review has no shape.

This page is a checklist you can print and work through. The first half is for buyers who send reviews. The second half is for sellers who answer them. The last part covers what a review is and what it is not.

If you are just starting, do the five-step security baseline first. It covers the accounts, devices, and owners that every answer below depends on.

Part 1: For buyers who send reviews

Before you send anything

• Write down what the vendor will touch: which data, which systems, and which users.
• Sort the vendor into a tier. A tool that holds customer data needs more review than a tool that holds a lunch menu.
• Pick one owner on your side who will read the answers and make the call.
• Set a due date that fits the deal, and tell the vendor up front.
• Decide what would stop the deal. Write it down before the answers come back.

What to ask for

Ask for what the vendor already has before you send a long form. Many vendors keep a trust page or a packet ready.

• A SOC 2 report or ISO 27001 certificate, if they have one.
• If they have neither, their security policies and a short summary of their controls.
• A recent penetration test summary, with the date and the scope.
• A list of the other companies that process your data for them (subprocessors).
• A data processing agreement, if personal data is involved.
• A questionnaire only for the gaps the documents do not cover. Standard forms like SIG or CAIQ are fine. Trim them to the tier.

How to read a SOC 2 report

A SOC 2 report is written by an independent CPA firm. It is not written by the vendor or by a consultant. Read it with care.

• Check the type. A Type I report looks at how controls are designed at one point in time. A Type II report also tests whether they worked over a period of time.
• Check the dates. Note when the period ended. If it ended a while ago, ask for a bridge letter that covers the time since. The vendor's own management writes that letter, not the CPA firm, so treat it as the vendor's statement.
• Check the scope. Make sure the product you are buying is inside the system the report describes.
• Check which Trust Services Criteria are covered. Security is always included. Availability, confidentiality, processing integrity, and privacy are optional.
• Read the exceptions. These are places where a test found a problem. Ask the vendor what they did about each one.
• Read the user entity controls (the report calls them complementary user entity controls). These are the things the report says you, the customer, must do. Assign each one to someone on your team.

Getting ready for your own report? See SOC 2 Readiness in 90 Days.

What to check in the answers

• Single sign-on and MFA for staff who can reach your data.
• Who can reach production, and how that access is approved and removed.
• Where your data lives, how it is encrypted, and how long it is kept.
• How backups work, and when a restore was last tested.
• How the vendor finds and fixes security bugs.
• How and when they will tell you about an incident that affects you.
• How they review their own vendors.

Closing the review

• Log any gap you accept, with an owner and a date to check again.
• Put the must-haves into the contract, such as breach notice timing.
• Save the answers and documents where your next review can find them.
• Set a date to review the vendor again, based on the tier.

Part 2: For sellers who answer reviews

Most small SaaS teams meet their first review as a spreadsheet in a sales thread. We wrote about that in Questionnaires Before the Audit. The checklist below is the short version.

Build the packet once

• A one-page security overview in plain words.
• Your current policies, each with an owner and a review date.
• Your SOC 2 report, if you have one, shared under NDA.
• A recent penetration test summary, if you have one.
• Your subprocessor list, kept up to date.
• A simple diagram of where customer data lives and moves.

Keep an answer library

• Write core answers once, in plain words, and tag them by topic.
• Start with the topics every form asks about: logins, access, data, backups, incidents, and vendors.
• Give each topic a named owner who keeps it accurate.
• Date every answer. Update it when the system changes, not when the next form arrives.

Map each claim to evidence

• For each answer, note the control behind it and where the proof lives.
• Keep current evidence, such as your last access review, your MFA settings, and your last backup restore test.
• If a buyer asks to see proof, you should find it in minutes, not days.

Answer honestly

• If a control is planned but not live, say so. Give the date and what you do in the meantime.
• Never claim a report, a certificate, or a control you do not have.
• Make sure two people do not give two different answers to the same question.
• Have one person check each packet for conflicts before it goes out.

Run a turnaround path

• One intake point, so forms do not get lost in inboxes.
• Sort each question: library answer, small edit, or new.
• Send only the new questions to the people who know the answer.
• Return the packet through one channel that sales can track.
• Add every new answer back to the library.

Part 3: The topics both sides should cover

Whether you send or answer, most reviews come back to the same topics. Use this as a quick shared list.

• Identity. Single sign-on, MFA, and how accounts are created and removed.
• Access. Who has admin rights, and how often access is reviewed.
• Data. Where it lives, who can see it, how it is encrypted, and when it is deleted.
• Devices. Whether staff laptops are managed, encrypted, and kept up to date.
• Change. How code and system changes are reviewed before they ship.
• Backups. How often they run, and proof that a restore works.
• Logs and alerts. What is logged, who looks, and how fast.
• Incidents. A written plan, who runs it, and when customers are told.
• Vendors. How the vendor reviews its own vendors and subprocessors.
• AI tools. Which AI tools touch customer data, and who approved them. Our note on shadow AI covers this one.

What a review is, and what it is not

A vendor review is diligence. It helps a buyer decide whether to trust a vendor with their data. It is useful, and it is often required.

It is not an audit. A completed questionnaire is not a SOC 2 report. A policy is not a certificate. Only an independent CPA firm can issue a SOC 2 report, and only an accredited certification body can issue an ISO 27001 certificate.

That line matters for both sides. Buyers should know what they are relying on. Sellers should only claim what they can show. Grey Wing helps teams with the readiness work: the packet, the answer library, the evidence, and the turnaround. We take ownership of GRC and security questionnaires for growing SaaS. We do not audit, and we do not issue reports.

Print and reuse

Print this page and keep a copy with each review. Check the boxes as you go. Next time, start from your saved answers and evidence, not from a blank sheet. Each review should be faster than the last.

If a review is stuck in someone's inbox right now, you can tell us about it.