The Sub-Processor Problem: Every SaaS Tool Is Someone Else's Data Policy

Nearly a third of breaches in 2025 involved a third party, double the share from the year before, according to Verizon's 2025 Data Breach Investigations Report. That number is the clearest way to describe the sub-processor problem: every SaaS tool a business runs places its client data under someone else's security posture, retention rules, and vendor chain. When you sign up for an app, you inherit its vendors, and their vendors after that.

I study behavioral psychology, and I find the way we reason about vendors fascinating. We evaluate the app in front of us, the one with the clean interface and the demo, and we rarely picture the ten companies standing behind it. That gap is where the risk lives.

What is the sub-processor problem?

A sub-processor is a vendor your vendor uses to do its job. Your email tool sends through a delivery service. Your CRM stores files on a cloud provider. Your analytics vendor pipes data to a warehouse. Each of those is a hop your client data takes, under terms you never read.

The legal language is precise about this. Under GDPR Article 28, a processor must get prior written authorization before engaging a sub-processor, must bind that sub-processor to the same obligations it owes you, and remains liable for the whole chain. The law assumes the chain exists. Most inventories do not.

This is why data governance and third-party risk are the same problem wearing two names. Governance asks where your data lives and who can touch it. Third-party risk asks the same question one company removed. The honest answer usually reaches further than anyone expects, which is worth understanding before you ask what your vendors' security posture means for you.

Your data policy is only as strong as the weakest vendor

You can write an excellent privacy policy. You can encrypt everything you hold. None of it matters more than the practices of the least careful company in your chain, because your data is subject to their controls once it arrives.

The measured trend is steady. SecurityScorecard's 2025 Global Third-Party Breach Report found 35.5% of breaches in 2024 were third-party related, up from roughly 29% the year prior. IBM's Cost of a Data Breach 2023 report added that supply-chain breaches cost more and took 26 days longer to detect than the average incident, against a global average of $4.45 million.

Longer to find means longer for someone to sit inside data you handed off. The cost is not only money, it is time you never knew you were losing. Knowing which questions surface that risk early is the practical work, and it starts with what to ask your vendors about security.

You cannot audit what you have not inventoried

The reason chains stay invisible is simple: almost nobody writes them down. Ponemon Institute and RiskRecon, in their 2022 study "Data Risk in the Third-Party Ecosystem," found that 61% of organizations do not keep a comprehensive inventory of the third parties they share sensitive data with. Only 32% do.

Visibility drops sharply past that first layer. The same study reported that only 29% of organizations have any view into their Nth parties, the vendors of their vendors, and that 38% of third-party breaches were actually caused by an Nth party. Among organizations that did keep an inventory, the average count was 2,103 third parties.

The tooling problem compounds the counting problem. Productiv's 2024 State of SaaS found the average company's portfolio reached 342 apps, and roughly 48% of enterprise apps run unmanaged as shadow IT. You cannot govern a tool you do not know is running, which is the quiet argument for vendor consolidation in regulated industries. Fewer tools means a shorter chain to map.

If this feels familiar, it is the same picture I described in the piece about data living in four SaaS tools and a group chat. The sprawl is normal. The blindness to it is the risk.

Self-hosting collapses the chain

There is a structural answer to a structural problem: remove links instead of managing them. When you host your own infrastructure, the data does not hop to a vendor, whose vendor hops it again. It stays on systems you control, and the chain of external processors shrinks toward zero.

I think of this as governance by subtraction. Every hop you remove is a security review you no longer owe, a retention policy you no longer inherit, a breach surface that no longer belongs to a company you have never met. Good engineering makes systems that do not leak by default, and a shorter chain leaks in fewer places by construction.

Building this way, custom to each business and self-hosting the parts that matter most, sometimes means we grow slower and take on fewer clients than a volume shop would. That is a trade we are happy to make. Depth is the point.

This is not a call to rebuild everything overnight. It is a lens for deciding where your most sensitive data should sit. The trade-offs are real and worth reading honestly, which is why we wrote the case for self-hosted infrastructure and, just as candidly, what self-hosting actually costs.

How to think about your chain this quarter

Start with the map, not the fix. List every SaaS tool that touches client data, then ask each vendor for its sub-processor list, which most publish. The first draft of that map is usually longer than anyone on the team guessed, and that surprise is the useful part.

From there, decide by sensitivity. The data that would hurt most if it leaked deserves the shortest chain, and that often means owning the stack for that slice. We wrote more on that reasoning in what owning the stack means for client data.

The point is not paranoia. It is authorship. When you know your chain, you can choose it, and when you can choose it, your data policy stops being a document and starts being the truth. At Kief Studio we build this way on purpose, and tools like myrhc.com exist to make the mapping and assessment concrete rather than theoretical.

The through-line runs straight into what comes next for most businesses: you cannot feed AI what you cannot govern, the argument in our sibling piece on why data governance is the prerequisite for AI. And the sub-processor problem is a close cousin of the broader pattern in what supply chain attacks actually are.

Related reading

• Your Data Lives in Four SaaS Tools and a Group Chat
• The Case for Self-Hosted Infrastructure
• What to Ask Your Vendors About Security
• What Owning the Stack Means for Client Data
• Data Governance Is the Prerequisite for AI

Frequently Asked Questions

What is the sub-processor problem in plain terms?

It is the fact that every SaaS tool you use hands your data to its own vendors, and those vendors to theirs. You inherit a chain of companies you never chose, each with its own security posture and retention rules, and your data policy is only as strong as the weakest link in it.

What is an Nth party?

An Nth party is a vendor's vendor, one or more hops removed from you. The Ponemon Institute and RiskRecon 2022 study found that 38% of third-party breaches were actually caused by an Nth party, yet only 29% of organizations have any visibility into that layer.

Does GDPR address sub-processors?

Yes. GDPR Article 28 requires a processor to obtain prior written authorization before engaging a sub-processor, to bind it to the same data obligations, and to remain liable for the chain. The law assumes the chain exists, which is a strong hint that yours does too.

How does self-hosting help with the sub-processor problem?

Self-hosting removes external hops rather than managing them. When data stays on infrastructure you control, the chain of outside processors shrinks toward zero, so there are fewer companies whose practices your data depends on. We call it governance by subtraction.

Where should I start if I have never mapped my chain?

Inventory every tool that touches client data, then request each vendor's published sub-processor list. You cannot audit what you have not inventoried, and the first honest map almost always reveals more vendors than the team expected.