When Your People Analytics Outlasts the Privacy Laws That Governed It

Your people analytics dashboard still lights up every morning. Predictions refresh. Attrition models churn. But the privacy law that let you collect that data? It's gone. Repealed. Replaced by something stricter—or maybe more permissive. Either way, the legal foundation your HR dataset sat on just crumbled.

This isn't a hypothetical. Teams at mid-size tech firms and European manufacturers have told me: they built dashboards under GDPR Article 6, then local labor law changed. Consent periods expired. Purpose limitations shifted. Yet the analytics pipeline never stopped. So what do you do when your data outlives its legal authorization? This article gives you a concrete workflow—not legal advice, but practical steps to avoid a compliance landmine.

Who Needs This and What Goes Wrong Without It

HR analysts with legacy datasets from 2018–2020

You're the person staring at a spreadsheet that says 'GDPR consent: 2019-03-12' for 40,000 records—employees who quit, transferred, or died. The law under which you collected that data? Sunset. Replaced. Or quietly annulled by a newer regulation you only heard about in a compliance webinar you skipped. I have seen teams discover this mid-audit, five hours before a client wants a retention report. The dataset is gold—tenure patterns, exit interview sentiment, promotion velocity. But without a valid legal basis today, holding it's a liability, not an asset. That hurts.

Worse: you can't simply keep it because you always kept it. The privacy regime that authorized collection no longer applies. Your 2018 consent forms referenced a law that got rewritten in 2021. The data subjects never re-consented. So now what? You audit, you re-consent, or you delete. Pick one, because inaction is the fourth option—and that one leaks.

Companies that expanded into new jurisdictions post-GDPR

Your People Analytics team started in Germany, then opened a hub in Brazil, then a remote team in South Korea. Each jurisdiction had different sunset clauses for consent. LGPD, PIPA, CCPA—the acronym soup thickened. The catch is that your SaaS platform stored everyone under one tenant, one consent model, one timestamp. Wrong order. The seam blows out when a Brazilian ex-employee requests deletion under a law that didn't exist when you hired them. You never built the workflow for that. Most teams skip this: mapping data collection dates to the legal regime active at that moment. Not the current law. The historical one.

What usually breaks first is the audit trail. You have the consent checkbox but not the version of the privacy notice shown when they clicked it. That matters when the sunset law required a specific disclosure format. "You asked for permission in 2019, but in 2019 you didn't tell them you'd keep the data for five years." A regulator sees that gap. Then you explain—not to me, to a data protection authority.

'We kept the data because the old law said we could. The old law doesn't exist anymore. Nobody told the database.'

— HR operations director, post-audit debrief, 2023

SaaS platforms that never updated consent records

Here is the concrete failure I have debugged twice in the last year: a people analytics vendor that stored a single boolean column called 'consent_given'. True or false. No timestamp. No legal basis tag. No version reference. When the privacy law sunset, that column became a lie. You can't re-consent 12,000 people retroactively—you'd need a current legal basis to contact them, which you don't have because the old one expired. Circular? Yes. Fixable? Only by deletion. A rhetorical question (one per section, promised): Do you really need those 2018 engagement survey responses to calculate turnover risk for next quarter? Probably not. But the team that built the model on those rows will fight you. I have seen that fight lose a company three weeks of remediation time.

The trade-off is brutal: keep the data and risk a fine under the new regime, or delete it and lose the longitudinal trend. The pragmatic fix—re-consent a sample, model the bias, extrapolate—works only if you act before the next audit cycle. That said, most teams delay until the regulator's letter arrives. Don't be most teams. Start with the oldest records. They expire first. They hurt most.

Prerequisites: What You Should Settle First

Your Current Data Inventory and Classification

Before you touch a single record, you need to know what you actually hold. I have seen teams charge into re-consent campaigns only to discover they had no idea which fields were PII, which were inferred attributes, and which were stale beyond use. That hurts. Build a flat inventory first — every table, every export, every API endpoint that touches personal data. Classify each column: direct identifier, quasi-identifier, derived score, or anonymized aggregate. The catch is that most HR systems blur these boundaries. A "performance percentile" might be harmless alone, but combine it with a cost center code and a hire date, and you've re-identified someone. Wrong order. You can't remediate what you can't see.

Your inventory should also flag data that arrived under old consent but was later enriched. That enrichment breaks the original purpose statement — worth flagging — and a blanket "keep it" decision invites legal exposure. Most teams skip this. They assume data lineage is a one-time artifact from implementation, but lineage shifts every time a new survey tool pipes in or a manager exports a spreadsheet. Without a living map, your privacy remediation becomes guesswork.

