Is your cybersecurity Governance, Risk & Compliance (GRC) team perceived as a source of bureaucracy and undue friction? Third Party Risk Management (TPRM) is a high visibility opportunity among GRC services to turn those perceptions and realities around.

Nowhere is that perception more deserved than in the TPRM intake form. If yours is asking for encryption details or identity provider configurations, that can cause end users' eyes to glaze over, or worse, fostering shadow IT instead of a strong cybersecurity culture.

There's a core problem with vendor due diligence as most GRC teams run it. You're collecting evidence from the person least equipped to give it. Ask them only for the business use case and the highest classification of data involved, then use this free kit to get the rest in writing from the vendor.

A SOC 2 Type II report, an executable DPA, a sub-processor list, and a written answer on whether the vendor trains on your data tell you what actually happens to that data. An intake form tells you what your colleague believes happens to your data. When those disagree, and they often do, only one of them will hold up in a breach post-mortem.

📚 Free resource: Vendor Security & Privacy Due Diligence Kit on GitHub.

Five pieces:

There's also a block of project instructions in the README you can paste into a Claude project so the kit becomes a working assistant: name a vendor, it checks the directory, re-verifies the gate, drafts the request, and updates the tracker.

Supply chain risk management is a big topic, and the whole thing hangs on NIST CSF's GV.SC-07:

Implementation example 2 under that subcategory is the one that matters here. It says to evaluate third parties' evidence of compliance: attestations, certifications, and other artifacts.

Evidence, meaning documents the vendor produced and stands behind. A colleague's recollection of a sales demo is not on that list.

Know your role in the shared responsibility model. When you use a SaaS app hosted on AWS, there are three parties with security obligations, and the contract is how you find out which ones are yours. The DPA and the SOC 2 system description are where the vendor writes that down. The intake form doesn't have a column for it.

Dr. Gerald Auger walked through a vendor questionnaire challenge on the Simply Cyber channel, and it's a good primer on what a security questionnaire is actually trying to establish.

I built on that in the Assessing Third Party Risk lesson, where the emphasis is on reasonable due diligence. You can't buy infinite security and you can't review every vendor to the same depth. What you can do is make sure the depth you apply is defensible, and the cheapest way to make it defensible is to anchor it to documents the vendor signed.

Everything in the 41-item checklist adjusts your confidence. Four items decide the outcome.

The badge on the trust center and the two-page executive summary do not count. Read the system description and confirm it covers the product you are buying, in the period you care about, with the criteria you need. Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional and frequently excluded. Then find the CUECs section. Those are the controls the auditor assumed you operate. For Salesforce, that means permissions, not handing everyone admin. For a storage service it might mean key management. The vendor can't secure what sits on your side of the line.

If the report period ended more than about 90 days ago, ask for a bridge letter. It is conditional rather than gating on its own, which is why it sits in the checklist's conditional tier, but a stale report with no bridge letter is a SOC 2 finding all the same.

No SOC 2 at all? An ISO 27001 certificate with the ISMS scope and Statement of Applicability is the accepted alternative, and it is the first Tier 2 item in the checklist for that reason. The certificate by itself only proves an ISMS exists somewhere; the SoA is where you find out which controls were excluded and whether the scope statement covers the service you are buying. GitLab's assessment template (more on that below) treats SOC 2 Type II and ISO 27001 plus SoA as interchangeable for the attestation step and only falls back to a SIG Lite or CAIQ self-attestation when a vendor has neither.

This one is new to Tier 1 and it earns the spot. Does the product include AI features at all? If it does, is any of your data, meaning prompts, uploaded files, audio, outputs, and the thumbs up and thumbs down feedback people forget about, used to train or improve a model, the vendor's or a third party's? Get the answer in writing, and get two more details with it: whether no-training is the default or something you have to configure, and which plan tiers it applies to. Record a "no AI" answer too. It is the one most likely to be wrong by the next release.

Check the breach notification clock (push for 72 hours, not "without undue delay"), the transfer mechanism, the sub-processor objection right, deletion on termination including backups, and audit rights. Know what belongs in your own information security addendum. The DPA is where you check whether the vendor already committed to most of it before you send them your paper.

Named entities, their function, the country of processing, and a way to subscribe to changes. Check specifically whether AI model providers are on it. If the vendor has an AI feature and no model provider appears on the list, either they built their own model or the list is incomplete. Ask which.

The reason the kit ships with 200 vendors is that the biggest time sink in due diligence isn't reading documents. It's finding out where the documents are and what it takes to get them.

Three things I learned researching it.

SafeBase, Vanta and Conveyor host most of it: 56 vendors on SafeBase, 33 on Vanta, 22 on Conveyor, 37 self-hosted. A portal NDA is per vendor, not per platform. Four SafeBase vendors means four separate acceptances.

Roughly two thirds publish a DPA or sub-processor list with no request at all, 126 and 130 of 200 respectively. Sweep those first. It costs nothing and it tells you exactly what to ask for in the request.

Google Cloud is the benchmark for a good gate. Sign in, accept a click-through NDA in the console, download the SOC 2 for the specific services you use. Quarterly reports with monthly bridge letters. When a vendor tells you everything has to go through a two-week email thread, you now have a comparison point. Anthropic is the other useful reference: a SOC 2 executive summary, ISO 27001 and 42001 certificates, the sub-processor list, and a DPA template, all public before you've asked for anything.

Every scope warning in the directory is one of these. They are the most common way a review that looks complete turns out to be wrong.

