Originally published: 29 April 2026 | This analysis is based on Nimble Global's proprietary research and 30+ years of practical experience across over 90 countries. | © 2019 - 2026 Nimble Global. All rights reserved.

Most organisations believe their hiring documentation is defensible because it is consistent. For years, consistency has been positioned as the standard.

I recently spent three weeks unpacking hiring documentation practices across a portfolio of enterprise clients operating simultaneously in the EU, Brazil, California, and Singapore. What I found was not chaos, exactly, but something closer to organised confusion. Each organisation had independently reasoned through its hiring process, only to discover that what worked in one jurisdiction created exposure in another.

One client, a financial services organisation, had built their hiring documentation around GDPR principles. Minimal data collection. Clear purpose limitation. Retention limited to two years post-decision. It was defensible, efficient, and aligned with how they thought about data governance globally.

Then they hired someone in Brazil to lead regional expansion, and within six months, a candidate filed a data access request under LGPD. The organisation compiled its response based on its standard two-year retention policy. They deleted interview notes older than that, assuming the LGPD request could be satisfied from what remained.

The regulator's position was different. Under LGPD, retention must be proportionate to the purpose. Since the purpose was hiring, a bounded activity that completed when the decision was made, continued retention must be justified under an alternative legal basis, such as legal defence or regulatory obligation, and is subject to closer scrutiny. The candidate had been hired fourteen months earlier. Why were their interview notes still retained?

The organisation hadn’t done anything obviously wrong. They had followed a rational logic. They just hadn’t recognised that…

This is the real challenge with global hiring operations. It is not that compliance frameworks are unknowable. It is because they were designed independently, often by different regulatory traditions, and they make genuinely conflicting demands on how you collect, store, and handle candidate data. Understanding those conflicts is not an academic exercise. It determines whether your hiring process can survive scrutiny.

This analysis focuses on GDPR, CCPA, LGPD, and PDPA as they govern the majority of multinational hiring. However, similar tensions emerge in other significant hiring jurisdictions. The UK closely mirrors GDPR with minor post-Brexit divergences. Australia, Canada, India, and New Zealand introduce additional consent and decision-making scrutiny that creates distinct conflict profiles. Understanding these four primary frameworks provides the conceptual foundation for managing complexity across any jurisdiction. 

What Each Framework Actually Wants

Before we can talk about resolving conflicts, we must understand what each framework is fundamentally trying to achieve, because that shapes everything downstream.

GDPR emerged from a European tradition emphasising individual rights and the principle that organisations should not collect data they do not strictly need. It assumes that legitimate interest, the organisation’s need to make a hiring decision, is a valid reason to process data without explicit consent, but it demands that the data collected be truly necessary and no more. It treats candidates as data subjects whose privacy must be protected, even when they are competing for a job. The regulation is precise, detailed, and assumes that organisations will be audited on their compliance practices.

CCPA comes from California, emerging in response to concerns about data brokers and algorithmic decision-making rather than from a comprehensive data protection philosophy. Its core idea is fundamentally different from GDPR. It does not prohibit data collection. Instead, it gives consumers the right to know what data was collected, how it is used, and whether it was 'sold', a term deliberately broad in California’s statutory definition. It is less prescriptive about what organisations can collect and more focused on transparency about what happens after collection.

LGPD, Brazil’s data protection law, mirrors GDPR structurally but applies it through a different cultural and regulatory lens. Critically, LGPD defines 'sensitive data' more broadly than GDPR does. It includes data that could 'facilitate discrimination', as explicitly stated in Article 5 of the LGPD and increasingly interpreted by regulators to extend beyond explicitly named categories to questions that correlate with protected characteristics.

A question about caregiving responsibilities might trigger sensitive data protections under LGPD because it correlates with gender, but not under GDPR, where protected characteristics are more narrowly defined. LGPD also applies stricter scrutiny to retention once the original purpose has been fulfilled, particularly in hiring contexts where the activity is clearly bounded. 

PDPA, Singapore's Personal Data Protection Act, reflects an approach that emphasises consent and proportionality, but with less detailed, prescriptive guidance than GDPR. It prefers organisations obtain consent where practical, while also recognising legitimate interests in defined circumstances. It is less procedural and more reliant on organisations exercising reasonable judgment about what is proportionate and appropriate.

