Post: Data Governance Glossary: HR Tech Compliance Terms

By Published On: November 15, 2025

Data Governance Glossary: HR Tech Compliance Terms

HR data governance is not a legal formality your compliance team handles separately from recruiting operations. It is the structural layer that determines whether your automated candidate workflows are defensible or a liability. Every ATS integration, every automated offer letter, every AI-assisted screening step touches personal data governed by GDPR, CCPA/CPRA, EEOC, and a growing lattice of state and international privacy laws. The teams that get this right do not treat governance as a checklist — they embed it into workflow design from day one.

This FAQ answers the compliance questions HR and recruiting professionals ask most often, in plain language, with direct implications for how you build and operate automated talent acquisition systems. For the broader framework of how structure enables automation in recruiting, start with the Master HR Automation with Adobe Workfront for Recruiting pillar. Then use this glossary to make sure your governance foundation matches your automation ambitions.

Jump to a question:


What is data governance in the context of HR technology?

Data governance in HR technology is the formal system of policies, roles, and procedures that controls how candidate and employee data is collected, stored, accessed, processed, and retired. It answers three foundational questions: who owns the data, who may access it, and what rules govern every step of its lifecycle.

Without data governance, even well-designed automation workflows introduce compliance risk — because automated systems execute exactly what they are configured to do, including any policy gaps. Gartner defines data governance as the specification of decision rights and an accountability framework for managing data assets — a definition that translates directly into HR tech as: document who is accountable for each data type, define the rules, then configure systems to enforce them.

Effective governance maps to your recruiting process directly. Requisition intake, candidate screening, interview scheduling, offer management, and onboarding each carry distinct data-handling obligations that must be documented and enforced in every platform you use. Adobe Workfront’s workflow engine supports governance by enforcing approval gates and access permissions at each stage — but the governance policies must exist before the workflow is configured.

Jeff’s Take: Governance Is Not a Compliance Tax — It’s Automation Infrastructure

Every time a team asks me why their HR automation keeps breaking down or generating exceptions, the root cause is almost always the same: they skipped governance. They built workflows before they defined data ownership, access rules, or retention triggers. Governance feels like overhead until the moment a regulator or a plaintiff’s attorney asks you to produce evidence of compliant data handling — and you can’t. Build the governance layer first. It does not slow down automation; it is the structure that makes automation trustworthy and scalable.


What is PII and why does it matter more in recruiting than in most business functions?

PII — Personally Identifiable Information — is any data point, or combination of data points, that can be used to identify a specific individual. In recruiting, PII is unavoidable: candidate names, email addresses, phone numbers, employment history, educational credentials, and salary expectations are all PII.

What makes recruiting uniquely high-risk is the volume of PII processed for people who never become employees. A company screening 500 applicants for one role creates 499 records for individuals who have no ongoing relationship with the organization — yet those records carry full regulatory obligations under GDPR, CCPA/CPRA, and applicable state laws. SHRM has long emphasized that applicant recordkeeping requirements are as demanding as employee file obligations, yet far fewer HR teams have formal processes for them.

Indirect PII compounds the risk: resume metadata, IP addresses from application portals, and even inferred demographic signals derived from name or address can qualify as protected personal data under GDPR and CCPA. HR teams must define retention schedules and deletion triggers for rejected-applicant data specifically, not just for active employee files.


What does GDPR require of HR and recruiting teams specifically?

GDPR — the General Data Protection Regulation — requires organizations processing personal data of EU/EEA individuals to establish a lawful basis for every processing activity, minimize data to only what is necessary, maintain accuracy, limit retention to the minimum necessary period, and protect data with appropriate technical and organizational measures.

For recruiting, the practical implications are significant:

  • Identify your lawful basis for processing candidate data (typically legitimate interest or consent) before the application goes live.
  • Inform candidates how their data will be used via a privacy notice at the point of application.
  • Honor subject access requests within 30 days.
  • Execute erasure requests for candidates who invoke the right to be forgotten — and propagate those deletions across every connected system simultaneously.
  • Notify the supervisory authority within 72 hours of becoming aware of a breach likely to result in risk to individuals’ rights and freedoms.

Automated candidate pipelines must be designed so that deletion triggers propagate across all connected systems — ATS, HRIS, scheduling tools, and any integrated automation platform — at the same time. Gaps between systems are the primary source of GDPR violations in HR tech deployments. For workflows that enforce these checkpoints automatically, see Adobe Workfront: Automate Ironclad HR Compliance.


How does CCPA/CPRA differ from GDPR for HR teams?

The California Consumer Privacy Act (CCPA), strengthened by the California Privacy Rights Act (CPRA), applies to businesses meeting specific revenue or data-volume thresholds that process personal information of California residents. Unlike GDPR, CCPA/CPRA does not require a lawful basis for processing — but it grants consumers the rights to know what data is collected, to delete it, to opt out of its sale or sharing, and to correct inaccurate data.

