GDPR compliance in HR is not a privacy policy and a consent form — it is an operational system built into your data architecture, vendor contracts, Make.com automation workflows, and retention schedules. This guide walks through the exact steps to build a defensible, auditable GDPR posture across the full employee data lifecycle.

Most HR teams have a privacy policy, a consent form from 2018, and a vague memory of a GDPR training session. None of that constitutes compliance. GDPR compliance in HR is an operational system — built into your data architecture, your vendor contracts, your Make.com automation workflows, and your retention schedules — or it is a liability waiting to be triggered. For the structural governance foundation that makes each step below durable, start with our guide to HR data governance for AI compliance and security.

Before You Start: Prerequisites, Tools, and Risk Assessment

Confirm these prerequisites before executing any step below. Skipping them converts this guide into compliance theater.

• Data inventory baseline: You must know what personal data your HR function holds, where it lives, who accesses it, and what processing activities touch it. If you do not have a Record of Processing Activities (RoPA), complete one before proceeding. Every step below assumes RoPA exists.
• Data Protection Officer or designated privacy lead: GDPR Article 37 mandates a DPO for organizations processing employee data at scale or processing special-category data. Even where not legally mandated, designate an internal privacy lead with decision authority.
• Legal counsel with GDPR jurisdiction expertise: Employment law intersects with data protection law in ways that vary by Member State. Do not rely solely on a generic GDPR checklist — local employment law obligations extend retention periods or restrict processing in ways that contradict the GDPR default.
• HR system access map: Know exactly which roles access which data fields in your HRIS, payroll, benefits, LMS, and performance platforms before you design access controls.
• Estimated time investment: Initial operationalization for a mid-market organization (250–2,500 employees) requires 60–120 hours of structured effort across HR, IT, legal, and operations. This is not a one-afternoon project.

Key risks to flag before you begin: Legacy HR systems frequently lack the technical capability to execute automated deletion or field-level access controls. Identify those gaps in week one — retrofitting a legacy system is a longer timeline than the compliance steps themselves. See our related guide on data governance for legacy HR systems for a dedicated remediation path.

Step 1 — Map Every HR Processing Activity to a Lawful Basis

GDPR requires a documented lawful basis for every processing activity. In HR, the lawful basis determines what you can do with data, for how long, and what happens when an employee invokes their rights. Without this map, every downstream compliance decision is guesswork.

How to execute this step

1. Pull your current Record of Processing Activities. If one does not exist, build it now — list every data category your HR function touches (application data, employment contracts, payroll, benefits enrollment, performance records, disciplinary records, health and absence data, training records) and the systems that process each category.
2. For each processing activity, assign a lawful basis from the six available under Article 6. In HR, the correct basis is almost always one of three:
   • Contractual necessity (Art. 6(1)(b)): Processing required to perform the employment contract — payroll, tax withholding, benefits administration.
   • Legal obligation (Art. 6(1)(c)): Processing required by law — I-9 verification, OSHA records, FMLA documentation, EEO reporting.
   • Legitimate interests (Art. 6(1)(f)): Processing for a genuine business purpose that does not override employee rights — limited to activities that pass a three-part legitimate interests assessment (LIA). Document the LIA in writing.
3. For any processing involving special-category data (health records, disability status, biometric data, union membership), identify the corresponding Article 9 condition in addition to the Article 6 basis. Special-category processing without a documented Article 9 condition is a regulatory violation regardless of Article 6 status.
4. Record the lawful basis in your RoPA alongside the processing activity — not in a separate document. Auditors pull the RoPA first.

Common mistake to avoid: HR teams default to consent as the lawful basis for employee data processing. Consent is almost never the right basis in employment relationships because it is not freely given when there is a power imbalance between employer and employee. Consent-based processing collapses the moment an employee withdraws it. Use contractual necessity or legal obligation wherever the facts support it.

Step 2 — Build Data Subject Rights Workflows

GDPR grants employees eight rights: access, rectification, erasure, restriction, portability, objection, not to be subject to automated decisions, and the right to be informed. Each right requires a documented, executable response process — not a policy statement that says “we respect your rights.”

How to execute this step

