A Right to Be Forgotten request requires HR teams to verify identity, map all data locations, apply legal retention holds, execute deletion across every system and vendor, and issue written confirmation — all within a statutory deadline. Miss any step and you face regulatory penalties or a secondary breach.

Before You Start: Prerequisites

Three foundational elements must be in place before a deletion request arrives. Building them under a live compliance deadline multiplies risk and guarantees scrambling. If your HR operation is still working through a broader infrastructure cleanup, the guide on fixing broken HR operations for small teams addresses the full scope of what needs to be in order first.

• A live data inventory. A documented map of every system holding personal data — HRIS, payroll, ATS, benefits platform, learning management system, email archives, and all third-party sub-processors. Without this, a complete deletion is impossible.
• A legal retention schedule. A jurisdiction-specific matrix that maps data categories (payroll records, tax documents, workplace injury logs, investigation files) to their statutory retention periods. This is the document you check before deleting anything. HR teams that have not built this yet should reference the approach to data validation and record integrity in HRIS systems as a parallel foundation task.
• Legal counsel access. Active litigation holds, ongoing regulatory inquiries, and ambiguous data categories require legal sign-off before deletion proceeds. Establish the escalation path before you need it.
• Vendor deletion clauses. Every third-party vendor contract must include explicit data deletion obligations, response timelines, and written confirmation requirements. Silent contracts need to be fixed now, not during an active request. The broader framework for HR triage and risk mapping covers how to prioritize vendor contract gaps alongside other inherited compliance risks.

Building a complete data inventory and retention schedule requires 20–40 hours for a mid-size HR operation. That front-end investment eliminates the 10–20 hours of unstructured scrambling that an underprepared deletion request produces.

Step 1 — Verify the Requester’s Identity and Clarify the Scope

Accept no deletion request as valid until you have confirmed who is making it and exactly what they are asking for. Identity verification is a legal requirement, not a bureaucratic step — responding to a fraudulent or misdirected request creates a separate data breach liability.

Actions

1. Log the request immediately. Record the date and time of receipt — the response clock starts now. Under GDPR Article 17, you have one calendar month. Under CCPA/CPRA, you have 45 days. Use your automation platform to timestamp the intake automatically and open a tracked request record. If your team uses Make.com for HR workflow automation, intake logging and deadline tracking are straightforward to build without developer support.
2. Verify identity using a documented method. For former employees, match against known identifiers: employee ID, last four of SSN, date of birth, verified email address. Do not rely on a single factor. Document the verification method used.
3. Clarify scope in writing. Respond with a written acknowledgment confirming receipt and asking the requester to specify: all personal data, specific data categories, or specific systems. This protects against scope creep after the fact.
4. Confirm legal basis for the request. RTBF applies when data is no longer necessary for its original purpose, when consent has been withdrawn, or when there is no overriding legitimate ground for processing. If the requester’s stated reason does not meet one of these criteria under applicable law, document the basis for declining and notify the requester in writing within the response window.

Common Mistake

Treating every deletion request as automatically valid. Incomplete or unverifiable requests can be declined — with a written explanation — without initiating the deletion process. Proceeding without verification is itself a compliance failure.

Step 2 — Run a Full Data Map Against the Request

Once the request is verified and scoped, pull your data inventory and systematically identify every location where the individual’s personal data exists. This step is where underprepared HR teams lose the most time and make the most errors.

Actions

1. Query every system in your inventory. Active HR systems are the starting point, not the finish line. Include: HRIS, payroll platform, ATS (including candidate profiles), performance management tools, benefits administration, learning management system, internal communication archives where retained, and any ad-hoc spreadsheets or shared drives used for HR tracking.
2. Identify backup and archive locations. Deletion from active systems does not satisfy GDPR if backups remain indefinitely. Work with IT to document where backups are stored, the retention cycle, and the process for flagging data for deletion at the next backup refresh.
3. List all third-party vendors holding the individual’s data. Cross-reference your vendor inventory against the requester’s employee or candidate record. Background check providers, payroll bureaus, benefits carriers, and learning platform vendors all likely hold personal data that must be addressed.
4. Flag data categories for legal-hold review. As you map, flag every data category against your retention schedule. Do not delete anything at this stage — the legal-hold analysis in Step 3 determines what is actually subject to deletion.

Step 3 — Apply Legal Retention Holds Before Touching a Single Record

Not all data subject to a deletion request is legally deletable. Applying the wrong determination in either direction — deleting data you were required to retain, or retaining data you were required to delete — creates compliance liability. This step is where you make the legal determination before acting.

Actions

