Finding personal data for DSARs and erasure

Why finding personal data across systems sets your DSAR response time

When an access request or erasure demand arrives, the clock is one month under the GDPR, and the search for personal data is usually where that month is won or lost. The controller owns both the deadline and the outcome: it decides what data exist, what is disclosed or deleted, and what is refused. The cost and effort of meeting the deadline depend mainly on how current the record of processing and the inventory of systems and processors are. A controller that already knows which systems hold customer data, who can access them and which processors host them can search in days. One that must discover those systems during each request cannot.

The EDPB's guidelines on the right of access expect the controller to search all IT systems and non-IT filing systems using search criteria that mirror how the data are structured, such as name and customer number. The record required by Article 30(1) is the natural starting point for that search: it lists the purposes, categories of data subjects and personal data, recipients, third-country transfers and, where possible, erasure time limits for each processing activity. An implementation partner can help prepare the inventory, document a search method for each system, and test that the method finds known records. Only the controller decides what the search returns and how each result is answered.

This page does not give a price for building or refreshing this inventory. The effort depends on the number of systems, how many are self-hosted and how many sit with external processors, and how much of the search can be scripted. Ask any partner for a written scope that names the systems covered, the search criteria to be tested, the processor assurances to be collected and the deliverables, because the quote follows from that scope. Confirm with your own team how long a representative search takes today before you commit to a timeline.

Which search criteria the EDPB expects and how to build them

The EDPB expects a search to mirror how your data are structured, so the criteria you use must match the identifiers each system stores. The cards below cover the identifiers that most often decide whether a search finds everything it should, and the places where a search quietly misses data.

Name and variant spellings

Names are the most common search key and the least reliable one. Systems may store a legal name, a display name, a previous surname or a transliterated form, and a search on one spelling will miss the others. Build the search from every name variant the organization has recorded, and check how each system handles accents, case and initials before relying on a single match. Illustrative example: a customer who changed surname after marriage may appear under two records that share no other field.

Customer and account numbers

Customer, contract and account numbers usually link records across billing, support and product systems more precisely than names. The EDPB's search guidance points to identifiers like the customer number because they reflect how the data are structured. Confirm which systems store the number, whether some use a different internal key, and whether old numbers were reissued after a migration.

Email addresses and phone numbers

Contact details appear in many places that a team may not think of, including marketing lists, support tickets, invoices and login records. Search for every address and number the person has used, not only the current one, and normalize formats such as country codes and separators before comparing. Ask each processor whether its copies are indexed the same way, because a supplier's ticketing tool may hold the only copy of a conversation.

Employee and user identifiers

Staff and user IDs tie personal data to access logs, HR systems, collaboration tools and cloud accounts. They are often the only key that reaches activity records, so a search without them can leave logs out of scope. Map which identity provider issues each ID, and confirm whether a deprovisioned account still keeps its ID and history in archived systems.

Device, cookie and advertising identifiers

Device IDs, cookie values and advertising identifiers can be personal data when they single out a person, even without a name attached. These keys often sit in analytics platforms, web server logs and consent records, and they may not match any customer number. Decide in advance whether the request covers them, record the reasoning, and confirm which tools can search by identifier rather than only by account.

Pseudonymised keys and activity logs

Pseudonymised data remain personal data, so a hashed user token, a tokenized card reference or a pseudonymous ID must be searched like any other identifier. Activity logs and records of searches can also be personal data within scope. Document which keys link back to a person, who holds the mapping table, and how the mapping is protected, since the person who can reverse a pseudonym is usually the one who must answer the request.

Who searches, who assists and who answers

The controller remains legally responsible for answering each access or erasure request, including when a processor or partner holds part of the data. Inside the organization, the privacy or compliance lead owns the process, the record of processing and the response deadline, while named data owners in HR, customer service, finance and product confirm which systems hold personal data for their activities and who can run searches in them. Their input is what turns a generic system list into a usable search plan.

Process owner: keeps the request log, sets the search criteria standard and signs off each response.
Data owners: confirm the systems, paper files and mailboxes for their activities and name a backup for each.
Access holders: restrict who may run searches and export results, and record each search.
Record keeper: keeps the record of processing current so the search scope matches what the organization actually does.
Decision maker: decides whether an exemption, refusal or extension applies, with reasons documented.