1. Build a single intake point for all data subject requests. This is a form, email alias, or HR portal field — one destination, logged to a system of record the moment a request arrives. A Make.com scenario watching a dedicated inbox or form submission fires immediately on receipt, timestamps the request, and creates a task in your HR ticketing system. The 30-day GDPR response clock starts at receipt, not at when someone notices the email.
2. Map each right to the specific systems it touches. A subject access request for a single employee record crosses HRIS, payroll, benefits, LMS, performance management, and email. Document that system list now — not during a live request under a deadline.
3. Build the erasure workflow carefully. Erasure is not deletion everywhere. Payroll records, tax records, and safety records carry legal retention obligations that survive an erasure request. Your erasure workflow must route requests through legal review before executing any deletion. Make.com handles the routing, the legal hold check, and the documentation — the deletion decision stays with a human.
4. Test every workflow before you need it. Run a simulated subject access request through your system quarterly. The test reveals gaps that a policy document never surfaces.

The OpsMap™ discovery process we run at the start of every engagement consistently identifies data subject rights workflows as the most underdeveloped GDPR control in mid-market HR operations. The intake point exists on paper. The execution path behind it does not. See what an OpsMap audit covers for a breakdown of how we surface these gaps before building anything.

Step 3 — Automate Retention and Deletion Schedules

A retention schedule that lives in a spreadsheet is not a retention schedule — it is a list of aspirations. GDPR requires that personal data is deleted when it is no longer needed for the purpose for which it was collected. In HR, that means different categories of data have different retention clocks, and those clocks must be enforced automatically or they will not be enforced at all.

How to execute this step

1. Build a retention matrix. For each data category in your RoPA, define the retention period (driven by legal obligation, contractual necessity, or documented legitimate interests), the trigger event that starts the clock (hire date, termination date, last payroll run, training completion), and the system that holds the data.
2. Automate the deletion trigger. A Make.com scenario runs on a schedule, queries your HRIS for records where the retention period has elapsed, and either deletes the records directly via API or generates a deletion task routed to the system owner for confirmation. Systems without API access get a flagged report delivered to HR with a deletion confirmation checklist.
3. Log every deletion. The deletion log is as important as the deletion itself. When a supervisory authority asks for evidence that you deleted former employee data within your stated retention period, your answer is the log — timestamped, record-level, system-specific.
4. Review the retention matrix annually and when you add a new HR system or data category. Retention schedules calcify. A new benefits platform or a new performance review tool creates new data categories that are not automatically covered by existing schedules.

State law overlay: Several U.S. states apply data privacy laws that intersect with GDPR standards for multinational employers. California’s CPRA, Colorado’s CPA, and Virginia’s CDPA each impose retention and deletion obligations independent of GDPR. Your retention matrix needs a jurisdiction column if you operate across these states.

Step 4 — Audit and Enforce Data Processor Agreements

Every vendor that touches employee personal data on your behalf is a data processor. GDPR Article 28 requires a written Data Processing Agreement (DPA) with every processor — not a privacy policy link in the vendor’s footer, but a bilateral contract that meets the Article 28 content requirements.

How to execute this step

1. Pull a complete vendor list against your RoPA. For every system in your RoPA, confirm whether the vendor acts as a processor (processes data on your instructions) or a controller (determines purposes and means independently). Most HR SaaS vendors are processors. Payroll bureaus and background check companies are common exceptions — they often act as independent controllers for portions of their processing.
2. Audit existing DPAs against the Article 28 required content: subject matter and duration, nature and purpose of processing, type of personal data, categories of data subjects, obligations and rights of the controller. A DPA that predates 2018 or does not include all six elements requires renegotiation.
3. Confirm subprocessor disclosure. Article 28 requires processors to disclose subprocessors and obtain controller authorization before engaging them. If your HRIS vendor uses a subprocessor for data storage or analytics, that subprocessor must appear in a disclosed subprocessor list and must itself operate under a DPA equivalent.
4. Track DPA expiration and renewal dates in a vendor registry. A Make.com scenario running on a scheduled trigger queries the registry, flags DPAs expiring within 90 days, and sends renewal reminders to procurement. No manual calendar tracking required.

Step 5 — Implement Field-Level Access Controls and Audit Trails

