Third-Party Risk: Your Security Is Your Suppliers' Security
A growing share of breaches now originate through a vendor rather than a direct attack. Your own security controls can be excellent and still not protect you, if the weakest link is a supplier you never properly vetted.
You can build excellent internal security controls and still suffer a serious breach — through a vendor, contractor or supply chain relationship you never adequately vetted. This is a companion piece to our guide on data security for enterprise software projects.
Why this risk keeps growing
Modern organisations depend on a growing web of third-party software, cloud services, AI vendors and contractors, each with access to some slice of the organisation's data or systems. Every one of those relationships is a potential entry point that exists outside the organisation's direct control — and the more vendors an organisation adds, the larger this collective surface becomes, often without anyone tracking the aggregate exposure.
IBM's Cost of a Data Breach research puts the global average cost of a breach at $4.99 million. (IBM) A breach originating through a third party carries the same financial consequence as one originating internally — the source does not soften the impact, and in some cases makes the incident harder to detect and contain because it is happening in systems the affected organisation does not directly monitor.
The specific ways third-party risk materialises
Direct access to your systems or data. A vendor with legitimate access — a support tool, an analytics platform, an AI service processing your data — is a channel an attacker can compromise once, rather than needing to breach your own defences directly.
Sub-processor chains you may not have visibility into. Your vendor may use their own vendors, each potentially handling a piece of your data. Contract language alone does not guarantee you know the full chain unless you actively ask.
Software supply chain dependencies. Every open-source library and third-party component in your codebase is a dependency whose security is now partially your responsibility, whether or not you wrote it or actively maintain it.
Credential and access sprawl. Vendors often receive broader access than they strictly need, because scoping access precisely takes more upfront work than granting a convenient, over-broad permission. That convenience becomes exposure the moment the vendor's own security is compromised.
Building vendor due diligence into procurement, not after a problem
Ask for security documentation before selection, not after signing. A SOC 2 report, a security questionnaire response, or a description of their own sub-processor chain should inform vendor selection, not arrive as an afterthought once the relationship is already committed. Our dedicated piece on what SOC 2 actually proves covers how to read what you receive.
Scope access to the minimum the vendor actually needs. Resist the convenient over-broad grant. A vendor with access only to what their function genuinely requires limits your exposure if that vendor is compromised.
Map your full vendor and sub-processor chain, and revisit it periodically. Vendors add new sub-processors over time, sometimes without prominent notice. A map built once at onboarding and never revisited will drift out of date.
Include security obligations and audit rights in the contract, not as an assumption. The right to ask for evidence of ongoing compliance, and a defined process for what happens in the event of a breach on the vendor's side, both belong in the contract rather than in an unstated expectation.
Apply the same due diligence to AI vendors specifically. AI systems often introduce additional sub-processor layers — the underlying model provider, in particular — that a standard vendor security questionnaire may not surface. Our companion piece on questions to ask any AI vendor covers this in detail.
Why this belongs at the procurement stage, not the security team's backlog
By the time a security team is asked to assess a vendor that is already integrated into daily operations, the organisation's actual leverage to demand changes — or to walk away — has largely evaporated. The point of maximum leverage is before the contract is signed, which means vendor security review needs to be a procurement gate, not a security team's post-hoc audit of decisions already made.
What we do
We build vendor and sub-processor mapping into every project's security review, and we treat a client's third-party exposure as part of the system we are responsible for, not a boundary where our accountability ends. If you want your vendor and supply chain risk assessed properly, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source.