Guidance for Data Brokers

How We Submit and Manage Deletion Requests on Behalf of Individuals

We act on behalf of individuals to exercise their data protection rights under the UK GDPR and EU GDPR. This page explains how deletion (Right to Erasure) requests submitted by us should be handled, and what organisations can expect when receiving such a request.

1. Requests Submitted by an Authorised Agent

Deletion requests may be submitted by us as an authorised representative of the data subject. Each request is supported by a valid Letter of Authority (LOA), which confirms that we are entitled to act on the individual’s behalf.

Regulatory guidance confirms that organisations must accept GDPR requests submitted by third parties, provided appropriate authorisation is supplied.

2. Scope of the Request

Our requests are made under Article 17 Right to Erasure (also known as the right to be forgotten) of the UK GDPR / EU GDPR.

We do not request access to personal data. We request Deletion of personal data; or where deletion is not lawful possible:

  • the restriction of processing in line with Article 18, and

  • the objection of processing of personal data for all purposes afforded by Article 21 of the above.

Our requests relate specifically to data held or processed for marketing, data-sharing, or data-broking purposes, the part of your business where individuals’ data is compiled, traded, enriched, bought, sold, shared, or licensed. We are not asking you to search employment records, applicant files, or data obtained directly from the individual in the course of a genuine business or contractual relationship with them, provided that data isn’t also fed into or drawn on for marketing or broking purposes. Where it’s used for both, it falls within scope; where it’s genuinely separate, it doesn’t.

3. Identifiers Provided

Each request includes one or more identifiers (such as confirmed email addresses) that the individual has authorised for use. All details are included in the Letter of Authority attached to each request.

Organisations are expected to locate and act upon all personal data linked to the individual, including (but not limited to) data associated with:

  • Contact Info: Name, address, phone, email.

  • Identification: ID numbers, driver's license, passport info.

  • Online Identifiers: IP addresses, cookie IDs, usernames, device IDs.

  • Demographics: Age, gender, date of birth, marital status.

  • Financial: Salary, bank details, credit card numbers.

  • Employment / Education: Job history, qualifications, training records.

  • Location: GPS data, location history.

  • Physical / Behavioral: Photos, voice recordings, work times. 

  • Racial or Ethnic Origin.

  • Political Opinions.

  • Religious or Philosophical Beliefs.

  • Trade Union Membership (or lack of membership).

  • Health Data: Medical conditions, treatments, symptoms.

  • Genetic Data.

  • Biometric Data: (including for identification).

  • Sex Life or Sexual Orientation.

  • Criminal Convictions & Offences. 

If another identifier is used as the primary key within your systems, it should also be included in the search.

4. Deletion and Restriction Expectations

The individual’s preference is for permanent deletion of their personal data.

Where an organisation believes it has a valid legal obligation or lawful basis to retain some data:

  • The request should be treated as an objection to processing (Article 21), and

  • Processing should be restricted under Article 18, except where retention is strictly required by law.

Restricted data must not be actively processed, shared, sold, or otherwise reused.

5. Suppression

We offer data controllers a mechanism to close matters like this permanently rather than requiring repeat requests, and this is our strongly preferred outcome, for three reasons: our customers want their data out of data brokers’ hands entirely, not just temporarily absent from one database; it removes the burden on us of repeat requests; and it removes the burden on data brokers of repeat searches.

If technically possible you may apply a supression to prevent the subject of the request from being reaquired into your systems. If this is possible then you can opt to include this fact in your response to us.

By confirming supression you must ensure that:

  • The individual’s actual personal data (email, phone number, etc.) is removed from your live and backup records and is not retained in identifiable form;

  • You retain a way to check, at the point any new record is acquired or loaded, whether that incoming record corresponds to a previously suppressed individual, so it can be blocked or excluded before being added to the live database.

One way of achieving this, offered as an example, not a requirement, is a one-way cryptographic hash (e.g. SHA-256) of the individual’s normalised contact details. No plaintext personal data is retained, only the irreversible hash value. Any newly acquired record is hashed the same way before being loaded; if the resulting hash matches an entry on the suppression list, the record is blocked or excluded from the live database rather than being added. Any equivalent method that achieves the same two outcomes above would be equally acceptable to us.