Original Consent Forms and Purpose Statements

Find the actual documents. Not the policy page you wrote last month — the exact consent screen, the email copy, the checkbox language that employees saw when they first handed over their data. The privacy laws that governed that consent might have expired, but the consent itself remains the only legal basis for retention. If that form said "we use this for engagement surveys only," you can't pivot to retention modeling without fresh permission. A rhetorical question: does your legal team even know where those forms live?

The typical problem is that consent forms got rewritten three times over the years, and each revision broadened the purpose. Yet the old data never received updated consent. So you now hold a mixed bag — some records bound by narrow 2019 language, others by broad 2022 language — and no single policy covers both. That's the seam that blows out when a regulator asks for your data mapping. You need the original text, the revision history, and the date range each version applied. Archive it all. Then compare it against your current processing purposes. Where they mismatch, mark that bucket for re-consent or deletion.

Jurisdictional Mapping of Active Privacy Laws

Your privacy law landscape is not static. While the law that originally governed data collection may have sunset, new statutes might now claim jurisdiction over the same records. GDPR, CCPA, LGPD, PIPL — each has its own retention limits, right-to-deletion windows, and consent requirements. Map every jurisdiction where your people reside, not just where your company is headquartered. One concrete anecdote: we fixed a client's compliance gap by discovering that a remote employee in Brazil, hired under UK GDPR, was now covered by LGPD's stricter anonymization rules. That overlap changed the deletion deadline by six months.

The tricky bit is that jurisdictional mapping must account for data movement. If you stored employee records in a US-based server but the employee later relocated to the EU, both GDPR and the original law may apply simultaneously. You can't pick one. And if the original law sunset, the remaining statute still binds you.

'Sunset of the governing law doesn't sunset the data. The data stays; the legal basis evaporates.'

— privacy engineer, after a cross-border audit

Odd bit about resources: the dull step fails first.

Odd bit about resources: the dull step fails first.

That said, map conservatively. Over-assign jurisdiction rather than under. The cost of deleting data you could have kept is far lower than the cost of retaining data you should have purged. Returns spike when you get this wrong. Start with a spreadsheet of employee locations, data storage regions, and the active privacy law for each combination. Then overlay your retention schedules. If any record sits outside its governing law's retention window, flag it for the workflow in the next section. Not yet ready to act? At least you know where the landmines are.

Core Workflow: Audit, Re-consent, or Delete

Step 1: Tag every dataset with its authorizing law and expiration date

You can't fix what you haven't found. Begin by inventorying every people-analytics dataset — every table, every spreadsheet, every embedded dashboard — and tag each with the specific privacy law that originally justified its collection. GDPR? CCPA? Brazil's LGPD? A now-expired employment consent clause? Be explicit about the expiration date. I have seen teams discover a three-year-old engagement survey that was collected under a consent form that explicitly expired in 2022. The data still lived in the BI tool, untouched, ticking like a compliance bomb. This step is not glamorous — it's tedious, manual, and absolutely required. Most teams skip this: they assume IT already knows. IT doesn't. HR knows the source; legal knows the jurisdiction. Pin a single owner per dataset and force a deadline column. Without it, re-consent and deletion become guesswork.

One concrete trick: run a column profile on your 'consent_date' and 'consent_expiry' fields. Null values are your enemy. If more than 15% of rows lack an expiry, stop everything and treat that entire dataset as high-risk until tagged.

Step 2: Run a sunset impact analysis

Once every dataset carries a law-label and an expiry date, build a simple heatmap: cohorts whose authorizing law has already sunset sit red; those expiring within 90 days sit yellow; everything else green. The catch is that 'sunset' rarely means the law vanished overnight — more often it means the specific consent or legal basis for that processing activity no longer applies. A regulation might still exist, but your particular data-use justification evaporated. That distinction trips up most teams. They check whether the law is still on the books, not whether their permission slip is still valid. Wrong check. Wrong outcome.

For each red cohort, ask two questions: (1) Can we obtain fresh, valid consent under current law? (2) If yes, what is the cost — time, legal review, employee friction — to do so? If the answer to either is 'no' or 'prohibitively expensive', deletion is the only defensible path. This is where the trade-off bites: retaining historical trend data may require stripping it of personally identifiable information entirely, losing granularity for the sake of legality. A former colleague chose to keep aggregated averages but deleted all individual-level rows for a pre-2018 engagement dataset. Ugly solution. Clean outcome.

