GDPR and Journalism: What EU Publishers Need To Know About Reader Data

When independent publishers think about GDPR, they tend to think about the cookie banner.

They added one when the regulation came into force. They updated their privacy policy. They ticked the boxes. And for most publications, that’s where the GDPR conversation ended.

The problem is that cookie consent is the beginning of a publisher’s data obligations — not the end. And for publications that have grown to collect meaningful reader data, the gap between a cookie banner and genuine compliance is wider than most have examined.

What data publishers actually collect

Before thinking about compliance, it’s worth being specific about what a typical independent publication actually holds about its readers.

Newsletter subscribers. Name, email address, subscription date, engagement history — open rates, click behaviour, device information. For paid newsletters, payment details and billing history.

Registered users and paywall accounts. Everything above plus login credentials, reading history, content preferences, and potentially location data inferred from IP addresses.

Analytics data. Pageviews, session duration, referral sources, device and browser information, geographic location. Depending on the analytics platform, this may be linked to individual profiles rather than anonymised aggregates.

Comments and community. Names, email addresses, comment history, IP addresses. Depending on the platform — Disqus, a native system, or a third party — this data may sit entirely outside the publication’s direct control.

Advertising data. For publications running programmatic advertising, reader data is being processed by ad networks and data brokers whose practices the publication has limited visibility into.

Each of these data streams carries specific obligations under GDPR. None of them are covered by a cookie banner.

The consent problem

GDPR requires that consent for data processing be freely given, specific, informed, and unambiguous. For publishers, this creates practical questions that many have not fully worked through.

When a reader subscribes to a newsletter, what exactly are they consenting to? Receiving the newsletter — clearly. Being profiled based on their reading behaviour — less clearly. Having their engagement data used to inform editorial decisions — possibly not at all, depending on how the consent was obtained.

When a reader creates a paywall account, are they consenting to their reading history being analysed? To receiving marketing communications beyond the content they paid for?

The gap between what publishers do with reader data and what readers understood they were consenting to is, for many publications, meaningful. And meaningful gaps are risks.

The third-party platform problem

This is where independent publishers face their most significant and least discussed exposure.

Most publications don’t hold all their reader data directly. It’s distributed across the platforms they use: Mailchimp or Substack for newsletters, Google Analytics for web data, Disqus for comments, Stripe for payments, and a range of other services depending on the publication’s setup.

Under GDPR, the publication is the data controller. It is responsible for what happens to reader data — including what third-party processors do with it. This means the publication is responsible for ensuring that each platform it uses processes data in a manner consistent with GDPR, has appropriate data processing agreements in place, and doesn’t transfer data outside the EU in ways that aren’t properly governed.

For a publication using five or six third-party platforms, maintaining genuine oversight of all of this is a real compliance burden — one that most independent publishers haven’t fully addressed.

Reader rights and what they mean in practice

GDPR grants readers specific rights that publications must be able to honour.

The right of access. A reader can ask what data a publication holds about them. The publication must be able to answer accurately and completely — including data held by third-party processors.

The right to erasure. A reader can ask to have their data deleted. For a publication using multiple platforms, complete erasure means deleting data from all of them — newsletter platform, analytics system, comment platform, payment processor — and being able to verify that deletion was complete.

The right to portability. A reader can ask for their data in a machine-readable format. For publications without direct control over their data infrastructure, fulfilling this request requires the cooperation of multiple vendors.

The timeline for responding to these requests is one month. For a publication that doesn’t know exactly where all its reader data lives, that month can disappear very quickly.

What genuine compliance looks like for publishers

A publication that takes reader data seriously — not just legally, but as a matter of the trust its readership represents — approaches this differently.

Reader data is held in systems the publication controls, not distributed across platforms whose practices the publication can’t fully verify. Consent is obtained specifically for each type of processing, not bundled into a single acceptance. Analytics are handled with privacy-preserving tools that don’t build individual reader profiles without explicit consent. Newsletter infrastructure is self-hosted, meaning the subscriber list is an asset the publication owns and can fully account for.

When a reader asks what data the publication holds, the answer comes from one place, under one data policy, that the publication controls entirely. When a reader asks for deletion, the publication can execute and verify it completely.

That’s the standard. For a publication whose relationship with its readers is its most valuable asset, it’s also the right one.

A practical starting point

Full compliance doesn’t happen overnight. But a useful starting point is a data audit — mapping every place reader data is currently held, what it contains, under what legal basis it was collected, and what your obligations are toward it.

That exercise typically surfaces three or four areas that warrant immediate attention and a clearer picture of where the real risks are concentrated.

From there, the path forward becomes practical rather than overwhelming.

If you’re running a publication and want to think through what genuinely GDPR-compliant reader data infrastructure looks like, I’m happy to have that conversation.

Connect on LinkedIn or reach out directly at hi@madalin.me.