6. Confirmation of Outcome

There are two methods you can use to confirm deletion, either replying to the request we sent you just adding the simple statement of ‘deletion confirmed’ or by filling in the linked form attached to the email we sent you. Note, the form will be hosted on our sub-domain forms.guardID.app and will be secured via https. We take security seriously and our entire domain (inclduing all sub-domains) is set to only accept https traffic (no http) with HSTS & HSTS Preload configured.

You can also confirm supression either to a certain date or indefientyl using the form. Alternatively in your email reply state ‘Permanately Suprpressed’ or ‘Supressed until dd/mm/yyyy’. Once confirmed on either basis, we will treat that as protection for the stated period and will not send further erasure requests for that person within it, unless we have specific reason to believe the suppression has failed. We’d flag one further practical exception: if our customer subsequently updates the details they’ve given us (for example, a new email address or phone number), we may need to send a fresh request to cover the updated details, since these would not be caught by a hash generated against the old information.

7. Verification and Proportionality

In many cases; particularly where data was not collected directly from the individual; requests for additional verification may be unnecessary. GDPR requires that verification steps be proportionate and not create undue barriers to exercising data protection rights.

We reserve the right to escalate undue and unneccessary additional verification to the Information Commissioner or other regulatory authorities to seek intervention if we deem the verification to be disproportionate to the requests we make on behalf of our clients.

It is the view of guardID that companies who request verification beyond our Letter of Authority for data that was aquired by them without verification from the data subject is manifestly disproportionate and is being completed with the primary aim of reducing the amount of data shrinkage by making deletion harder for the data subject (or an agent acting lawfully on their behalf).

8. Record Keeping and References

Each request includes a unique reference identifier. Organisations should quote this reference in any correspondence to ensure accurate tracking and closure of the request.

9. Regulatory Context

We may share correspondence or outcomes with relevant supervisory authorities where this is necessary to protect the interests of the individual or to clarify regulatory expectations.

Our aim is to ensure deletion and restriction requests are handled efficiently, transparently, and in line with data protection law.

10. Correspondence use for Transparency & Marketing

To promote transparency, accountability, and industry understanding of data protection practices, we may use excerpts from correspondence received from data brokers, data controllers, or other third parties in our communications and marketing materials.

We may reference, use or quote:

  • Written responses to deletion, suppression, or restriction requests,

  • Explanations of processing practices or legal positions,

  • Confirmations of deletion or suppression,

  • General commentary on compliance processes or timelines.

When using such correspondence:

  • All personal data relating to individuals is removed or irreversibly redacted, including names, email addresses, identifiers, and case references,

  • No information capable of identifying a data subject is ever published,

  • Internal request identifiers and correspondence metadata are removed.

However:

  • We may retain and display the name of the responding organisation (for example, the data broker or data controller), where this is relevant to understanding industry practices or outcomes,

  • Individual employees, officers, or representatives of an organisation are not identified.

Correspondence is used solely for purposes such as:

  • Educating consumers and organisations about data protection rights,

  • Demonstrating real-world responses to erasure and restriction requests,

  • Highlighting variations in industry compliance approaches,

  • Promoting best practice and accountability within the data ecosystem.

Any such use is limited to what is necessary, proportionate, and fair, and is consistent with applicable data protection law, including principles of minimisation and transparency.

Use of correspondence does not imply endorsement, criticism, or regulatory findings unless explicitly stated. Excerpts are presented to illustrate processes and outcomes, not to attribute intent or legal conclusions.

If an organisation has concerns about the use of its correspondence in this way, it may contact us using the details provided on this website. We will review all objections in good faith and assess them in line with applicable data protection and fairness obligations.

11. Premium Integrations

We know some data brokers and other companies are seeking to do right by their customers and data subjects but also would like to remove a large chunk of the work out of the SAR / Data Deletion process. As such at guardID we want to help you with automating as much of the process as possible.

