Most publishers don't get many subject access requests. That's exactly why they go wrong. When one turns up, nobody remembers the process, the email sits in a shared inbox for a fortnight, and half the month has gone before anyone starts looking.
So here's the process, written down once. Everything below comes from the ICO's own guidance, which is linked throughout and worth reading in full.
Spotting one
A subject access request (SAR) is simply someone asking for a copy of the personal data you hold about them. The ICO's guide to subject access is clear that it can be verbal or written, can arrive through social media, and needs no particular form of words.
For a publisher, that means it might arrive as a note on a renewal form, a comment on a call to customer services or a message to the editor. "What have you got on me and where did you get it?" is a SAR.
So everyone who deals with readers needs to know what one looks like and where to send it. One named person should own them. It doesn't have to be a lawyer. It does have to be someone who'll notice the date.
The clock
You must respond without undue delay and within one month. The ICO's guidance on responding to a request says to count from the day you receive it to the same date next month. If that lands on a weekend or bank holiday, you get until the end of the next working day.
A few things change the clock:
- Identity checks. If you genuinely need to confirm who someone is, the clock doesn't start until you have it. The ICO says to be reasonable about what you ask for and only ask for formal ID if necessary. A request from the email address already on the subscription record may well be enough.
- Clarification. If you hold a lot about someone and genuinely need to know what they're after, you can ask. The clock pauses the day you ask and restarts the day after they reply. You can't ask on a blanket basis, and you can't make them narrow it.
- Extensions. For a complex request, or several from the same person, you can extend by up to two further months. You have to tell them, with reasons, within the first month.
You generally can't charge. A reasonable fee is only allowed for requests that are manifestly unfounded or excessive, or for extra copies, and the ICO sets a high bar for those.
Where a publisher has to look
The ICO expects a reasonable and proportionate search. For a publisher that's usually more places than people expect:
- the subscription or circulation system, including lapsed and gone-away records;
- payment and invoice history;
- the email platform, with its sends, opens and unsubscribes;
- event registrations and delegate lists;
- customer service notes and emails;
- the mailing house files, if they hold your data;
- spreadsheets on someone's desktop (there's always one).
Duplicate records make this much harder. If the same reader exists four times under different email addresses, you'll need to find all four. We wrote about how that happens in why one reader ends up as four records.
One firm rule. Once a request arrives, don't tidy up. The ICO says it's not acceptable to amend or delete information you wouldn't otherwise have changed, and altering data to stop it being disclosed is an offence. Normal processing can carry on. A sudden clear-out can't.
What to send
The person gets a copy of their data, and some supporting information. The ICO's right of access guidance lists it: your purposes, the categories of data, who you've shared it with, how long you'll keep it, their other rights, their right to complain to you and to the ICO, and the source of the data if it didn't come from them.
Two of those deserve extra thought in publishing.
Recipients. If you rent your list to advertisers or run sponsored mailings, the person is entitled to know who received their details. That's much easier if every selection and list rental is recorded against the people in it.
Source. B2B files are often built partly from event lists, bought data and colleague requests. If the reader didn't give you the data themselves, you need to tell them where it came from. If you're ABC or AAM (formerly BPA) audited, you should already be recording the source and date of each request. The same record does double duty here.
Much of the supporting information should already be in your privacy notice, and the ICO says you can point to it rather than rewriting it.
Other people's data
Some records will mention other people. The obvious publishing example is a colleague request, where someone else at the reader's company asked for the title on their behalf. You don't have to disclose another person's information unless they consent or it's reasonable to do so without consent. The ICO's guidance sets out a three-step process for deciding. Work through it, and note what you decided and why.
Send the response in a commonly used electronic format if the request came in electronically, unless they ask for something else.
Complaints: the newer rule
This is the bit many publishers will have missed. Since 19 June 2026, under the Data (Use and Access) Act, every organisation must have a process for data protection complaints. The ICO's guidance on receiving a complaint says you must acknowledge it within 30 days, look into it without undue delay and keep the person updated.
A reader unhappy with how you handled their SAR is exactly that kind of complaint. If you refuse all or part of a request, you also have to explain why and tell them about their right to complain to you, to the ICO and to the courts. You don't need a separate system. Your existing complaints process can do the job if it meets those rules.
Keep a log
For every request, record when it arrived, who checked identity, where you searched, what you sent or withheld and why, and when you replied. If the ICO ever asks, a short log answers most of their questions before they ask them.
Where we fit in
None of this needs special software, but it's easier when the data is in one place and you can see who changed what. In Adeptis, our all-in-one platform for smaller publishers, consent is recorded by channel and media group on each contact, and merges and gone-aways keep their own history. In Avio, our subscription platform for larger publishers, the event log records changes to orders down to the field, and the work queue can track a request from arrival to reply.
If a SAR has shown you how scattered your reader data is, our team can do a one-off data clean to pull it back together.
If you'd like to talk it through, get in touch.
Rob Sherwood is Managing Director of Adept Data Services. He has spent his career in subscriptions and circulation, at WDIS, Optima and CDS Global before founding Adept.