'We spent two weeks on step one alone. By step two, we knew exactly which six datasets had to go. The rest we saved with a single email-based re-consent campaign.'

— senior people analytics lead, mid-size tech firm

Step 3: Decide re-consent or deletion per cohort

Now the real work. For each red dataset, split your cohorts into two piles: those with a realistic path to re-consent, and those without. Re-consenting a current employee population is feasible — send a clear, plain-language notice explaining what data you hold, why, and for how long, then require an affirmative opt-in. Silence is not consent. That hurts, because many teams hope a passive 'we're keeping this unless you object' email suffices. It doesn't. Regulators in the EU and California have made that abundantly clear. For former employees, contract workers who left, or candidates who never joined — re-consent is often impossible. Their contact data may be stale, or they have no obligation to respond. Delete those rows. No archive. No 'just in case' backup folder. Permanent, verified deletion.

What about datasets that mix consent-expired rows with still-valid rows? This is the messiest edge case. You can't delete only part of a table if the schema ties rows together through foreign keys or aggregated calculations. The pragmatic fix: extract the valid cohort into a new, clean table with a fresh consent audit trail, then drop the original table entirely. Yes, that means rebuilding your dashboard. Yes, that takes a day. But a partial cleanup that leaves orphaned references or stale aggregates is not clean at all — it's a future audit finding waiting to surface. I have debugged exactly this situation: a company kept a 'training completion' table because 80% of the rows were fine, but the 20% expired rows created a legal exposure that a regulator spotted in a routine data-protection review. The fine was small; the reputational sting was not.

Tools and Setup: What You Actually Need

Data lineage platforms (e.g., Atlan, Collibra)

You can't fix what you can't see. That's the brutal reality when privacy laws expire and your data still sits in some forgotten Snowflake instance. I have watched teams waste two months manually tracing where PII lives — only to miss a backup in an old S3 bucket. Do that. A data lineage platform like Atlan or Collibra gives you a living map: which fields touch which datasets, which transformations added noise, which copies were handed to a vendor in 2022. The catch is cost. These tools run $15k–$50k annually, and for smaller shops the overhead stings. But the alternative — guessing — costs more in legal liability alone.

You need three configurations from day one. Tag every column that ever held GDPR or CCPA data, even if pseudonymized. Set automated freshness checks: if a dataset hasn't been touched in six months, flag it. Then wire lineage alerts to your compliance Slack channel. Most teams skip this — they buy the tool, map one pipeline, and call it done. Wrong order. Without continuous scanning, you're auditing a snapshot that expired yesterday.

Better a scrappy script than no map at all. If budget blocks Collibra, use dbt's built-in lineage features plus a weekly `SELECT * FROM information_schema.columns` sweep. It's ugly. It works.

Consent management systems with expiry tracking

A consent management platform (CMP) alone is useless post-sunset. I mean that. Standard CMPs log "user agreed on 2023-03-01" but never ping you when the underlying law dissolves. What breaks first is re-consent timing: if your legal basis evaporates on July 1, you have maybe 30 days to either refresh consent or delete records. Without expiry tracking, you fly blind.

Look for CMPs that support event-driven retention schedules. OneLogin's governance module does this — you set a legal basis ID per regulation, attach an expiration date, and the system triggers a workflow when that date passes. The workflow should generate two outputs: a list of affected subjects and a pre-built deletion request for your data warehouse. That is the tooling pattern. Most vendors sell "consent lifecycle management" but skip the sunset hook. You want the one that screams when a law dies, not one that silently archives the checkbox.

We fixed this once by bolting a simple Python cron job onto our existing CMP. Every morning it checked a YAML file of active privacy laws. When a law's end date matched `today + 30`, it dumped affected user IDs into a bucket. Hacky? Yes. Running in production for 18 months without a single missed sunset? Also yes.

Not every human checklist earns its ink.

Not every human checklist earns its ink.

"The moment you stop tracking consent expiry is the moment you start storing data without permission. That's not a policy problem. It's a tool gap."

— Lead data engineer, mid-market SaaS firm (anonymized)

Pseudonymization utilities for legacy datasets

