Sub-Processor Boundary

A support team enables an AI summarisation feature in its existing helpdesk tool. Three weeks later a customer asks for the subprocessor list, and a review finds ticket contents including personal data have been sent to a model provider in another jurisdiction with a 30-day retention default.

No contract was signed, no procurement happened, and no engineer deployed anything. The vendor's own subprocessor list changed, and a feature toggle was the mechanism by which that change took effect inside your estate.

Why it matters

Controls that attach to the act of buying cannot see capabilities that arrive inside products already owned, and the arrival rate of those capabilities is currently high. A policy requiring approval for new processors governs purchasing and has no purchase to attach to.

The consequence is contractual as well as regulatory: a subprocessor you did not list is a breach of every customer agreement that names the list, which in a 400-customer book means 400 notifications. And there is no technical signal, because the data left through the vendor's backend rather than your network, so egress monitoring never sees it.

Implementation patterns

• Process subprocessor notices as events with a named owner and an SLA. Most data-processing agreements grant a notice period of around 30 days and a right to object; that right is worthless if the notice lands in a shared inbox. A register, one owner, and a rule that an unreviewed notice blocks renewal.
• Disable the capability at the tenant level where the vendor offers administrative control over AI features and data-sharing defaults, and make the setting part of a configuration baseline you audit. A control you have configured beats a control you have written down.
• Treat vendor admin consoles as reviewed configuration surfaces for the handful of tools holding regulated data: changes logged, a second approver, a quarterly diff against the baseline.
• Route your own model calls through a gateway you control, so processor, region, retention and redaction are architecture rather than a per-team choice. This covers your code and not your vendors, which is why notice processing still matters.
• Assess at the data-flow level, not the application level, so a new destination for existing data triggers review even when nothing new was bought.
• Scope all of this by what each vendor can reach, which requires the shadow-SaaS register first; otherwise you are controlling the vendors you remember.

Industry example

The control surfaces exist because vendors expect this requirement: major SaaS platforms now ship administrative switches for AI features and data-sharing defaults, and publish subprocessor lists with notification mechanisms, precisely because enterprise customers made it a contractual condition. Regulatory reinforcement is arriving too — DORA's register of information, applicable to EU financial entities from January 2025, requires firms to maintain information on ICT third parties including subcontracting chains. The architectural reading is that the fourth party is now in scope by regulation as well as by contract, so the register has to be maintained rather than assembled for an audit.

Failure scenarios

• A capability enabled by a non-technical team, with the same effect as a production deployment and none of its controls.
• A notice nobody processed, so a right to object expired unused.
• Point-in-time assessment, where the vendor was reviewed at purchase and never re-triggered.
• Discovery at a customer audit, typically a year later, which is both a contractual and a credibility problem.
• A redaction gateway bypassed by a vendor path, giving a false sense that model calls are controlled.
• Retention defaults, where the vendor's default retention period silently becomes your retention policy for that content.

Trade-offs

The register, the review queue with an SLA and the quarterly configuration diff cost perhaps a couple of days a month of a named person's time, plus friction for teams who wanted a vendor's new feature today. What it prevents is unbounded: an undisclosed processor is a disclosure obligation to every customer whose agreement names the list, and a data flow nobody assessed. The honest counter-argument is that the controls are only as good as the register, so investing here before you have a reliable inventory of what each vendor can reach is doing the second step first.

When not to use it

For a vendor holding no personal data and no confidential content, the notice-processing machinery is disproportionate and policy can carry it. Scope by reach, not by spend. And do not extend admin-console change control to every tool in the estate: pick the small number that hold regulated data, because a review process applied to everything is routed around and then applies to nothing.

Interview question

Q: A customer's annual review asks for your complete list of subprocessors, including any used by your vendors. You suspect the official list is incomplete. How do you produce a defensible answer, and what do you put in place so the list stays true without blocking every team that wants a new tool?

What a strong answer covers: starting from the register of what each vendor can access, and stating honestly what the feeds cannot see · subprocessor notices as owned events with an SLA, and the objection right as the thing being protected · tenant-level configuration as the control that actually holds, versus policy · admin consoles as configuration surfaces scoped to tools holding regulated data · a model gateway for first-party calls, with the explicit note that it does not cover vendors · assessment at the data-flow level · and a proportionality rule so that low-reach vendors are not put through the same process.

Quick check

Quiz: Why does a procurement-based approval control miss AI features in existing products? — Because nothing is purchased: the capability arrives in a product already owned and is enabled by a configuration change, so there is no purchase for the control to attach to.

Flashcard: Which single control most reliably stops a vendor's new AI feature from creating an undisclosed subprocessor? — Setting the vendor's tenant-level switch off and auditing it as part of a configuration baseline, because a configured control does not depend on anyone remembering a policy.