The critical distinction for HR teams is scope: CPRA’s 2023 enforcement removed the employee data exemption that existed under the original CCPA, meaning California employee and applicant records now carry full consumer privacy rights. HR teams operating in California must:

  • Build opt-out mechanisms and data-deletion workflows covering both active and rejected candidates.
  • Document all data-sharing relationships with third-party recruiting vendors.
  • Provide California employees and applicants with a Privacy Notice at Collection at or before the point of data collection.
  • Honor deletion requests within 45 days (extendable by 45 days with notice).

Organizations operating across both the EU and California must maintain parallel compliance frameworks — the requirements overlap but do not map perfectly onto each other.


What is a data retention schedule and how should HR teams enforce it?

A data retention schedule is a documented policy specifying how long each category of HR data must be kept and when it must be deleted or anonymized. Retention periods vary by data type and jurisdiction:

  • EEOC (U.S.): Applicant records must be retained for one year from the date of the personnel action.
  • I-9 records: Three years after hire or one year after termination, whichever is later.
  • GDPR: Retention must be limited to the minimum period necessary for the stated purpose — there is no universal fixed period; it is purpose-dependent.
  • CCPA/CPRA: Data must not be retained longer than reasonably necessary for the disclosed purpose.

The enforcement gap most HR teams face is manual deletion — someone must remember to act. That process fails at scale. The only scalable solution is programmatic enforcement: configure your workflow platform to trigger deletion or anonymization tasks automatically at the scheduled date. Automated onboarding and compliance workflows built in Adobe Workfront can incorporate retention-trigger tasks as standard workflow steps, removing human memory from the compliance loop. For practical workflow structuring, see Automate Employee Onboarding with Adobe Workfront.


What is an audit trail and why is it the most important compliance record in automated HR workflows?

An audit trail is a chronological, tamper-evident log of every action taken on a record — who accessed it, who modified it, what changed, and when. In automated HR workflows, audit trails serve as the primary evidence layer for regulatory investigations, employment litigation, and internal compliance reviews.

When a candidate claims their data was misused, or a regulator requests proof that consent was obtained, the audit trail is what you produce. The risk with automation is a false sense of security: automated systems move fast and at scale, which means a misconfigured workflow can create thousands of non-compliant records before anyone notices. A robust audit trail makes that pattern detectable and correctable early.

In Practice: The Deletion Propagation Problem

The most common GDPR gap we see in HR tech stacks is deletion that only works in the ATS. A candidate submits an erasure request, the recruiter deletes the record from the ATS — and the data persists in the HRIS, the scheduling tool, the interview feedback system, and the automation platform’s own logs. Each of those systems carries its own deletion obligation. The only way to solve this at scale is to make deletion a workflow trigger, not a manual task. When erasure is requested, a workflow should fire simultaneously across every connected system — not rely on a recruiter to remember five separate login screens.

Platforms like Adobe Workfront maintain system-level logs of workflow actions and approvals. HR teams must verify that those logs capture the specific data fields and user actions required by their applicable regulations — not just generic system events. Audit trail completeness is a configuration decision, not a platform default.


What is role-based access control (RBAC) and why does it matter for candidate data?

Role-based access control (RBAC) is a security model that grants data access permissions based on a user’s role in the organization rather than granting access individually. In recruiting, RBAC means:

  • A hiring manager can view candidate profiles for their open requisitions but cannot see compensation benchmarking data visible to compensation analysts.
  • A recruiter can update candidate status but cannot modify offer approval records accessible only to HR leadership.
  • A background check vendor integration can read specific fields needed for screening but cannot write to or read the full candidate record.

RBAC matters because insider data misuse — whether malicious or accidental — is the most common source of PII breaches in HR systems. Configuring RBAC correctly in your ATS, HRIS, and workflow orchestration platform is a governance requirement, not an IT preference. Every new integration between systems must preserve RBAC boundaries; data flowing through an automation layer must not inadvertently expose fields to roles that lack permission to view them in the source system. McKinsey research on data-driven enterprise operations consistently identifies access control gaps as a leading source of data quality and security failures in complex integrated environments.


What is data minimization and how does it apply to automated recruiting workflows?

Data minimization is the principle that organizations should collect and process only the personal data strictly necessary for the specified, legitimate purpose. GDPR codifies this as a core principle; CCPA/CPRA enforces it through proportionality expectations.

In recruiting, data minimization is frequently violated not by intent but by default form design. Application forms that collect date of birth, marital status, or national origin “just in case” create regulatory liability for data that serves no lawful purpose in hiring decisions. Automated workflows amplify the problem: if an intake form passes unnecessary fields through an automation pipeline to multiple downstream systems, the violation multiplies with each integration.

The fix is upstream:

  1. Audit every data field collected at the application stage.
  2. Document the lawful purpose for each field.
  3. Remove fields that cannot be justified under that purpose.
  4. Configure your automation to route only the justified fields to each connected system — not the full record.

The Streamline Your Recruitment Funnel with Workfront Automation satellite addresses how field-level control in workflow design prevents unnecessary data propagation across recruiting systems.


What is a data breach and what are the notification obligations for HR teams?