Deleting is cheap. Keeping is expensive — but sometimes necessary. For datasets where deletion would crater your ML models or break historical reporting, pseudonymization buys you a bridge. The tool to reach for is Apache DataFu (for Pig/Hive) or Presidio from Microsoft. Both provide tokenization that replaces direct identifiers with reversible (but access-controlled) tokens. The trick: store the mapping table in a vault outside the dataset's region. If the old privacy law required data to stay in the EU, your token vault must too — even if the pseudonymized copy lives in us-east-1. That nuance kills teams who lift-and-shift.

What about open source? `hashids` or Django's `crypto.sign` work for simple cases, but they lack audit trails. A regulator will ask: "Show me who reversed those tokens." Presidio logs every de-tokenization attempt. So does Talend's pseudonymization component. Spend the extra engineering time to wire audit logging; otherwise your pseudonymization becomes a liability masquerading as a solution.

One pitfall I see regularly: teams pseudonymize the production database but forget the analytics sandboxes. Those sandboxes often have raw PII from last year's export. So after you run your tool on the main warehouse, grep for email patterns in every `.parquet` file. The utility works. The scope management is where it fails.

Variations for Different Constraints

When you have no legal team (startup scenario)

You're the People team. You're also the legal team, the IT team, and probably the person who unjams the printer. Privacy laws sunset, and suddenly your employee data lake feels like a loaded weapon with no safety. Most startups default to panic-deleting everything. That's wrong. The better move: map what you actually hold before touching a single row. I have watched a twelve-person company waste three weeks because they deleted a survey dataset they still needed for a harassment-pattern audit. The catch is you cannot afford fancy consent-management platforms. So build a spreadsheet with three columns — data type, collection date, original consent purpose — and flag anything older than the law that just expired. Then send a single, brutally honest email: 'We stored X for Y reason. The old legal basis is gone. Please re-consent here, or we erase your records in 14 days.' That email is your legal team. It works. One founder told me it returned a 92% re-consent rate because employees actually read it — no legalese, just clarity.

'We burned two months building a custom retention engine. A Google Sheet and three calendar reminders would have done the same job.'

— CPO, Series B health-tech startup, after a GDPR sunset scramble

Trade-off: you trade scalability for speed. That spreadsheet breaks at 500 employees. But you probably are not there yet.

When the law changed mid-study (longitudinal research)

Your engagement pulse has run quarterly for four years. Now the privacy regulation that rubber-stamped it's dead. The study itself is priceless — you track turnover predictors across tenure, and killing the data mid-stream destroys your model. This is where most teams freeze. Don't. The fix is narrower than you think: you don't need to re-consent the whole archive. You need to re-consent forward collection under the new law, and retroactively anonymize the historical data that no longer matches the updated consent scope. That sounds fine until your HRIS vendor tells you they cannot partial-anonymize without a custom script. What usually breaks first is the join key — employee ID. One longitudinal client had 18 months of perfectly linked data, but the old consent form allowed 'aggregate trend analysis' while the new law required 'specific, bounded use for retention-risk modeling only.' We solved it by splitting the dataset: historical records got a salt-hash replacing the employee ID (irreversible, so not personal data anymore), and new records used a fresh consent flag. The model retrained on a hybrid set — older anonymous trends plus new identified data — and predictive accuracy dropped only 4%. Not zero. But not a rebuild either.

The pitfall: assuming your data vendor will help. They won't. Most third-party cloud hosts (Think: BambooHR, Culture Amp, Qualtrics) treat re-consent as a feature you pay extra for or do manually via API exports. Test your export format before the law changes. CSV with nested consent fields? JSON with timestamps? If the export flattens consent status into a single boolean, you lose the audit trail. That hurts.

When data is hosted in a third-party cloud

Your data lives in someone else's infrastructure. Their privacy policy changes. Your obligations don't. The hard truth: you're still the data controller, even if your SaaS provider bungles the sunset. I have seen a company assume their ATS vendor would auto-delete expired candidate records when Quebec's Law 25 took effect. The vendor didn't. The company got a fine because they owned the data, not the tool. The variation here is about control — or the lack of it. If your vendor has no API for selective deletion, you have three options: download everything, strip personally identifiable information locally, then re-upload the anonymized set; negotiate a custom data-processing agreement with a specific sunset clause (costs time, not always money); or migrate to a platform that supports retention policies by jurisdiction. Most teams skip the second option. That's a mistake. A well-written addendum — three paragraphs, no legalese — can force your vendor to act as your deletion arm. We did this for a mid-market retail chain using a legacy performance tool. They added a line: 'Upon expiry of any applicable privacy law, Provider shall, at Controller's direction, irreversibly anonymize or delete records within 10 business days.' The vendor complied because it was simpler than arguing. Start there. If they refuse, you have your answer: they're not a long-term partner for regulated People Analytics.