1. Cross-reference each data category against your retention schedule. Common categories with mandatory retention periods include: payroll and tax records (typically 3–7 years depending on jurisdiction), I-9 records (three years from hire date or one year post-termination, whichever is later), workplace injury and OSHA records (5–30 years depending on category), FMLA and ADA documentation (3 years minimum), EEOC and discrimination complaint files (1–3 years), and benefits plan documents (6 years under ERISA).
2. Check for active litigation holds. If the individual is a party to pending litigation, an active EEOC charge, or a regulatory investigation, all relevant data is subject to a legal hold and cannot be deleted regardless of the RTBF request. Confirm with legal counsel before proceeding.
3. Document the determination for every data category. Create a written record that maps each data category to either: (a) approved for deletion, (b) retained under [specific statute] until [specific date], or (c) escalated to legal for determination. This documentation is your evidence of good-faith compliance in the event of a later audit.
4. Notify the requester of partial retention where applicable. If some data must be retained, inform the requester in writing which categories are being retained, the legal basis, and the expected retention end date. Transparency here reduces the likelihood of a regulatory complaint.

Step 4 — Execute Deletion Across Systems and Vendors

With the legal determination complete and documented, you are ready to execute. Deletion must be systematic, documented, and verified — not a series of manual spot checks.

Actions

1. Delete from internal systems in a defined sequence. Start with the primary system of record (typically the HRIS), then move through the full system list from Step 2. For each system, document: the date of deletion, the method used (manual delete, data subject request tool, API call), and the name or role of the person who executed it.
2. Anonymize where full deletion is not technically possible. Some systems — particularly legacy platforms and certain analytics tools — cannot permanently delete individual records without corrupting aggregate data or audit logs. In these cases, pseudonymization or anonymization (removing all identifying fields) is an accepted alternative under GDPR Recital 26, provided the remaining data cannot reasonably be re-identified.
3. Issue formal deletion requests to every vendor on the list. Send written deletion requests to each third-party vendor identified in Step 2, referencing the original RTBF request date, the individual’s identifiers, and the specific data categories to be deleted. Require written confirmation of completion with a timestamp.
4. Flag backups for deletion at the next cycle. Coordinate with IT to flag the individual’s records in backup systems for deletion at the next scheduled backup refresh. Document the flag and the expected deletion date.
5. Automate the vendor outreach and tracking where possible. If you process deletion requests more than once or twice a year, manual vendor outreach quickly becomes unmanageable. A Make.com automation can generate vendor deletion request emails, log responses, and flag overdue confirmations automatically — without custom development.

Common Mistake

Treating the HRIS deletion as a completed request. Deletion from one system does not satisfy the obligation. Every system in your inventory, including vendors, requires documented completion before the request is closed.

Step 5 — Issue Written Confirmation and Close the Request Record

The deletion process is not complete until the requester has received written confirmation and the request record is formally closed with full documentation. This is also the stage where most HR teams under-document, creating audit risk later.

Actions

1. Issue written confirmation to the requester. The confirmation must state: the date the deletion was completed, which data categories were deleted, which categories (if any) were retained and on what legal basis, and a contact for follow-up questions. Send this before the statutory deadline — GDPR one-month deadline, CCPA/CPRA 45-day deadline — even if some vendor confirmations are still pending (note that in your communication and follow up).
2. Compile the full request record. The closed record should contain: the original request with date and time stamp, identity verification documentation, the data map from Step 2, the legal determination matrix from Step 3, deletion confirmations from every internal system, deletion confirmations from every vendor (add as they arrive), backup flagging documentation, and the written confirmation sent to the requester.
3. Store the request record according to your retention schedule. You must retain evidence that you complied with the deletion request — which means retaining documentation about the deletion itself — for the period required by applicable law. This is not a contradiction; it is a legal requirement.
4. Conduct a post-request review. After closing the record, note any gaps exposed during the process: systems not in the inventory, vendors without deletion clauses, data categories without a retention schedule determination. Use these findings to update your data inventory and vendor contracts before the next request arrives.

How to Know the Process Worked

A completed RTBF process produces four verifiable outcomes:

• Written confirmation was issued within the statutory deadline — one month under GDPR, 45 days under CCPA/CPRA — with no outstanding action items that could invalidate the response.
• Every system in the data inventory has a documented deletion or retention determination — no system is simply unlisted or skipped.
• Every vendor has provided written confirmation of deletion — or a documented explanation of why deletion has not yet occurred and a committed completion date.
• The closed request record contains enough documentation to reconstruct every decision made — verifiable by a regulator or auditor without additional context from the HR team member who handled it.

If any of these four outcomes is missing, the request is not complete. Do not close the record until all four are satisfied.

Common Mistakes That Create Compounded Liability

RTBF compliance failures fall into predictable patterns. Understanding them is the fastest way to close gaps before they cost you.

• Starting the deletion process without identity verification. Deleting records based on an unverified request is itself a compliance failure — you have disclosed the existence and contents of someone’s data to an unverified third party.
• Relying on a single-system deletion. The most common failure mode. HR teams delete from the HRIS and consider the matter closed. ATS records, performance management data, email archives, and every vendor remain untouched.
• Having no retention schedule and defaulting to full deletion. Deleting payroll, tax, or injury records that had active statutory retention requirements exposes the organization to audit liability that often exceeds any regulatory fine for an imperfect RTBF response.
• No written confirmation to the requester. Even a technically complete deletion fails the statutory test if you do not notify the requester in writing within the response window.
• No documentation of the process. In a regulatory inquiry, an undocumented deletion is indistinguishable from no deletion at all. The burden of proof is on the organization.
• No vendor tracking. Issuing deletion requests to vendors without tracking responses leaves your compliance status permanently uncertain. Vendor non-compliance is your liability under GDPR Article 28, not theirs alone.

