When we ask a client how many vendors have access to their systems or data, the first answer is usually a number between five and fifteen.
The real number is almost always higher. Sometimes by a lot.
That gap is the whole problem. Third party risk is not hard to understand and it is not expensive to reduce. It is just difficult to manage something you have not finished listing, and most organizations have not.
The list is longer than you think
The first ten vendors come to mind easily. The managed service provider, the cloud platform, the core business application.
The rest surface slowly. The payroll processor. The document signing service. The marketing platform holding customer contact data. The analytics script running on every page of your website. The contractor who still has remote access from a project two years ago. The billing system a single department bought on a credit card.
Then there is the layer behind that. Your vendors have vendors. The platform you rely on may run on infrastructure you have never evaluated, with subprocessors you have never been told about. That is real exposure and it rarely appears on anyone’s list.
Building the list is genuinely the hardest part, and it is not a security exercise. Accounts payable usually knows more than IT does, because everything eventually gets paid for.
Access is broader than assumed
Once the list exists, the next question is what each vendor can actually reach.
The answer is often more than intended. Access granted for an implementation and never reduced afterward. Administrative rights where read only would have been enough. A support account created for a specific incident that is still active. Integrations authorized with broad permissions because narrowing them would have required more configuration than anyone had time for.
It is worth reviewing this against a simple standard. What does this vendor need to do their job today, and does their access match that? Not what they needed at onboarding. Today.
A questionnaire is not an assessment
Most vendor risk programs run on questionnaires, and questionnaires have a specific weakness. They collect what a vendor says about itself, usually completed by someone in sales, often reused unchanged across dozens of clients.
That is not worthless. It creates a record and it occasionally surfaces something useful. But it should not be confused with knowing whether a vendor is secure.
For the vendors that matter most, ask for evidence instead. A current independent audit report. Recent penetration test results, even summarized. Their incident notification commitment in writing. How they handle subprocessors.
Which raises the point most programs get wrong. Vendors should not all receive the same scrutiny. A vendor holding your customer data with administrative access deserves a different level of attention than the company that services the coffee machine. Tiering by actual exposure is what makes this manageable.
Concentration risk
This one is less discussed and more consequential.
Organizations that have carefully avoided single points of failure internally often discover their vendors share one. Three supposedly independent systems running in the same cloud region. Two providers relying on the same underlying platform. A continuity plan that fails over to a service dependent on the thing that just went down.
You do not need to eliminate concentration, which is usually impractical. You need to know where it exists, so that when it fails you are executing a decision you already made rather than discovering the dependency during the outage.
What happens when a vendor fails
Most contracts are reviewed for price, term, and liability. Fewer are reviewed for what happens during an incident.
Worth checking in the agreements that matter. How quickly must they notify you of a breach affecting your data. What are their committed recovery objectives, and do those match what your own plan assumes. Can you get your data out, in a usable format, if you leave or they fail. Who is liable, and is that limit meaningful relative to the actual exposure.
These questions are far easier to negotiate at renewal than during an incident.
Where to start
This work expands to fill whatever time you give it, so the sequence matters more than completeness.
- Build the list, using accounts payable rather than memory.
- Tier it by what each vendor can reach, not by what you spend with them.
- Review access for the top tier against what they need today.
- Ask the top tier for evidence rather than assurances.
- Map where concentration exists and decide in advance what you would do.
Most organizations get meaningful risk reduction from the first three, and most have not completed the first.
We help organizations build the list, tier it, and work through the top tier. It takes less time than most people expect. Reach out and we will walk you through what it involves.
https://systemcustom.com/about-us/
