The single most reliable way to unsettle a management team in late 2017 was to ask them to list every organisation holding their customers' or employees' personal data. The answers averaged around fifteen. The actual numbers, once anyone looked properly, ran into the hundreds. This was not incompetence. Vendor relationships accumulate through ordinary business activity over many years, and nothing in a normal company's processes ever required someone to record which ones involved personal data. The payroll bureau was obvious. The email provider was obvious. Less obvious: the recruitment platform holding candidate records, the survey tool with employee responses, the marketing automation system, the analytics provider, the customer support platform, the training system, the expense tool, the background check agency, the insurance broker, the offshore support centre, the design agency with a copy of the customer list from a campaign three years ago, and the former employee's consultancy still receiving a monthly export because nobody cancelled it. Then the layer nobody had considered at all: the sub-processors behind each of those. A SaaS vendor runs on a cloud provider, uses a separate email delivery service, a support ticketing tool, an offshore engineering team and three monitoring services. Each is a place your data sits. The processor inventory exercise was the first time most organisations saw the actual shape of their data estate, and the shape was a network rather than a list.
Why the obligation is not delegable
GDPR Article 28 sets out what a controller must require of a processor, and the structure is unforgiving: the controller remains accountable for personal data it has handed to someone else. Processing must be governed by a written contract specifying subject matter, duration, nature and purpose, the type of data, categories of individuals, and the controller's rights. The processor must act only on documented instructions, keep the data confidential, implement appropriate security, assist with individual rights and breach notification, obtain authorisation before engaging sub-processors, and delete or return the data at the end of the relationship. Every one of those clauses implies something the controller must actually be able to do. You cannot instruct a processor you have not identified. You cannot meet a 72-hour breach clock if your vendor's contract gives them thirty days to tell you. You cannot answer an access request without knowing which processors hold the individual's data. And you cannot assert that data was deleted at contract end if nobody ever asked for confirmation — which, in practice, almost nobody did. That is why the inventory is the foundational artefact rather than a compliance annexe. Without it, the rest of a privacy programme is assertion.
How to actually find them
Asking departments to list their vendors produces a fraction of the answer, because people do not think of tools as vendors. The methods that work are indirect and should be run together. Start with accounts payable and the corporate card statements — every vendor receiving money appears there, including the small subscriptions that never went through procurement. Pull the single sign-on and identity provider logs to find every application anyone authenticates into. Review outbound network and DNS traffic for services nobody declared. Examine the integration and connected-app lists inside your major platforms, because API connections are data flows that no contract review will surface. Check email forwarding rules and scheduled report distributions, which is where the standing exports to former employees and dormant agencies hide. And read the contracts you do have for the sub-processor lists most vendors publish by reference. Expect the discovered number to be several times the declared one, and expect a meaningful tail of relationships nobody can explain. That tail is the highest-value finding of the whole exercise: dormant data flows to organisations with no current business purpose, which are pure exposure and free to remove. Then tier by risk rather than treating all of them equally. Volume and sensitivity of data, criticality to operations, and jurisdiction determine how much diligence each deserves. A vendor holding employee medical records offshore warrants a security assessment and contractual scrutiny; one holding a list of conference attendees warrants a contract clause and nothing more. Programmes that applied uniform diligence ran out of budget before reaching the material relationships.
| Evidence source | What to look for |
|---|---|
| Payables and cards | Subscriptions and vendors outside normal procurement. |
| Identity logs | Applications people authenticate into. |
| Network and DNS | Undeclared external services requiring investigation. |
| Connected applications | Integration and API-driven data flows. |
| Exports and forwarding | Standing distributions with no current purpose. |
| Contract references | Sub-processors behind direct providers. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Processor Inventory Engagement
- Discover from accounts payable, SSO logs, network traffic and platform integration lists. Asking departments to self-declare finds a fraction, because people do not think of tools as vendors.
- Enumerate sub-processors, not just direct vendors. Your data sits wherever your vendor's vendors keep it, and that chain is where residency commitments quietly break.
- Hunt the dormant flows first. Standing exports to former employees, old agencies and cancelled projects are pure exposure and cost nothing to remove.
- Tier by data sensitivity, volume and jurisdiction. Uniform diligence across hundreds of vendors exhausts the budget before reaching the ones that matter.
- Fix the breach notification clock in every contract. If a processor has thirty days to notify you, your own 72-hour obligation is already unachievable.
- Require deletion or return at contract end, and verify it. Almost nobody asks for confirmation, which means almost nobody knows whether it happened.
- Make sub-processor changes notifiable with a right to object. Vendors add processors through product updates, so the inventory decays unless changes reach you.
- Assign each vendor relationship an internal owner and review annually. An inventory without owners is a snapshot that is wrong within a year.
The Regional Dimension
Processor inventories in the Gulf uncover a category of exposure that European templates do not anticipate, and it is consistently the largest finding. The intermediary layer comes first and matters most. Regional business depends on public relations officers, typing centres, visa agents, medical testing centres, recruitment agencies, insurance brokers and customs brokers — external parties that routinely hold passports, visa applications, medical test results, Emirates ID and Iqama details, dependants' documents and salary information. These are processors handling some of the most sensitive data an organisation possesses, frequently under informal arrangements, often receiving documents by messaging app or personal email, and almost never appearing in a vendor register because they are treated as service intermediaries rather than data processors. Any regional inventory that does not start here is mapping the wrong estate. The systems integrator relationship is the second. Much of the regional technology estate is implemented and operated by integrators and managed service providers with standing privileged access to ERP, HR and infrastructure — frequently from offshore delivery centres, sometimes through shared accounts. That is processing at the deepest possible level of access, and the contractual position is usually silent on named individual accounts, unilateral revocation, session recording and sub-contracted offshore resource. The questions to put in writing are narrow: who exactly can access what, from which country, under whose name, and can we revoke it within the hour. Third, group structure turns intra-group flows into processor relationships. In a diversified family or state-linked group, the shared service centre processes for the operating entities, one entity's IT function administers another's systems, and group HR holds records for subsidiaries in different jurisdictions. Under GDPR, Saudi PDPL, the UAE federal framework and the separate DIFC and ADGM regimes, those are controller-to-processor or controller-to-controller relationships between distinct legal entities, requiring intra-group agreements that most groups have never executed. This is unglamorous paperwork with genuine consequences, because it is also the mechanism that makes cross-border group reporting defensible. Two further specifics. Residency commitments break at the sub-processor layer more often than at the vendor layer: a vendor may host in-country while its email delivery, support tooling, monitoring or backup sits elsewhere, so an in-country hosting commitment needs to be verified down the chain rather than accepted at the top. And mandated software channels create concentrated processor dependencies unique to the region — WPS submission tools, ZATCA-certified e-invoicing providers, customs and trade portal clients, visa and labour platforms, and tax filing software. Those providers process payroll, commercial and identity data for large numbers of organisations, are frequently a small set of certified local firms, and belong in the inventory with a note on concentration risk.
The objection worth taking seriously
The strongest criticism is that vendor due diligence at this scale is theatre — a paper exercise that produces contracts and questionnaires without changing anyone's security posture. The evidence for that view is reasonable. Processor contracts were largely issued as unnegotiable addenda by vendors with more leverage than their customers, which means the controller's supposed instruction rights exist on paper and not in the relationship. Security questionnaires are answered by sales teams, read by nobody, and filed. Sub-processor lists are published as web pages that change without notice, and the contractual right to object is functionally unusable when the alternative is terminating a platform the business runs on. Meanwhile the breaches that actually happen — a compromised support tool, an exposed storage bucket, a supplier's credentials reused — would not have been prevented by any of it. The honest response is that the inventory and the diligence do different jobs, and only one of them is weak. The diligence paperwork is indeed of limited value against a determined adversary. The inventory is not: knowing which vendors hold what data is what allows you to respond when one of them is breached, answer an individual's request, terminate a dormant flow, and assess concentration risk. The practical reframing is to stop treating this as a vendor assessment exercise and treat it as an exposure map — for each vendor, what could happen to us if this organisation were compromised tomorrow, and would we find out. There is also a leverage problem worth naming plainly. A mid-market organisation has no ability to impose terms on a major cloud platform, and pretending otherwise wastes legal budget. Leverage exists with mid-sized regional vendors, integrators and intermediaries — which, conveniently, is where the informal arrangements and the real gaps mostly are. Spend the negotiating effort there and accept the standard terms from the hyperscalers, where the security posture is generally stronger than anything your questionnaire would have required.
Common Questions
How many processors does a typical organisation have?
Far more than it thinks. Declared lists tend to run to a dozen or two; discovered inventories commonly reach the hundreds once subscriptions, integrations, intermediaries and sub-processors are included.
What is the most valuable finding from the exercise?
Dormant data flows — standing exports, forwarding rules and access grants to former employees, closed projects and agencies with no current relationship. They carry real risk, and removing them costs nothing.
Which contract term matters most?
The breach notification clock. A processor permitted thirty days to notify you makes your own 72-hour obligation impossible, and this is the clause most often left at the vendor's default.
How does AI change processor management?
It breaks the assumption that the processor list changes only when someone signs something. AI features added to existing platforms frequently introduce model providers as new sub-processors through a product update, which means your data reaches a new organisation without a procurement decision, a contract review or a notification anyone reads. Three practical responses. Ask every material vendor a direct question: which AI or model providers process our data, under what retention, and is that processing enabled by default. Check whether prompt and completion logs are retained by the provider and for how long, since those logs can contain the personal data your contracts govern elsewhere. And extend the inventory to the artefacts rather than just the parties — training data, fine-tuned weights, embeddings and retrieval indexes are copies that outlive source deletion, and they sit with whoever holds them. The related exposure runs the other way too: your own staff pasting documents into consumer assistants creates processors nobody approved, which is a discovery problem for the same tooling that found the rest of the estate.
Processor Inventory Engagement — discover from payables and SSO logs, start with the intermediaries, and treat the list as an exposure map.