Almost every company we work with has a vendor spreadsheet. Far fewer have a vendor management program, and the difference shows up quickly under testing. The spreadsheet lists the vendors someone remembered. The program can answer why that list is complete, why each vendor sits in the tier it sits in, and what was actually done about the ones that matter.
Auditors are not evaluating your document. They are evaluating whether you have identified the third parties that can affect the commitments you make to your customers, and whether the diligence you applied was proportionate to the risk each one carries.
What the auditor is actually testing
Three things, roughly.
Identification. Do you know who your third parties are, including the ones nobody signed a contract for?
Assessment. Did you evaluate them before they got access, at a depth that matches what they can do to your data or your availability?
Ongoing oversight. Did anything happen after onboarding — a periodic review, a look at their latest report, a response when something changed?
There is also a distinction worth getting right early. Some vendors are ordinary suppliers. Others are subservice organizations: providers performing functions that are necessary for you to meet your own criteria, such as your cloud hosting provider or a payment processor embedded in your service. Subservice organizations get separate treatment in a SOC report — you either carve them out and rely on complementary controls, or include them in scope. Confusing the two categories is a common structural problem, because a carved-out subservice organization creates obligations for you that a normal vendor does not.
Completeness of the inventory is the first real test
The auditor’s question will be some version of “how do you know this list is every vendor?” A list you maintain by hand cannot answer that about itself, so answer it with reconciliation against sources that were created for other reasons:
- Accounts payable and corporate card statements — anything you pay is on this list
- The application catalogue in your identity provider — anything anyone signs into
- Cloud provider bills and marketplace subscriptions — including the small add-ons
- Your published subprocessor list — which should match reality in both directions
- Integration and API key inventories — the tools with access but no invoice
That last one is where the gaps live. The analytics tool on a free tier, the AI service someone connected to a repository, the monitoring agent installed during a trial that never got removed — none of them appear in AP, and all of them may hold data. Run the reconciliation once and you will find something.
The reason completeness matters here is the same as everywhere else in an audit: the auditor samples from the population you provide. If the risky vendor is not in the population, the sample cannot reach it, and the testing tells nobody anything. A clean sample from an incomplete list is worse than useless, because it looks like assurance.
Tiering, and why it is the part that saves you work
You cannot apply deep diligence to two hundred vendors, and you should not try. Tiering is what makes the program survivable, but it only works if the criteria are written down and applied consistently.
Practical criteria that hold up:
- Does the vendor store, process or transmit customer data, personal data, or protected health information?
- Does the vendor have access to your production environment or source code?
- Would an outage at this vendor cause an outage or material degradation for your customers?
- How quickly could you replace them?
A vendor that hits none of those is low tier and reasonably gets an inventory entry and a renewal-time check. A vendor that hits two or more gets the full treatment. Write the criteria into your policy, apply them at onboarding, and record the resulting tier on the inventory entry. An auditor testing tiering will pick a vendor and ask why it sits where it sits; “judgment” is a weaker answer than a criterion someone applied.
What real due diligence evidence looks like
For high-tier vendors, the artifact that matters most is a record that someone read and reached a conclusion. Having a SOC 2 report on file is not diligence. A short memo saying what you found in it is.
That memo should note:
- The period covered and whether it leaves a gap against your own audit period — if it does, you need a bridge letter or an explanation
- The opinion — unqualified or qualified, and if qualified, whether the qualification touches anything you rely on
- Exceptions in the testing section and whether they matter to your use of the service
- The complementary user entity controls listed in the report, and which of them you are responsible for implementing
- The scope — which systems and services the report actually covers, since it is frequently narrower than the vendor’s full product line
The CUEC point is the one most programs skip entirely and the one most likely to be probed, because a carved-out subservice organization’s report explicitly hands you a list of controls you must run. Reading the list and doing nothing with it is a control failure of your own making.
For lower tiers, proportionate evidence is fine: a completed questionnaire, a certificate with its scope statement checked, contract terms covering security obligations, breach notification and data handling. Where protected health information is involved, a business associate agreement is a separate requirement with its own specifics that depend on your arrangements, and it is worth confirming those with counsel rather than assuming a standard template covers them.
The failure modes
Onboarding with no gate. Anyone can sign up for anything with a company card, so the inventory is permanently behind reality.
Diligence with no artifact. Someone genuinely evaluated the vendor, in a meeting, and nothing was written down. Under testing, that is indistinguishable from having done nothing.
Reports that expired mid-period. The vendor’s SOC 2 covered a period ending eight months before yours ended, and nobody chased the new one.
Reviews that never happened. The policy commits to annual review of critical vendors and the evidence shows one review in year one and nothing since.
No offboarding. The vendor relationship ended, and there is no record that data was returned or deleted and access revoked. Auditors ask about terminated vendors, not just new ones.
Subprocessor list drift. Your public list says one thing, your inventory says another, and a customer’s security team will eventually notice the difference.
Making the evidence a by-product
The mechanism that works is a gate at the point of purchase. No new vendor gets a contract signed or a card charged without a ticket, and the ticket is the evidence: what the vendor does, what data it touches, the tier that results, the diligence artifacts attached, and the approval. Finance can enforce it more effectively than security can, because finance controls payment.
Then drive the recurring work off dates you already track. Contract renewal dates make natural review triggers, because someone is already thinking about the vendor that week. Assign a named business owner per vendor rather than routing everything to one person who becomes the bottleneck and the single point of failure.
Set a small number of off-cycle triggers too: the vendor discloses a breach, changes ownership, materially changes its subprocessors, or receives a qualified opinion. Write them down, because an auditor will ask what would cause you to review a vendor outside the annual cycle.
Finally, keep the inventory somewhere queryable rather than in a document. You will need to filter it by tier and by data type more often than you expect, including every time a customer sends you a security questionnaire.
What to do next
Export last quarter’s card and AP transactions and compare them against your vendor inventory. The vendors that appear in one and not the other are your actual starting point, and the exercise usually takes under an hour.
Then pick your two most critical providers, open their latest reports, and find the complementary user entity controls section. If you cannot say which of those controls you have implemented, that is the first gap to close.
Assurion performs SOC 1, SOC 2 and ISO 27001 examinations and can tell you during readiness which of your providers your report will need to treat as subservice organizations.