GDPR data erasure during offboarding is deterministic — the data is deleted on schedule or it is not. Automated Make.com workflows enforce deletion across every mapped system on every departure. Manual checklists fail because employee data lives in dozens of tools, and human processes miss at least one of them every time.

This guide is the operational companion to our parent piece on offboarding automation as your first HR project. That piece establishes the strategic case. This one gives you the step-by-step implementation for GDPR-compliant data erasure using Make.com.

Before You Build: Prerequisites, Tools, and Risk Factors

Building a deletion workflow before your legal and data governance foundations are in place creates the appearance of compliance, not the reality. Address these prerequisites before touching Make.com.

What You Need Before Building

• A signed data retention matrix. Every data category — payroll records, performance reviews, biometrics, communications — needs a documented retention period with legal sign-off. Automation enforces whatever rules you give it. Bad rules produce bad compliance.
• A complete data-store inventory. You cannot automate deletion from systems you have not mapped. This includes shadow IT, departmental SaaS subscriptions, and shared credentials. Gartner research identifies shadow IT as the primary source of post-departure data exposure.
• A legal-hold gate. Active litigation holds must intercept erasure workflows before they execute. Build this check into every workflow path from day one — not as an afterthought.
• HRIS termination event access. Your Make.com scenario needs a reliable trigger — typically a status change or termination date field in your HRIS. No trigger means no automation.
• An immutable audit log destination. Deletion events are compliance-valuable only when recorded. Identify where logs will be written, confirm they are append-only and access-controlled, and test the write path before building anything else.

Time and Scope Estimate

A phased implementation covering your top five data stores can be designed, tested, and deployed in four to eight weeks. Full coverage across all SaaS integrations typically requires three to six months. The primary exposure is incomplete data mapping — automating deletion from 80 percent of systems while missing 20 percent delivers partial compliance, not full compliance. Start narrow, audit for gaps, then expand.

Running an OpsMap™ audit before you build is the fastest way to find those gaps before they become violations.

Step 1 — Map Every System That Holds Former Employee Data

You cannot delete data you have not located. This step is the most labor-intensive part of the process and the one most organizations skip — which is exactly why they remain exposed.

Convene a cross-functional working group that includes HR, IT, Legal, Finance, and at least one representative from each major business unit. Your goal is a complete inventory of every system that processes or stores employee personal data. Forrester research notes that organizations consistently underestimate the number of systems holding employee data by a factor of two or more when relying on IT system-of-record lists alone.

What to Capture in Your Inventory

• System name and owner — who is accountable for data in this system
• Data categories stored — name and contact details, salary, performance ratings, biometrics, communications
• API availability — can Make.com call this system to trigger deletion or deactivation?
• Retention period — what your signed matrix requires for each category in this system
• Deletion method — full record delete, anonymization, or field-level redaction
• Manual fallback — for systems without APIs, document the human step and who owns it

Build this inventory in a shared spreadsheet with a status column. It becomes your master reference when you configure Make.com modules and when regulators request evidence of your deletion process.

Step 2 — Configure Your Make.com Trigger

Every GDPR erasure workflow in Make.com starts with a reliable trigger. The trigger is the source of truth that tells Make.com a termination event has occurred and the clock has started.

Common Trigger Sources

• HRIS webhook — the cleanest option. Your HRIS fires a webhook to Make.com the moment an employee’s status changes to terminated. Make.com receives the payload, extracts the employee ID, and routes to your erasure logic.
• Scheduled poll — if your HRIS does not support webhooks, a Make.com scenario runs on a schedule (daily or twice daily) and queries for employees whose termination date equals today or is within your trigger window.
• Google Sheets or Airtable row update — for teams running manual offboarding trackers, a row status change can fire the Make.com scenario. Less reliable than a direct HRIS connection but workable as a bridge while you build toward full HRIS integration.

What the Trigger Payload Must Include

At minimum, the triggering event must pass the employee’s unique identifier, their termination date, their department, and any legal-hold flag. The legal-hold flag is the gate that prevents erasure from firing on protected records — map it explicitly before you build downstream modules.

