Mapping HR Data to PII Compliance: A Developer's Guide to CCPA and GDPR Fields

GDPR Article 12(3) gives you one month to answer an access request. CCPA gives you 45 days, extendable once by another 45. Both clocks start from the same thing: whether you can find the person's data in your HR schema.

HR data PII compliance mapping is the practice of tagging every field in an employee record with the legal category it falls into under GDPR Article 4(1) and CCPA §1798.140(o), then driving retention, transfer, and DSR logic off that tag instead of off the table name. Get the tag right and the rest is configuration. Get it wrong and every downstream control — masking, deletion, export — inherits the error silently.

Key takeaways

• GDPR and CCPA classify HR fields differently. A field can be ordinary personal data under one and sensitive under the other.
• Pseudonymous identifiers like employee_id are still personal data. Pseudonymisation is not anonymisation.
• CCPA has covered job applicants and employees since 1 January 2023. The old HR exemption is gone.
• Retention periods must be justified per record class, not per database. "Keep everything seven years" fails Article 5(1)(e).
• Classify at ingestion. Retrofitting tags onto a populated warehouse is the expensive version of this work.

What Constitutes PII in HR Data? (GDPR Article 4(1), CCPA 1798.140(o))

GDPR Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. CCPA §1798.140(o) defines personal information as information that identifies, relates to, describes, or could reasonably be linked to a particular consumer or household. Both are broad enough to cover almost every column in an HR system, including the ones you think are internal.

The US Department of Labor's guidance on protecting personally identifiable information treats PII as information that can be used to distinguish or trace an individual's identity, alone or combined with other information. That "combined with" clause is the part that bites in HR, because your schema is unusually good at combining.

Note the last row. GDPR tells you to keep data no longer than necessary and lets you decide what necessary means. CCPA makes you publish the number first. If your retention policy lives in a wiki and your schema has no retention_days field, you are out of compliance with the CCPA row and probably the GDPR row too.

How Do You Map Common HR Data Elements to PII Categories?

Map each field to a category per regime, not per system. A single classification array on the field definition — carrying both the GDPR tag and the CCPA tag — is what lets one pipeline serve both regimes without forking your code. The table below is the mapping I would start from.

The emergency contact row is the one teams miss. You are processing a non-employee's personal data with no relationship to them and no notice. Give it a retention period and a lawful basis or drop the field.

For the schema-mapping discipline itself, the same rules that apply to CSV to FHIR mapping apply here: define the target shape first, then map, then validate. Mapping into a schema you have not defined is how you end up with three spellings of "date of birth."

Data Minimization in HR Systems: Which Fields Can You Drop or Mask?

Data minimization under GDPR Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary. CCPA §1798.100(c) imposes a similar proportionality rule. In practice, most HR schemas fail minimization not because of the fields they collect but because of the fields they copy — into analytics, into test environments, into a data lake nobody owns.

Start with three questions per field:

1. Is there a legal or contractual driver? Payroll, tax, immigration, and pension fields usually have one. Engagement scores usually do not.
2. Does anything downstream read it? If the only consumer is a report nobody opens, the field is a liability with no return.
3. Can it be masked rather than deleted? Masking preserves referential integrity while removing the identifier. The trade-offs are the same ones I wrote about in data masking for PCI DSS 4.0 — masking is not encryption, and a masked field can still be a quasi-identifier when joined against another table.

The failure mode is not collecting too much. It is replicating what you collected into systems that have no retention policy, no access log, and no owner.

How Do You Transfer HR Data Across Borders? (SCCs, Adequacy, and the DPF)

GDPR Chapter V governs transfers of personal data outside the EEA. CCPA does not have an equivalent transfer regime — it regulates disclosure and service-provider contracts under §1798.100(d) instead. That asymmetry matters: a US-headquartered employer moving EU employee data to a US HR system needs a GDPR mechanism, and the same transfer is largely invisible to CCPA.

The mechanisms in use:

• Adequacy decisions — the European Commission has adopted these for a list of countries. The EU-US Data Privacy Framework adequacy decision took effect on 10 July 2023 and is the mechanism most US HR teams rely on. It has been litigated before and will be again; treat it as a live dependency, not a permanent answer.
• Standard Contractual Clauses — Commission Implementing Decision (EU) 2021/914, in force since 4 June 2021, with four modules. Module 2 (controller to processor) is the one most HR vendors sign. Module 1 covers intra-group controller-to-controller transfers.
• Article 49 derogations — narrow, and not a system design. Do not build a recurring payroll sync on explicit consent.

After Schrems II (CJEU C-311/18, 16 July 2020), SCCs alone are not sufficient. You need a transfer impact assessment that documents what US law could compel your importer to disclose and what supplementary measures you applied. For HR data that includes national IDs and health records, "we signed the SCCs" is the beginning of the answer.

