The subprocessor register, and why recruitment needs one

In most business software a subprocessor sees metadata: an email address, a company name, an invoice line. In recruitment software, the data flowing to other companies is the substance of a person's working life. A resume is employment history, education, salary expectation, location, immigration signals, health disclosures people put in without thinking, and often a photograph.

Two categories in particular receive that substance rather than metadata. Model providers receive resume text and job descriptions because parsing, matching and drafting cannot happen otherwise. Messaging and telephony providers receive message bodies, phone numbers and, where call recording is enabled, audio of a candidate speaking about their circumstances.

That is the honest reason this page exists as a separate page rather than a line in the privacy policy. A buyer evaluating recruitment software should know which categories of third party will hold candidate substance, because it is a question their own clients will eventually ask them.

Six categories are used, and the register lists the named entities inside each one. Hosting and infrastructure holds the primary data store, object storage for uploaded documents, and encrypted backups. Model providers receive resume text, job descriptions and prompt context for parsing, matching, drafting and summarisation. Messaging and telephony providers carry SMS and WhatsApp message bodies, phone numbers and, where enabled, call audio.

Email delivery providers carry outbound message bodies, recipient addresses and delivery events. Analytics and product telemetry receives usage and error data about the application rather than candidate content. Support tooling receives whatever a person chooses to put into a support ticket, which is why the support process asks people not to paste candidate records into tickets.

Each category is described in the register with what it processes, why it is needed and where it processes. That last field is the one to read if you have a residency requirement, because a category can be fine in principle and unacceptable in the region a particular vendor runs in.

The commitment here is specific. Candidate data sent to a model provider is sent to serve your request and is not used to train general models offered to anyone else. The contractual terms behind that sit with the provider and are reflected in the flow-down obligations of the addendum, and retention at the provider is configured to the shortest option the provider supports.

There are limits worth naming. Model processing is a synchronous call to another company's infrastructure, and while the content is transient and covered by the terms above, a firm with a hard rule against any candidate content leaving its own boundary cannot use AI matching, parsing or drafting. That is a real constraint, and the sensible answer is to disable those features rather than to pretend the calls do not happen.

Demographic data is a separate case with an absolute rule. It is never included in a prompt, a feature vector, an embedding, a training set or a fine-tune. The payload assembled for any model call is built from an allow-list of fields, and the demographic table is not on that list and cannot be added to it by configuration.

A new subprocessor is not added quietly. The register is versioned, changes are published, and a subscription route exists so the person responsible for vendor management in your firm hears about a change without watching a web page. A stated notice period runs before the new subprocessor begins processing customer data.

Inside that period you can object on reasonable data protection grounds. An objection is a conversation first: sometimes the concern is met by configuration, by region selection or by excluding your tenant from the affected feature. Where it cannot be resolved, the escalation ends at termination for the affected service without penalty.

The reason to look for that escalation clause in any vendor's paper, not only this one, is simple. A notice you have no power to act on is an announcement. The objection route is what converts a notice into a control, and its absence tells you what the notice is actually worth.

This distinction gets lost regularly and it matters. When you connect your own LinkedIn Recruiter seat, your own WhatsApp Business number, your own Twilio account, your own job board contract or your own accounting system, you are the one instructing that vendor. They are your processors or your independent controllers, not ours, and they do not appear on our register.

The practical consequence is that your data protection assessment has to cover them, your contracts have to reach them, and their notices belong in your candidate-facing documentation. A buyer who assumes the CRM vendor's register covers the whole stack ends up with a gap exactly where the candidate messaging happens.

Where an integration is provided as part of the service rather than connected under your own account, it sits on the register like anything else. The integration pages state which model applies for each connector, and the register is the place to check when the answer matters.

Reviewers tend to ask for a list and stop. The register is more useful read as four questions per entry: what does this vendor receive, why is it necessary, where does it process, and what happens to your tenant if you object to it. An entry that cannot answer the second question is a vendor somebody should be removing rather than documenting.

For firms whose clients audit them, the register is also a supply-chain document. Staffing suppliers to regulated buyers are routinely asked to name the subprocessors behind their own tooling, and being able to hand over a versioned register with a date on it is considerably easier than reconstructing one under a deadline.

The register is not a certification and does not imply one. It is a disclosure. What it lets you do is make your own decision about a chain of vendors instead of taking a single reassuring sentence on trust.