Step 3 — Build the Erasure Router

The erasure router is the core of your Make.com scenario. It receives the termination event and branches into parallel paths — one per system in your inventory that holds data for this employee.

Router Logic

Use Make.com’s Router module to split execution into independent paths. Each path handles one system: CRM, HR platform, payroll provider, collaboration tools, access management, and any others in your inventory. Paths execute in parallel, which keeps the total scenario run time reasonable even across a dozen systems.

Each path follows the same pattern:

1. Check retention hold. Before any deletion action, the path queries whether the employee record has an active legal hold or an unexpired retention period. If yes, the path logs the hold and exits without deleting.
2. Execute the deletion or anonymization action. For systems with direct Make.com modules, use the native Delete Record or Update Record action. For systems accessible only via REST API, use Make.com’s HTTP module with the appropriate DELETE or PATCH request.
3. Confirm the action. After the deletion call, query the system to confirm the record no longer exists or has been anonymized as specified. A deletion call that returns a 200 status does not guarantee the record is gone — verify it.
4. Write an audit log entry. Every completed action writes a timestamped record to your audit log destination — system name, employee ID, action taken, timestamp, and confirmation status.

Error Handling

Every external API call in your Make.com scenario needs an error handler. The 4Spot standard is a Break handler with three retry attempts at 60-second intervals. After three failed attempts, the error handler fires an alert — Slack message or email — with the scenario execution URL so your team can investigate without hunting through logs. Do not let a failed deletion silently pass. A system that did not respond is a system that may still hold personal data.

Step 4 — Handle Retention Exceptions and Legal Holds

GDPR erasure obligations do not override every other legal requirement. Payroll records carry multi-year retention requirements in most jurisdictions. Active litigation holds override deletion schedules entirely. Your automation must respect these exceptions, not ignore them.

How to Implement Exception Handling in Make.com

The cleanest implementation is a holds table — a structured list in Airtable or your HRIS that records every employee ID subject to a hold, the hold type, and the hold expiration date. Before any deletion path executes, the Make.com scenario queries this table. If the employee ID appears with an active hold, the path logs the exception, skips deletion, and routes a notification to the responsible party.

For retention period exceptions — payroll records that must be kept for seven years, for example — the logic is a date comparison. The scenario computes the required retention end date from the employee’s termination date and the retention matrix rule. If today’s date is before the retention end date, the path skips deletion and schedules a re-evaluation. Make.com’s built-in scheduling allows you to queue a future re-check without manual follow-up.

Partial Anonymization as an Alternative

For records that cannot be deleted but do not need to retain personal identifiers, anonymization satisfies GDPR’s data minimization requirement without destroying the record’s business utility. A payroll record stripped of name, address, national ID, and contact details retains its financial data for audit purposes while eliminating the personal data exposure. Build a separate Make.com path for anonymization-eligible records and verify that each targeted field is actually overwritten, not just hidden.

Step 5 — Build Your Audit Log

An audit log is not optional. It is how you demonstrate to regulators, auditors, and data subjects exercising their rights that deletion occurred on schedule. A deletion you cannot prove is legally the same as a deletion that did not happen.

What Each Log Entry Must Contain

• Employee identifier (anonymized — do not log the employee’s name in the deletion record)
• System name where the action was taken
• Action type: full deletion, anonymization, or retention hold applied
• Timestamp of the action (UTC)
• Confirmation status: success, failed with retry, or exception noted
• Make.com execution ID for traceability back to the specific scenario run

Audit Log Destination Requirements

The destination must be append-only — no one should be able to modify or delete existing entries. Google Sheets with restricted editing permissions is a workable starting point for smaller organizations. For higher-volume or higher-stakes environments, a dedicated logging service or a write-only database table provides stronger guarantees. Whatever you choose, test the write path before you run your first real termination through the workflow.

Step 6 — Test Before You Run a Real Termination

Testing a deletion workflow on real employee data is not acceptable. Build a parallel test environment using synthetic employee records that mirror your actual data structure, and run every scenario path against those records before touching production.

