§ CAPABILITY

Third-Party Risk Management and Vendor Review

Both directions of the same problem: assessing the vendors you depend on, and answering the questionnaires your own enterprise buyers send. One evidence base serves both.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call How the work runs

What you're seeing

A customer asked for the list of subprocessors and it had to be reconstructed.
Usually means There is no vendor inventory. Reconstructing one under a deal deadline is how tools nobody remembers approving get discovered, usually with customer data in them.
The same engineer answers every security questionnaire, from memory.
Usually means There is no response library, so the cost recurs in full each time and the answers drift between submissions. Two customers comparing notes will find they were told different things.
Vendor assessments exist as a folder of PDFs somebody filed.
Usually means Assessment happened once at procurement and nothing has been reviewed since. Certificates expire, ownership changes, and none of that triggers anything.
A design tool and a payment processor were assessed with the same questionnaire.
Usually means There is no tiering, so effort is spread evenly across risk that is not evenly distributed. Programmes run this way stop being run within two quarters, and the critical vendors go unreviewed alongside the trivial ones.

Two directions, one evidence base

Assessing your suppliers and answering your buyers are the same information viewed from either side of the table.

The controls a customer asks you to demonstrate are the controls you ask of a processor holding your data. The certificate you send is the certificate you request. The subprocessor list you publish is the vendor inventory you maintain.

Teams build these separately, because they arrive from different directions — one from compliance, one from sales — and then maintain both badly. The divergence shows up in public: a control described one way in a questionnaire answer and another way in an internal register, discovered by an auditor or, worse, by a customer comparing two documents.

Building one evidence base and serving both directions from it is more coordination up front and considerably less work every quarter after.

Tier or it collapses

The single decision that determines whether this programme exists in two years is the tiering.

Vendors do not carry equal risk and cannot absorb equal effort. A payment processor and an identity provider justify a real review — the certificate read rather than filed, the subprocessor chain followed, the incident history checked. A design tool with no customer data in it justifies a line in the inventory and an owner.

Programmes that refuse to make that distinction do not become more thorough. They become unrunnable, and then they stop, and the payment processor goes unreviewed alongside the design tool. Uniform depth is the enemy of the depth that matters.

The response library

The outbound half pays for itself fastest.

A maintained set of answers to the questions buyers actually ask, each linked to the evidence behind it, turns a week of a senior engineer’s time into an hour of review. It also makes the answers consistent, which matters more than it sounds: two customers comparing notes should not find they were told different things about the same control.

It has to be maintained rather than written once. An answer that was true at the last audit and is not true now is a commitment you have made to a customer in writing, which is a considerably worse position than not having answered.

Where it sits

This is a capability inside SOC 2 Readiness, where vendor management is a control set an auditor will sample, and where the questionnaire loop is frequently what caused the certification to be needed in the first place.

It shares its evidence pipeline with Compliance Automation — vendor records, certificate expiry and review dates belong in the same continuous collection as everything else — and it sits next to Security Audit, which assesses your own posture with the same questions you are asking of others.

How the work runs

  1. Inventory and tier the vendors

    Every third party touching customer data or production, tiered by what an incident there would cost you. Uniform assessment wastes effort on low-risk tools.

  2. Set assessment depth by tier

    A critical processor gets a real review; a design tool with no customer data does not. The tiering is what makes the programme sustainable.

  3. Build the response library

    Your own answers to the questionnaires buyers send, maintained and evidenced, so the same engineer is not writing them from memory each time.

  4. Put it on a cycle

    Reassessment triggered by time and by change, with contract dates and certificate expiries tracked in one place.

What arrives

  • A vendor inventory tiered by risk with named owners
  • An assessment standard per tier
  • A maintained questionnaire response library with evidence links
  • A review calendar tracking reassessments and certificate expiry

What it costs your team

An initial inventory session, then roughly two hours a month once running.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Vendors are tiered before any of them are assessed

    Costs Tiering is a judgement call that has to be defended, and some vendor owners will disagree with where theirs landed.

    A programme that assesses a design tool as thoroughly as a payment processor is not thorough, it is unsustainable — and when it collapses, it stops covering the payment processor too. Tiering by what an incident at that vendor would actually cost is what makes the depth affordable where it matters.

  • The inbound and outbound sides share one evidence base

    Costs It requires the security and sales sides of the organisation to agree on a single source, which is more coordination than either would choose.

    Assessing suppliers and answering buyers are the same information seen from two directions. Teams build them separately and maintain both badly, and the divergence surfaces publicly — a control described one way in a customer questionnaire and another way in an internal register is an audit finding and a sales problem at once.

  • Reassessment triggers on change, not only on time

    Costs Change triggers require somebody to be watching for them, which annual review does not.

    An annual cycle means a vendor breached in month two is reviewed in month twelve. Time is a weak trigger on its own. Ownership changes, breach disclosures and certificate expiry are the events that actually alter risk, and tracking them is a calendar and a few alerts rather than a programme.

Frequently Asked Questions

Knowing which external parties can affect your security, assessing them in proportion to what an incident there would cost you, and keeping that current as they and you change. Auditors ask for it because a large share of breaches arrive through a supplier rather than through the front door.
No, and attempting it is why these programmes collapse. Tier by impact: a processor holding customer data gets a real review, a design tool with none does not. The tiering is the part that makes the programme survive its second year.
We build the library and the evidence behind it so your team answers in an hour rather than a week. The answers themselves have to be yours — they are commitments about your systems, made to a customer, and a supplier cannot make them on your behalf.
Critical vendors annually, and any vendor on a trigger: a disclosed breach, a change of ownership, an expired certificate, or a material change in what data they hold. Time alone is a weak signal, which is why the change triggers are tracked as well as the calendar.
A third party that processes your customers' data on your behalf — your cloud provider, your email service, your analytics. Customers ask because your obligations to them flow down to anyone you pass their data to, and enterprise contracts increasingly require the list to be published and notified on change.

Sources

Page reviewed