Pitfalls and Debugging: What to Check When It Fails

Consent records with no expiry date (common legacy bug)

Most teams skip this: your old HRIS or survey tool probably stored consent as a binary flag. Yes or no. No timestamp, no jurisdiction tag, no expiry field. That sounds fine until a privacy law sunset clause kicks in and you cannot prove when that consent was given — or whether it covers the new legal basis. I have seen a People Analytics stack that still held opt-in records from 2018 with an empty `valid_until` column. The diagnostic fix is brutal but quick: export all consent rows, filter for null expiry dates, and cross-reference against the employee's last active date. If the record predates the current regulation by more than five years, flag it for re-consent immediately. Wrong order? You lose your safe harbor.

The catch is that many legacy systems never wrote an expiry because the original law didn't require one. You cannot assume silence means "still valid." That hurts.

Models that break after data deletion

You delete 40% of your historical training data to comply with a retired law — and your turnover prediction model drops from 82% AUC to 0.61. I have debugged this exact scenario. The model had learned patterns from a subset of employees whose consent had lapsed, and removing those rows created a distribution shift that the production pipeline never saw coming. The fix is not "restore the data." That would violate the new framework. Instead, you retrain on the remaining population and accept a narrower feature set — typically dropping tenure buckets and manager-ratings that were over-indexed on the deleted cohort. One concrete anecdote: a client's churn model regained acceptable performance only after we added an interaction feature between department and project count, compensating for the lost rows. Not perfect. But lawful.

What usually breaks first is the feature engineering layer. You delete rows, but the aggregations that fed the model still reference deleted records. Silent errors. Schedule a full pipeline test after any data purge. Don't trust the dashboard until you see a fresh confusion matrix.

Reality check: name the resources owner or stop.

Reality check: name the resources owner or stop.

Jurisdictional conflicts (e.g., GDPR vs. new local law)

The tricky bit is when a data subject requests deletion under a law that has been replaced. GDPR's right to erasure might still apply if the data was collected while the regulation was active — even if the company has since adopted a newer local framework. Most people analytics teams treat the sunset as a clean cut. It's not. You can have two legal obligations on the same record: the old law says delete, the new law says retain for tax audit. The diagnostic step is ugly but necessary: map every data field to both the original regulation and the current one. Where they conflict, the stricter retention rule wins — but you must log the override. We fixed this by adding a `legal_conflict_resolution` field that stores the date and rationale. Without it, an auditor sees a deletion gap and assumes negligence.

“We kept the data because a newer law demanded it — but we couldn't prove when or why. That cost us six months of remediation.”

— Lead People Analyst, anonymous feedback from a 2023 privacy audit

Another common failure: ignoring the data's original location. If an employee was based in Germany when they opted in, but the company later moved all records to a US-based warehouse under a new state privacy law, the cross-border transfer clause from the old regulation may still bind you. Check the jurisdiction tag at the point of collection, not the current storage region. That mismatch breaks compliance faster than any expired consent flag.

FAQ: Quick Answers on Legal Sunset and Data Retention

Can I keep analytics if I anonymize the data?

Yes—but only if the anonymization is irreversible and truly strips all re-identification paths. Pseudonymization (replacing names with tokens) is not enough; a determined actor with access to your HR system can often re-link rows. The catch: most people-analytics tools store metadata—device fingerprints, location pings, click trails—that remains personally identifiable even after you scrub names. I have seen teams 'anonymize' a dataset, only to realize six months later that a join on team ID + shift start time uniquely identifies every employee. That hurts.

If you go this route, run a k-anonymity audit. Every row must be indistinguishable from at least four others. And document how you anonymized—regulators may demand proof later. The GDPR enforcement in 2023 fined one firm €1.2m for claiming anonymization when they had only done pseudonymization. Worth flagging—the moment a regulator proves re-identification is possible, your 'anonymized' data becomes personal data again. Retroactive.

Do I need to re-consent employees hired before the law changed?

Almost always yes. Consent collected under a legal framework that has since expired—or been replaced—doesn't carry over. The common mistake: assuming 'we got consent in 2019' covers you in 2025. It doesn't. The new law may require a tighter description of processing purposes, shorter retention windows, or explicit opt-in for automated decision-making. If your old consent form simply said "we use your data to improve workplace experience," that's too vague under most modern privacy acts.