Testing Checklist

• Trigger fires correctly on a test termination event
• Legal-hold check correctly intercepts records flagged as held
• Retention period check correctly skips deletion for records within their retention window
• Each system path executes and returns a confirmation
• Error handler fires and sends an alert when a system path fails
• Audit log entries are written for every path execution, including holds and exceptions
• Post-deletion verification confirms the record is gone or anonymized as intended

Run the full test sequence at least twice — once for a clean termination with no holds, and once for a termination with an active legal hold. Both paths must behave exactly as designed before you go live.

Step 7 — Monitor and Maintain the Workflow

An automated workflow that runs without oversight is not a compliance solution — it is a liability waiting to surface. GDPR data erasure automation requires ongoing attention.

What to Monitor

• Failed scenario runs. Make.com’s execution history surfaces failed runs. Review them at least weekly. A failed run on a termination event means personal data was not deleted on schedule.
• New system additions. Every new SaaS tool added to your stack is a potential new data store. Your working group should review new tool onboarding against your inventory and add Make.com paths before the tool goes live, not after.
• Retention matrix changes. Legal and regulatory updates change retention requirements. When your signed matrix changes, the corresponding Make.com logic must change to match.
• API changes in connected systems. Third-party API updates break Make.com modules. Build a quarterly test run of your erasure workflow to catch breaking changes before a real termination exposes them.

How OpsMesh™ Structures This Work

At 4Spot, GDPR erasure automation follows the same engagement structure we apply to every operational workflow project. The OpsMesh™ framework sequences this work as: OpsMap™ discovery to inventory systems and map data flows, OpsSprint™ to design and test the core scenario, OpsBuild™ to deploy and integrate across all mapped systems, and OpsCare™ to monitor, maintain, and update as your stack evolves.

The OpsMap™ phase is the step most teams skip — and the gap in their system inventory is exactly where GDPR exposure lives. Running discovery before building saves significantly more time than it costs.

Frequently Asked Questions

Does Make.com have native GDPR deletion modules?

Make.com does not have a single “GDPR delete” module because GDPR compliance is system-specific. Make.com provides native modules for most major SaaS platforms — CRMs, HR tools, collaboration platforms — and HTTP modules for any system with a REST API. The compliance logic lives in how you configure and sequence those modules, not in a pre-built GDPR tool.

What if a system in my inventory does not have an API?

Systems without APIs require a manual step. Your Make.com scenario should flag those systems in the audit log as requiring manual deletion, route a task to the system owner, and track completion. Do not automate around a missing API by granting Make.com access to credentials it should not hold — the security exposure outweighs the compliance convenience.

How long does a GDPR erasure scenario take to run?

A well-built Make.com scenario covering ten to fifteen systems runs in under five minutes for most terminations. The bulk of that time is API response latency from external systems. Parallel routing — running system paths simultaneously rather than sequentially — keeps total run time flat as you add more systems.

What is the right retention period for former employee data?

Retention periods vary by data category and jurisdiction. Payroll records typically require six to seven years in the US and EU. Performance records have shorter requirements in most frameworks. I-9 records follow a formula tied to the employee’s tenure. Your legal counsel must sign off on every retention period in your matrix — these are not defaults to pull from a template.

Can this workflow handle employees in multiple jurisdictions?

Yes, with routing logic added to the Make.com scenario. The triggering payload must include the employee’s work jurisdiction. The router uses that field to branch into jurisdiction-specific paths with the correct retention matrix rules. Build and test each jurisdiction path independently before combining them into a single scenario.

What should we automate first if we have limited capacity?

Start with your highest-risk systems — those holding the most sensitive data categories or the largest volumes of personal data. Payroll and HR platforms typically top this list. Automate deletion from those two systems first, get the audit log working correctly, and expand from there. A working two-system workflow delivers real compliance improvement immediately and gives your team confidence in the approach before you scale it across your full inventory.

The 7-question pre-automation checklist is a useful filter for deciding which systems to tackle in which order.