A data breach is any unauthorized access, disclosure, alteration, or destruction of personal data. In HR and recruiting, breaches most commonly occur through phishing attacks on recruiter accounts, misconfigured integrations that expose candidate data to unauthorized parties, or improper disposal of physical or digital records.

Notification obligations depend on jurisdiction and breach severity:

  • GDPR: Notify the supervisory authority within 72 hours of becoming aware of a breach likely to result in risk to individuals’ rights and freedoms. Notify affected individuals without undue delay when the risk is high.
  • U.S. state laws: Vary significantly in timing (ranging from 30 to 90 days in most states) and in the definition of what constitutes a notifiable breach. There is no single federal standard.

HR teams must maintain an incident response plan that specifically addresses candidate and employee data, including procedures for identifying which automated workflows may have propagated the breach across connected systems. Forrester research on data breach response consistently identifies the lack of a tested incident response plan as the primary driver of delayed and non-compliant notifications.


How do data governance requirements intersect with AI-assisted candidate screening?

AI-assisted candidate screening introduces governance obligations beyond standard PII rules. When an algorithm influences a hiring decision, several additional frameworks apply:

  • The EU AI Act classifies recruitment AI as high-risk, requiring transparency, human oversight, bias audit documentation, and registration in the EU database of high-risk AI systems.
  • EEOC guidance in the U.S. holds employers liable for discriminatory outcomes produced by third-party screening tools — “vendor did it” is not a defense.
  • New York City Local Law 144 requires annual independent bias audits of automated employment decision tools used with NYC candidates or employees.

From a data governance standpoint, AI screening creates new categories of derived data — scores, rankings, and inferred attributes — that are themselves PII and must be retained, disclosed, and deleted under the same rules as the source data.

What We’ve Seen: AI Screening Creates Data You Didn’t Know You Had

Teams adopting AI-assisted resume screening are often surprised to learn that the scores and rankings the AI generates are themselves PII under GDPR and subject to subject access requests. A candidate can ask not just for the data they submitted, but for the derived outputs your system created about them — including why they were ranked below the cutoff. If your AI vendor cannot produce that explanation in a human-readable format, you have both a compliance gap and an EU AI Act exposure. Governance documentation for AI-derived data fields is now a non-negotiable part of any compliant recruiting tech stack.

The governance principle that applies is structure before AI: establish compliant, deterministic workflow rules first, then deploy AI only at the specific judgment points where rules-based logic is insufficient. This sequence — not the reverse — produces defensible, auditable hiring processes. The parent pillar on HR automation with Adobe Workfront for recruiting addresses this sequencing in full.


What is data portability and when must HR teams honor it?

Data portability is the right of an individual to receive their personal data in a structured, commonly used, machine-readable format and to transmit it to another organization. GDPR grants this right to individuals whose data is processed by automated means on the basis of consent or contract.

In recruiting, this means a candidate can request a copy of all data your organization holds about them — application form responses, assessment scores, interview notes, and any data derived from their application — in a portable format. HR teams must be able to compile and export this data across all connected systems: ATS, HRIS, scheduling tools, and any automation platform that processed the candidate’s data.

Manual compilation from multiple disconnected systems is operationally untenable at scale. Integrated workflow platforms with centralized data records and standardized export functions are the only scalable path to honoring portability requests within the legally required timeframe. This is one of the strongest operational arguments for centralizing HR operations in a single orchestration platform rather than managing a fragmented point-solution stack.


What is the difference between a data processor and a data controller in HR tech?

Under GDPR, the data controller is the entity that determines the purposes and means of processing personal data — typically the employer or recruiting organization. The data processor is any third party that processes data on behalf of the controller under the controller’s instructions.

In HR tech, processors include your ATS vendor, HRIS provider, background check service, video interview platform, and any automation platform connecting those systems. The distinction matters because:

  • Controllers bear primary legal liability for compliance.
  • Processors must operate under a documented Data Processing Agreement (DPA) that constrains how they handle the data.
  • Controllers are responsible for ensuring their processors are GDPR-compliant — due diligence on vendor compliance is a controller obligation.
  • Processors’ subprocessor relationships must be disclosed and approved.

HR teams must maintain an inventory of every processor in their tech stack, ensure a valid DPA exists with each vendor, and verify that processors’ subprocessor relationships (the vendors their vendors use) are disclosed and compliant. When an automation platform connects your ATS to your HRIS, that platform is a processor — and its data handling practices, server locations, and subprocessors become part of your compliance obligations. Deloitte’s research on data-driven HR consistently identifies processor inventory gaps as a leading source of undetected compliance exposure in complex HR tech stacks.


Build Compliance Into Every Recruiting Workflow

These governance terms are not abstract legal concepts — each one maps directly to a configuration decision in your HR tech stack. The teams that treat data governance as workflow infrastructure rather than a legal afterthought build automation that scales without creating regulatory exposure. The foundational framework for sequencing structure before automation in recruiting is in the Master HR Automation with Adobe Workfront for Recruiting pillar.

For the operational side of applying these principles across your HR function, see 12 Ways AI & Automation Transform HR and Recruiting and Break HR Silos: Centralize Workflows with Adobe Workfront.