Per-product splits. CrowdStrike issues separate SOC 2 coverage for corporate operations, the Falcon platform, and the forensic lab. You want the platform one. Atlassian covers about 19 Cloud products in one report. The hyperscalers scope per service and per region. Always name the product in your request.

Self-hosted versus cloud. GitLab, MongoDB, Elastic, Redis, Grafana, PostHog, n8n, and others certify the hosted service only. If you run the self-managed edition, the certificate describes someone else's deployment.

Plan tier. Zero data retention, HIPAA BAAs, SSO, audit log export, data residency, and BYOK are Enterprise-only at a large share of these vendors. Notion guarantees zero retention on AI features only on Enterprise. Same badge wall on the pricing page, different product underneath. Ask which plan the review is for before you start.

The AI chain. Meeting tools send transcripts to OpenAI and Anthropic. Those run on hyperscalers. Agentic features add inference hosts. Your no-training clause with the vendor means nothing unless it flows through every hop. OpenAI's own Zero Data Retention is approval-gated, not default, and it excludes abuse-monitoring logs. The Whisper transcription endpoint is covered by the API platform's SOC 2, which answers the certification question and says nothing about how long your audio sits in a log.

The kit has a separate AI addendum template because the standard request misses what matters. For any vendor with AI functionality, get written answers to:

The first question is already Tier 1 for every vendor. The rest are Tier 2.5 in the checklist, which means treat them as Tier 1 the moment the answer to "does it have AI" is yes. An ISO 42001 certificate is a good sign; it still doesn't answer any of the five.

Most trust centers gate the full SOC 2 behind a click-through NDA. Three things to know.

The click-through binds your company, not you. Confirm you have signature authority, or route it to legal once and record the standing approval.

Log the counterparty, the date, and the expiry. Most expire at 12 months, which is also when the next SOC 2 lands, so you'll be back.

Read it before you click. I've packaged a version tuned for trust-center clickwraps as a Claude Code skill: nda_review_skill. It knows which clauses are normal in a confidentiality wrapper and hunts for the ones that aren't, especially non-compete, non-solicit, and no-publication clauses that could constrain your own internal reporting of findings.

Requirements have to be commensurate with criticality, so tier the vendor first. A tool that touches public marketing copy does not get the 41-item checklist. A tool that ingests customer PII or call audio gets the full salon treatment: all of Tier 1 and the AI addendum.

If you're building the program rather than running one review, prioritize the following:

The kit is the evidence layer for step 3. The intake form still has a job: it tells security a purchase is happening and roughly what data is involved. Nobody should expect it to tell you what the vendor does with that data, because the person filling it in has never seen the vendor's sub-processor list either.

👉 Pro Tip: A missing artifact is a finding, not a blank. Record it as a Gap. And distinguish a Gap from an N/A. Obsidian has no SOC 2 because there's no cloud backend to certify; notes are Markdown on your disk. Replicate, Midjourney, and Discord have no public security page at all, and all three process real data. Same empty cell, completely different meaning.

I've long pointed to GitLab's handbook page for third-party risk management because it's a great public example of a review process embedded in procurement. Since then their Security Risk team has published the actual issue templates they use: gitlab-security-oss/risk-mgmt/tprm-templates, under CC BY-SA 4.0. There are three.

The Intake Request is the form the stakeholder fills in: vendor, data types, integrations, new or renewal. Then a "Security Risk to Complete" block where the analyst sets data classification, inherent risk and residual risk. Notice the split. The requester supplies context. The analyst supplies the risk judgement, and the template does not pretend the requester's data-type answer is the evidence.

The Assessment Report is the write-up, and its summary of procedures is worth reading on its own. Step one is a SOC 2 Type II report or an ISO 27001 certificate with the ISMS scope and Statement of Applicability. If the vendor has neither, it falls back to a SIG Lite or CAIQ self-attestation. It asks for the reporting period, whether deficiencies were identified, and whether CUECs are defined, with a hand-off to the business owner when they are. Then a security rating, then a conclusion: controls effective or ineffective, residual risk one to four. That is the same review the checklist in this kit is built to feed, item for item.

The Security Notice is my favourite of the three. One issue per observation, with the risk, the worst-case impact, a recommendation, and a three-level risk acceptance sign-off that goes up to the executive group if needed, plus annual recertification of anything accepted. This is what "a missing artifact is a finding" turns into when a program is mature: a Gap on your tracker becomes a notice that a named person has to remediate, accept, or deny.

The README in the kit has a crosswalk table mapping each template to the checklist items that feed it. I linked rather than copied, because the templates are share-alike licensed and the kit is MIT; if you use GitLab, drop them into .gitlab/issue_templates/ as is.

TPRM Vendor Security & Privacy Due Diligence Kit is MIT licensed. Fork it, swap in your shared mailbox, and add the vendors I missed. The directory was researched on 22 August 2026, and trust centers move, so re-verify the gate before you send anything and stamp the date column when you do.

A note on sources, since this is the kind of thing I would ask a vendor about: every row and every worked finding comes from publicly accessible pages. Trust centers, security pages, published DPAs, sub-processor lists, help centre articles. Nothing in the kit quotes or summarizes a SOC 2 report or any other document that sits behind an NDA. "NDA required" means the public portal says so. It is a snapshot, not a ranking and not legal advice, and if you work at one of these vendors and a row is wrong, open an issue with the URL and I will fix it.

If you want the full supply chain module with the policy template, the security addendum, the risk record, and the Cyber Risk Management Action Plan (CR-MAP) process it sits inside, you'll find it in the Cyber Resilience Practitioner course at Simply Cyber Academy.