I am going to assume your privacy policy is up to date, that you have the permissions or other lawful bases you need, and that somebody competent has signed them off. Whether that process took two hours or two years is irrelevant to what follows. You have customers who have trusted you with information about themselves, and you are entitled to use that information for the purposes you have set out.
The question is what happens after that.
Most businesses do not keep customer data entirely inside their own systems. They share some of it with advertising platforms, measurement providers, agencies, analytics companies, identity services and other technology partners because those businesses can do something useful with it that the brand cannot do alone.
That is normal. It is also where I think a surprisingly large business risk begins.
The obvious privacy question is: what data are we sharing?
I think there is a better one:
What are we leaking by sharing it?
I use leaking deliberately, but I am not talking about a breach. The transfer can be authorised, encrypted, hashed, contractually permitted and completely intentional. You can still reveal considerably more than the fields you believe you have handed over.
The identifier may be the least interesting thing you share
Take one of the most familiar examples in digital advertising. A brand wants to target existing customers on another platform, so it uploads email addresses or phone numbers, usually after hashing them. The word hashed is reassuring because it suggests that the original identifier has been made unreadable.
Technically, it has. But matching would be useless if the result were unconnectable.
The platform does not need to reverse the hash to discover the email address. It has its own copy of the same identifier, transforms it in the same way and establishes that the two records refer to the same person. The hash has hidden the readable identifier while preserving the connection. Google and Meta both describe customer matching processes built around precisely this kind of matching.
Once you see that, the identifier begins to look like the least interesting piece of information in the exchange.
Suppose the audience is called high-value customers. You have just told the partner which of the people it already knows are high-value customers of your business. If the audience is customers who have not purchased for 90 days, you have told it something else. If you pass last purchase date, last interaction, recency, frequency or timestamps, the picture becomes richer again.
“Customer” is fairly weak information. “Frequent customer whose last purchase was four months ago, who returned to the site three days ago and has not purchased since” is considerably more revealing.
Timestamps are especially powerful because they turn facts into sequences. They show movement, recency and direction. A purchase tells you something happened. A series of timestamped interactions starts telling you where a relationship may be going.
None of this requires anybody to steal the data or break the encryption. The additional information comes from what the data means when it is placed alongside something else.
That is the point I think businesses routinely underestimate.
What you share is not the same as what you reveal
We tend to think about data sharing as if we were passing a parcel. The company has some information, selects a defined portion of it, passes it securely to another company and then worries about whether that recipient stores and protects the parcel properly.
Information does not work like that.
What a recipient learns depends partly on what the recipient already knows.
Give an address to a courier and it helps deliver a box. Give a stable identifier and behavioural information to an organisation that already has its own relationship with the same person, and the consequence can be very different. Your information can be joined to another timeline, another set of behaviours or another body of knowledge. Neither dataset has to contain the whole picture for the combination to produce something new.
And the original data does not necessarily need to remain there for that to matter.
Once the match has enabled an audience to be activated, another stream of information begins to exist inside that partner’s environment. Advertising was served. Somebody responded or did not. One message worked differently from another. A click happened at a particular time. A conversion may subsequently have been reported back. The uploaded matching file might later be deleted while the campaign events it enabled still occurred.
What happens to those events will vary by partner, product, contract and law. That distinction matters. Google, for example, explicitly says Customer Match files are restricted to creating the audience and policy compliance and are not used to build or enhance customer profiles.
But the broader business point survives even under tightly controlled arrangements:
The data you transfer is not necessarily the limit of the information your transfer causes to exist.
That is why I think privacy risk cannot be understood simply by inventorying the fields a company sends outside the building.
You also need to understand what those fields mean in the environment you send them into.
Permission changes when the context changes
This led me to a conclusion I had not previously thought about clearly enough:
Permission is not an intrinsic property of the data. Its adequacy depends partly on what you do with the data and who you give it to.
The same piece of information can have very different consequences in two different environments.
One supplier may be performing a tightly constrained function on your behalf. Another may have its own identity infrastructure, its own users, its own data, its own models and a much greater ability to connect your signal to other information.
The field you shared may be identical. The informational consequence is not.
Nor does that consequence remain fixed.
A partner that could infer relatively little from a signal five years ago may be able to extract considerably more value from it today. Identity resolution improves. More information becomes connectable. Models improve. AI accelerates the speed and scale at which patterns can be found in data that previously looked unrelated.
AI did not create this problem. It is accelerating the consequences of a problem that already existed.
Which produces a slightly uncomfortable thought:
The same permission can become less adequate without either the permission or the underlying data changing.
What changed was the capability around it.
If that sounds theoretical, look at the contracts.
Read what you have promised your partners
This is where the issue stops being primarily philosophical and becomes a management problem.
Major advertising platforms do not simply assume responsibility for determining whether you were entitled to supply the data in the first place. Meta’s current Customer List Custom Audiences terms, for example, require the advertiser to represent and warrant that it has the necessary rights, permissions and lawful basis to disclose and use the hashed data. Google’s Customer Match policy requires advertisers to disclose relevant third-party sharing in their privacy policies and obtain consent where required.
That does not mean the partner has no responsibility of its own. Under UK GDPR, processors have direct obligations, and controller processor contracts are supposed to specify the nature and purpose of processing, the data involved, the controller’s instructions and responsibilities around subprocessors, security, deletion and audit. The controller also has an obligation to choose processors that provide sufficient guarantees.
But that is precisely why I think marketers should take another look at what they have actually signed.
The uncomfortable question is not whether your partner has a privacy policy.
It is what you have warranted to them about your right to put customer data into their system, and what processing you have authorised once it gets there.
You may have spent years asking whether customers gave you permission.
Have you spent anything like the same amount of time asking what you subsequently gave your partners permission to do?
That is where the business exposure sits.
A large company may have dozens of relevant technology relationships. Some will be tightly bounded processors. Some may act as controllers for particular activities. Some may use subprocessors. Some will possess substantial independent knowledge about the same people. The contractual position will vary, but the brand cannot sensibly treat all those relationships as informationally equivalent simply because the original customer data was lawfully collected.
The customer trusted you first.
You chose what happened next.
Start with the contracts, not another privacy-policy rewrite
The useful thing about this problem is that there is something businesses can do immediately.
Start with your most important data partners and reread the actual agreements.
Not the sales deck. Not the privacy FAQ. The warranties, data-processing terms and permitted-use clauses.
What have you represented about the permissions or lawful bases you hold? What data have you authorised the partner to receive? What does the agreement say about matching, derived information, retention, deletion, subprocessors and reuse? Which liabilities remain with you? Which sit with them? What happens when the service changes?
Then look at the data itself from the other direction. Do not ask only what are we sending? Ask what are we revealing by sending it to this particular company?
An email address may reveal little in isolation but become a powerful join key. An audience name can disclose customer value or intent. A timestamp can reveal recency. A series of timestamps can reveal direction. Purchase frequency, browsing activity and customer status can each become more informative when combined with knowledge that already exists elsewhere.
For the largest platforms, you may have little ability to negotiate the standard terms. But you still control some important choices: which products you use, which data you supply, how granular that data is and whether the commercial return justifies the exposure.
With smaller partners, there may be more room to negotiate. Purpose limitation, retention periods, onward sharing, subprocessors, rights over derived information, audit rights and responsibility for downstream processing are not merely legal boilerplate if they determine what happens to information about your customers.
That may also become commercially interesting for the less visible parts of the data industry. A provider willing to accept tighter limits and clearer responsibility for what it derives or does with customer information is offering something materially different from one that pushes as much responsibility as possible back onto the client.
Responsibility has economic value.
Which brings me back to the thing that started bothering me.
Businesses already understand the danger of losing customer data. They invest heavily in keeping it secure, controlling access and preventing unauthorised disclosure.
But there is another kind of leakage.
It happens when the data goes exactly where you intended it to go.
You shared it legally. You transferred it securely. The partner received exactly what you meant to send.
And you may still have revealed more than you realised.
That is why permission should not be where the privacy conversation ends.
It is where responsibility begins.
Do you know what you’re leaking to your data partners?