Exercising data subjects’ rights - a request for access as a test of knowledge about one’s own data
Exercising data subjects’ rights under the GDPR boils down to a single step on which all others depend: identifying every instance where a company processes a specific individual’s data. The rights of access, rectification, erasure or data portability can only be exercised in respect of data whose existence the controller is aware of. Therefore, a request under Article 15 of the GDPR is, in practice, a test that assesses not the procedure, but the company’s knowledge of its own systems.
We have outlined the rights themselves and the conditions for exercising them in our guide to data subjects’ rights under the GDPR. This text focuses on the operational aspects: time limits, the scope of the search, the conflict between erasure and the obligation to retain data, and proof that the request has been complied with.
The one-month period runs from the date the request is received, not from the moment it is noticed
Article 12(3) of the GDPR requires information to be provided without undue delay, and in any event within one month of receiving the request. An extension of a further two months is permitted due to the complexity of the request or the number of requests, but the individual must be informed of this - stating the reasons - within the first month. Two details regularly take organisations by surprise. Firstly, the time limit runs from the date on which the request reached the controller via any channel, not from the date on which it reached the DPO. A message sent to a general customer service address, which spent two weeks awaiting forwarding, had already used up half the time limit. Secondly, an extension is not a time buffer in the event of a lack of tools. The EROD guidelines on the right of access expect the controller to organise themselves in advance so as to respond quickly and accurately - and the complexity justifying an extension must stem from the nature of the request, not from ignorance or disorganisation in the systems. Verification of identity (Article 12(6)) is justified where there are reasonable doubts, but should not become a means of stalling the process by requesting documents which the organisation has not previously required from that individual.
An access request reveals whether the controller knows where the data is
The scope of an access request is, by default, comprehensive: it covers all data relating to the individual, unless the individual narrows it down themselves. The EROD guidelines explicitly state that the controller must search all IT systems and records outside them, using criteria corresponding to the way in which the information is structured - for example, first name and surname, customer number, employee number. This is where the problem begins. The record of processing activities describes data categories and purposes, rather than specifying in which tables and folders an individual’s data is actually stored. A response prepared on the basis of the register and the knowledge of process owners covers only the systems that someone happened to remember. It omits the rest: an export to a spreadsheet from three years ago, an attachment in a sales representative’s email inbox, the ‘comments’ column in the ordering system where consultants note down telephone numbers. This is shadow data in its most practical form. Such a response is incomplete in a way that the organisation cannot rule out - and this is worse than a deliberate omission. A person who subsequently lodges a complaint and presents a document containing data not included in the response undermines not only that single instance but the credibility of the entire process.
The right to erasure versus the obligation to retain data
The second area where the exercise of rights breaks down is Article 17 of the GDPR. The EROD report from the coordinated inspection campaign of 2025 identified, amongst seven recurring problems, difficulties in determining retention periods, deleting data from backups, and using anonymisation instead of data erasure. The authorities also noted that the findings confirmed the conclusions of the 2024 inspection campaign concerning the right of access to data, in particular the lack of documented internal procedures. A legal obligation arising from tax, accounting or sector-specific regulations may justify a refusal to delete data. The problem is that the same customer may simultaneously be subject to a deletion obligation in the marketing system and an archiving obligation in the financial system. The authorities have highlighted a data deletion matrix as good practice, which links data types to legal bases and retention periods. Without it, decisions are made on an ad hoc basis, and the data remains intact because no one can identify which fields may be deleted. Two practical points. Replacing deletion with partial masking or pseudonymisation does not meet the requirements of Article 17 - the report states this explicitly, and the distinction between pseudonymisation and anonymisation is decisive here. Backups, in turn, require a documented procedure, rather than a tacit assumption that the data ‘will be overwritten at some point’.
How Detecto and Revelio support the exercise of data subjects’ rights
Data detection tools do not respond to a request on behalf of the controller. They solve the problem on which the response depends: they provide a map of the locations where personal data actually exists, rather than a list of locations where it ought to exist. Detecto connects to databases (including MySQL, Oracle, SQL Server, PostgreSQL and DB2), analyses schema definitions and data samples, and classifies columns containing personal data based on rules, regular expressions, dictionaries and heuristics. The result is a map identifying specific tables and columns. In one implementation, it covered over 8,000 tables in a system that had been under development for twenty years, in which the organisation had previously been unable to identify the location of personal and financial data. Detecting changes to the schema is also crucial for ensuring compliance: a new column containing personal data appears on the map before it falls outside the scope of the next query. Revelio performs the same task on unstructured data: folders, repositories, email inboxes and files in over 200 formats, with OCR for scans. This is the part of the environment not covered by any database and which is usually omitted from activity logs. With a map generated by both tools, the team searches for a specific individual’s data using their identifiers across all indicated locations, rather than just in the systems they can remember. In the event of a deletion request, the map is utilised by Oblivio, which carries out deletion or anonymisation consistently across multiple systems - with different legal bases and retention periods - and logs every operation.
Proof of compliance is part of the process
The principle of accountability under Article 5(2) of the GDPR means that, in proceedings before a supervisory authority, the company does not submit declarations but evidence: the date the request was received, the sources searched, the criteria applied, the grounds for any refusal together with a reference to the relevant provision, and confirmation of compliance. The EDPB report from 2025 explicitly recommends documenting the grounds for refusals and involving legal or compliance teams in this process. The data discovery report fulfils a function here that no procedure can replace: it demonstrates that the scope of the search was based on the actual state of the systems, rather than on memory.
Frequently asked questions
How long does the controller have to comply with a data subject’s request? One month from receipt of the request, with the possibility of a two-month extension due to the complexity or number of requests. The data subject must be informed of the extension and the reasons for it within the first month. Does a request for access require a search of all systems? Yes. According to the EROD guidelines, the controller must search all IT systems and any data held outside them, unless the data subject has narrowed the scope of the request themselves. Can the erasure of data be refused on the grounds of a retention obligation? Yes, if retention is necessary to comply with a legal obligation (Article 17(3)(b) of the GDPR). The refusal must specify the relevant provision and apply only to the data covered by that obligation - all other data must be erased.