spot -suite
English
Start a 30-day trial

· Yair Knijn

The fourth-party concentration risk nobody mapped until the subprocessor went down

The head of procurement keeps a vendor register that is honest about everything it can see. Every direct supplier has a contract, a risk tier, a renewal date, an owner. The dangerous assumption baked into it is that the suppliers on the list are independent of each other. Different names, different logos, different invoices, so they get treated as different bets. They are not. The independence is in the contracts, not in the infrastructure.

That assumption breaks the morning a subprocessor you never put in your register has a bad day and four of your "diversified" critical vendors go dark inside the same hour. The ticketing tool, the e-signature provider, the payroll platform, and the identity broker were all standing on the same fourth party. You diversified at the layer you could see and concentrated at the layer you could not.

Why DORA Article 30 made subcontracting chains a board concern

DORA's third-party rules came into application in January 2025, and Article 30 ends the fiction that your duty stops at the direct contract. For any arrangement supporting a critical or important function, you have to know which subcontractors deliver material parts of the service, assess whether a subcontractor's failure degrades that function, and capture those chains in your Register of Information. That register is not a binder. A competent authority can ask for it, current and complete, and you produce it.

What makes this a board concern is concentration. The regulation expects you to notice when the same subcontractor sits underneath several of your critical providers, because that is the dependency that takes four vendors down at once. You cannot answer that from contracts that each describe one supplier in isolation.

The hidden shared dependency: same cloud, same region, same IdP

Concentration almost never announces itself. It hides in three places questionnaires rarely surface honestly:

Mapping fourth parties from your own estate, not vendor questionnaires

The instinct is to mail every vendor a subprocessor questionnaire and tabulate the answers. Do that, but do not trust it as your map. Questionnaires are self-reported, lag reality by quarters, and go stale the moment a vendor re-platforms. The more reliable signal is already inside your walls: the DNS your tools resolve to, the OAuth consent grants in your tenant, the ASNs your traffic hits, the status pages that light up together. Build the map from the observed behaviour of your estate, then reconcile it against what vendors claim. Where the two disagree, the disagreement is the finding.

Building an exit and substitutability plan for a concentrated supplier

Once you can see the concentration, Article 30's exit and substitutability expectations stop being abstract. For each cluster of critical vendors sharing a fourth party, the real question is not "can we leave vendor A" but "if the shared subprocessor fails, which functions degrade together, and what is the manual fallback for the whole cluster." An exit plan that assumes one vendor at a time is fiction when the failure domain is shared. Test the cluster failure, and write down the substitute you would actually reach for.

That work needs one place where every critical vendor, its tier, its observed dependencies, and its exit plan hang off the same record, so the concentration question is a query and not a fire-drill spreadsheet the night before. In Spot Suite, each supplier and the function it supports lives in a Customer Environment alongside the identity and audit trail it touches, so a fourth-party cluster is something you see before the outage rather than reconstruct after it. Our security page lays out how the estate is structured underneath.