Confirm that your named owners can actually run searches in their systems within your response window, not only that they are listed in a spreadsheet.

How to build a system and processor inventory you can search in a deadline

This sequence turns a vague list of applications into a record of processing and a set of search keys that let you find one person's data across every system and processor within the one-month response window. Each step closes with a check you can show an assessor.

Scope the systems that hold personal data
Start by listing every system, application, database, file share, mailbox store, SaaS tool and paper filing location where personal data could sit. Include systems run by your team and by vendors, and include non-IT filing systems, since the EDPB expects searches to reach them too. Owners are the business units and IT leads who know what they run. The step is complete when each system has a name, an owner and a one-line description of the data it holds, and the list has been signed off by someone who can say what is missing.
Map each system to a record of processing entry
Match every scoped system to the activity it supports in your record of processing, such as recruitment, payroll, training, badge and access management or prospect lists. Article 30(1) asks for the categories of data subjects and personal data, recipients, third-country transfers and, where possible, erasure time limits and a general description of security measures. Where a system has no matching activity, either the record is incomplete or the system should not hold personal data. The step closes when every system points to a record entry and every record entry points to at least one system.
Record the search keys and data owners
For each system, write down the identifiers you can search on, such as full name, email address, employee or customer number, account ID and any pseudonymous reference, and note where each identifier is stored. The EDPB expects search criteria that mirror how the data are structured. Also record the named owner who can run the search and confirm results. Note that pseudonymised data remain personal data, so pseudonymous keys belong in the search list too. The step is done when a person outside the project could run a search on any system using only this record.
Identify processors, sub-processors and their assistance terms
List every processor that hosts or handles personal data for you, and each sub-processor they rely on. For each, check the processing agreement against Article 28(3), particularly the duty to assist with rights requests and with Articles 32 to 36, the duty to delete or return data at the end, and the duty to provide information and allow audits. Record the response time and the contact route written into the contract, and the processor's search keys. Confirm these points with the processor in writing where the contract is silent. The step closes when every processor row shows a contact, an assistance clause reference and a sub-processor list.
Test one search end to end
Choose a test identity, ideally a dummy record created for the purpose, and run the full search across every system in the inventory, including processor-hosted systems. Log each system searched, the criteria used, the number of hits and the time taken. Compare the results against the record and note any system that returned nothing when you know it holds data, or that you could not reach. Treat activity logs and search activities as potentially personal data within the scope of the request, so keep the test log controlled. The step is complete when the test produces a written result with every gap either fixed or assigned to an owner.
Document gaps and retest after fixes
Turn each gap from the test into a tracked item with an owner and a target date set by your own team. Common gaps include shadow spreadsheets, unindexed archives, mailboxes outside the search tool and processors that cannot search by a given key. Fix what you can, record what you accept as a residual gap with the reason, and rerun the search on the changed systems. The step closes with a signed gap register and a retest result, which together show an assessor that the inventory works in practice and not only on paper.
Set a maintenance owner and review cycle
Name one accountable owner for the inventory, usually the DPO function or the privacy lead, and give that person authority to require updates from system owners. Set a review trigger for new systems, new processors, contract changes and changes to the record of processing, and schedule a periodic retest. The EDPB guide lists keeping the register up to date as a core practice, so the inventory must change when the systems change. Ask any implementation partner to hand over the inventory, its search procedure and the maintenance workflow as documented deliverables, and confirm your own team can run them without outside help.

Passing erasure and rectification results on to recipients

Article 19 requires the controller to tell each recipient to whom personal data have been disclosed when it carries out a rectification, an erasure or a restriction under Articles 16, 17(1) and 18. The duty has an exception: the controller may skip notice where it proves impossible or involves disproportionate effort. For the inventory, this means a field that shows only where data are stored is not enough. Each record needs to show who received the data, when, and under which processing activity, because the controller cannot notify a recipient it has not logged. The disclosure log must be kept at the level of individual recipients, not just as a generic category such as "payroll provider."

