How should organisations prepare to handle GDPR erasure requests across structured and unstructured data sources?

Organisations should map where personal data lives, then create a repeatable process to find, verify, and delete every instance across databases, files, workstations, cloud storage, archives, and copies. They also need evidence that deletion occurred, plus a way to notify third parties if data was shared. Without that end to end capability, compliance becomes slow, inconsistent, and hard to prove.

Preparation starts with locating personal data wherever it exists, not just in primary systems. That means building a data map that includes structured databases, file shares, collaboration tools, endpoints, cloud storage, backup sets, archives, exports, and copied datasets. For erasure requests to be workable, each source needs an owner, a search method, and a defined deletion or suppression path.

For organisations handling this at scale, the hard part is not the request itself but completeness. Data often persists in replicas, log files, test environments, cached exports, and user workstations long after the original record is changed. A useful readiness plan therefore treats discovery, verification, and deletion as one workflow rather than separate tasks. That is the practical difference between a one-off manual cleanup and a repeatable privacy process supported by the GDPR.

Why structured and unstructured data need different deletion methods

Structured data is usually easier to search and delete because it lives in systems with records, identifiers, and queryable fields. Unstructured data is harder because personal data may appear in documents, email threads, shared folders, spreadsheets, scanned files, ticket attachments, or free-text notes. Preparing for erasure requests means matching the method to the storage type, then proving that the right item was removed rather than broadly wiping adjacent content.

That distinction matters because the same person can appear in both environments in different forms. A customer may be a clean row in a CRM, a named attachment in a case file, and a copy in an analyst’s download folder. If the organisation only deletes the row, the request is not really complete. If it deletes too broadly, it can disrupt other records or create operational gaps. For that reason, erasure handling should be tied to content classification, record ownership, and retention rules, not just to database administration.

How to build a repeatable erasure process that can be proved

A reliable process usually has five steps: receive and validate the request, identify all relevant data sources, delete or suppress the data where deletion is required, confirm the outcome, and retain evidence of completion. The evidence layer is especially important because GDPR compliance is not only about doing the right thing, but being able to show what was done, when it was done, and which systems were affected.

That proof should be operational rather than ceremonial. Teams need deletion logs, ticket history, system output, exception records, and escalation notes where a source cannot be fully erased because another obligation applies. Where data has been shared externally, the process should also support notification to recipients so downstream copies can be handled consistently. Good practice is to define the erasure workflow before the request arrives, then test it against real data paths so the organisation is not discovering exceptions under deadline pressure. The GDPR’s data protection by design expectations make that planning discipline central, not optional.

Risk and Threat Considerations

Erasure requests fail most often because organisations underestimate hidden copies, retention layers, and unstructured repositories. The risk is not only a compliance miss, but also inconsistent deletion across systems, which can leave personal data exposed long after the business believes it has been removed.

Failure mechanism: A record is deleted in the source system, but replicas, backups, exports, logs, shared documents, or endpoint copies remain searchable and retrievable, creating a partial erasure that is hard to detect and harder to prove.

Impact: The organisation may continue processing personal data without a lawful basis, fail to meet deletion deadlines, and lack defensible evidence if challenged by a regulator, customer, or partner.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 sets the technical controls, while GDPR defines the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	A.5.15 — Data protection by design and by default	Erasure readiness depends on designing deletion into data handling across systems.
	A.5.17 — Record of processing activities	A complete data map is needed to find where personal data exists for erasure.
	A.5.29 — Supervisory authority cooperation	Delete requests may need evidence and response handling if challenged or investigated.
Recommendation — Design deletion workflows into data collection, storage, and sharing processes from the start. Maintain current records of processing to support locating and erasing personal data. Retain erasure evidence and response records so you can demonstrate compliance.
CIS Controls v8	CIS-3 — Data Protection	Supports locating, protecting, and securely removing personal data across stores.
	CIS-5 — Account Management	Ownership and access paths affect where copies of personal data are created and retained.
	CIS-8 — Audit Log Management	Deletion must be evidenced with logs and records of what was removed and when.
Recommendation — Apply data protection safeguards to identify, store, and delete personal data consistently. Review accounts and access paths that can create or retain personal-data copies. Preserve audit records that show which data was deleted, by whom, and when.

Practitioner Guidance

What to prioritise: Start with the systems most likely to create untracked copies, especially email, shared drives, collaboration platforms, analytics exports, and endpoint storage. Those are usually the places where structured deletion logic breaks down.

What to verify: Before treating the process as ready, confirm that each high-risk source has an owner, a search method, a deletion method, and an exception path. If any source cannot support all four, treat it as an open control gap rather than an implementation detail.

Practitioner takeaway: Erasure readiness is not a database feature, it is an end-to-end data handling capability, and it is only credible when the organisation can find every copy, remove it consistently, and prove the result.