Sharing guide

Make sure you first read the label structure page about the sharing section of the label first. It explains the recipient types the label allows for. To recap:

  • Processors (contracted third parties, who act under strict guidance)
  • Service providers (providers of "free" services, without a contract, who may use the data for their own purposes) 
  • Customers (third parties that are paying to access the data)
  • Government organisations (often a legal requirement, often a non-profit exchange)
  • Parent, sibling or daugher organisations (it's complicated)
  • Advertising organisations (the only option that describes a business sector)
  • Third parties (this one may be used if none of the other options are a better match)

More details about these options can be found lower down on this page. First, let's talk about how to choose the categories and calculate their optimal position in the label's list.

Choosing the right option

Some of the options are more generic, while others describe more specific cases. Use the more precise description wherever possible. For example, advertising organisations is a very specific option because it's such an important to group to inform people about. But any advertiser is likely to also fit in either the broader processor or service provider category. Similarly, a parent organisation can at the same time be a government organisation (in which case the 'family relation' is more descriptive, so should be chosen).

‌It might be handy to follow these steps in determining the correct category:

  • Is it an advertiser? if not, then:
  • Is it a parent, sibling or daughter organisation? If not, then:
  • Is it a government organisation? If not, then:
  • Is it a customer? If not, then:
  • Is it a service provider? If not, then:
  • Is it a processor? If not, then:
  • It may be labeled as a 'third party'.

Order of display

The data sharing items listed in a privacy label should not be placed in a random order. They should be arranged by how often they occur. The most commonly used one should be at the top, followed by the next most common one, and so forth.

‌Counting how often each option occurs is not a question of how many parties data are involved. As in other parts of the label we are counting data types. For example:

Data type Shared with  Details
Email address Advertising organisation Uploading a list of customer email addresses to Facebook to target them with advertisements, and a second company that estimates add effectiveness.
Email address Parent, sibling or daughter organisation Updating a customer database that is shared with a daughter organisation.
Email address  Processor The email address may be shared with multiple data processors that are under contract for detecting  fraud and business opportunities.
 Full name  Processor Shared with a fraud detection company.

‌There are a number of things the example shows:

  • Processors are given access to two types of data (email address and name), while advertisers and 'parent, sibling or daughter organisations' are only given access to one data type (email address). This means that processors score two points, and the others score one point each. This means that in the label's sharing list, 'processors' should be placed above the other two.
  • While the details mention that the email address is in fact shared with "multiple processors", this still counts as 1 in our calculation. It doesn't matter if it's 1 processor or 100. 

Here's another way of looking at our web shop's calculation:

 Recipient: Advertisers Processors Government
 Data types shared: Email addresses
‌Cookie IDs
Email addresses
‌Phone numbers
‌Purchased product IDs
‌Bank account numbers
‌Email addresses
‌Taxes owed
 Total score:  2  6  4

Why do we count data this way?

It might seem strange that for the label's calculations it doesn't matter if an email address is shared with 1 or 100 advertisers. There are some reasons for doing it this way though.

‌Firstly, we feel there is value in expressing the number of data types that are shared with a certain type of recipient. For example, which would you place higher on the list: sharing 100 data types with one government organisation, or sharing one data type with 100 advertisers?

‌Secondly, there is a practical reason. Not having to know the exact count makes the calculations easier for larger organisations with multiple departments, where the number of organisations they share data with can fluctuate quickly. Meanwhile, the type of data shared can remain much more stable over time. For example, the organisation can set some basic rules, like: "only share email addresses with advertisers, nothing more".

‌A practical outcome of this approach is that an organisation doesn't have to update the label as often. If an organisation starts working with an additional advertiser or processor, but they are still only uploading email addresses, then the label will remain accurate.

‌In the end the label goal is to offer an indication. It's designed to be a little vague, since this means calculations are simpler, and it has to be updated less frequently. If an organisation wants to be more detailed about the number of parties they share data with, then this might still be expressed in the full privacy statement.

A closer look at the recipient options

The distinction between the categories may not always be clear, and in some cases you may not even realise you are sharing data with them, so let's look a little closer.


If your organisation is working with a processor, you will know it. It means there is a signed contract somewhere, which accurately describes and limits what the processor may do with the data. They may only do what's in the agreement. In legal terms, this means that you remain the "controller". Examples of processors are:

  • Banks
  • Billing service providers
  • Payroll service providers
  • Web hosting providers
  • Website analytics providers
  • Document verification services
  • Fraud detection services
  • Most cloud-based subscription services
    • Microsoft windows
    • Security cameras with cloud storage
Service providers

If you look a little closer at your website you may discover that it has some some scripts, fonts or media from other websites embedded into it. For example, you may have embedded a video from Youtube, or a fancy font provided by Google, a share button from Facebook, some javascript from jQuery, an advertising script from Doubleclick, a script that adds a cookies permissions popup, and so forth.


‌If you are curious what your website contains, try installing the excellent uMatrix addon in your browser Pretty much all mayor browsers except for Safari support it. It will give you some indication of what third parties are embedded in your website.

‌To calculate or estimate how many types of (observed) data your website visitors may be providing, you will have to read their terms of service documents.

When users visit your website, they are also loading downloading the data from these third parties. And each connection reveals something about your users to that third party. For example, what cookies are available, and what their IP address is (which is a piece of personal data). In short, it can help these parties get accurate pictures of people's online behavour.

‌You may have an agreement with these providers, you are unlikely to be the "data controller". Which means these parties may use the data they learn about your website visitors for their own purposes.

‌That's why we felt it very important to add this category to the label.

‌This isn't restricted to the online environment. Service providers might operate in the realm of smart homes and smart cities. The core thing is that they are offering "free" services which they offer to embed in your website/infrastructure/home/office/city, while retaining the legal position of data controller. Examples are:

  • Embedding Instagram or Twitter posts in a page on your website.
  • Content delivery networks

Your organisation may offer products or services in which other parties gain access to data. Some examples:

  • Literally selling data. For example as datasets, or as an on-demand a data-enrichment service.
  • "Renting" out data.
  • Offering services in which data is indirectly made available. For example, a browser plugin that offers insight into recipients of emails.
Government organisations

Your organisation is likely sharing data with government organisations, simply because it may be a legal requirement to do so. For example:

  • Sharing data about who you employ with national health insurance institutions
  • Sharing data necessary to do your taxes
Parent, sibling or daugher organisations

Your organisation may be part of a larger conglomerate within which data is shared. For example:

  • Franchise companies sharing data about employees or VIP customers
  • Connecting user accounts between multiple organisations
Advertising organisations

In order to advertise to specific groups you may want to share some data with specialised advertising parties. For example:

  • Sharing a list of address with a company that will mail flyers to customer's houses for you.
  • Sharing a list of email address with a social network in order to target advertising.
Third parties

If none of the other categories offers a more accurate fit, this category may be used.