Safeguard
Compliance•

Vendor onboarding security checklist: what to ask and verify

A one page checklist for onboarding a new vendor: scope the data, ask for evidence, check access and exit terms, and set a review date before you sign.

Safeguard Security Team
3 min read

Before you onboard a vendor, define what data and access they will have, ask for evidence proportionate to that risk, verify the answers that matter, agree breach notice and exit terms, and set a review date. A one page record per vendor is enough for most small teams.

Step 1: scope the relationship

Write down, in plain words:

  • What the vendor will do for you.
  • What data they will see: none, business data, personal data, credentials, source code.
  • What access they will hold: an API key, a login, a network connection, an agent on your machines.
  • Which business owner is accountable.

This scoping decides how much diligence you need. A design tool that sees public marketing files is not a payment processor.

Step 2: ask for evidence in proportion

For low risk vendors, a short questionnaire and public documentation may be enough. For higher risk, ask for:

  • A recent independent audit report or equivalent, and read the scope, not just the cover page.
  • Their policy on incident notice and the typical time frame.
  • Where data is stored and processed, and who their own sub processors are.
  • How they handle your data at the end of the contract.
  • Their vulnerability reporting process.

A report that exists but covers a different product or a different region than you are buying does not help you. Check that the scope matches.

Step 3: verify what you can

Do not rely only on answers.

  • Single sign on and multi factor authentication available and enabled for your account.
  • Role based permissions that let you give your own staff least access.
  • Audit logs you can export.
  • The access you grant them is scoped: a read only key, a limited folder, a dedicated service account.
  • Where they connect into your systems, they connect through something you can revoke in one step.

Step 4: contract points to settle

Breach notification timing, data return and deletion at exit, a right to receive audit evidence annually, liability for data incidents, and a requirement to tell you about material changes to sub processors. Ask your legal advisor for the exact wording. This post is a checklist, not legal advice.

Step 5: record and schedule

Add the vendor to a register with owner, data class, access type, evidence reviewed and next review date. Review annually for higher risk vendors, and on any incident or ownership change.

Safeguard has vendor and trust tooling for keeping this register and collecting evidence, though a spreadsheet works to start.

One practical habit: send the same short questionnaire to every vendor in a tier, so you can compare answers side by side. Keep a library of past answers from vendors, and reuse what is still current. Treat unanswered questions as information. A vendor that cannot say where your data is stored, or who can access it, has told you something useful before you have signed.

Quick check

Do all vendors need the full process?

No. Tier them by data and access, and keep the heavy review for those with sensitive data or deep access.

What is the most common miss?

Not recording the exit plan. Teams often discover at renewal that they cannot easily get their data out.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.