Third-party risk management for small businesses: a programme without a GRC team

Third-party risk management, as usually described, is a discipline for banks. It has committees, inherent-risk questionnaires, residual-risk heat maps, and a tooling budget. A forty-person company has none of those and the same obligations: a SOC 2 auditor sampling its vendor reviews, a customer’s security team asking for its TPRM policy, a regulator that holds it responsible for its processors.

This guide describes a programme for that company. It keeps everything the frameworks actually require and drops everything that only exists because a large organisation has to coordinate across departments. It is designed to be run by one person with a few hours a month once it is set up.

What enterprise TPRM gets wrong for small teams

Enterprise programmes optimise for scale and separation of duties. Neither is your problem. Three patterns in particular fail when copied into a small company:

• Inherent-risk questionnaires before every assessment. A twelve-question form to decide how long the next form should be makes sense at ten thousand vendors. At forty, the person running the programme already knows which five matter.
• Assessments generated from scratch. Large buyers can make vendors complete bespoke 300-question forms. Small buyers cannot, and should not try: accept the vendor’s existing SOC 2 report or standard questionnaire and ask only for what it leaves out.
• Governance by committee. A vendor risk committee that meets quarterly is a mechanism for spreading accountability across a large organisation. In a small one it spreads it thin. One owner, one approver for exceptions, and a written policy do the same job.

What a small programme still must not skip

Simplifying is not the same as omitting. Every framework that touches third parties expects the same five things, and an auditor will look for each.

The programme, in five parts

1. A one-page policy

Write down: who owns third-party risk; the four tiers and the criteria for each; what assessment, evidence and contract terms each tier requires; the reassessment cadence per tier; the events that trigger an early review; and who may accept a risk outside policy. Have it approved by whoever runs the company and date it. One page is enough; auditors test whether you follow the policy, not how long it is.

2. An inventory with owners

Build the register from accounts payable, expense reports, the SSO application list and a conversation with every team lead. Reconcile it against those sources quarterly, because the vendor you did not know about is the one that fails the audit. Each vendor gets one internal owner — the person who would notice if the service changed — and that owner is the person the reminder goes to.

3. Tiering that does the prioritising for you

Three questions assign a tier: what data and access does the vendor have; how badly would an outage hurt; how hard would they be to replace. Critical vendors get the full assessment annually. Low-tier vendors get a contract check and nothing else. The point is that the programme’s effort goes to a handful of vendors and stays there. Vendor risk tiering: how to classify third parties and set a review cadence gives the criteria and the cadence.

4. Assessment that reuses what the vendor already has

For each critical and high-tier vendor, ask first for what they already produce: SOC 2 Type II report, ISO 27001 certificate and statement of applicability, penetration test summary, standard questionnaire (SIG, CAIQ), data processing agreement. Review those, then send a short questionnaire covering only the gaps. Score it with a fixed method, record the decision, set conditions where needed. Vendor due diligence: a practical guide for small and mid-sized businesses walks through the steps and Vendor risk assessment questionnaire: what to ask, and how to score the answers the questions and scoring.

5. Monitoring that runs on reminders, not memory

Between reviews, four things should move a review forward: a certificate or report expiring, a breach notification, a change of ownership or sub-processors, and a material change in what you share with the vendor. The reassessment date is set when the current review closes and lands in someone’s calendar. If that reminder depends on a person remembering, the programme has a single point of failure — automate it.

Reporting: what to show, and to whom

Three audiences ask about the programme, and they want different things from the same records.

• Leadership wants a one-screen view: how many vendors, how many in each tier, how many overdue for review, how many accepted with open conditions. Quarterly is plenty.
• Auditors want the population and a sample: the inventory, the policy, and for each sampled vendor the assessment, evidence, decision and contract. They will check dates against the policy’s cadence.
• Customers doing their own due diligence on you want to know the programme exists and is followed: the policy, a description of the process, and the statement that critical vendors are assessed annually. They rarely need vendor names.

Keeping the records in one place with their history intact means each of those is a filter on the same data rather than a separate exercise.

A first-year plan

1. Month 1: policy approved; inventory built and owners assigned; tiers set.
2. Months 2–3: critical and high-tier vendors assessed, contracts checked, decisions recorded; gaps given remediation dates.
3. Month 4: medium-tier vendors sent the short questionnaire; low-tier contract checks done.
4. Quarterly: inventory reconciled against AP, expenses and SSO; overdue reviews and open conditions reported to leadership.
5. Month 12: first reassessment cycle for critical vendors; policy reviewed and re-approved.

At the end of that year the programme has everything an auditor needs and has cost the company a few weeks of one person’s time. The following years cost less, because the vendor evidence renews on its own schedule and the records already exist.

Where to go next

For the assessment step in detail, Vendor due diligence: a practical guide for small and mid-sized businesses. For the checks to run before a new vendor is signed, Vendor onboarding checklist: the checks to finish before the contract is signed. If a particular audit is driving the work, SOC 2 vendor management: what auditors expect from your third-party programme and ISO 27001 supplier relationships: meeting Annex A 5.19–5.23 with evidence describe what each one samples.