Pope Leo XIV called his Chicago bank to update his address and phone number. He gave his legal name — Robert Francis Prevost — and correctly answered every security question. The representative told him that wasn't enough: bank policy required a branch visit in person to complete the update. When he explained he couldn't travel from the Vatican, and mentioned who he was, she hung up. The story was shared by Father Tom McCarthy, an Augustinian priest and longtime friend of the Pope, at a gathering in Naperville, Illinois, and confirmed to The New York Times.
This happened at a US bank, outside GDPR's jurisdiction. But the situation — a process that clears identity verification and still produces an absurd outcome — maps directly onto how Data Subject Requests break down. The system worked exactly as designed. That was the problem.
GDPR protects all natural persons. Data Subject Rights apply regardless of who submits them. You have one month to respond from the moment you receive the request, regardless of how inconvenient the circumstances.
For AdTech platforms processing millions of user interactions daily, DSRs are where the real state of compliance infrastructure becomes visible.
What Data Subject Rights Cover
Under GDPR Articles 15–22, anyone whose data you handle has the right to submit specific requests:
Right of Access (Article 15): What data you hold, why you're processing it, who you share it with, and how long you keep it.
Right to Rectification (Article 16): If the data is wrong, they can require you to fix it.
Right to Erasure (Article 17): Deletion of their data when it's no longer needed, when consent is withdrawn, or when there's no legal basis to retain it.
Right to Restriction (Article 18): A pause on processing while accuracy or legal disputes are resolved.
Right to Data Portability (Article 20): Their data in a standard, machine-readable format for transfer to another service.
Right to Object (Article 21): Stopping processing based on legitimate interest, or blocking their data from direct marketing use.
A platform processing RTB data must respond to requests from ordinary individuals, public figures, and heads of state alike.
Who Can Submit Requests
Under GDPR, every person whose data you process has the right to submit a Data Subject Request. That includes:
Registered users on publisher sites where you operate. If your platform processes their data — through consent signals, cookie syncing, or RTB participation — they have legal rights over that processing.
People who never interacted with your platform directly. If you acquired their data through third-party sources — data brokers, partners, vendor integrations — they can still submit requests. GDPR rights attach to the person, not to how the data was obtained.
People who don't remember interacting with you. Users often have no idea which AdTech platforms handled their data during a site visit. They may submit requests to every vendor listed in a publisher's consent framework. The obligation to search and respond still applies.
People submitting on behalf of others. Parents for minor children, legal guardians for individuals in their care, lawyers for clients. Processes for validating these representative relationships are a requirement, not an edge case.
If you process someone's personal data, that person has rights. Your business relationship with them — or the absence of one — doesn't change that.
The 30-Day Deadline
Article 15 GDPR requires controllers to respond "without undue delay and in any event within one month of receipt." Extensions of up to two additional months are permitted for complex requests, but the requestor must be informed within the first month.
The clock starts when you receive the request.
For AdTech platforms, a deletion request means searching bid logs across potentially terabytes of data, identifying every system where the user's data exists (RTB platform, analytics, frequency capping, lookalike modeling, reporting databases), coordinating deletion across vendors and subprocessors who received that data downstream, documenting the deletion, and confirming completion to the requestor — all within 30 days of receiving an email that may arrive on a Friday afternoon with no account details attached.
The GDPR Enforcement Tracker documents enforcement actions across Europe for DSR failures: missed deadlines, incomplete responses, inadequate verification. These are not hypothetical risks.
One month is a hard limit.
What Unusual Requests Look Like
AdTech platforms encounter their own version of the Pope's situation regularly.
Some requests arrive with almost nothing to work with — "delete my data," no account, no device ID, no indication of where the person encountered the platform. The obligation still applies. If nothing comes up, document what was searched and explain why the request couldn't be completed.
Some requests are for data the platform doesn't hold. A user who visited a publisher site may have no idea that the platform never saw their name, email, or any direct identifier — only a bid request with a cookie ID, a timestamp, and a handful of targeting segments. The response should say that plainly: what the platform actually collects, and what it doesn't. GDPR transparency obligations extend to the boundaries of your processing, not just its contents.
Some requests arrive in languages the compliance team doesn't speak. The law may not specify a reply language in every case, but dismissing a request because the team only works in English is difficult to defend for a platform that actively operates in that market.
Some requests challenge the legal basis directly. A user objects to processing based on legitimate interest. That objection can't be dismissed with a reference to an internal policy document or a line in a privacy notice. To continue processing, the platform needs a documented balancing test — one that looks at the specific circumstances of that user's objection, not a generic statement that the business has valid reasons. If that assessment doesn't exist, the processing stops.
Some requests are technically awkward to fulfill. If someone asks which third parties received their data, the answer in an RTB environment could involve hundreds of DSPs, with data flowing to them in milliseconds. Retrieval after the fact isn't possible — but records showing which vendors received data, when, and on what basis are. That's the point where vendor contracts and Data Processing Agreements stop being paperwork and become the only evidence you have.
Verification and Procedural Flexibility
The Pope's bank ran into two separate problems, and they're worth keeping apart.
The first is verification. ICO guidance on Subject Access Requests allows controllers to ask for information confirming a requestor's identity when reasonable doubts exist — but the process has to be proportionate and consistent with data minimization principles. EDPB Guidelines 01/2022 on Data Subject Rights put it plainly: the bar for verification should reflect what's actually being requested. Asking someone for a passport scan because they want to check their ad preferences is not proportionate. Asking them to log in through an existing account before deleting their data across all systems is. The stricter the consequence of the request, the more verification is warranted — not the other way around.
The second problem is what happens after verification succeeds. The Pope answered every security question correctly. The system confirmed who he was. It then required something from him that was physically impossible — and had no path for handling that. This is where AdTech platforms run into the same wall. A user submits an access request from an email different from their account email; standard procedure auto-rejects it. A user requests deletion but the platform stores only pseudonymous cookie IDs; the right response is to ask for additional identifiers, not to close the request. A legal representative submits on behalf of a client; verification procedures for that need to exist and should not treat every such submission as suspect.
Support teams need somewhere to send requests that don't fit the standard flow. The bank employee who hung up on the Pope wasn't negligent — she followed her instructions exactly. There was simply no step in those instructions for a verified request that couldn't satisfy a standard procedural requirement. AdTech compliance teams face the same gap: when the person handling day-to-day requests has no route to legal or privacy counsel, unusual cases either get rejected or sit unanswered until the deadline passes.
What Makes Responses Legally Sufficient
Under GDPR, a legally sufficient response meets four requirements.
Complete. An access request covers everything processed about that person — archived systems and secondary databases included. Leaving out sources because they're inconvenient to query is not a defense.
Intelligible. A raw database export doesn't satisfy an access request. Technical logs need explanation. The person receiving the response should be able to understand what they're looking at.
Free of charge. Responses cannot be billed unless a request is manifestly unfounded, excessive, or repetitive — and the burden of demonstrating that falls on the controller.
Timely. One month is binding. Extensions require documented justification and advance notice to the requestor.
ICO guidance identifies the most common failure modes: incomplete data from omitting certain systems, incomprehensible formats like raw JSON without context, and missed deadlines treated as targets rather than limits.
Build the Infrastructure First
How a platform handles Data Subject Requests shows whether its privacy compliance works in practice or only looks reasonable on paper.
Platforms that built DSR processes into their technical architecture from the start can respond quickly and completely. They know where data lives, their lookup systems work, and their vendor contracts include DSR obligations.
Platforms that left privacy as a post-launch task tend to show it. Data is spread across systems with no unified way to search. Vendor contracts don't cover DSR handling. Manual searches miss things.
The difference becomes visible when requests arrive. And they will arrive — from ordinary users, public figures, and people the platform never expected to hear from.
The Pope's bank eventually resolved the situation through a priest who knew the bank's president. That path isn't available to most companies. What's available instead is a regulatory inquiry.
This piece draws on operational experience with GDPR Data Subject Request handling and publicly reported information. It is not legal advice. For specific compliance requirements, consult qualified legal counsel.