Where the controller decides not to notify a recipient, it must be able to show why. Keep a written note for each case that names the recipient, the data affected, the reason notice is impossible or disproportionate, and who approved the decision. Impossibility is usually a matter of fact, such as a recipient that no longer exists. Disproportionate effort is a judgment that needs a documented comparison of cost and effort against the impact on the individual. Store these notes with the request record so that the same file answers both the requester and any supervisory authority that asks how the request was handled.

Confirm recipient lists and exception decisions with your legal team before you rely on them. Counsel should decide what counts as a recipient in your processing chains, including processors, sub-processors and independent controllers, and whether a given case meets the threshold for disproportionate effort. Ask counsel to review the notice template and the decision record format once, then apply them consistently. Where a system holds a copy that is not reachable by normal deletion, such as a backup or a replica, record that gap in the same log so the notification decision and the technical limitation are documented together.

What makes the search larger or smaller

The search for a data subject's information grows or shrinks with a handful of structural factors. Each one is a design choice or a documentation gap that the organization can change before the next request arrives, and most of them compound each other.

Number of systems and filing systems

Every application, database, file share, mailbox store and paper archive that holds personal data must be searched, not only the main CRM. The EDPB expects the controller to cover non-IT filing systems too. Reduce the search by consolidating where personal data sits and by keeping a current list of every location in the record of processing. Check whether each system can be queried by the identifiers you actually use, such as name, email address or customer number.

Number of processors

Data held by a processor, such as a hosting provider, payroll bureau or support desk tool, is still the controller's data for access purposes. Under Article 28(3), the processor contract must require assistance with rights requests, so the search extends to each processor and its sub-processors. Keep a register of processors with named contacts and agreed response times, and confirm in each contract how quickly the processor must return results.

Data spread across backups and logs

Backups, application logs, audit trails and replicas often hold copies of personal data that no one indexes. The EDPB guidelines state that activity logs and search activities can themselves be personal data within scope. Ask how long each log and backup is kept, whether it can be queried by identifier, and whether it is included in the search or handled under a separate documented approach.

Age of the record of processing

A record of processing that was written once and not reviewed will name systems that have been retired and omit new tools added by product or marketing teams. Article 30(1) requires the record to list categories of data, recipients, transfers and, where possible, erasure time limits. Review it on a fixed schedule and after each new system or processor is approved, so the search starts from current facts.

Volume of past requests

Each completed request leaves behind exports, search notes and correspondence that may need to be retrieved or checked in the next case. High volume also tends to expose gaps in search criteria, because the same systems are repeatedly found to hold data the team did not expect. Track request volume and the systems each case touched, then use that history to tighten the search steps and to prioritize where to build better tooling.

Staff turnover and undocumented owners

When the engineer who knows how a legacy system stores customer records leaves, the search slows or stops. Each system in the inventory should name an accountable owner, a backup owner and the search method that works for it. Document these in a runbook kept with the register, and test it periodically by having someone outside the original team run a sample search.

Questions buyers ask about finding personal data for DSARs

Can we build the personal data inventory for DSARs in house?

Yes, many organizations do this in house, provided the people doing it know the systems and the processing well enough to find every place personal data sits. The work needs three things: someone who owns the record of processing, system owners who can say what they hold and who can query it, and a process that keeps the inventory current as systems change. Outside help usually makes sense when the estate is large, when systems are poorly documented, or when no internal team has time to chase owners across departments. Whichever route you take, the controller remains responsible for the result, and an implementation partner can prepare the inventory and search procedures but does not take that responsibility from you.

What must our team supply before an inventory can start?

The inventory is only as good as the inputs your team provides. Plan to supply:

The current record of processing, with activities, categories of data, recipients and storage periods.
A list of IT systems, databases, file shares and SaaS tools, with named owners.
A list of processors and sub-processors, with the contracts that set out their duties.
Access to administrators or read-only accounts so the search can be tested against real records.
Confirmation of the identifiers you use for people, such as name, customer number or employee ID, since search criteria should mirror how your data are structured.

Missing items here are the most common reason an inventory takes longer than planned, so confirm them before work is scoped.

How long does building the inventory take?

The duration depends on scope, and it should be agreed in writing before work starts. The main drivers are the number of systems and paper or non-IT filing systems in scope, how much documentation already exists, how many system owners must be interviewed, and whether searches must be tested on live records. Ask any provider to state the systems covered, the deliverables (inventory, search criteria per system, and a documented procedure), the assumptions about access, and what is excluded. A fixed-scope agreement makes these trade-offs visible before the work begins.

