THE TAKEAWAYS
What to take away
- Erasure includes not only deletion but also making the individual no longer identifiable from the data
- Fix intake methods, identity and agent verification, and fees in advance so they can be published
- Where a ground exists, act without delay within the necessary limits; handle retention collisions with alternatives
- Design erasure across primary data, derivatives, backups, and processors, and verify after execution
- Notify the individual without delay whether or not you complied, and keep the full record set
EDITORIAL PRACTICE
First, separate the types of requests
Requests from individuals come in types: disclosure, correction, addition or deletion of content, suspension of use or erasure, and disclosure of third-party provision records. They look similar but differ in requirements and responses. This article's subject is suspension of use and related measures: stopping the use of, or erasing, personal data. The guidelines read 'erasure' broadly: beyond deleting data, making the individual no longer identifiable from it also counts as erasure.
The grounds for suspension or erasure are enumerated in the Act. They include unlawful handling such as use beyond purpose, improper use, acquisition by wrongful means, and improper third-party provision. They also include cases where the business no longer needs to use the data, where a leakage or similar incident has occurred, and where the individual's rights or legitimate interests may be harmed. Identifying the ground at intake is the foundation for the judgment that follows.
Remember an obvious fact: at the door, individuals do not speak in legal terms. Behind 'stop it', 'delete it', or 'never contact me again', a suspension request, an erasure request, and a simple unsubscribe may be mixed. Intake needs an interview design that translates the person's words into the institutional request and confirms scope and intent.
Mistranslation misaligns the response. Answering an unsubscribe-level wish with total erasure overshoots; answering an erasure request with mere suspension undershoots. Separating request types is not legal formalism; it is the first practical step toward honoring exactly what the person asked for.
Disclosure and suspension requests may also arrive together, in stages: first confirm where the data lives through disclosure, then ask for suspension or erasure based on the result. Manage each type with its own case number and deadline while keeping related requests from the same person visible as one bundle, and the responses stay consistent.
Also note for triage that some information falls outside the statutory category of retained personal data, such as short-term data scheduled for deletion within six months. Being out of scope and choosing to comply voluntarily are separate decisions, and the distinction needs careful explanation at the notification stage described later.
Request type also drives internal routing: disclosure to the information-management team, correction to the business team that owns the data at its source, suspension to legal and operations together. Correct typing at intake reduces internal hand-offs and speeds the first move. Typing speed translates directly into shorter handling times.
Sources: [1]
EDITORIAL PRACTICE
Design intake and identity verification in advance
How requests are received is something the business determines and publishes beforehand. Section 3-8-7 of the guidelines lists what the reception method covers: where to submit, the form of the request, how the requester or agent's identity is confirmed, and how fees are collected. In an organization without a defined intake, requests sink into individual mailboxes, and delay itself becomes the problem.
Identity verification is a balance. Too loose, and impersonation leads to wrongful erasure or disclosure. Too strict, and legitimate rights are obstructed. The system's design is that the business confirms, by its predetermined method, that the requester is the individual or their agent. Design the method in tiers matched to the request type and risk.
Prepare for agents as well: agents delegated by the individual, and legal representatives of minors or adult wards. Procedures for checking letters of attorney and legal authority cannot be invented after a request arrives. Put the required documents and how confirmations are recorded into the intake checklist.
Fees are also a design item. Suspension requests themselves normally carry no fee, while disclosure and similar requests may charge fees within actual cost. Fix the amounts and collection method in advance so they can be explained at request time. Surprise charges create a second friction.
Intake recording starts at that moment: date and time received, request type and scope, verification method and result, and the response deadline. Every later judgment and notice traces back to this record. An undocumented response cannot prove, in an audit or dispute, that anything was done. Standardize the intake form so the same record survives staff changes.
Diversified intake channels are another challenge: web forms, email, phone, post. Unless every channel converges into one ledger, deadline management breaks. Define the first-response rule per channel and when entries are transcribed into the ledger; that is the precondition for having multiple doors.
Intake information is normally published within the privacy notice on the website. Make the path to the contact point, address, and forms effortless to follow. A published window that cannot be found is practically the same as no window at all. Add a user-eye check of the path to the review items for published information.
Sources: [1]
EDITORIAL PRACTICE
Eligibility: checking grounds and collisions with retention duties
On receipt, first check whether the request meets a statutory ground: unlawful handling, no longer any need to use the data, a leakage-type incident, or a risk to the person's rights. The guidelines state that where a ground exists, the business must suspend use or erase without delay, within the limits necessary to correct the violation. Both 'without delay' and 'necessary limits' are yardsticks for judgment.
The hardest practical problem is collision with statutory retention duties. Records that tax, accounting, or industry law require to be kept cannot be erased on request immediately. This collision is not a reason to abandon judgment; it is handled by design, through alternative measures or erasure after the retention period ends, as discussed later. Whether the retention basis can be identified per record decides how well this works.
Scoping the erasure is also judgment. A person's data is scattered across core systems, analytics platforms, backups, processors, and paper forms. Identify the retained personal data in scope using the data map. Erasing everything versus suspending data tied to a specific purpose are very different amounts of work.
Judgment carries a clock. Responses must be made without delay, and the individual must also be notified without delay, including when the decision is not to comply. The more a case needs internal approvals and legal review, the more progress tracking and interim communication design matter. Silence is what grows distrust fastest.
Documenting the basis when deciding a request does not qualify is part of the judgment too: why it falls outside the grounds, and on what facts. Without an organized basis, the explanation fails when the person asks for reasons at notification. Judgment records also protect the responding organization.
Settle decision authority as well. Front-line staff should not decide alone; define the route through the privacy officer or legal. But long routes delay responses. Build triage criteria in advance: clear-cut standard cases proceed at the front line, and only cases with collisions or exceptions escalate.
Fact-finding scope is part of judgment practice. Verify in system logs and processor records whether the handling the requester points to actually occurred. Skipping verification produces responses to violations that never happened, and misses violations that did. Write the verification procedure and the kinds of evidence used into the judgment checklist.
Sources: [1]
EDITORIAL PRACTICE
Implementing erasure: deletion, de-identification, and derived data
Erasure has more than one method. As the guidelines note, beyond deleting data, making the individual unidentifiable from it is also erasure. Aggregation and anonymization that sever the link to the person can be the right tool in some situations. The goal is protecting the person's rights; physical deletion is not the only answer.
Implementation differs per data location: the primary database, search indexes, caches, logs, copies in analytics platforms, machine-learning features. Erasing only the primary store while derivatives survive is survival in substance. The data map and lineage prepared in peacetime become the work instructions here, as-is.
Backups are a realistic issue. Where immediate rewriting is impractical, define the policy in advance: re-apply erasures on restore, so erased data is erased again after a recovery, or let backups age out through generation management. Without a policy, erased data resurrects on restore.
Do not forget processors' copies. Completing your own erasure while a processor retains the data is not a completed response. Put instruction and completion-report clauses in contracts, and at execution time obtain the processor's completion confirmation as evidence. For SaaS, confirm the admin-console operations and what proof the vendor can give, in advance.
The choice between suspension and erasure is also implementation design. Suspension keeps the data but stops its use, fitting cases with possible resumption or legal retention. Erasure is irreversible. Decide from the request's wording and ground which is needed, and record the decision. The more irreversible the erasure, the thicker the pre-execution checks should be.
The work ends with verification. Search for remnants of the erased scope; confirm suspended data is no longer referenced by business screens or batch jobs. Separate the executor from the verifier, and attach verification results to the case record. Because erasure makes things invisible, design how you confirm disappearance before you erase.
Prioritizing erasure is another practical device. Process data that is public, searchable, and referenced daily first, and handle low-frequency archives on a plan. Working from the highest-risk locations minimizes the individual's disadvantage during the handling period. Record the reasoning for the order in the case file.
Sources: [1]
EDITORIAL PRACTICE
When it is difficult: protect rights with alternative measures
The system also provides for cases where suspension or erasure is difficult. Where it would require a large amount of expense, for example, taking alternative measures necessary to protect the individual's rights and interests can suffice. The guidelines give examples such as promising to erase the data once the retention period expires, and publishing or notifying that fact.
The point of alternative measures is to not end at 'we cannot'. Why it is difficult, how the person's rights are protected in the meantime, and when it will finally be resolved: design these three and make them explainable to the person. Concretely: restrict access during the retention period, confine use to that sole purpose, and erase the moment the period expires.
Do not let alternative measures become permanent. Register the post-period erasure as a dated task in a ledger and verify execution. A verbal promise dies with a staff change. Keep the alternative-measures ledger joined to the case records, with all open measures visible in one list.
Do not claim difficulty lightly, either. Costing something and requiring a large amount of expense are different claims. Ordinary operational burden is not difficulty; it is the work to be done. Unless the criteria are articulated internally, front-line workload sentiment will sway decisions.
Even with alternative measures, accountability for what was not done remains. In the notice to the individual, separate what was done, what was not done, the reasons, and the alternatives. The care taken in that communication influences whether disputes and regulator consultations follow.
Designing alternatives is also a chance to face system realities. If erasure is difficult because of architecture, that is a declaration of technical debt. Accumulating the reasons for difficulty in case records gives the next system renewal its evidence for requiring partial-erasure-capable design.
Explaining alternative measures calls for plain language. Whether the difficulty is cost or technology, translate it into the person's everyday words. Alternatives are easily heard as the business's excuse, so the transparency of the explanation decides how it lands. Naming concrete timing and means is the minimum of good faith.
Sources: [1]
EDITORIAL PRACTICE
Notification and records: tell the person, and keep the trail
When the response is done, notify the individual. Based on Article 35(7), the guidelines organize the duty to notify without delay when suspension or erasure was carried out, when the decision was not to comply, and when a different measure was taken than requested. The system's shape is to report not only what was done but also what was not.
The notice should state concretely: the measure taken, the scope covered, the date, and a contact point. Do not settle for boilerplate; identify the scope as it relates to this request. The quality of a notice is whether the person can read how their request was handled.
Keep the full trail from intake to notice: the request, identity verification, the basis of judgment, execution evidence, processor completion reports, and a copy of the notice. With that set intact, audits, regulator inquiries, and repeat requests can all be answered consistently. Set the retention period and access rights for these records in advance.
Use the records for improvement as well. Aggregate counts by type, handling days, and points of difficulty, and structural problems surface: flawed retention design, gaps in the data map. Request handling is not only a cost; it can be read as audit results for your own data management.
When deciding not to comply, or to take a different measure, record the decision path and approver too. Non-compliance decisions are exactly the ones examined later. Recording the process is what guarantees organizational explainability.
Design notification and recording as state transitions in case management to reduce omissions: received, verifying, judged, executing, notified, closed, with alerts on overdue cases. This moves request handling out of personal inboxes into organizational case management.
The notification channel needs design too. Replying through the channel the person used is the default, but postal or identity-bound methods may fit better. A notice that never arrives becomes a second problem, so decide the delivery-confirmation method as well. Include the case number and contact point so follow-ups continue as the same case.
Sources: [1]
EDITORIAL PRACTICE
Peacetime preparation decides response speed
The speed and accuracy of a response are decided almost entirely by peacetime preparation, not by effort on the day. First, the data map: which system holds which personal data, for what purpose, for how long. Without that map, merely identifying the scope consumes the days.
Second, retention design. Since data that is no longer needed becomes a ground for requests, organizations that set retention periods and erase routinely in peacetime face far smaller workloads per request. Request-handling burden is the deferred bill for unmanaged retention. Period rules and automated erasure are the highest-leverage preparation.
Third, procedures and drills. Intake forms, judgment triage, erasure work instructions, notice templates. Document them and rehearse with a mock request at least yearly. Real requests will not wait. Flaws found in drills become a fixable list on the procedure side.
Fourth, the processor and contract inventory. List processors and, in peacetime, confirm whether they can follow erasure instructions and in what form they report completion. Learning a processor's specifications after a request arrives is too slow. Include data erasure at contract end and at migration in this inventory's scope.
Fifth, reporting to management: request counts and handling status, difficult cases, improvement progress. Personal-data request handling should be reported as an indicator of data-governance health, not left as a legal or front-line chore. A reporting venue also makes investment in peacetime preparation easier to approve.
The destination of preparation is turning requests from exceptional events into routine work. In a routinized organization, a request is not a reason to panic but an occasion to watch the designed flow run. Building that state is the most reliable protection for the individual and the business alike.
Sources: [1]
WITH OPERUN.
Delegate everyday AI management.
Handling suspension and erasure requests is the work of translating legal knowledge into an operational flow. Intake, verification, judgment, execution, alternatives, notice, records: designing that flow in peacetime turns request day from a scramble into a confirmation of the design. This article is a general organization of the system; for specific cases, decide with professional advice.
Discuss your product and AI workPrimary sources
Sources checked on 11 November 2026. The workflows and checklists are editorial proposals.
- [1]
Share this insight