Buckets, Benefits, and Boundaries: HR Records in a Growing Privacy Climate
Date: Thursday, Aug. 21, 2025
Featuring Brandon Tuley, Senior Analyst & Jennifer Chadband and Rick Surber, Zasio Senior Consultants
Editorial Note: Portions of this transcript have been reviewed and refined using AI tools to improve readability, punctuation, and clarity. While the content remains true to the original discussion, minor edits were made to enhance understanding.
—
Thanks, Jerry, for that introduction, and thanks, everyone, for joining us today.
We’re really excited to have Brandon with us.
Brandon is a senior analyst and has been with us for a little over five years.
In that time, he’s established himself as an important part of our consulting division and has had plenty of opportunities to dive deep into this topic. He’s incredibly knowledgeable, and we’re happy to have this conversation today.
Just a quick introduction to Virtual Coffee:
If this is your first time joining us, we encourage everyone to grab a cup of coffee—or whatever your beverage of choice is: Diet Coke, water, etc.
We try to structure these sessions with visuals and slides to guide the conversation, but we keep things casual and conversational. We’ll share industry best practices, general trends we’re seeing, and some guidance we’ve developed that we hope will be helpful.
We welcome questions throughout.
There are opportunities to submit them, and we’ve received quite a few in advance. While we won’t be able to address all of them today, we’ll follow up afterward as needed.
Now, a bit more on today’s topic:
This is a fascinating area for a few reasons. We’re thinking about HR records, personal data, and the evolving technology used to manage these records—even down to a very granular level.
About eight years ago, I wrote a blog titled Is Big Bucket Dead in the Age of Privacy? We’ll revisit that question today and explore how things have evolved, especially in the context of HR-related records.
There’s a lot to cover, so I’ll hand it over to Brandon to walk us through the agenda and the key subtopics we’ll be discussing.
Brandon:
Thanks for the introduction, Jen, and thank you all for joining us.
I’ll start with a bit of a spoiler: the big bucket retention schedule is still very much alive.
We’ll talk about why it remains a best practice and how it’s evolving under increasing privacy pressures.
From high-level strategy to specific HR record categories, we’ve got a full agenda.
We’ll cover:
- The tension between big bucket simplicity and data object-level complexity
- How to bridge that gap while keeping privacy in mind
- Specific “hot ticket” areas within HR records
To kick things off, let’s talk about a common challenge: the deletion vs. retention dilemma.
I think of this as a classic tug-of-war:
- Privacy advocates say delete it.
- Operations wants to keep it.
- Legal says, “It depends.”
Each stakeholder has valid reasons.
Privacy concerns and administrative costs drive deletion.
Retention is often justified by legal requirements or past experiences where old records were needed.
Legal, of course, tends to hedge.
Once you’ve worked through that dilemma, global operations add another layer of complexity.
You’re trying to create a unified policy that accounts for different jurisdictions and record types—a one-size-fits-all approach that’s incredibly difficult to achieve.
Over the past few years, especially post-GDPR, we’ve seen more organizations reassessing global retention periods—particularly for buckets containing personal data.
They’re trying to apply the data minimization principle, shorten retention periods, and avoid unnecessary data storage.
Then comes the structure of the retention schedule itself:
Are we aiming for big buckets or a granular approach?
The answer is: both.
The goal is to strike the right balance—broad enough to be manageable, but with carve-outs where privacy demands it.
Too little granularity leads to over-retention.
Too much, and the schedule becomes impossible to follow.
We want that middle ground—structured enough to be compliant, but simple enough to be practical.
With that, I’ll pass it back to Jen to talk about data object-level management and how it fits into the big bucket model.
Jen:
Thanks, Brandon.
You hit on some of the most important points—especially the tension we’re all trying to manage between simplicity and precision.
Let’s talk about how we go granular—and why.
I think this is definitely being driven by privacy laws.
Stepping back and looking at the retention schedule, we’re also considering this in the broader context of personal and sensitive information. Legal recordkeeping requirements help define what the appropriate level of granularity should be.
At the same time, we’re increasingly managing information at the data object level and reconciling that with the big bucket retention schedule—two ends of the spectrum.
What does that look like in practice?
As Brandon noted, going too granular can make things overly complex, difficult to manage, and costly. Each law associated with granular data adds layers of complexity.
So, it’s really about finding the right balance.
When managing data at the object level, the complexities increase.
For anyone unfamiliar with systems that manage at this level:
A data object can be an individual electronic document (like a performance review), an email, or even a field entry—such as an address or benefits enrollment—within a system.
The benefit of managing at this level is precision.
You can apply retention rules in various ways, including event-triggered management.
This helps mitigate risk by allowing you to tag, add metadata, and track creation and management of data objects.
Retention can be applied with audit trails and other capabilities.
One of the most common systems for this is an HRIS—Human Resources Information System.
Workday is a well-known example.
These systems often integrate with broader document and content management platforms, including electronic records management systems (ERMS), to automate classification and retention.
This allows your retention schedule to flow through to these systems and apply rules at the most granular level.
Now, here’s where complexity really comes in:
We have big buckets, but multiple data objects may relate to a single bucket.
Different jurisdictions may require different retention periods.
How do we manage that?
Which retention period do we follow?
This introduces another layer of complexity we need to address.
There are also benefits:
Enhanced automation and improved compliance with privacy laws like GDPR and CCPA.
You can track and audit at a granular level, which is essential in today’s regulatory environment.
This isn’t just an HR issue.
Other industries—like financial services and healthcare—are also managing data at the object level.
Customer and patient information are prime examples.
This is the emerging reality we’re dealing with.
So how do we bridge the gap between big bucket retention schedules and granular data object management?
We received a great question that ties directly into this topic:
What is the recommended industry approach for managing the retention of employee source data, particularly when the data set serves as a foundational record due to its extensive interdependencies with other HR records? Is it appropriate to retain employee source data until all dependent records have reached the end of their retention periods? If so, what are the best practices for documenting this approach to ensure compliance with regulatory requirements?
This question really hits on the core issue.
Source data—often a data object or field-level entry—can include things like an employee’s address, benefits enrollment, or Social Security number.
These data points may be needed for multiple HR records: benefits, payroll, personnel files, etc.
It creates a spiderweb of dependencies, with the source data at the center.
Downstream systems rely on it for data integrity.
So what’s the answer?
Yes—most clients retain source data for as long as the dependent records exist.
This ensures downstream data integrity, prevents orphan records, and allows for verifiable audit trails.
This approach is typically documented in two places:
- The records retention schedule, aligning systems and repositories with record categories
- A data disposition policy, which calls out specific categories and their alignment to source data
We’re hitting on key points here:
We need to be able to audit and verify our records, and the data is what those records are comprised of.
It’s part of the audit and verification process.
That’s one of the justifications for tying records to the retention schedule and the legal requirements that support it.
Another issue is orphaned records.
Too often, we hear horror stories about data disposition teams trying to clear out personal information—doing what they think is right—but ending up with orphaned records downstream that lack identifiable information they may still need.
Yes, that’s absolutely on point, Rick.
The general rule of thumb is to consider the longest applicable requirement when setting retention periods.
There’s a lot to think about.
Practically, this process often involves mapping granular data objects to the records retention schedule.
This helps determine appropriate retention periods—whether global or country-specific exceptions.
For example, a data object related to a submitted application might fall under the recruitment record series.
If the applicant isn’t hired, the retention period might be short globally, but longer in the U.S.—California requires four years, Colorado five.
This illustrates the complexity of managing retention periods across jurisdictions.
Organizing data under your retention schedule allows you to see all applicable retention periods and create a clear trail for decision-making.
This helps determine the final retention period for each data object.
For hired employees, you might retain a data object for the duration of employment plus seven years.
But if there are ongoing obligations—like benefits—you may need to retain it much longer, possibly 20, 30, or even 40 years.
There’s a wide disparity in how long a single data object might be needed for different business purposes.
You can manage this manually by tracking it within your retention schedule fields.
If you have an electronic solution, those fields can be mapped and traced.
You can then create classification rules based on the retention schedule, tailored to each data object’s content, sensitivity, and regulatory requirements.
If you’re fortunate, your system may include AI or machine learning capabilities to automate some of this.
Automation helps apply retention periods directly within systems like HRIS, which often have built-in retention features.
This is great because it adds accountability.
Everything is mapped, retention periods are known, and manual effort is reduced with system support.
Systems should also provide audit trails—tracking when data is deleted and why.
Always document the justification for retention periods, especially for broader record sets, to ensure compliance.
Having a clear trail from the data object level up helps justify broader retention periods and ensures they’re set appropriately.
This is an evolving area.
We’re reconciling these new realities with our retention schedules.
It ties into the broader conversation about designing schedules that reflect the shift toward more granular retention requirements.
We’re seeing laws and regulations increasingly focused on personal data at a granular level.
We’re accountable for justifying retention periods in specific cases involving personal data.
All of this helps us manage information more efficiently and effectively, while maintaining compliance.
With that, I’ll transition to Brandon, who’s going to dive deeper into specific record categories and how they’re being addressed in retention schedules with these new factors in mind.
Brandon:
Thanks, Jen.
Let’s zoom in on our first HR records category: recruitment records.
Specifically, we’ll look at how retention strategies and schedule structures differ for hired vs. non-hired candidates, and how global operations impact retention periods for these groups.
First, regarding retention schedule structure:
We commonly see two separate buckets—one for non-hired individuals and one for hired individuals, whose recruitment records become part of the personnel file (which we’ll cover later).
This structure allows retention periods to be tailored to the purpose for which the information was collected and helps address express retention requirements that are increasingly common worldwide.
We commonly see that non-hire recruitment records have much shorter retention periods.
They often lose their value once the individual is no longer a candidate for the position.
Focusing on those who aren’t offered employment—or perhaps are fortunate not to be—non-hire records typically have a global retention period ranging from six months to two years.
Common retention triggers include the creation date or the employment decision, allowing for a more privacy-conscious approach aligned with the purpose for which the information was collected.
Two key considerations drive that six-month to two-year retention range:
- Recordkeeping requirements
- Discrimination claims
As Jennt mentioned, U.S. requirements tend to be longer than those in other countries.
California previously led with a four-year requirement, but Colorado recently extended that to five years, pushing retention even further.
It’s interesting how neighboring jurisdictions often follow suit.
Ontario, for example, recently introduced a three-year retention requirement for non-hire records—the first express requirement of its kind in Canada.
We expect these express retention requirements to continue growing as more jurisdictions adopt similar standards.
Yes, and when it comes to recordkeeping requirements, they’re major drivers of the retention schedule—especially for privacy.
Outside the U.S., though, few jurisdictions have defined retention periods for recruitment records.
That leaves us with limited guidance.
Sometimes, legal teams will reference statutes of limitations for discrimination claims, which might support a one-year retention period.
Beyond that, privacy laws generally say to retain data no longer than necessary.
That could mean deleting records once an employment decision is made—whether the person is hired or not.
It’s a wide range of retention periods, and reconciling them is a challenge when designing your retention schedule.
Rick:
Exactly.
It also depends on what’s in those records.
Discrimination concerns might justify longer retention, but if you can support your processes using summary data without personal information, that’s ideal.
Still, some clients—especially in California—retain recruitment records long-term due to frequent legal challenges.
Having more information helps them defend against claims.
It becomes a company-by-company risk analysis.
If you’re facing discrimination suits and personal data is relevant to those cases, longer retention may be justified.
Brandon:
Absolutely.
And with global operations, retention requirements can vary widely.
Outside the U.S., we often see maximum compelled deletion requirements—laws that specify how long certain types of data can be retained before mandatory deletion.
Examples:
- France: 2 years
- Germany: 6 months
- Netherlands: 4 weeks after the application process ends
Even within the EU, there are significant differences in privacy regulations.
For hired recruitment records, once someone joins the organization, their recruitment records typically become part of the personnel file.
We’ll cover that in more detail in upcoming slides.
Closely tied to recruitment records are background checks.
Let’s look at how organizations manage these records and the differences between hired and non-hired individuals.
Like recruitment records, it’s common to see two buckets:
- One for non-hired individuals
- One for hired individuals
For non-hire background checks, we typically see a global retention period from the employment decision to one year.
This is driven by privacy considerations and potential discrimination claims.
What makes this more privacy-focused is the lack of express retention requirements for this group.
So, privacy principles often guide shorter retention—keeping data only as long as necessary for its original purpose.
In the case of background checks for non-hires, that purpose is usually to make a hiring decision.
Once that decision is made and the individual is no longer under consideration, the records lose their retention value.
Jenn:
And to add to that, background checks can contain very sensitive or even embarrassing information—especially if unrestricted.
This is a recurring theme:
Data minimization is key.
If your industry allows, maybe you only pull 5 to 10 years of information—or ideally, don’t collect detailed data at all.
There are background check providers that offer a pass/fail approach.
You provide the conditions, they return a pass or fail result.
They may only share personal information if there’s a potential fail to review.
This isn’t always feasible for highly regulated industries—like nuclear energy—but for most, there’s room to minimize the information initially collected.
Absolutely.
Those minimization principles help reduce risk by keeping privacy considerations front and center.
This is addressed at the process level, outside the retention schedule, but still contributes to strong privacy practices.
Once an employee is onboarded, many of the records we’ve discussed become part of the personnel file.
But what exactly goes into that file, and how should it be managed?
It’s critical to define what the personnel file includes within your organization.
This definition will vary by jurisdiction and be shaped by local policy, operational needs, legal requirements, and risk considerations.
Some jurisdictions don’t have express retention requirements for personnel files, so it’s important to establish clear parameters—for both privacy and compliance.
This helps avoid under-retaining or over-retaining certain types of information and ensures records are placed in the correct buckets or adjusted as needed.
Another key consideration is understanding what information goes into the personnel file so you can apply appropriate protections for sensitive data.
It’s important to note:
The personnel file is not a file plan.
Communicating this distinction to stakeholders helps reduce confusion and unnecessary questions.
And it’s not just stakeholders—sometimes even records managers confuse the retention schedule with a file plan.
That’s a great point.
Just because something is part of the personnel file from a retention schedule standpoint doesn’t mean it’s physically bundled together.
Certain records—like employee grievances, investigations, and medical files—should be maintained separately due to their sensitive nature, even if they share the same retention period.
So, distinguishing between retention periods and how the personnel file is managed is critical for privacy and organizational clarity.
If you’ve stuck with us through defining the personnel file, let’s talk about retention periods.
Globally, the common retention period for personnel files is duration of employment plus 5 to 7 years.
In the past, we saw retention periods as long as duration plus 10 years, but that’s shifting as privacy requirements gain traction and organizations adopt better practices.
Retention periods are often based on:
- Recordkeeping requirements
- Express retention laws
- Statutes of limitations
- Legal liability considerations
Local legal counsel may request longer retention periods—even when express requirements exist.
Opinions can vary even among experts within the same jurisdiction, so it’s important to align everyone during the review process.
Getting buy-in across the organization makes the process smoother and ensures the retention period is appropriate.
We’ve addressed our first question—now let’s move to the next two, which highlight the complexity of personnel files.
We’re considering digitizing our HR records, which include background checks, address changes, annual performance reviews, and more. Each document type has its own retention requirements, which adds complexity. What’s an effective strategy for applying the correct retention period to each document type within a personnel file? Alternatively, would it be more practical to assign the longest applicable retention period to the entire file?
Let’s start with the second part:
We do not recommend applying the longest retention period to the entire file.
Defining the personnel file—based on jurisdictional requirements—is essential.
Once you know which records are included, you can structure your HR records accordingly.
Be aware of express retention requirements, operational needs, and record life cycles.
Group records logically into buckets that reflect these considerations.
Jenn:
Quick question for clarification, Brandon:
If we define a personnel file to include five record types, and individually those records have different retention periods—say, one year for recruitment records and seven years for performance reviews—would the personnel file follow the longest retention period?
Brandon:
Yes—if those records are officially part of the personnel file as determined through legal counsel, express requirements, and internal policy, then they would be grouped and follow the longest applicable retention period.
But we can’t let the tail wag the dog.
We shouldn’t include benefits or pension records in the personnel file just to apply a permanent retention period across the board.
There needs to be logic behind the grouping to avoid unnecessary over-retention.
Based on data minimization principles, sometimes retention periods force us to step back and ask:
Do we really need to retain all these records for the longest possible time?
Or would it make more sense to break them out and assign shorter retention periods—especially for highly sensitive information?
That’s a great question.
Next question related to personnel files:
Given that employee documentation is often segmented into distinct record types—such as personnel files, learning and development records, benefits documentation, and performance management files—each governed by different legal and regulatory retention requirements, what is the recommended industry approach for managing these interdependencies while avoiding unnecessary over-retention?
Specifically, is it advisable to apply the longest retention period—typically driven by benefits records like pension or life insurance—to all employee-related records for simplicity and risk mitigation? If so, how is this reconciled with increasingly stringent privacy regulations that emphasize data minimization and purpose limitation? If not, what criteria or framework should guide decisions about what to retain versus what to securely dispose of?
As Rick mentioned earlier, we don’t want the “tail to wag the dog.”
You should parse records out in your retention schedule so that the longest retention period doesn’t drive over-retention across all record types.
While longer retention may help mitigate risk in some cases—such as defending against claims—it also increases privacy risk when data is kept longer than necessary.
Instead, match each record type to its legal and regulatory requirements, consider its lifecycle, and group similar records into logical buckets.
This allows for a structured retention schedule tailored to your organization.
Cookie-cutter schedules won’t account for these nuances.
It’s important to dive into the process and create a document that reflects your operations and compliance needs.
A one-size-fits-all approach rarely works.
Tailoring your schedule is critical for both compliance and risk mitigation.
Now, let’s talk about managing benefits and pension records while staying mindful of privacy considerations.
Where retention meets retirement, organizations often ask:
Do we need a “skeleton” record series?
Before we get there, let’s look at the typical structure of these records.
For individuals, we commonly see a global retention period of final payment plus 5 to 11 years.
Retention considerations are based on recordkeeping requirements and risk—especially in the U.S.
One notable case is Barton v. ADT, from the U.S. Ninth Circuit.
Barton claimed he worked for ADT from 1967 to 1986.
In 2010, he sought pension benefits, but the plan administrator denied the claim, citing lack of records.
The court ruled that when a claimant lacks access to key information controlled by the plan administrator, the burden of proof shifts to the administrator.
Beneficiaries aren’t expected to produce records—the administrator must.
This ruling triggered a conservative approach in many organizations, leading to longer retention periods.
Jenn:
That ruling doesn’t specify a retention period, right?
It just says the administrator must produce records related to benefits paid or payable.
Brandon:
Exactly.
The “payable” language puts organizations on high alert.
It implies that records may need to be produced at any time, which leads to very long-term retention.
Some organizations now use final payment as a trigger to account for that “payable” clause.
But there’s still pushback from stakeholders.
This language has caused challenges—but also helped ensure people receive the benefits they’ve earned.
Jenn:
With clients who offer traditional pension plans, we often see permanent retention for these records—especially in the U.S.
But there are exceptions.
Brandon:
Yes, some countries also have long-term retention requirements.
For example:
- Brazil: 30 years for Social Security indemnity records
- Latin America: Frequent requests for long retention periods, often citing archival laws
- Russia: Shelf-life law
- China: Archives Order No. 10
- Eastern Europe: Similar long-term archival requirements
Globally, retention schedules are often split—some jurisdictions require long-term retention, others don’t.
Reconciling this with the need to defend against pension claims remains a challenge.
The idea of a skeleton category is widely appealing.
We’re short on time, but let’s quickly describe it.
The “skeleton” category is meant to be bare bones—only essential information.
It aligns with data minimization principles.
Think of it this way:
What is truly essential to retain long-term or permanently (preferably with a defined long-term period to avoid “permanent” where possible)?
This would include only the core data needed to guarantee payment of benefits to employees or their beneficiaries.
The goal is to create a category that captures only that essential data—avoiding over-retention across other categories in the retention schedule.
Some organizations go with permanent retention, while others intentionally choose shorter periods to avoid permanence—especially in Europe.
Retention ranges vary widely, from 40 years on the low end to 85–90 years for those accounting for all conceivable contingencies.
It’s a risk-based decision.
Let’s touch on two specific areas: leaves of absence and collective bargaining.
For leaves of absence, records often contain sensitive health information—physician certificates, medical documentation, and related requests.
These are typically separated from payroll records so their retention period can be tailored and minimized.
Common global retention ranges:
- Creation plus 2 to 7 years, with exceptions
- Australia: Duration of employment plus 7 years
- Ireland: Creation plus 12 years
These variations reflect efforts to reduce retention periods while respecting privacy concerns.
For collective bargaining, global retention periods typically range from expiration plus 7 to 15 years.
Retention requirements are scarce, so these periods are often driven by dispute resolution needs and operational considerations, which vary by jurisdiction.
Stakeholders and subject matter experts from different regions will often request very different retention periods based on local context.
Another hot-button item: data subject requests.
Let’s discuss how to retain the right records while avoiding unnecessary copies of personal data.
Typical global retention range:
Final resolution plus 2 to 5 years, aligned with emerging express retention requirements—including in the U.S.
What should be retained:
- The original request
- Final resolution summary
- Log information detailing how the request was handled
- Access records for specific data types
Copies of personal data should be treated as transitory.
This avoids retaining unnecessary personal data and allows for streamlined deletion under a separate policy.
On the topic of downstream dependencies, this is where systems become invaluable.
You can trace a data object or piece of personal data across the organization to ensure complete deletion—assuming no unauthorized copies are saved elsewhere.
This is a key component of compliance and tracking.
Final question—let’s answer it quickly:
Best practices for purge logs and certificates of destruction:
- Systems should auto-generate logs showing what was deleted, when, by whom, under what process, and under which retention rule
- These processes should be integrated with legal hold protocols to suspend disposition when necessary
- Purge logs should be stored similarly to certificates of destruction
- Logs should be audited periodically to ensure the process is functioning properly
- Purge rules should be reviewed and certified for alignment with the retention schedule—typically by legal and records management teams
If there’s one key takeaway from today’s session, it’s this:
Review. Align. Train. Monitor.
Why?
Because privacy isn’t a project—it’s a practice.
It’s not something to focus on for a month or a year.
It should become part of your organization’s culture.
Big bucket retention schedules are still best practice—but add granularity where it makes sense.
Be mindful of express retention requirements and record lifecycles.
Train teams to understand the balance between retention and deletion.
Stay up to date with global legal developments—jurisdictions often follow each other’s lead.
Jenn:
I love how you put that, Brandon.
Privacy isn’t a project—it’s a process.
Privacy by design.
Brandon:
Exactly.
It’s something we always need to stay on top of.
Thanks again, everyone.
We appreciate you taking the time to join us today.