For third-party and supply chain risk managers
The two things that make a list of parties useful are the notice period attached to changing it and whether it stops at the layer that would actually cause your incident. Both are stated here before contracting, alongside the arrangement that removes parties from the chain entirely by putting the credential back in your hands.
A register lists the suppliers your supplier uses. It rarely lists the suppliers those suppliers use, and the incidents that reach the news are disproportionately caused at that lower layer — a file transfer product, a support desk platform, an analytics library, a payment intermediary. The organisation writing the notification is four contracts away from the party that failed.
Notice is the mechanism that determines whether the register is a living document or an artefact from a signing date. A supplier who may add a party and inform you afterwards has given you a list, not a control. A supplier who commits to notice before a change, with a window in which you may object, has given you something you can actually operate. Almost nobody reads that clause with the attention it deserves.
Concentration is the risk nobody owns. Twenty suppliers, each with a short and reasonable register, and every one of them resting on the same two infrastructure providers and the same identity platform. Each supplier assessment passes. The aggregate exposure is invisible because no single assessment is scoped to see it, and it becomes visible on a day when everybody is affected at once.
And the practical burden is unglamorous: keeping the register current across a large supplier estate, chasing updates that arrive as marketing emails, and being asked in an audit to demonstrate that you knew about a change you were told about in a footer link. The work is real, it is nobody’s favourite, and it is the work an examiner samples.
Underneath it sits a question about direction. Every party a supplier interposes between you and a service is a party you did not choose, cannot instruct, and will not be able to reach during an incident. The chain grows because it is convenient for the supplier, and it is measured in your risk register rather than theirs.
A register is only worth what its notice mechanism is worth — because a supplier who may add a party and tell you afterwards has given you a document, and the party they add is the one your own examiners will ask about.
The commitment made here is notice before a change rather than after it, with a stated window in which you may object, and a right to terminate without penalty if an objection cannot be resolved. That combination is what turns a register into something you operate rather than something you archive. It is written into the agreement rather than described on a page, and a supplier unwilling to write it has answered the question.
Notice reaches a named contact you nominate rather than a marketing list, because an audit asking you to demonstrate awareness of a change is not satisfied by a footer link in a newsletter. This sounds like a small operational detail and it is the difference between a finding and no finding.
The chain itself is short, and the reason is structural rather than virtuous. The architecture pushes credentials back to the customer wherever a connection reaches a customer estate: your messaging provider under your account, your payment processor under your account, your model provider under your credentials at no markup. Every one of those is a party we do not interpose, a contract you already hold, and a line that does not appear on your register because of us.
What remains is named rather than summarised: infrastructure hosting, which is where the records physically sit; monitoring and error reporting, which receives operational measurement rather than record content; and the parties a customer themselves connects. Each entry says what it does and what it can reach, because a register that lists names without functions cannot be assessed.
On concentration, the honest disclosure is that we cannot see your aggregate exposure and will not pretend to. What we can do is name our own infrastructure dependencies specifically enough that your team can add them to whatever aggregate view you maintain — which is the only place that analysis can actually be performed.
Who is in the chain, and what each one does — measured by the register, listing a function and a reach beside every name.
Whether a change reaches you before it happens — measured by the notice period written in the agreement as a number of days.
Whether you can act on a change — measured by the objection window and the termination right, both in the agreement.
Whether notice reaches a person or a mailing list — measured by a nominated contact named in the agreement rather than a newsletter.
How many parties are interposed at all — measured by counting connections that use your own credentials rather than ours.
What your aggregate exposure includes — measured by our infrastructure dependencies named specifically enough to enter your own view.
no visibility into your aggregate concentration across your other suppliers, and no attempt to assess it on your behalf. No claim that every party in the chain has been independently assessed by us. No claim to control what a party you connect yourself does with your data under your own contract. An independent SOC 2 Type II attestation is in progress and no report exists yet.
This is the practical lever and it is worth being explicit about the mechanism. Where a connection reaches your estate or your customers, the design intent is that it runs under a credential your organisation issued, on an account your organisation holds, with a contract your organisation signed. The consequence for a risk register is direct: that provider is your supplier, assessed once by you, rather than a subprocessor of ours that you assess through us at one remove.
It also changes what happens during an incident. A party you contracted with is one you can call, instruct and escalate to. A party interposed by a supplier is one you will hear about through an intermediary on their timeline, which is the position everybody discovers is untenable at the worst moment.
Where you would rather not hold the credential, that is a legitimate choice and the arrangement supports it — but the party then appears on your register through us, and this page would rather you made that trade deliberately than discovered it during an assessment.
The register names each party with its function and what it can reach, because a list of company names cannot be assessed by anybody. A register that says only who and not what is a document produced to satisfy a request rather than to answer a question.
What it cannot tell you is your aggregate concentration, and we will not imply otherwise. Your exposure across an estate of suppliers who all rest on the same infrastructure is real, it is invisible from inside any single supplier assessment, and the only place it can be computed is your own aggregate view. Our contribution is to name our dependencies specifically enough to be entered into it.
We also do not claim to have independently assessed every party in our own chain. Each is contracted with obligations that flow down, which is the ordinary mechanism, and it is a weaker thing than an assessment. Recording it as flow-down rather than as assessment is the accurate entry for your file.
On independent assurance the position is the same as everywhere else here: a SOC 2 Type II attestation is in progress and no report exists yet, so nobody can be handed one, and it is an attestation with a scope and a period rather than a certification.
The notice period, as a number of days before a change rather than after it. Read this clause before you read the register, because it determines whether the register will still be true in a year.
The objection window and the termination right, together. An objection window with no consequence attached is a courtesy, and everybody drafting these knows which of the two they have written.
The nominated contact. Insist that notice goes to a named person or role in your organisation rather than to whoever subscribed to a mailing list, because the audit question is whether you were told and a footer link does not answer it.
Then read the register itself for functions rather than names, and add our infrastructure dependencies to your own concentration view. That last step is the only one that can be performed on your side, and it is the one most likely to change a decision.
A review of the register together with the draft notice, objection and termination clauses, before any commercial discussion — and a decision about which credentials you would rather hold yourself.
The clauses determine whether the list stays true, so reading them first is the correct order and it is the opposite of how these reviews usually run. A short register with a weak notice clause is worse than a longer register with a strong one.
The credential decision is the one with the most leverage and it is usually made by default. Every connection you run under your own account is a party that does not appear on your register through us, a contract you can enforce directly, and somebody you can call during an incident.
Only then is the register itself worth reading closely, and it should be read for functions rather than names — what each party can reach is the thing your assessment is actually about.
Ask for what each named party can reach rather than for another layer of names, because that is the question your assessment is actually about and it is answerable. A party that receives operational counts and timings is a different exposure from one that holds records, and a list of company names cannot distinguish them. Where a party of ours has its own dependencies that would reach your records, that belongs in the register with its function stated, and if we cannot say what a party reaches then we have not assessed it well enough to have contracted with it.
The clause, and it is worth more than the list. Notice goes to a contact you nominate before the change takes effect, there is a stated window in which you may object, and if an objection cannot be resolved you may terminate without penalty. Read those three before you read the register — they determine whether the register is still true in a year. A supplier who may add a party and inform you afterwards has given you a document rather than a control, and most registers are handed over exactly that way.
They do, and we cannot see that from here — your aggregate concentration is invisible from inside any single supplier assessment and we will not pretend to assess it for you. What we can do is name our own infrastructure dependencies specifically enough that your team can enter them into whatever aggregate view you maintain, which is the only place the analysis can actually be performed. A supplier who claims to have considered your concentration risk has described something they have no information to do.
Because of where the credentials sit rather than because of restraint. Messaging, payments and model providers run under accounts your organisation holds, under contracts you signed — so each is your supplier, assessed once by you, rather than a subprocessor of ours you assess at one remove. Payment settlement never passes through us at all. Every credential you keep is a line that does not appear on your register because of us, and a party you can call directly during the incident rather than hearing about through an intermediary.
They carry contractual flow-down obligations, which is the ordinary mechanism, and that is a weaker thing than an independent assessment — so it is recorded here as flow-down rather than dressed up as assessment. Enter it in your file that way; it is the accurate entry and it is the one your examiner would arrive at anyway. Where a party would hold your records rather than operational measurement, that distinction is stated in the register, because it is the line along which the risk actually differs.