Send a fresh re-consent campaign. Give employees a 30-day window. And track who responds—those who ignore the request should be treated as non-consent. One client tried to skip re-consent for their 'low-risk' engagement survey data. That seam blew out during an internal audit: the auditor flagged every pre-law respondent as non-compliant. We fixed it by deleting all pre-2022 survey rows and starting over. Not yet painful enough? Consider that consent withdrawal is also retroactive under some statutes—employees hired under the old law can demand deletion of all their historical data, not just post-transition data.

What if the new law is less strict?

Less strict doesn't mean weaker—it means different boundaries. A new law might drop the consent requirement for certain analytics but impose stricter data minimization. Or it might allow longer retention but mandate a privacy impact assessment every 12 months. The pitfall: teams often relax controls because 'the new rules are easier.' That's a trap. You still need to prove compliance with whichever framework was active at the time of collection. You cannot retroactively apply new rules to old data unless the statute explicitly says so.

In 2022 we collected productivity logs under a law that allowed 5-year retention. In 2024 that law was repealed and replaced with a 2-year cap. We had to delete 3 years of data overnight. The analytics models we built on that old data? Useless.

— HR Analytics Lead, mid-size tech firm

This is the real cost. Your models, dashboards, and benchmarks trained on sunset-legal data become orphan assets. You cannot keep the insights without keeping the underlying data—and if the data must go, so do the predictions derived from it. What to do next: survey your current retention schedule against both the old and new legal floors. Where they conflict, pick the shorter window. Then run a 30-day deletion project for everything that exceeds that window. I have done this at three organizations; the first pass always reveals at least one forgotten data lake with expired consent logs. Start there.

What to Do Next: Your 30-Day Remediation Plan

Week 1: Inventory and tag all datasets by authorizing law

Pick a single source of truth — a spreadsheet, a lightweight data dictionary, anything that exists outside someone’s head. I’ve watched teams burn two weeks arguing over taxonomy when they could have just started tagging. Tag every people dataset with the specific regulation that authorized its collection: GDPR Article 6(f), CCPA Business Purpose, LGPD consent clause, whatever applies. Performance reviews, engagement surveys, termination codes — if you can’t name the law that let you collect it, that data is already a liability. The catch is that most HRIS exports don’t include a “legal basis” column. You will have to reconstruct this from intake forms, old privacy notices, and verbal handoffs. Painful, yes. Cheaper than a regulator knocking.

One hard rule: don’t move data between environments until it’s tagged. Wrong order — and you lose audit trail.

Week 2: Identify sunset risks and prioritize cohorts

Now sort your inventory by expiry date. Some laws had explicit sunset clauses — Italy’s emergency remote-work decree expired in 2022, for example. Other data was collected under a consent version that users haven’t renewed. The tricky bit is prioritization. Cohort A: data collected under a repealed statute. Cohort B: data whose consent is older than 24 months. Cohort C: everything else. Focus on Cohort A first. Why? Because a repealed law gives you zero standing to retain — not even a transitional grace period in many jurisdictions. Most teams skip this step and do a blanket delete. That hurts when Legal later needs a specific record to defend a wrongful-dismissal claim. Keep a deletion log before you hit erase.

“We kept survey responses from a program that legally ended in 2021. By week three we realized that data was still feeding our attrition model — silently, illegally.”

— People Analytics Lead, EMEA retail firm

Week 3: Execute re-consent or data deletion

For Cohort B, send re-consent requests — but only after Legal approves your language. A common pitfall: asking for “continued use” instead of explicitly naming the original purpose. That gets rejected. Worse, it triggers data-subject-right requests. If response rates drop below 40%, pivot to deletion. Don’t hoard. I’ve seen teams hold onto 70% of stale data because “we might need it for benchmarking.” You won’t. You’ll inherit a new privacy regime in 18 months and repeat this whole process. For Cohort A: delete or pseudonymize irreversibly. “Anonymization” sounds safe but most pseudonymization re-identification methods survive SQL joins. Hard delete is cleaner.

Week 4: Update analytics pipeline and document changes

Rebuild any dashboard or model that touched the removed data. That means updating feature schemas, retraining outlier detectors, and — critically — rewriting the data dictionary you started in Week 1. Document every deletion: what, when, under which legal rationale. This isn’t bureaucracy; it’s your shield during the next audit. Then schedule a quarterly review. Privacy laws change faster than most HR analytics roadmaps. A 30-day plan gets you compliant today. A recurring check keeps you from waking up to a cease-and-desist next year.