HR Tech Compliance Glossary: Data Security Acronyms Explained
HR and recruiting professionals now process more sensitive personal data than almost any other function in the enterprise — candidate resumes, employee health records, payroll figures, performance data, and more flow through ATS platforms, HRIS integrations, AI parsing engines, and automation workflows every day. The regulatory frameworks governing that data come with a dense alphabet of acronyms. This glossary defines each one plainly and maps it directly to the HR and recruiting automation contexts where it matters most.
This reference is a companion to the broader AI in HR automation strategy covered in the parent pillar — because every automation workflow your team builds is also a data governance decision.
GDPR — General Data Protection Regulation
GDPR is the European Union’s comprehensive data protection regulation, and it applies to any organization that processes the personal data of EU residents — regardless of where that organization is headquartered.
How It Works
GDPR establishes six lawful bases for processing personal data (consent, contract, legal obligation, vital interests, public task, and legitimate interests). For most HR and recruiting use cases, the operative bases are either contract (processing necessary to fulfill an employment agreement) or legitimate interests (balanced against data subject rights). Consent is rarely the right basis for employee data, but it is commonly the correct basis for retaining rejected applicant data beyond the immediate hiring cycle.
Why It Matters in HR Automation
- AI resume parsing: Automated decision-making that produces legal or similarly significant effects on individuals requires explicit disclosure and, in many cases, a Data Protection Impact Assessment (DPIA).
- Data retention: GDPR’s storage limitation principle prohibits keeping personal data longer than necessary for the stated purpose. Automation workflows must include retention timers and deletion triggers.
- Right to erasure: Candidates can request deletion of their data. Every node in your workflow — parsed database, ATS record, email thread, spreadsheet export — must be reachable by that deletion process.
- Data transfers: Routing EU applicant data through US-based cloud platforms requires Standard Contractual Clauses (SCCs) or an equivalent transfer mechanism.
For a deeper compliance framework, see our guide to GDPR compliance for AI resume parsing in European HR.
CCPA — California Consumer Privacy Act
CCPA is California’s landmark state-level data privacy law, granting California residents specific rights over their personal information — including the right to know, the right to delete, and the right to opt out of the sale of their data.
How It Works
CCPA applies to for-profit businesses meeting certain thresholds (annual gross revenue above $25 million, data on 100,000+ consumers or households annually, or deriving 50%+ of revenue from selling personal data). Subsequent amendments and regulations under CPRA (California Privacy Rights Act) have extended CCPA-style protections to employee and applicant data, closing the prior HR exemption.
Why It Matters in HR Automation
- Applicant data: California-resident candidates have the right to know what data you collected, how it is used, and to request its deletion.
- Vendor contracts: Third-party HR platforms processing California resident data must be covered by a service provider agreement that restricts data use to the defined HR purpose.
- Data mapping: Automated data inventory tools that track where applicant data resides across your tech stack are the practical foundation of CCPA compliance — you cannot honor deletion requests for data you cannot locate.
Note: CCPA thresholds and employee data applicability have evolved through regulatory updates. Confirm current requirements with legal counsel.
HIPAA — Health Insurance Portability and Accountability Act
HIPAA is US federal legislation establishing national standards for protecting sensitive health information. Its relevance to HR extends well beyond healthcare employers.
How It Works
HIPAA’s Privacy Rule and Security Rule govern Protected Health Information (PHI) — any individually identifiable health information held or transmitted by a covered entity or its business associates. HR departments become HIPAA-relevant whenever they handle PHI, which occurs in benefits administration, FMLA processing, workplace accommodation requests, disability leave, and self-insured employer health plan administration.
Why It Matters in HR Automation
- Benefits portals and leave management tools: Any platform that receives or stores employee health data must have appropriate technical safeguards and a Business Associate Agreement (BAA) with your organization.
- System integrations: When an HRIS integration passes leave-related fields to a benefits platform, that data transfer is a HIPAA-regulated event if it contains PHI.
- Separation of data: Best practice is to architect HR automation workflows so that health-related data flows through isolated, HIPAA-compliant paths rather than general-purpose automation pipelines that touch non-PHI HR data.
PII — Personally Identifiable Information
PII is any data that can be used — alone or in combination with other data — to identify a specific individual.
How It Works
Direct PII includes name, Social Security number, date of birth, email address, phone number, and government-issued ID numbers. Indirect PII includes data points that, when combined, create a unique identifier — such as job title + employer + zip code, or IP address + browser fingerprint. Regulatory frameworks differ on exactly where the line falls, but the operational principle is consistent: if it could lead to an individual, treat it as PII.
Why It Matters in HR Automation
- Resume data is saturated PII: A standard resume contains name, address, employment history, education, skills, and often demographic signals — every field is a regulated data point.
- Parsing output fields: When an AI resume parser extracts structured data from unstructured resumes, each output field that resolves to an individual is PII and must be handled within the appropriate regulatory framework.
- Workflow logging: Automation platforms often log payload data for debugging. Ensure those logs do not retain PII beyond the minimum necessary period.
PHI — Protected Health Information
PHI is the subset of health information that is both individually identifiable and covered under HIPAA. It is the more specific term used within HIPAA’s Privacy and Security Rules.
How It Works
PHI includes 18 categories of identifiers defined by HIPAA — name, geographic data smaller than state, dates (other than year) relating to an individual, phone and fax numbers, email addresses, SSNs, medical record numbers, health plan beneficiary numbers, account numbers, certificate or license numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code.
Why It Matters in HR
HR teams often inadvertently create PHI when they record health conditions alongside employee identifiers in spreadsheets or HRIS notes fields. Any such record that links health information to an individual, held by or on behalf of a HIPAA-covered function, is regulated PHI.
SOC 2 — System and Organization Controls 2
SOC 2 is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) that evaluates a service organization’s controls across five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
Type I vs. Type II
A SOC 2 Type I report attests that controls were designed appropriately at a single point in time. A SOC 2 Type II report attests that those controls operated effectively over a defined audit period — typically six to twelve months. For HR tech vendor due diligence, a Type II report is the meaningful benchmark. Gartner recommends requiring Type II attestation from any vendor processing sensitive HR data as a baseline procurement requirement.
Why It Matters in HR Automation
- Vendor selection: Any ATS, resume parser, HRIS, or automation platform handling candidate or employee data should hold a current SOC 2 Type II report. See our guide to choosing a compliant AI resume parsing vendor.
- Audit readiness: Your organization’s own SOC 2 posture — if applicable — requires that third-party processors also meet equivalent standards.
- Scope of audit: Request the full report, not a summary letter. Confirm that the systems processing your HR data fall within the audit scope.
AES — Advanced Encryption Standard
AES is a symmetric encryption algorithm adopted as the US federal standard and used globally to protect data at rest and in transit.
How It Works
AES operates on fixed block sizes using key lengths of 128, 192, or 256 bits. AES-256 — using a 256-bit key — is the current industry standard for encrypting sensitive data at rest. Data in transit between systems should be encrypted using TLS (Transport Layer Security), which can use AES cipher suites as part of its protocol.
Why It Matters in HR Automation
- Data at rest: Candidate records, parsed resume data, and employee files stored on HR platform databases should be AES-256 encrypted.
- Data in transit: Every API call between your ATS, HRIS, automation platform, and third-party services should occur over TLS — verify that your automation platform enforces HTTPS for all connections.
- Key management: Encryption is only as strong as the key management practice. Ask vendors where encryption keys are stored and who can access them.
DPA — Data Processing Agreement
A DPA is a legally binding contract between a data controller (your organization) and a data processor (your vendor) that specifies how personal data will be collected, used, stored, protected, and deleted.
How It Works
Under GDPR Article 28, a DPA is mandatory for any processor handling personal data on behalf of a controller. The DPA must define the subject matter, duration, nature, and purpose of processing; the type of data and categories of data subjects; and the obligations and rights of the controller.
Why It Matters in HR Automation
Every vendor in your HR tech stack that touches personal data — resume parsing services, ATS platforms, background check providers, payroll processors, and automation platforms — requires a DPA. This is not a legal formality; it determines your liability exposure if a vendor experiences a breach and who bears responsibility for compliance failures in their systems.
DPIA — Data Protection Impact Assessment
A DPIA is a structured risk assessment process required under GDPR for processing activities that are likely to result in high risk to the rights and freedoms of individuals.
How It Works
GDPR Article 35 mandates a DPIA before commencing processing that involves: systematic and extensive profiling with significant effects, large-scale processing of special category data, or systematic monitoring of publicly accessible areas. HR applications of AI — including automated resume screening, skills inference, and culture-fit scoring — frequently trigger the DPIA requirement.
Why It Matters in HR Automation
- AI resume parsers: When a parser’s output influences which candidates advance — producing an effect on employment — a DPIA is likely required under GDPR.
- Predictive models: Workforce analytics tools that profile employees for flight risk or performance prediction involve large-scale profiling and require a DPIA.
- Documentation: A completed DPIA becomes part of your accountability record under GDPR — it demonstrates that your organization evaluated and mitigated risks before deployment.
For a full treatment of bias and governance in AI screening, see our guide to bias and governance in AI resume parsing.
MFA — Multi-Factor Authentication
MFA is an authentication method that requires users to verify their identity using two or more independent factors before accessing a system — typically something they know (password), something they have (authenticator app or hardware token), and something they are (biometric).
Why It Matters in HR Automation
HR systems are high-value targets for credential-based attacks precisely because they contain dense concentrations of PII. Forrester research identifies credential compromise as the leading initial access vector in enterprise data breaches. Requiring MFA for all HR platform logins — ATS, HRIS, automation platform, and benefits portals — is a foundational control that significantly reduces unauthorized access risk. Automation service accounts should use token-based authentication with scoped permissions rather than shared username/password credentials.
RBAC — Role-Based Access Control
RBAC is an access control model in which system permissions are assigned to roles rather than directly to individual users. Users inherit permissions by being assigned to a role.
Why It Matters in HR Automation
- Principle of least privilege: Automation workflows should operate with the minimum permissions required for their function. A workflow that reads job requisition data should not have write access to payroll fields.
- Audit trails: RBAC structures make it easier to audit who accessed what data and when — a requirement under GDPR accountability provisions and SOC 2 security criteria.
- Offboarding: RBAC makes user deprovisioning faster and more complete. When an HR team member leaves, revoking their role assignment removes access across all associated systems.
Related Terms at a Glance
| Acronym | Full Term | Primary HR Relevance |
|---|---|---|
| GDPR | General Data Protection Regulation | EU applicant and employee data processing |
| CCPA | California Consumer Privacy Act | California resident applicant and employee data |
| HIPAA | Health Insurance Portability and Accountability Act | Employee health data in benefits, leave, and accommodations |
| PII | Personally Identifiable Information | All candidate and employee data that identifies an individual |
| PHI | Protected Health Information | Health data regulated under HIPAA |
| SOC 2 | System and Organization Controls 2 | Vendor security audit standard for HR tech procurement |
| AES | Advanced Encryption Standard | Encryption of HR data at rest (AES-256) |
| DPA | Data Processing Agreement | Mandatory contract between HR org and data processors |
| DPIA | Data Protection Impact Assessment | Pre-deployment risk assessment for high-risk AI processing |
| MFA | Multi-Factor Authentication | Access security for HR platforms and automation accounts |
| RBAC | Role-Based Access Control | Permission governance across HR tech stack and workflows |
Common Misconceptions
Misconception: GDPR Only Applies to European Companies
GDPR applies to any organization that processes the personal data of EU residents, regardless of where the organization is based. A US company that sources candidates from European job boards or operates a careers page accessible to EU residents is within GDPR’s scope for that data.
Misconception: Anonymizing Data Removes All Compliance Obligations
True anonymization — where re-identification is not reasonably possible — does remove GDPR obligations. But pseudonymization (replacing direct identifiers with a code while retaining a mapping key) does not. Most “anonymized” HR datasets retain enough indirect identifiers to be re-identifiable, and regulators treat them accordingly. The International Journal of Information Management has published research demonstrating high re-identification rates in supposedly anonymized HR datasets.
Misconception: Compliance Is a One-Time Configuration
Compliance is an operational posture, not a project. Regulations change, your tech stack changes, your data flows change. SHRM recommends annual HR data audits at minimum, with triggered reviews whenever a new platform or integration is added to the stack.
Misconception: Small HR Teams Are Below the Regulatory Radar
GDPR enforcement actions have targeted organizations of all sizes. CCPA applies based on revenue and data volume thresholds, not headcount. HIPAA obligations arise from the type of data handled, not the size of the HR team handling it. The regulatory exposure scales with the data, not the org chart.
Putting the Glossary to Work
These acronyms are not abstract legal vocabulary — each one maps to a concrete decision in how your HR automation workflows are designed, what vendors you select, and how your team handles data at every step of the recruiting and employment lifecycle.
The practical starting point: treat every automation workflow that touches candidate or employee data as a compliance artifact. Map where data enters the workflow, where it is stored, who can access it, and how it is deleted. Build the retention and deletion logic into the workflow from the start. Require DPAs from every vendor before procurement, not after. Validate SOC 2 Type II status as a non-negotiable for any platform storing regulated data.
For the full framework on building an HR automation program that incorporates these compliance guardrails from the ground up, return to building a compliant HR automation spine in the parent pillar.
For specifics on how these frameworks apply to AI resume parsing in practice, see our guides to legal compliance risks of AI resume screening and the ethical AI resume parsing framework.




