HR Data: Confidentiality, Pseudonymization and Anonymization

Data About People

Salaries, absences, evaluations, departures: HR analytics works on the most personal data in the company. A leak or poor disclosure can directly harm an employee, and teams’ trust in the HR department depends on it. This course therefore starts with data protection, before any calculation.

HR data is personal data within the meaning of the GDPR. A few established principles guide any analysis:

• purpose: you know why you process the data (manage turnover, measure pay equity) and you do not reuse it for anything else;
• minimization: you keep only the columns needed for that purpose;
• limited access: only authorized people see individual data;
• limited retention and security: protected files, no copy on a USB stick or in an email.

Some information falls under the special categories of data (notably health or trade union membership) and benefits from enhanced protection. A medical reason for absence is one of them: it is analyzed only in aggregate, if necessary, and discussed with the company’s data protection officer (DPO).

Minimize and Pseudonymize

To analyze salaries by department, you need neither the name nor the email address. Step one: remove them. Step two: replace the employee ID with a pseudonym, so you can link several files without exposing the real identifier.

A simple hash (sha256 of the employee ID) is not enough: employee IDs are few and predictable, and it is enough to hash all possible numbers to recover the correspondence. Use a function with a secret key, HMAC:

import hmac, hashlib

def pseudo(employee_id, secret):
    digest = hmac.new(secret.encode(), str(employee_id).encode(), hashlib.sha256).hexdigest()
    return digest[:12]

clean = raw.drop(columns=["name", "email"])
clean["pid"] = clean["employee_id"].map(lambda i: pseudo(i, SECRET))
clean = clean.drop(columns=["employee_id"])

The same employee ID always gives the same pseudonym with the same key, which allows joins. The key is kept separately, by an authorized person, never in the notebook or in the code repository.

Pseudonymization Is Not Anonymization

• Pseudonymized: the person is no longer named, but can be found again (with the key, or by cross-referencing columns). The data remains personal and the GDPR continues to apply.
• Anonymized: re-identification is impossible, irreversibly, by any reasonable means. The data then falls outside the scope of the GDPR.

Real anonymization is hard: in a small business, “the only female manager in the legal department over 50” is identifiable without any name. Cross-referencing a few columns (department, age, sex, hire date) is often enough. The usual techniques: generalize (age bands rather than exact age), remove rare columns, and publish only aggregates.

The Disclosure Threshold

Publishing “average salary of the legal department” when that department has two people amounts almost to publishing their salaries: each knows their own and deduces the other’s. Apply a threshold rule: any indicator calculated on fewer than N people (often 5; the value is an internal rule to set with the DPO) is masked.

def safe_aggregate(df, by, value, min_n=5):
    out = df.groupby(by)[value].agg(n="size", mean_value="mean")
    out["suppressed"] = out["n"] < min_n
    out.loc[out["suppressed"], "mean_value"] = float("nan")
    return out

Beware of deduction by difference: if you publish the company total and all departments but one, the masked department can be recalculated. Then mask a second group or group the small departments into an “other” category.

Key Takeaways

• Minimize: keep only the columns useful for the purpose.
• Pseudonymize with a secret key kept separately; the data remains personal.
• Never disclose an aggregate calculated on too small a group.