How Automation Reduces RTBF Process Risk

Manual RTBF processing at any volume creates inconsistency risk. The same five-step process executed by five different HR professionals without a structured workflow produces five different documentation trails — and unpredictable compliance outcomes.

Automation addresses this by enforcing consistency at each step: intake timestamping, identity verification checklists, system query prompts, vendor outreach generation, deadline tracking, and confirmation logging. HR teams that have already built HR workflow automations in Make.com can extend those workflows to cover RTBF intake and tracking without custom development.

The starting point for any automation build is a process map — you need to document what the manual process actually does before you can replicate it reliably in an automated workflow. The pre-automation checklist walks through the seven questions every HR team should answer before building any compliance workflow. And if your team has not yet mapped which processes are worth automating first, the OpsMap™ discovery process provides the structured framework for making that determination before committing build time.

For teams handling RTBF requests infrequently, a structured manual checklist with automated deadline reminders is often sufficient. For teams processing multiple requests per month — particularly in organizations operating under GDPR with a European employee or customer base — a fully automated intake-to-confirmation workflow pays for itself in the first quarter.

Frequently Asked Questions

Does RTBF apply to job applicants who were never hired?

Yes. GDPR Article 17 and CCPA/CPRA apply to any individual whose personal data you hold, regardless of whether they became an employee. Former job applicants whose data sits in your ATS are entitled to submit deletion requests. Your data inventory must include candidate records, and your retention schedule must specify how long candidate data is held post-rejection and under what legal basis.

What happens if a vendor fails to complete deletion within the response window?

Under GDPR Article 28, data controllers are responsible for ensuring sub-processors (vendors) comply with deletion obligations. A vendor’s failure to respond or complete deletion is a compliance gap you are responsible for managing. Issue a formal escalation in writing, document your efforts, and notify the requester that vendor deletion is pending if you have already issued the primary confirmation. Update your vendor contracts to include response timelines and escalation procedures.

Can HR decline a RTBF request when there is an active employment relationship?

Yes. When data processing is necessary to fulfill the employment contract — payroll processing, benefits administration, tax reporting — the legal basis for processing overrides the deletion right. The request can be declined for those specific data categories with a written explanation. Document the specific legal basis for each category retained and notify the requester in writing.

How long do we retain documentation of a completed RTBF request?

Retain the full request record — including the original request, identity verification, deletion documentation, and confirmation sent to the requester — for a minimum of three years. Some jurisdictions and some data categories may require longer retention. Confirm with legal counsel based on the jurisdictions you operate in.

What is the difference between deletion and anonymization for RTBF purposes?

Deletion removes all records of the individual. Anonymization removes all identifying fields such that the remaining data cannot reasonably be re-identified. GDPR Recital 26 recognizes that anonymized data falls outside the scope of the regulation — so anonymization satisfies the RTBF obligation for data that cannot be fully deleted without corrupting system integrity. The anonymization must be irreversible; pseudonymization (where re-identification is possible with a key) does not satisfy the obligation.

Does RTBF apply to paper records, not just digital files?

Yes. Physical personnel files, paper I-9 forms, printed performance reviews, and any other physical records containing personal data are subject to the same deletion or retention analysis as digital records. Your data inventory must include physical record locations, and your deletion process must include secure destruction with documented confirmation.

Additional Reading

• What Is HR Triage Risk Mapping? How HR Leaders Prioritize Inherited Messes
• HRIS Required Fields vs Manual Data Validation: Which Is Safer for Small HR Teams?
• 11 Warning Signs Your Inherited HR Operation Is Bleeding Money
• How to Audit Inherited I-9 Records Without Creating New Violations
• 9 HRIS Configuration Defaults Every Small HR Team Should Change
• Drowning in Admin: How Solo and Small HR Teams Can Fix Broken HR Operations Without Burning Out
• How to Build a 90-Day HR Triage Plan Your CEO Will Sign
• The $27K Overpayment: How One HRIS Data Entry Mistake Cost a Manufacturer a Year of Salary
• How to Reconcile a Broken Benefits Carrier Feed: Step by Step
• What Is OpsMap? The Discovery Step That Prevents Automation Mistakes
• How a Non-Technical HR Team Started Building Their Own Automations With Make + AI
• 7 Questions to Ask Before You Automate Anything (The OpsMap Checklist)
• 9 EEOC AI Compliance Requirements HR Teams Must Meet in 2026
• What Is a Minimum Viable HR Process? A Plain-Language Definition
• HR of One Survival FAQ: Inherited Operations Questions Answered