Picture two decisions made in the same month at the same company. A ninety-question security questionnaire goes out to a software vendor, comes back complete and signed, and gets filed. Down the hall, a marketing manager clicks Accept on a consent screen granting a new scheduling tool standing read access to every mailbox in the tenant.
Both are vendor risk decisions. Only one of them went through a process.
That gap is the whole subject. Supply-chain risk management at mid-size companies has become a documentation exercise pointed at the vendors that send invoices, while the real exposure accumulates through the vendors that send integrations. The paperwork is aimed at procurement. The risk is sitting in your identity provider.
Your vendor list and your risk list are different documents
Ask a CFO for a vendor list and you will get an accounts-payable export. It is accurate, it is complete, and it describes the wrong universe. Payables ranks vendors by spend. Risk ranks them by access.
The cleaning service is a vendor. So is the payroll platform holding every employee's banking details, the marketing automation tool mirroring your customer database, and the free browser extension four people installed to summarize PDFs. Three of those have material reach into sensitive data. Only one of them is likely to appear near the top of a spend report.
The reframe is simple, and everything downstream depends on it: a vendor's weight in your risk posture is a function of what it can reach, not what it costs. Sort that way and the list of vendors genuinely requiring review usually collapses to something a small team can work through — a fraction of the ledger, and a fraction that is knowable.
The unit of review is the connection, not the company
What changed is the shape of a vendor relationship, and it changed faster than most governance programs noticed. A decade ago, working with a software vendor meant a contract, a login, and data you deliberately uploaded. Now it means an authorization grant. The tool asks permission once, receives a token, and holds continuous programmatic access until someone revokes it. No password. No MFA prompt on each use. No expiry anyone tracks.
Those tokens are machine identities. They accumulate through ordinary enthusiasm: a pilot nobody decommissioned, an integration built by a departed employee, a meeting assistant that joins calls and retains transcripts, an AI agent authorized to read a shared mailbox so it can draft replies. Each is a durable path into your data that outlives the person who created it. A fair test of whether your program is current: could you produce that inventory this week, without guessing?
This is why cybersecurity reviews stopping at a vendor's corporate posture miss the point. The relevant question is not whether the supplier runs a competent security program. It is what a compromised credential at that supplier would reach inside your environment on a Tuesday morning. Different questions, different answers — and only the second one is under your control.
For most businesses the highest-concentration surface is Microsoft 365, because mail, files, identity and increasingly AI-assisted workflows all converge there. An enterprise application carrying broad delegated permissions in that tenant is not a peripheral integration. It is a second front door.
What a SOC 2 report can and cannot tell you
Mid-size buyers treat an attestation report as a verdict. It is closer to a photograph.
A SOC 2 Type II tells you an auditor examined a described set of controls over a defined window and reported on their operation. Genuinely useful information, and a vendor who cannot produce one is telling you something. But the report describes the vendor's internal discipline. It does not describe your exposure. Nothing in it addresses which permissions you granted, which of your users can push data into the platform, what the vendor's subprocessors do with it, or how you operate if the service is dark for a week.
Subprocessors deserve particular attention now, and this next point is analysis rather than established fact: as SaaS vendors add generative features, their data flows can change underneath contracts signed before those features existed. A tool you evaluated two years ago may route content to a model provider you never assessed. The attestation was accurate when issued. The data map moved.
Practical translation: read the subprocessor page and the change-notification clause before you read the audit report. One tells you who touches your data today. The other tells you whether you will hear about it when that list changes.
A review a company without a security team can finish
Ambitious vendor risk programs fail at this size for a predictable reason. They are designed for staff who do not exist. Anything requiring a dedicated analyst gets abandoned by month three, and an abandoned program is worse than none, because it leaves behind the belief that the work was done.
What holds up is narrower and repeatable:
- Produce the access inventory, not the vendor inventory. Pull every third-party application, OAuth grant and API integration with access to your identity platform and core data systems. Expect entries nobody can explain. That list, not the AP export, is the working document.
- Tier by blast radius. Three tiers is enough: vendors holding regulated or customer data, vendors holding internal operational data, vendors holding neither. Only the top tier gets a real review.
- Revoke by default. Any integration without a named internal owner who can state its business purpose gets disabled. Restore on request. In our experience this step removes more standing risk than a year of questionnaires.
- Ask three questions instead of ninety. How will you notify us of a breach, and within what window. Who are your subprocessors, and how do we learn when that list changes. What is your documented recovery objective if your service is unavailable. Vague answers are answers.
- Test the dependency, not the document. Take your most critical vendor and run a tabletop where it is offline for a week. Gaps surface immediately, and they are almost always operational rather than technical.
Run that quarterly. Assign it to one person with authority to disable things. Unglamorous, and it works, largely because it produces decisions rather than binders.
Assume the failure, then price it
The executive shift worth making is from prevention to consequence. Certainty about another company's internal controls is not purchasable, and pretending otherwise consumes budget you need elsewhere. What you can do is decide in advance, in writing, what each vendor's failure costs you and what you will do about it.
That is a resilience question rather than a procurement question. It connects directly to your data backup architecture, your identity controls, and whether your team can operate for a week without a system they have quietly made load-bearing. Worth checking your own cyber policy application too — whether your insurer already asks about third-party access is something you can verify without taking anyone's word for it.
Companies that handle a vendor compromise well are rarely the ones with the thickest questionnaire files. They are the ones that knew, before the notification email arrived, exactly which systems that vendor touched and how to cut it off.
Pro Link Systems has supported Los Angeles businesses from Woodland Hills since 1999. If your integration inventory is currently a guess, that is where our managed IT services work starts.
Ready to talk to a real IT engineer?
Pro Link Systems has been protecting and managing IT for Los Angeles businesses since 1999. Book a free 15-minute discovery call — no pressure, no obligation, no scripts.