Beyond these four, other jurisdictions introduce additional layers. Canada's PIPEDA places greater emphasis on consent, particularly in employment contexts, creating tension with GDPR's interest-based approach. India's recently enacted Digital Personal Data Protection Act similarly mandates consent for most hiring processing, conflicting with both GDPR's flexibility and CCPA's approach. Australia's Privacy Act introduces prescriptive requirements around automated decision-making and algorithmic accountability that exceed GDPR's explainability demands. New Zealand's Privacy Act follows a similar trajectory.

So far, this sounds manageable. Four different frameworks, four different emphases. But when you add jurisdictions that require consent where you planned to rely on legitimate interest, or that impose stricter algorithmic scrutiny than you anticipated, the problem becomes acute. The problem emerges when you try to satisfy all frameworks simultaneously in a single global hiring process because… 

Where the Conflicts Actually Bite

Let me walk through three real conflicts that organisations face, not as abstract regulatory theory, but as operational problems that create exposure.

The minimisation problem

GDPR demands data minimisation. Collect only what is necessary for the hiring decision. This is unambiguous. While subjective assessment is not explicitly prohibited, it must be clearly documented, tied to defined job requirements, and applied consistently across all candidates to remain defensible under GDPR scrutiny. It means you should avoid collecting subjective commentary about ‘culture fit’ or ‘team dynamic’ where it cannot be tied to defined job requirements, because these are preferences, not qualifications.

But CCPA's right to know creates a different pressure. Under CCPA, candidates have the right to understand what data was collected and how it was used. In practice, this extends beyond regulatory disclosure into litigation risk and candidate challenge, where organisations may be required to explain how decisions were made. This creates tension.

Where subjective judgment influences hiring decisions, organisations must ensure that any supporting documentation is role-relevant, consistent, and defensible, rather than informal or unstructured. While GDPR does not prohibit subjective assessments, it requires that they be documented consistently and demonstrably tied to defined job requirements and applied uniformly across candidates.

They document more detail than GDPR strictly requires, assuming that transparency demands will come later. This creates a different exposure. If you are collecting subjective panel impressions without clear documentation that ties them to job requirements and demonstrates consistent application, you will struggle to demonstrate necessity under GDPR. 

The retention contradiction

GDPR, LGPD, and CCPA all recognise retention limits, but they define necessity differently.

GDPR uses the principle 'no longer necessary' for the purpose. In hiring, organisations commonly interpret this as one to two years post-decision to support employment law defence and auditability. This is not a prescribed rule, but it has become a widely adopted operational standard.

LGPD applies the same principle but often interprets it more strictly in hiring contexts. Once the hiring decision is complete, continued retention must be justified under an alternative legal basis, such as legal defence or regulatory obligation, and regulators are more likely to question whether that justification genuinely applies.

CCPA’s 'reasonably necessary' standard provides flexibility but little precision. Organisations interpret it differently based on risk appetite. The result is practical conflict.

Retain for two years, and you may face LGPD scrutiny. Delete earlier, and you may weaken your ability to defend hiring decisions in GDPR jurisdictions.

There is no single answer that satisfies all frameworks perfectly. In practice, this means retention cannot be treated as a fixed policy decision. It must be a documented outcome of legal basis, risk tolerance, and operational capability. 

The sensitive data expansion problem

GDPR defines sensitive data narrowly and precisely. LGPD defines it more broadly and with less precision. In practice, this means the same question can be treated as ordinary data in the EU and sensitive data in Brazil

This creates a decision point. Do you:

• apply stricter handling globally, or

• accept jurisdiction-specific treatment and the complexity that comes with it

Most defensible practice is to treat any data that could reasonably trigger LGPD sensitivity as sensitive globally. This is over-compliance in some jurisdictions, but it reduces exposure where definitions are broader.

The consent requirement polarity

A subtler but equally problematic conflict emerges in consent-first jurisdictions. GDPR permits hiring decisions based on legitimate interest without explicit consent. CCPA is indifferent to consent (it focuses on disclosure). But Canada's PIPEDA and India's Digital Personal Data Protection Act require consent for most processing, including hiring, even where legitimate interest might otherwise suffice.

On one pole: minimisation. GDPR demands you limit what you collect. Collect only what is necessary. Reduce friction. The pressure is toward restraint, efficiency, and data parsimony. This is the European model of data governance: less data is safer data. 

