GDPR-compliant PDF tracking

You can know who read your document and stay on the right side of the GDPR - but only if the tracking is built to avoid collecting personal data in the first place. Most document trackers do the opposite: they log every reader's IP address, which the GDPR treats as personal data, and hand you a compliance obligation you never asked for. Here's how to track readership the compliant way.

Is PDF tracking even allowed under GDPR?

Yes - tracking how a document is read is not banned by the GDPR. What the regulation governs is personal data: information relating to an identifiable person. The question is never "can I see who read it?" but "what personal data am I collecting to do so, and do I have a basis to hold it?" If your tracking records readership without collecting personal data, most of the heavy GDPR machinery simply doesn't apply, because there is no personal data to protect.

The problem: IP addresses are personal data

Under the GDPR and UK GDPR, an IP address is generally personal data - the Court of Justice of the EU confirmed this for dynamic IPs in Breyer. The moment a document tracker stores a visitor's IP, you (the sender) are processing personal data and inherit the obligations that follow: a lawful basis, a defined retention period, the duty to minimise what you keep, and the ability to honour access and erasure requests.

For a freelancer sending a proposal or a founder sharing a deck, that's a lot of liability in exchange for a stat you barely look at - and it compounds with every tool that quietly logs reader IPs. The most reliable way to comply is the simplest one: don't collect the personal data at all. You cannot mishandle, over-retain, or be compelled to produce data you never stored.

Data minimisation in practice

Data minimisation - collecting only what you actually need - is one of the GDPR's core principles, and it maps perfectly onto document tracking. The job is "understand how my document is read." You do not need a reader's address to do that. You need to recognise a returning reader, know roughly where reads come from, and see which pages held attention - and all of that can be derived without retaining an identifier that points back to a person.

How EveryPage tracks readership without storing personal data

EveryPage is built for this. Instead of storing the IP, each reader's address is run through a salted one-way hash the moment a read happens, producing a stable pseudonymous identity (Reader #214). The hash can't be reversed back to the address, and the salt is a server secret, so the stored identity is meaningless to anyone who might come across it - yet it's stable enough to tell you the same reader came back three times. The IP itself is used only to resolve a country in-flight, then discarded. The detailed mechanism is in how to share a PDF without storing reader IP addresses.

On top of that, links expire on a schedule you set and the encrypted file is swept from disk shortly after - so there's no indefinite retention - and readership is measured first-party inside the viewer, with no third-party tracking scripts or cross-site cookies riding along on your document.

When a reader chooses to identify themselves

Sometimes you do want a name - which investor opened the deck, which client read the contract. EveryPage's optional email gate asks the reader to enter an email before the document opens. That is the reader consciously providing their data, which is a very different basis from quietly harvesting an address they never agreed to share. You collect a name because they chose to give it, you tell them why, and everything else stays pseudonymous.

Who is the controller - and who is the processor?

GDPR-conscious buyers usually ask this first, so here it is plainly. When you share a document through EveryPage, you are the controller of the readership data collected on your behalf: you decide what to share, who gets the link, whether it expires, and whether readers must identify themselves. EveryPage acts as your processor for that data - we hold it and show it to you, and we don't use it for purposes of our own. (For your account details - your email, your subscription - EveryPage is a controller in the ordinary way any service is.)

What makes the split unusually light here is how little sits inside it. For an ungated link, the readership processed on your behalf is a salted hash, page numbers, reading time, and a country - pseudonymised by design before anything is written down. Personal data really enters the picture at the email gate, where a reader types an address they know you will see. That address is yours to answer for as controller: collect it because you need it, and say why.

On paperwork, honestly: our processing commitments live in the terms and privacy policy; EveryPage doesn't currently publish a separate standalone DPA for countersigning. If your organisation's procurement requires one, talk to us. Either way, remember what a DPA actually governs - the personal data a processor holds for you - and that the design here keeps that set unusually small.

Where your data lives: residency and sub-processors

EveryPage is built and operated from the United Kingdom, so processing sits under the UK GDPR - a regime the EU has formally recognised as adequate, meaning personal data can flow from the EU to a UK-operated service without additional transfer safeguards. The service itself runs on a deliberately small stack of servers we administer directly, not a sprawl of managed cloud products each holding a copy of your data.

Fewer moving parts also means a short sub-processor list, kept current in the privacy policy: Stripe handles subscription billing, a transactional-email provider sends verification and notification emails, and a geolocation service resolves a reader's country in transit - the address is used for that lookup and then discarded, never stored. Traffic to everypage.co passes through Cloudflare's network on its way to our servers. Even our own site analytics follow the same posture: a self-hosted, cookieless analytics instance measured first-party, so reading this page doesn't ship your visit to an analytics company either.

Breach notification - and what a breach could even expose

Under the GDPR and UK GDPR, a processor must tell the controller about a personal-data breach without undue delay, and a controller must assess whether to notify the regulator within 72 hours. Those duties apply to EveryPage like anyone else: if an incident ever touched data we process for you, we would tell you promptly so you could meet your own clock.

The more useful question is what a breach here could actually expose. Documents are encrypted at rest with AES-256-GCM, each user's files under their own key, and readership rows contain pseudonymous hashes, page numbers, timings, and countries. A copied database would not contain a single reader IP address, because none was ever stored - you cannot leak what you don't hold. The email addresses collected by gates you enabled are the main personal data at stake, and that is exactly the set you knowingly chose to collect.

One thing we won't do is dress this up in acronyms. EveryPage is a small UK operation, not an enterprise compliance programme, and doesn't currently hold certifications such as SOC 2 or ISO 27001. What we can tell you precisely - and what this page tries to do - is what is stored, how it is protected, and what isn't there at all. For breach exposure, that last part is the one that matters.

Retention and deletion, on your terms

Storage limitation - not keeping data longer than the job needs - is the GDPR principle retention policies answer to, and EveryPage turns it into a control rather than a policy document. You decide how long a document stays live: set an expiry and the link stops serving the moment it passes, with the encrypted file swept from disk shortly after; or keep a document up indefinitely on Pro, because plenty of documents are meant to stay published. Retention matches the document's job, and you set it.

Deletion is equally direct: remove a document whenever you like, and deleting your account removes the account and its files with it. Pseudonymity pays off on the rights side too. For an ungated read there is no stored identifier that maps back to a person, so there is nothing to dig out of a log when someone asks what you hold on them - the scope of a subject-access request shrinks to the email addresses you deliberately collected through a gate.

A practical compliance checklist

1. Use a tracker that doesn't store reader IP addresses (or other raw identifiers).
2. Know your role: for reader data collected on your behalf, you are the controller and your tracking tool is your processor.
3. Set links to expire so readership data isn't retained indefinitely.
4. Only ask readers for an email (or other personal data) when you genuinely need it - and tell them why.
5. Keep your privacy policy honest about what is and isn't collected.
6. Prefer first-party measurement over embedded third-party trackers and cookies.

This guide explains the principles in general terms and is not legal advice; check your own obligations for your situation.

Related reading

See how to share a PDF without storing reader IP addresses, the full readership features, or why DocSend-alternative searches lead here (DocSend stores IPs; EveryPage doesn't).