Processor Instruction Boundary

A team adds an analytics SDK in a sprint and treats the contract as the compliance work. Six months later the privacy office asks which lawful basis covers the vendor's own use of the data, and the answer determines whether the SDK may run at all before a user has consented.

A processor acts only on the controller's documented instructions. A controller decides the purposes and the means. The line between them is not a contractual preference: it follows from who gets to decide what the data is for, and it lands in the code.

Why it matters

The role decides three architectural facts. Whether the vendor's collection needs its own consent gate before initialisation. Whether you can instruct deletion and expect it to happen. Whether the vendor's own suppliers become your problem. Getting it wrong is not a paperwork error; it is a launch blocker discovered late, or an enforcement finding discovered later still.

The useful test is one question: can the vendor use what it collects to improve its own product, build a cross-customer benchmark or enrich a profile it sells? If yes, it is a controller for those purposes, whatever the agreement is titled. Cross-customer learning is the product for most analytics, attribution and fraud-scoring vendors.

Implementation patterns

• Consent-gated initialisation. The SDK is constructed behind a locally readable consent flag, and the application's start-up path tolerates it never starting. Vendor documentation that says to call init() in Application.onCreate is written for a processor relationship.
• An inventory row per vendor carrying role, purposes, data classes, retention, sub-processors and the deletion mechanism, generated from the same source that provisions vendor credentials, so it cannot drift.
• Sub-processor change notification with somewhere to land. A new sub-processor in a new jurisdiction is a new transfer, so the notification needs an owner and a decision, not an inbox.
• A breach SLA inside your own. With a 72-hour controller clock, a processor commitment of 24 hours leaves a day for triage. Name the channel, define the minimum content, and rehearse it once a year.
• Tenant-scoped logs as a due-diligence requirement, because a vendor that cannot say which of your customers were affected leaves you notifying all of them.

Industry example

The structure is visible in any large SaaS trust centre: a published sub-processor list, a stated notification window for changes, and a data-processing addendum that enumerates instructions. The engineering counterpart to that page is what matters — Salesforce's metadata-driven multi-tenant design, published at SIGMOD in 2009, is the strongest version of it, where per-customer behaviour is configuration data rather than a code branch, and so is inspectable and provable per tenant.

Failure scenarios

• The SDK that phones home before consent, because it initialises in the start-up path.
• The 72-hour contract, which gives you zero hours to investigate and notify.
• The unlogged sub-processor, discovered when the vendor changes its cloud provider and your transfer analysis silently becomes wrong.
• Deletion on termination that cannot be executed, because nobody knows what the vendor holds.
• Free-text fields, which are agreed to carry no personal data and always do.

Trade-offs

Treating every vendor as a controller is safe and expensive: consent gates degrade measurement, and product teams route around them. Treating every vendor as a processor is cheap until an enforcement action. The proportionate position is to spend the effort where identifiers, device graphs or free-text fields flow, and to accept generic terms where the vendor receives neither.

When not to use it

A vendor that never receives personal data does not need this analysis. A font CDN, a symbolication service fed only stack frames, an open-source dependency mirror. Applying the full inventory to them produces a register nobody maintains, which is worse than a short one that is true.

Interview question

Q: Product wants a session-replay tool live next week. Walk me through what you check before it ships, and what you would have to change in the application if the vendor turns out to be a controller.

What a strong answer covers: the own-purpose test · consent-gated lazy initialisation and a start-up path that tolerates absence · masking rules for form fields and the fact that free-text is unbounded · the sub-processor list and where it lives · a 24-hour breach channel · and the recognition that session replay usually captures more than the product team believes, so the default should be deny-by-default field capture.

Quick check

Quiz: What single question decides whether a vendor is a processor? Whether it may use the data for purposes of its own; if it may, it is a controller regardless of what the agreement says.

Flashcard: Why must a processor's breach SLA be well under 72 hours? — Because the controller's 72-hour clock starts on awareness, so anything the vendor spends is subtracted from your time, not added to the deadline.