What Retention Schedule Should HR PII Follow?

Set retention per record class, then enforce it in the schema. GDPR Article 5(1)(e) requires storage limitation without naming a number, so the number comes from the underlying legal driver — tax law, immigration law, limitation periods for employment claims. CCPA requires you to disclose that number before or at collection.

Enforcement is the hard part. A retention policy that lives in a PDF is not a control. Put retention_days on the field definition, run a scheduled sweep, and log what was deleted. If you cannot produce a deletion log, you cannot demonstrate Article 5(1)(e) compliance to a supervisory authority.

How Do You Handle DSRs for HR Data? Access, Rectification, and Erasure

For HR data, DSRs are harder than for customers because the data is spread across payroll, the ATS, the performance system, and someone's spreadsheet. GDPR gives you Articles 15, 16, and 17 — access, rectification, erasure. CCPA gives you the rights to know, correct, and delete under §§1798.100, 1798.106, and 1798.105.

Three things that make HR DSRs different:

• Erasure has statutory carve-outs. GDPR Article 17(3) lets you refuse where processing is necessary for a legal obligation or the establishment of legal claims. Payroll records you must keep for tax purposes are not erasable, and you should say so in the response rather than deleting and hoping.
• Rectification is often a downstream problem. Correcting a name in the HRIS does not correct it in the payroll extract, the benefits feed, or the badge system. Your field map is the list of places you need to propagate to.
• The clock is real. One month under GDPR, extendable by two for complex requests. 45 days under CCPA, extendable by 45. If your DSR tooling cannot query a field you never tagged, the extension is the only honest option.

How Do You Validate HR Data at Ingestion?

Validate classification at the point of ingestion, not in a downstream job. If a new column arrives untagged, it should fail the load rather than land in a table where nobody knows whether it is sensitive. The pattern I would argue for is a field-level contract attached to every column:

{
 "field": "national_id",
 "classification": ["gdpr:art4", "ccpa:spi"],
 "retention_days": 2555,
 "masking": "last4",
 "transfer": "scc_module2",
 "dsr_exportable": true,
 "lawful_basis": "legal_obligation"
}

A row that fails validation — unknown column, missing classification, retention longer than the regime allows — should route to quarantine with the failure code attached, not silently coerce. The ingestion patterns in HIPAA-compliant data ingestion apply directly here: reject, log, and require a human to classify before the field is admitted. If you are choosing tooling for this, the comparison in Flatfile and OneSchema alternatives for regulated industries covers where each one stops short on field-level classification.

A checklist to run before your next HR import:

• Every column has a classification array covering both GDPR and CCPA.
• Every column has a retention_days value, or an explicit exemption reason.
• Sensitive fields have masking set for non-production environments.
• Fields with dsr_exportable: true are reachable by your DSR query tool.
• Cross-border fields reference a transfer mechanism by name.
• The loader fails closed on unclassified columns.

Take one HR export, tag every column, and see how many you cannot justify keeping. That exercise is most of the work, and it is cheaper to do once on a sample file than to retrofit onto a populated warehouse. If you would rather not hand-roll the classification and validation layer, that is what we build at AdaptivMapr — start by mapping a single file and see what your schema is actually carrying.

FAQ

Is an employee ID considered PII?

Yes, under both regimes. GDPR treats a pseudonymous identifier as personal data because it can be linked back to a person with additional information. CCPA §1798.140(o) explicitly lists unique personal identifiers. Pseudonymisation reduces risk; it does not remove the data from scope.

Does CCPA apply to employee and applicant data?

Yes. The HR data exemption sunset on 1 January 2023, so California employers covered by the §1798.140(d) thresholds must honour access, correction, deletion, and limit-use rights for employees, contractors, and job applicants.

How long can we keep HR records under GDPR?

GDPR does not set a number. Article 5(1)(e) requires that you keep personal data no longer than necessary for the purpose, so the period comes from the underlying driver — tax law, immigration law, or a limitation period for employment claims. Document the driver for each record class.

What is the difference between pseudonymisation and anonymisation for HR data?

Pseudonymisation replaces a direct identifier with a key, but the data stays personal because re-identification is possible. Anonymisation means re-identification is no longer reasonably possible, which takes it out of scope entirely. Most "anonymised" HR extracts are pseudonymised, because the join key still exists somewhere.

Do we need SCCs to send employee data to a US parent company?

If the transfer is from the EEA and the importer relies on the EU-US Data Privacy Framework, an adequacy route may cover it. Otherwise you need SCCs — Module 1 for controller-to-controller intra-group transfers — plus a transfer impact assessment. Signing the clauses without the assessment is not a complete answer.