Must our processors help us find data, and by when?

Yes. Under Article 28(3), a processor contract must require the processor to assist the controller with data subject rights requests, so your processor agreements should set out how that help is given, who requests it and how quickly it must be provided. The deadline you face is the controller's, which is one month under the rights framework, so processor assistance should be scheduled inside that window. Check each processor contract for a named assistance route, a contact point and any cost terms, and test that route before a live request arrives.

What should we do when a system cannot be searched?

Do not treat an unsearchable system as a reason to skip it. Record the system in the inventory, document why a search is not possible, and decide on a workaround such as an export, a scripted query, a database view or a manual review of a defined file set. Consider whether the gap reflects a design problem that should be fixed, such as missing identifiers or data spread across unindexed archives. Document each decision, because the search approach and its limits may later be questioned by a supervisory authority.

Does a complete inventory prove GDPR compliance?

No. An inventory is evidence that you know where personal data sits, which supports your ability to answer requests, but it does not by itself show compliance. The GDPR requires no audit, attestation or certificate, and supervisory authorities judge whether you can answer requests on time, search all relevant systems, pass results on to recipients and document decisions. The inventory must also stay accurate, which means it needs an owner, a review cycle and a link to the procedures that use it. Independent assessors can review the evidence, but only the controller owns compliance.

What to confirm with your legal team and processors

Before any search for personal data starts, confirm the inputs that decide the scope of that search. The first is the current record of processing under Article 30(1). Ask your legal or privacy lead whether the record lists every activity that touches personal data, including the categories of data subjects, categories of recipients and transfers outside the EEA, and whether it was last reviewed after the most recent system change. A record that omits a SaaS tool or an HR platform will send your search to the wrong places. Also confirm where storage periods are recorded. Article 30(1) requires erasure time limits only where possible, so many organizations hold gaps that the search must account for, such as logs or exports with no defined retention.

Next, check your processor contracts. Under Article 28(3), a processor must assist the controller with rights requests and must provide information needed to show compliance. Confirm that each contract names that assistance, sets a practical response window and states how the processor will return search results, since an assistance clause with no timeline does not help you meet the one-month deadline. Ask for the current sub-processor list and confirm that each sub-processor's terms flow down these duties. Where you are the processor yourself, confirm which controller instructions you must follow before you search or delete anything.

Finally, establish whether any transfer relies on a standard contractual clause set. Ask counsel to identify which processors or sub-processors receive data outside the EEA and under which instrument: the controller-to-processor clauses in Commission Implementing Decision (EU) 2021/915 or the general transfer clauses in Commission Implementing Decision (EU) 2021/914. Read both decisions yourself, or with counsel, before you rely on them, because the clause set determines who must assist with which requests. Record the answer in your DSAR procedure so that the search steps, and the processor contacts for each system, are fixed before the first request arrives.

How DeployOpen prepares your inventory and search method

DeployOpen works on the inventory and search method behind your rights responses in the same order a response runs: which systems hold personal data, how each can be searched, and how results reach the team that answers the request. The work runs inside your own cloud accounts, data centers or air-gapped networks, and your organization keeps ownership of its record of processing and its decisions.

How we scope

Written scope lists the systems, self-hosted platforms and processors to be inventoried before any work starts.
Scope states which search criteria each system supports, such as name, customer number or account identifier.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

Build a system inventory that maps each platform to the record of processing activities it supports.
Configure search and export procedures for each system, including non-IT filing systems where they hold personal data.
Test each search against sample identifiers to confirm results are complete and that logs and backups are flagged correctly.

How we hand over

Deliver a documented search runbook that staff can follow without the implementation team present.
Provide a processor contact list recording the assistance each processor has agreed to provide for rights requests.
Document how results are passed to recipients, and how each request, answer and refusal reason is recorded.

How we support

Ongoing support and upgrades are available as a retainer, so inventory and search procedures can follow system changes.
Re-run agreed search tests after platform upgrades, new integrations or new processors where the retainer covers them.
Your counsel or data protection officer confirms legal interpretation; an independent auditor issues any assessment report.

Finding personal data across systems for DSARs and erasure