Vendor and Third-Party Risk Management for Startups

Vendor risk management is the practice of knowing which third parties can reach your data, deciding how much assurance each one needs, and keeping that judgement current. You inherit your suppliers' security posture whether you assess it or not — the only variable is whether you find out on your own schedule or during an incident.

For a startup running on thirty SaaS tools and one cloud provider, this can sound like a programme you don't have the headcount for. It isn't. The workable version is a single register, three tiers, and an annual pass.

Where the Frameworks Put This

ISO 27001 spreads supplier requirements across five Annex A controls, which is why the topic feels bigger than it is:

• A.5.19 — Information security in supplier relationships. Define and apply processes to manage the risks of using suppliers.
• A.5.20 — Addressing information security within supplier agreements. The security requirements go in the contract, not just the assessment.
• A.5.21 — Managing information security in the ICT supply chain. Your suppliers have suppliers.
• A.5.22 — Monitoring, review and change management of supplier services. Assurance is not a one-time event.
• A.5.23 — Information security for use of cloud services. New in the 2022 revision, and the one most relevant to a cloud-native startup — see the 2013 to 2022 control mapping for how the Annex A structure changed.

SOC 2 handles the same ground under Common Criteria CC9, which addresses risk mitigation including vendor and business-partner risk. In practice, one process satisfies both. Operationally, supplier management is part of Clause 8 operation — it's a process you run, not a document you file.

Step 1: Build the Register From Billing, Not From Memory

The vendor register is the foundation, and the fastest honest way to build it is to export twelve months of card and invoice transactions from finance. Memory produces a list of the tools you like; billing produces the list of tools you have — including the ones a single team adopted without telling anyone.

Cross-check that against your SSO application list and your cloud provider's marketplace subscriptions. Anything that appears in billing but not in the register is either shadow IT to bring under management or a subscription to cancel, and both outcomes are useful.

Minimum fields per vendor: name, service provided, internal owner, what data it touches, whether it holds personal data, tier, assurance evidence held and its date, contract renewal date, and last review date.

Step 2: Tier by What They Can Actually Reach

Tiering by spend is the common mistake. A $30-a-month tool with production database access is a bigger risk than a $50,000 recruiting platform. Tier by access instead:

Three tiers is enough. Five-tier models look rigorous and, in a ten-person company, mostly generate arguments about whether something is a 3 or a 4.

Step 3: Ask for Evidence That Means Something

For Tier 1 vendors, the request is straightforward: their most recent SOC 2 Type II report or ISO 27001 certificate with the Statement of Applicability, plus a DPA and subprocessor list if personal data is involved.

What matters is what you do next. Collecting a report and filing it unread is a control that exists on paper only — and it is exactly what auditors probe when they ask how you assessed a supplier. When a report arrives, at minimum check the report period covers the time you actually relied on the vendor, the scope covers the service you use rather than a different product line, the opinion is unqualified, and any exceptions noted are ones you can live with. Then read the complementary user entity controls, which are the things you must do for the vendor's controls to work — this is the section customers most often skip. Our guide to reading a vendor's SOC 2 report walks the whole document.

Record a short written conclusion for each Tier 1 vendor: what you reviewed, what you found, what you accepted. Two sentences is enough. Without it, you have a filing cabinet rather than an assessment.

Step 4: Put the Requirements in the Agreement

A.5.20 exists because an assessment without contractual backing gives you nothing to enforce. For Tier 1 vendors, the terms worth having in writing are breach notification with a defined timeframe, a right to receive updated assurance reports, subprocessor change notification, data return and deletion on termination, and confidentiality obligations.

Realistically, a five-person startup will not negotiate bespoke terms with a hyperscaler — you accept the standard DPA and note that acceptance in the register. That is a legitimate outcome, and documenting the decision is what distinguishes an accepted risk from an overlooked one.

Step 5: Watch the Subprocessor Chain

Your vendors have vendors, and their changes become your changes. A.5.21 is about exactly this. Practical version for a small team: subscribe to the subprocessor-change notifications your Tier 1 vendors offer, and note in the register where a vendor's own critical dependencies overlap with yours.

That overlap is worth an explicit look. If your hosting, your monitoring, and your email delivery all ultimately rest on the same cloud provider in the same region, you have concentration risk that none of the individual assessments will surface — and it belongs as an entry in your risk register, not just in your vendor list.

Step 6: Re-Check Annually, and on Change

A.5.22 asks for monitoring and review over time, because assurance decays. SOC 2 reports cover a fixed period and go stale; certificates expire; vendors get acquired; products change architecture.

An annual pass over Tier 1 and Tier 2 vendors is a reasonable baseline, with event-driven reviews when a vendor is acquired, suffers a publicly disclosed breach, materially changes its subprocessors, or when your own use of it expands into more sensitive data. Fold the pass into the same calendar as your other periodic checks — see the year-round monitoring checklist.

Offboarding deserves the same discipline as onboarding: when you stop using a vendor, confirm data deletion, revoke API keys and integrations, and close the register entry with a date. Dormant integrations with live credentials are a recurring audit finding and a genuine risk.

The Takeaway

Build the register from billing so it's honest, tier by access rather than by spend, ask Tier 1 vendors for real assurance and actually read it, get the security terms into the agreement, and re-check once a year. That is a vendor risk programme a small team can genuinely run — and it satisfies both A.5.19–A.5.23 and CC9 without a dedicated hire.

Next: how to read a vendor's SOC 2 report, when your own SOC 2 becomes worth it now that you're on the other side of these questionnaires, or see how vendor assessment in AuditBadger keeps the register, the evidence, and the review dates in one place.