On the opposing pole: transparency through consent. PIPEDA, India's DPDP Act, and, to a degree, the CCPA shift the burden. They do not necessarily restrict what you collect. Instead, they require you to make explicit, documented agreements with candidates about why you are collecting it and what you will do with it. The pressure is toward disclosure, acknowledgment, and explicit agreement. This is the North American and emerging-market model: consent-based legitimacy. These poles are not complementary. They create genuine operational tension.

Where you require explicit consent (PIPEDA-style), you must articulate and defend every data point. An organisation cannot simultaneously satisfy both with a single hiring process without accepting the complexity that most do not anticipate.

The practical result is that organisations operating in Canada, or increasingly, India, face a daily operational choice: build consent infrastructure into their global hiring process, even where local regulation (GDPR, PDPA) would allow legitimate interest, or maintain separate hiring workflows for different jurisdictions. Most choose the former, accepting the consent overhead globally because the alternative (separate processes) is operationally untenable. This reshapes the entire hiring conversation from 'here's what we need' to 'here's what we're asking permission for.'

Australia's Privacy Commissioner compounds this by introducing a third dimension: automated decision-making scrutiny. Australia's guidance requires demonstrable human review of any algorithmic decision-making in hiring contexts, a requirement that exceeds GDPR's Article 22 explainability demands. If you operate in Australia, your algorithmic governance must be more rigorous than if you operated only in GDPR jurisdictions. This is not minimisation. It is not consent. It is accountability.

They are everyday requirements in jurisdictions where major enterprises, including those with significant Canadian or Indian operations, must navigate them daily. For organisations like those operating across North America and Asia simultaneously, polarity management becomes a core governance capability.

The Real Cost of These Conflicts

Most organisations recognise these conflicts exist. What they underestimate is the operational cost of managing them.

Take Subject Access Request timelines:

• GDPR: 30 days

• LGPD: 15 days

• CCPA: 45 days

• PDPA: reasonable timeframe

If you operate globally and build for 30 days, you are underperforming in Brazil. If you build for 15 days, you are compliant everywhere, but you have fundamentally changed your operational model.

A single SAR requires:

• identifying all data sources

• retrieving data across systems and vendors

• reviewing for relevance and third-party data

• assembling and validating a response

In a 15-day window, across multiple jurisdictions and vendors, this becomes an operational capability, not a legal exercise.

Now layer in third parties. This is where exposure multiplies.

Most hiring processes rely on a combination of platforms and third parties, including ATS, VMS, and FMS systems, alongside assessment vendors, background screening providers, and EOR or AOR structures in cross-border hiring. 

When an EOR or AOR sits between the hiring organisation and the worker, questions become immediate and practical:

• Who is acting as controller or processor at each stage? 

• Who is responsible for responding to SARs?

• Who determines retention timelines?

In many cases, the contractual answer and the operational reality do not align. Organisations discover this only when a request is filed or a regulator asks the question. That is where compliance stops being theoretical.

The Role Misalignment Problem

The complexity does not come from regulation alone. It comes from…

Most organisations assume that data protection roles are clearly defined. The ATS is typically positioned as a processor. The MSP is treated as an intermediary. The client is assumed to be the controller. The EOR sits somewhere downstream. On paper, it looks structured and defensible. 

Then the process begins.

The complexity begins with how candidates enter the process, not the system.

In many organisations, sourcing no longer follows a single path. Enterprise clients increasingly operate a tiered model. Direct sourcing platforms are often positioned as the initial point of entry, effectively sitting ahead of what the external supply chain would traditionally consider Tier 1.

If those channels do not yield results, the process expands into the third-party supply chain, where staffing agencies, recruitment firms, and consulting providers operate across multiple tiers, delivering both contingent workers and statement-of-work (SOW) services.

This shift is not always visible. In some cases, suppliers continue to operate within a tiered model without full visibility into upstream sourcing channels that are already shaping candidate flow, cost structures, and ultimately, hiring outcomes.

These different entry points introduce variation before the process has even formally begun. Candidate data is captured, structured, and assessed in different ways depending on where it originates. In practice, this means behaviour is shaped upstream, before the hiring decision is ever made. 

That data then flows into systems. A candidate may enter through an ATS that structures and stores their data in a particular way, shaping what can be captured, how it is categorised, and how it is later retrieved. The platform may not be making hiring decisions, but it is influencing how those decisions are recorded.

In many environments, that data then moves into a VMS, where the hiring process is managed. The VMS governs how roles are created, how candidates are submitted, how decisions are tracked, and how records are maintained. It may not make decisions directly, but it defines the framework within which decisions are made and documented.