To this end we offer premium integrations with our service to allow you to use our secure APIs (or other secure technologies are avaliable upon request) to automate the data lifecycle confirm removal / supression of data subjects within our member base. Moreover, we offer APIs which you can use upon aquiring new data to validate if they are a member of our service. We have found this service can help brokers minimise the costs of aquisition by eliminating wasted spend on records that will need deleting.

Note, in order to be eligible for this service we do have an application process to ensure our APIs are only used for legitimate purposes. This service also has custom pricing, reach out now to find out more. 

Email us

12. Fees Charged by Third-Party Controllers

We submit data subject rights requests, including erasure requests, on behalf of our customers, under proper authorisation. We do not pay, and will not agree to pay, any fee charged by an organisation in connection with actioning such a request. Any invoice issued to us on this basis will not be recognised or paid.

Why we take this approach?

These requests are free by default under UK GDPR. Article 12(5) UK GDPR requires that requests exercising data subject rights be actioned free of charge. An organisation may only charge a fee, or refuse a request, where it is manifestly unfounded or excessive, and even then, it must give reasons. A single, properly authorised request concerning one identified individual is not manifestly unfounded or excessive simply because it does not explain why we believe that organisation holds the individual's data. We also provide a method for you to inform us a data subjects data has been supressed from your systems to prevent repeat requests. If you would rather not supress their data then we are forced to repeatedly request deletion as an alternative.

We are not required to justify why we believe an organisation holds our customer's data. UK GDPR does not require a data subject or their authorised representative to set out a theory as to why a particular controller might hold personal data before that controller is obliged to check. A request we submit is not deficient, unfounded, or excessive merely because it does not include this explanation.

Why we cannot be expected to know who holds our customers' data

The data broker and data trading industry operates by continuously collecting, buying, selling, and re-sharing personal data across a large and shifting network of organisations. Data is aggregated from public records, third-party purchases, tracking, and other sources, then repackaged and passed on again, often multiple times over. There is no central register of who holds what data on any given individual, and no reliable way for a data subject — or anyone acting on their behalf — to determine at any point in time which organisations currently hold their details, have previously held them, or have since passed them on to others.

This means neither we, our customers, nor any other data subject can be expected to identify in advance which specific controllers hold a given individual's data, or to explain why a particular organisation is believed to hold it. Requiring that explanation as a precondition for action would be inconsistent with how this industry actually functions, and is not a requirement UK GDPR imposes. The only practical way to exercise the right to erasure against this backdrop is to submit requests to organisations that may hold the data, without needing to prove in advance that they do.

Our suppression solution

To reduce the burden of repeat requests on both sides, we offer organisations a suppression-based solution. Rather than treating each erasure request as an isolated, one-off event, an organisation can add the individual's details to a suppression record. This allows the organisation to:

  • Recognise the individual if their data is received again in future, whether through a new data feed, a repurchased list, or another route back into the organisation's systems and prevent it from being reloaded, reprocessed, or acted on.

  • Avoid the need to respond to a fresh erasure request reguarly in order to ensure that the data subjects data remains deleted.

  • Demonstrate an ongoing, auditable compliance measure, rather than relying on a single deletion event that offers no protection against the data being reacquired later.

Suppression addresses the practical reality that, because of how data is redistributed across the industry, deleting a record once does not guarantee it will not reappear through another channel. It offers organisations a durable way to honour an individual's erasure request on an ongoing basis, without requiring you process regular requests.

Summary

We submit valid, properly authorised data subject rights requests on behalf of our customers, in line with UK GDPR. We will not pay fees imposed by unilateral notice, and we do not accept that we are required to justify our belief that an organisation holds our customer's data as a precondition for that request being actioned. Given how the data broker industry operates, no one — including us, our customers, or the data subjects themselves — can reliably know who holds a given individual's data at any point in time. We encourage organisations to adopt suppression as a practical, ongoing solution to prevent recurring requests, rather than treating each request as a one-off event or a basis for a fee.