Data minimization and purpose limitation are not principles — they are technical requirements. GDPR Article 5 requires that personal data is accessed only by those who need it for a specific purpose. In HR systems, that means role-based access at the field level, not just the record level, and it means logging who accessed what and when.

How to execute this step

1. Map roles to data needs. A hiring manager reviewing a candidate needs name, resume, and interview notes — not national ID number, date of birth, or salary history. A payroll administrator needs compensation data — not performance review narratives or medical accommodations. Build the role-to-field matrix before you configure access.
2. Audit your HRIS configuration against the matrix. Most modern HRIS platforms support field-level visibility controls. Configure them. If your current platform does not support field-level access controls, that is a gap your DPO needs to document as a technical risk with a compensating control in place until you migrate.
3. Enable audit logging on every HR system that holds personal data. Audit logs record who accessed, modified, or exported data and when. Without logs, you cannot demonstrate compliance to a supervisory authority and you cannot investigate a potential breach.
4. Review access quarterly. Employees change roles. HR staff turns over. Access that was appropriate six months ago is a compliance risk today if it has not been reviewed. A Make.com scenario pulling current user-role assignments and comparing against your access matrix surfaces discrepancies on a defined schedule without requiring a manual audit.

Step 6 — Build and Test a Breach Response Procedure

GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Article 34 requires notification to affected individuals without undue delay when the breach is high risk. Seventy-two hours is not enough time to write a breach response procedure from scratch.

How to execute this step

1. Define what constitutes a breach for your organization. Unauthorized access to employee records, accidental disclosure to a third party, loss of a device containing unencrypted HR data, ransomware that encrypts payroll records — each of these meets the GDPR definition of a personal data breach. Every employee in your HR function and IT function needs to know how to recognize and report a breach immediately.
2. Build the internal escalation chain. Who receives a breach report? Who makes the decision to notify the supervisory authority? Who drafts the notification? That chain needs to be documented, trained, and tested — not decided in the moment at hour 60 of a 72-hour window.
3. Pre-draft your supervisory authority notification template. The Article 33 notification requires: nature of the breach, categories and approximate number of data subjects and records affected, name and contact details of the DPO, likely consequences of the breach, and measures taken or proposed to address it. Draft the template now against a hypothetical scenario so the structure exists when you need it.
4. Run a tabletop exercise annually. Walk your HR, IT, and legal team through a simulated breach scenario. The exercise surfaces gaps in your escalation chain, notification templates, and evidence preservation procedures before a real incident does.

A Make.com scenario connected to your IT security alerting platform automates the first hour of breach response: it logs the incident, timestamps the discovery moment (which starts the 72-hour clock), notifies the DPO and designated privacy lead simultaneously, and opens an incident record in your HR ticketing system. The humans make the decisions — the scenario ensures the clock is running and the right people know immediately.

Putting It Together: From Paper Compliance to Operational GDPR

Each step above is a standalone control. GDPR compliance requires all of them, operating together, with documented evidence that each one functions as designed. The audit trail is the compliance. A supervisory authority reviewing your HR GDPR posture does not read your policy documents — it asks for evidence of execution: RoPA records, DPAs, deletion logs, access audit trails, breach notification drafts, and data subject request logs.

The OpsMesh™ framework structures all six controls as connected operational systems rather than isolated projects. The OpsMap discovery audit surfaces the gaps in your current state. The OpsBuild™ phase configures the Make.com automation layer — retention triggers, request intake routing, access review scheduling, breach notification workflows. OpsCare™ maintains the system through annual reviews, vendor changes, and regulatory updates. The result is a compliance posture that holds up under scrutiny because it runs continuously, not because someone updated a spreadsheet before an audit.

For HR teams inheriting broken operations and needing to build GDPR controls into systems that were never designed for them, the path to defensible compliance starts with an honest current-state assessment. Read our guide on data governance for legacy HR systems for the specific remediation sequence when your underlying platforms are the constraint.

GDPR compliance in HR is not a project you complete. It is an operational posture you build, test, automate, and maintain — or it is a liability. The steps above give you the operational path. The Make.com automation layer gives you the execution speed and consistency that manual processes cannot sustain at scale.