An MSP sits over this process, coordinating activity across both sourcing channels and systems. They are not the employer, but they often define workflows, control submissions, and shape how hiring managers interact with candidate data. In doing so, they influence not just process, but hiring outcomes.

Assessment vendors and screening providers add another layer. They collect additional data, apply their own methodologies, and return outputs that directly affect hiring decisions. Each step introduces another party shaping how data is handled and interpreted.

Now introduce cross-border hiring.

An EOR or AOR may be the legal employer in one jurisdiction, while the hiring decision sits elsewhere. Data flows across entities, systems, and countries, each with its own obligations and assumptions about responsibility.

At no point in this process does the breakdown feel obvious. Each participant is operating within a defined role. Each system is doing what it was designed to do.

But when a Subject Access Request is filed, or a regulator asks how a hiring decision was made, the question is no longer theoretical.

• Who controlled the data at each stage?

• Who made the decision?

• Who is accountable for the outcome?

The contractual position suggests one answer. The operational reality often suggests another. This is where the problem surfaces, and...

Most organisations fail because they cannot demonstrate how responsibility is actually assigned and exercised across a hiring process that was never designed to be mapped that way, not because they misunderstand regulation.

Building a Framework That Survives Scrutiny 

Given these conflicts...

Start with a principle: optimise for the most demanding standard across the jurisdictions in which you operate, and document why.

• If Brazil requires a 15-day response, build for 15 days.

• If LGPD introduces broader sensitivity, treat data accordingly.

• If retention is more heavily scrutinised, design with that in mind.

This is not about being overly restrictive. It is about removing ambiguity in how decisions are made.

Next, translate principle into practice.

1. Data collection should be limited to what is tied to defined job requirements, with a clear rationale for why each data point exists.

2. Consent should be built explicitly into the hiring process, even where it is not strictly required. This simplifies global scalability.

3. Interview documentation should assume disclosure. Notes must be objective, role-relevant, and defensible.

4. Retention should move away from a single timeline and instead follow structured logic:

   • retain where legally justified

   • delete where purpose is complete

   • anonymise where insight is still valuable

5. Vendor relationships require clarity. If a provider cannot explain how they handle multi-jurisdictional obligations, you have already identified a risk.

   
   

The Unresolved Tensions

Some conflicts do not fully resolve.

Automated decision-making remains one of them. Requirements for explainability and human oversight vary, but the safest position is clear:

Future opportunity retention is another. GDPR allows it under legitimate interest. LGPD generally requires fresh consent.

Third-party data use sits in a grey area across all frameworks.

These are everyday decisions that shape how hiring processes operate. They are not edge cases. 

What To Audit and Prepare For Now

If you are hiring across jurisdictions, the questions are straightforward.

• Do your retention practices reflect legal reality, or internal habit (behaviour)?

• Can you respond to a SAR in 15 days, not 30?

• Would your interview notes withstand disclosure?

• Have you obtained consent where future jurisdictions will require it?

• Do your vendors understand the environments you operate in?

Most organisations can answer some of these. Very few can answer all of them consistently.

The Principle Underneath

What this ultimately comes down to is governance, not compliance.

• Compliance tells you what rules exist.

• Governance determines how decisions are made when those rules conflict.

Organisations that attempt to manage this through policy alone create exposure. The policy may be correct. The execution (behaviour) will drift.

Organisations that build governance into their hiring processes, that define how decisions are made, document why they are made, and ensure they are applied consistently, create something different. They create defensibility.

If your organisation cannot map who made decisions, how they were made, and where responsibility sits across the hiring process, you do not have governance. You have documentation.

Documentation does not stand up under scrutiny. Governance does. 

Stay Nimble. Stay Compliant.

About the Author: With extensive experience in workforce compliance and global workforce solutions, David Ballew has consistently driven innovation and operational excellence. As the Founder and CEO of Nimble Global, David combines deep industry expertise with a unique perspective shaped by his neurodiverse AuDHD profile, enabling creative problem-solving and multidimensional insight. A pioneer in MSP models and workforce technologies, he is dedicated to bridging global compliance gaps and helping organisations build resilient, future-ready workforces.

Real People. Real Action. Real Innovation.

Disclaimer: This content is intended for informational purposes only and does not constitute legal, tax, or employment advice. Readers should consult qualified professionals in relevant jurisdictions before acting on the guidance provided. Nimble Global disclaims any liability for actions taken based on this publication.