GDPR-compliant PDF tracking

You can know who read your document and stay on the right side of the GDPR. It only works 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, meaning you collect only what you actually need, is one of the GDPR's core principles, and it maps neatly 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. All three 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 exactly 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 comes across it. It is still 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 nothing is retained indefinitely. 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: it holds the data and shows it to you, and puts it to no purpose of its own. (For your account details, meaning your email and 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, all 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, plainly: the processing commitments live in the terms and privacy policy, and EveryPage doesn't currently publish a separate standalone DPA for countersigning. If your organisation's procurement requires one, get in touch. Either way it is worth remembering what a DPA governs, which is the personal data a processor holds for you. 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, so personal data can flow from the EU to a UK-operated service without additional transfer safeguards. The service runs on a deliberately small stack of directly administered servers. There is no 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 the EveryPage servers. Even the site analytics behind this page follow the same posture: a self-hosted, cookieless instance measured first-party, so reading this page doesn't ship your visit to an analytics company.

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 processed on your behalf, you would be told promptly, in time to 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.

None of this needs dressing up in acronyms. EveryPage is a small UK operation rather than an enterprise compliance programme, and it holds no certification such as SOC 2 or ISO 27001. What can be stated precisely, and what this page sets out, 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, meaning you don't keep data longer than the job needs, is the GDPR principle retention policies answer to. EveryPage turns it into a control you operate, not a policy document you file. 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 any plan, 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).