Priya Nandakumar found out how expensive a missing Trust Services Criterion could be on a Tuesday afternoon, three weeks before renewal. OrbitHR — the HRIS-plus-payroll-plus-benefits platform she'd spent four years hardening — was two signatures away from a $2.4M expansion with Meridian Foods, a 38,000-employee grocery chain that wanted to move its entire people-data stack onto OrbitHR's platform. Then Meridian's procurement team sent back OrbitHR's SOC 2 Type II report with a single-line note from their new Chief Privacy Officer: "This report only covers Security. We need Privacy and Confidentiality in scope, specifically covering how you handle SSNs, I-9 data, health plan elections, and background check results for our people. Resubmit or we walk."
OrbitHR had a clean SOC 2 report. It just wasn't the right SOC 2 report. The Security criteria — the Common Criteria every SOC 2 must include — said nothing about how long OrbitHR retained terminated employees' bank account numbers, whether candidates who withdrew an application could get their resume and background-check data deleted, or whether OrbitHR's Manila-based support team could see an employee's disability accommodation notes. Those are Privacy and Confidentiality questions, and for a platform that stores identity documents, payroll bank details, health elections, and background-check results for 3.2 million employee and candidate records across 41 countries, they are exactly the questions a sophisticated buyer's privacy office will ask. Priya's team spent the next five months rebuilding their control set and their system description around Privacy and Confidentiality before the auditor could even start testing. This article is the playbook she wishes she'd had on day one.
Who This Is For
This is written for security, privacy, and compliance leaders at HR technology companies — applicant tracking systems, HRIS platforms, payroll processors, benefits administration tools, background-check vendors, and workforce-management suites — who are scoping or re-scoping a SOC 2 engagement to include Privacy and Confidentiality. You'll walk away with a working map of the Privacy criteria (P1–P8) applied to real HR data flows, a framework for classifying and protecting employee/candidate PII at scale, a clear-eyed view of where SOC 2 ends and GDPR/CCPA-style obligations begin, and a practical roadmap — with cost, timeline, and common-finding data — for getting from "Security-only" to a report your enterprise buyers will actually accept.
Why HR Tech Sits in the Regulatory Crosshairs
Every SaaS company handles some personal data. HR technology companies handle personal data as their entire product. An HRIS doesn't process a customer's business records incidentally — it is a system of record for the most sensitive category of information an organization holds about the people who work for it: national identifiers, home addresses, bank details, salary history, performance ratings, disciplinary records, immigration status, union membership, religious accommodation requests, and health information tied to benefits and leave.
That concentration creates a specific risk profile. A CRM breach exposes prospect contact details. An HR platform breach exposes Social Security numbers, direct-deposit routing numbers, and — depending on the modules in scope — medical information protected under multiple overlapping regimes at once. Enterprise buyers know this, which is why HR-tech procurement teams increasingly route SOC 2 reports directly to the privacy office rather than just IT security, and why "Security only" reports are getting bounced back with exactly the kind of note Priya received. The SOC 2 Complete Guide: Understanding AICPA Trust Services Criteria is a useful primer if you're new to the framework; this article assumes that baseline and goes deep on the HR-specific application.
"I stopped asking vendors 'are you SOC 2 compliant' two years ago. Now I ask 'which criteria are in your report, and does Privacy cover candidate data or just employee data?' Nine times out of ten the answer tells me whether procurement should even keep talking to them." — Sam Whitfield, VP of People Systems, Meridian Foods
The Employee and Candidate Data Lifecycle
Before you can protect HR data, you need to map where it comes from, where it lives, and where it's supposed to stop existing. HR platforms are unusual in that they process two overlapping populations — candidates (who may never become employees) and employees (whose data footprint keeps growing for years) — through a single system, often with different legal bases and retention obligations for each.
Lifecycle Stage | Typical Data Captured | Primary Legal Basis | Retention Trigger |
|---|---|---|---|
Sourcing / application | Name, contact info, resume, work history | Consent / legitimate interest | Application withdrawal or rejection |
Screening / background check | Criminal history, credit check, education verification, SSN | Consent + statutory permissible purpose | Hiring decision date |
Onboarding | Government ID, I-9/right-to-work docs, bank details, tax forms | Contract necessity + legal obligation | Employment start |
Active employment | Payroll, benefits elections, performance data, health/leave records | Contract + legal obligation | Ongoing, reviewed annually |
Leave / accommodation | Medical certifications, disability documentation | Legal obligation (narrow access) | Case closure |
Offboarding | Exit interview, final pay, COBRA/benefits continuation | Legal obligation | Termination date |
Post-employment | Tax records, reference-check data, litigation holds | Statutory retention | Statutory retention period expiry |
Two things make this lifecycle harder to control than a typical B2B SaaS data flow. First, candidate data has a much shorter legitimate retention window than employee data, but it's frequently stored in the same database tables with the same access controls — meaning a recruiter who should lose access to a candidate's file 90 days after rejection often doesn't. Second, the transition from "candidate" to "employee" usually means data migrates from an applicant tracking module into a core HRIS record, and that migration point is where fields get duplicated, orphaned, or left unclassified. Your SOC 2 scoping exercise needs to walk this lifecycle end to end, not just document the production database schema.
What "Sensitive" Really Means in HR Data
Not all employee data carries the same risk, and treating a work email address the same as a bank routing number is how HR platforms end up either over-engineering controls on low-risk fields or under-protecting the fields that actually matter. Building a defensible data classification scheme — see also our deeper look at SOC 2 Data Classification: Information Sensitivity Management — is foundational to scoping Privacy and Confidentiality correctly.
Data Category | Examples | Sensitivity Tier | Typical Regulatory Overlay |
|---|---|---|---|
Directory data | Name, job title, work email, department | Low | General privacy law (minimal) |
Contact/identity | Home address, personal phone, DOB | Medium | GDPR, CCPA/CPRA |
Government identifiers | SSN/national ID, passport, visa/work authorization | High | GDPR special category (in some states), state ID-theft statutes |
Financial | Bank account, routing number, salary, garnishments | High | GLBA-adjacent, state financial privacy laws |
Health-adjacent | Benefits elections, FMLA/leave documentation, accommodation requests | Critical | HIPAA (in benefits-admin context), GDPR special category, ADA |
Background/criminal | Background check results, drug test results | Critical | FCRA, state ban-the-box laws, GDPR special category |
Biometric | Timeclock fingerprint/face scan | Critical | State biometric privacy statutes (e.g., BIPA-style) |
Diversity/demographic | Voluntary EEO self-ID, religion, union membership | Critical | GDPR special category, EEOC rules |
The "Critical" tier is where most HR-tech Privacy and Confidentiality findings originate. Auditors will specifically test whether access to accommodation records, background-check results, and demographic self-identification data is restricted beyond the general HR-admin role — because in most organizations it legally has to be. If your access-control model treats all "HR data" as one bucket, expect this to surface as a finding.
Security Alone Isn't Enough: Why Privacy and Confidentiality Join the Audit
Every SOC 2 report includes the Common Criteria (Security) — there's no opting out. Availability, Processing Integrity, Confidentiality, and Privacy (TSC) are additional categories included based on the commitments a service organization has made to its customers. For most SaaS companies, Security plus maybe Availability is sufficient. HR technology is the category where Privacy and Confidentiality stop being optional in practice, even though they remain optional in the standard.
Here's why: the Security criteria test whether you can keep unauthorized parties out. Privacy and Confidentiality test something different and more specific to HR data — whether you handle personal information appropriately even for authorized parties. A recruiter with legitimate system access viewing a candidate's background check results for a role they're not hiring for is a Security-criteria non-event (they had valid credentials) but a Privacy-criteria failure (collection and access exceeded the stated purpose). This distinction is exactly what tripped up OrbitHR — their access logs showed no unauthorized access at all, because the problem wasn't intrusion, it was over-broad internal use of data that was collected for one purpose and used for another.
Trust Services Category | What It Tests | Why It Matters Specifically for HR Tech |
|---|---|---|
Security (Common Criteria) | Unauthorized access prevention, system protection | Baseline — protects the data store itself |
Confidentiality | Designated confidential info is protected per commitments | Payroll figures, background-check results, medical/accommodation notes |
Privacy | Personal information collection, use, retention, disposal per notice | Candidate/employee PII across the full lifecycle, not just "confidential" fields |
Availability | System uptime per commitments | Payroll must run on schedule — a missed pay run is a real-world harm |
Processing Integrity | Processing is complete, accurate, timely | Payroll calculation errors, tax withholding errors |
"The report Meridian's CPO sent back wasn't wrong to reject. Security-only SOC 2 reports for payroll and benefits platforms are becoming a red flag, not a green light, in sophisticated procurement processes. If your product touches SSNs and health elections, buyers now expect to see Privacy and Confidentiality named on the cover page." — Marcus Delaney, Partner, Delaney & Cross CPAs
Inside the Privacy Criteria: P1 Through P8 for HR Platforms
The AICPA's Privacy criteria are organized into eight categories, P1.0 through P8.0. They were built generically enough to apply to any personal-information-handling business, but they map unusually cleanly onto HR-tech workflows because HR platforms are, functionally, personal-information-management systems with a payroll engine attached.
Criterion | Focus | HR Tech Application |
|---|---|---|
P1.0 — Notice and communication of objectives | The entity provides notice about its privacy practices | Candidate application notices, employee privacy policy, benefits-enrollment disclosures |
P2.0 — Choice and consent | Individuals are given choices and their consent is obtained/documented | Optional demographic self-ID, marketing opt-ins, background-check authorization forms |
P3.0 — Collection | Personal info is collected consistent with objectives | Limiting ATS fields to job-relevant data; not over-collecting on application forms |
P4.0 — Use, retention, and disposal | Info is used/retained/disposed of consistent with objectives | Purging rejected-candidate data on schedule; restricting use of accommodation data to leave administration |
P5.0 — Access | Individuals can access their personal information | Employee self-service portals; candidate data-access requests |
P6.0 — Disclosure and notification | Info is disclosed to third parties per commitments, with notice of breaches | Background-check vendor sharing; benefits-carrier data feeds; breach notification workflow |
P7.0 — Quality | Personal info is accurate, complete, and relevant | Data-correction workflows for name changes, address updates, dependent info |
P8.0 — Monitoring and enforcement | The entity monitors compliance and resolves complaints | Privacy complaint intake, internal audit of access logs, DPO escalation path |
For a deeper treatment of all eight criteria in general terms, see SOC 2 Privacy Criteria: Personal Information Management and Protection. What's worth calling out for HR tech specifically is P3 and P4 — collection and retention. Auditors testing an ATS will pull the actual application form and cross-reference every field collected against a documented business purpose. A "current salary" field, a voluntary religion question with no legal basis for asking, or a resume-parsing tool that extracts age from graduation dates are all the kinds of over-collection findings that show up in HR-tech Privacy testing far more often than in a typical B2B platform.
Confidentiality Criteria: The Other Half of the Story
Where Privacy governs personal information broadly, Confidentiality governs any information an organization has committed to protect — which for HR platforms includes both personal data and business-sensitive data like compensation structures, workforce reduction plans, and unpublished org changes. The two criteria overlap heavily on HR platforms but aren't identical.
Dimension | Privacy Criteria | Confidentiality Criteria |
|---|---|---|
Scope of information | Personal information about identified/identifiable individuals | Any information designated confidential by agreement or policy |
Example HR data | Employee home address, candidate SSN | Salary bands, pending layoff list, unreleased comp changes |
Governing question | Is this used/retained consistent with notice given? | Is this protected per the confidentiality commitment made? |
Typical control overlap | Access control, encryption, retention schedules | Access control, encryption, NDA-backed handling |
Where they diverge | Data-subject rights, consent, disposal timing | Confidentiality survives even for non-personal business data |
A practical example: an HR platform's reduction-in-force (RIF) planning module contains a list of employees slated for layoff before any employee is notified. That list is deeply personal (Privacy-relevant) and commercially sensitive to the customer (Confidentiality-relevant) — leaking it early causes both a privacy harm to named individuals and a reputational/legal harm to the customer. Controls like need-to-know access, watermarking of exports, and time-boxed access grants address both criteria simultaneously, which is why most mature HR-tech SOC 2 programs treat Privacy and Confidentiality as a joint control set rather than two separate workstreams.
SOC 2 Supports, It Doesn't Substitute: GDPR, CCPA/CPRA, and the Rest
This is the single most important framing point in this entire article, and it's worth stating plainly: a SOC 2 report — even one with Privacy and Confidentiality in scope — is not a substitute for GDPR, CCPA/CPRA, or any other data-protection law. SOC 2 is a US-originated, AICPA-governed attestation. It is not a certification, and passing it does not make an HR platform "legally compliant" with any statute. What it does is provide independent, third-party-tested evidence that supports your legal compliance posture — the kind of evidence a customer's own GDPR Article 28 processor-due-diligence process or CCPA service-provider assessment will want to see.
Regulation | Jurisdiction | Relevance to HR Tech | Relationship to SOC 2 |
|---|---|---|---|
GDPR | EU/EEA (extraterritorial reach) | Employee/candidate data of EU-based staff; special-category data rules | SOC 2 Privacy/Confidentiality controls support, don't satisfy, GDPR Art. 28 processor obligations |
CCPA/CPRA | California | Employee/applicant data now in scope (post-2023); data-subject rights | SOC 2 evidences technical/organizational measures referenced in CCPA service-provider contracts |
UK GDPR / DPA 2018 | United Kingdom | Mirrors EU GDPR post-Brexit | Same relationship as GDPR |
PIPEDA | Canada | Federally regulated employers and cross-border transfers | Supports but doesn't replace PIPEDA accountability principle |
LGPD | Brazil | Employee/candidate data of Brazil-based staff | Supports data-protection-officer and DPIA-style obligations |
State biometric laws | Various US states | Timeclock/badge biometric data | Confidentiality criteria evidence for biometric handling |
Sectoral (FCRA) | US, background checks | Permissible-purpose and adverse-action rules | Not covered by SOC 2 at all — separate compliance program required |
The failure mode I see most often is a sales or marketing team implying otherwise — a website line reading "GDPR compliant, backed by our SOC 2 certification" is wrong on two counts (SOC 2 isn't a certification, and it doesn't make anyone GDPR compliant). Get legal counsel to review every external claim that pairs SOC 2 language with a regulatory-compliance claim before it ships.
"We tell every HR-tech client the same thing: SOC 2 Privacy and Confidentiality make your GDPR and CCPA compliance credible to a customer's legal team, because now there's an independent auditor's testing behind your controls narrative. But the report itself is not a data-protection-law compliance certificate, and any salesperson who says otherwise is creating legal exposure for the company." — Renee Okafor, Data Protection Officer, OrbitHR EU
Data Subject Rights in an HR Context
GDPR- and CCPA-style data-subject rights (access, correction, deletion, portability, restriction of processing) apply to employees and candidates just as they apply to consumers — a fact many HR platforms built their systems without anticipating, because early HRIS design assumed the employer, not the individual, was the primary data controller relationship to serve. Auditors testing P5.0 (Access) and P4.0 (Use, retention, and disposal) will want to see these rights operationalized, not just described in a policy PDF.
Data Subject Right | HR-Tech Implementation Challenge | Practical Control |
|---|---|---|
Right of access | Employee data spans HRIS, payroll, benefits, performance modules | Unified self-service portal pulling from all modules |
Right to rectification | Name/address changes must propagate to payroll and benefits feeds | Single source of truth with downstream sync, not manual re-entry |
Right to erasure | Employee data has statutory retention that overrides "right to be forgotten" | Documented retention-override logic, field-level erasure where legally possible |
Right to data portability | Exporting structured employee data for departing employer | Machine-readable export function, access-logged |
Right to restrict processing | Employee disputes accuracy of a performance record | Flagging mechanism that freezes downstream use pending resolution |
Right to object | Candidate objects to automated resume-screening decision | Human-review escalation path for automated/AI screening decisions |
Note the erasure row carefully — it's the one that trips up HR platforms most often in practice. Employers frequently have a legal obligation to retain payroll and tax records for years after employment ends, which directly conflicts with an individual's erasure request. The correct control isn't "always delete on request" or "never delete" — it's a documented decision tree that your customer's legal team, not your engineering team, ultimately owns, with your platform providing the technical capability to execute either outcome per record type.
Cross-Border Transfers: Payroll, Benefits, and the Multinational Workforce
An HR platform serving a customer with employees in 15 countries is, by definition, moving personal data across borders continuously — payroll runs to in-country processors, benefits data to local carriers, background checks to jurisdiction-specific vendors. This is where Privacy criterion P6.0 (Disclosure and notification) intersects hardest with real regulatory risk, because cross-border personal-data transfer is one of the most heavily regulated data activities globally.
Transfer Mechanism | Typical Use Case | SOC 2 Relevance |
|---|---|---|
EU Standard Contractual Clauses (SCCs) | EU employee data to US-based HR platform | Confidentiality/Privacy controls provide supporting evidence for the transfer impact assessment |
UK International Data Transfer Agreement (IDTA) | UK employee data to non-UK processor | Same as SCCs, UK-specific instrument |
Binding Corporate Rules (BCRs) | Large multinational platform with intra-group transfers | SOC 2 report can be referenced as part of BCR compliance monitoring |
Adequacy decisions | Transfers to countries the EU deems "adequate" | No additional mechanism needed; SOC 2 still valuable as due-diligence evidence |
Data localization requirements | Countries (e.g., certain APAC/LatAm jurisdictions) requiring in-country storage | May require region-specific SOC 2 scoping or separate infrastructure boundary |
The practical control set here is less about the legal instrument (that's a legal/DPO function) and more about the platform being able to answer, precisely, where a given employee's data physically resides, which subservice organizations touch it, and what encryption and access controls apply in transit between regions. Auditors will test whether your data-flow diagram matches your actual infrastructure — a stale diagram that doesn't reflect a newly added APAC data center is a common, avoidable finding.
Data Classification for HR Platforms
We touched on sensitivity tiers earlier; this section is about operationalizing data classification as a control, not just a taxonomy. A classification scheme only earns its keep if it drives different technical treatment at each tier — different encryption requirements, different access approval workflows, different retention automation.
Classification Tier | Encryption Requirement | Access Approval | Retention Automation | Audit Log Detail |
|---|---|---|---|---|
Public | Standard TLS | Any employee | N/A | Standard |
Internal | TLS + at-rest | Role-based | Standard schedule | Standard |
Confidential | TLS + at-rest + field-level for exports | Manager approval | Automated purge on schedule | Enhanced (who, when, what field) |
Restricted (SSN, health, background) | TLS + at-rest + tokenization/field-level encryption | Named-individual approval, time-boxed | Automated purge, legal-hold override | Full field-level access log, quarterly review |
The tier-4 row is where most HR platforms discover they've under-invested. Field-level encryption at rest and encryption in transit for SSNs and background-check results, combined with named-individual (not just role-based) access approval, is increasingly the baseline enterprise buyers expect — generic "the database is encrypted" language doesn't satisfy a sophisticated privacy reviewer anymore.
Access Control Architecture for HR Tech
Access control design for HR platforms has to solve a harder problem than most SaaS products: the same underlying employee record needs radically different visibility depending on who's looking and why. A payroll admin needs bank details; an IT admin provisioning a laptop doesn't. A benefits coordinator needs to see a leave request exists; they don't need the medical certification behind it.
Role | Directory Data | Financial Data | Health/Accommodation Data | Background Check Results |
|---|---|---|---|---|
Employee (self) | Full (own record) | Full (own record) | Full (own record) | Full (own record) |
Direct manager | Full (team) | None | Case exists only, no detail | None |
HR generalist | Full | View only | None (routed to leave-admin role) | Summary (pass/fail) only |
Payroll administrator | Limited | Full | None | None |
Benefits/leave administrator | Limited | None | Full | None |
IT/platform admin | Limited (provisioning fields) | None | None | None |
Recruiter | Candidate records only, role-scoped | None | None | Summary for their req only |
Building this matrix is straightforward; enforcing it in a monolithic HRIS database where most tables were designed years before Privacy was a named requirement is the hard part. Role-based access control, layered with attribute-based restrictions (e.g., "leave-admin AND assigned-to-this-case"), and least privilege defaults for new roles, is the practical architecture most mature HR platforms converge on. See also SOC 2 Access Controls: User Management and Privilege Administration for the general control-design pattern this builds on.
The Subservice Organization Web: Payroll, Benefits, Background Checks, Immigration
Almost no HR platform operates its entire product surface in-house. Payroll tax filing, benefits-carrier integrations, background-check processing, and immigration/visa document handling are routinely delegated to specialized subservice organizations. Each one is a place where employee PII leaves your direct control, and each one needs to be reflected honestly in your SOC 2 system description using either the carve-out method or the inclusive method.
Subservice Category | Example Function | Typical Method | Data Shared |
|---|---|---|---|
Payroll tax processor | Federal/state/local tax filing | Carve-out | SSN, wages, withholding |
Benefits carrier integration | Health/dental/vision enrollment feeds | Carve-out | DOB, dependent info, plan elections |
Background-check vendor | Criminal, credit, education verification | Carve-out | SSN, DOB, consent record |
Identity verification | I-9/right-to-work document validation | Carve-out or inclusive | Government ID images |
Cloud infrastructure | Hosting, storage, compute | Inclusive (usually via provider's own SOC 2) | All data at rest |
Immigration/visa processing | Work-authorization case management | Carve-out | Passport, visa status, employer petition data |
The carve-out vs. inclusive decision matters more here than in most industries because so many of these vendors handle Restricted-tier data. Under the carve-out method, your report explicitly states that the subservice organization's controls are not included in your testing, and you rely on complementary subservice organization controls — meaning your customers need independent assurance over that vendor too (often via the vendor's own SOC 2 report). If you can't produce a current SOC 2 report for your background-check vendor when a customer asks for it, that's a real gap, not a theoretical one. For the general pattern, see SOC 2 Common Controls: Shared Responsibility in Service Organizations.
Vendor Risk Management for HR-Specific Vendors
Vendor risk management for HR-tech subservice organizations deserves its own tier of rigor because the failure modes are specific and severe: a compromised background-check vendor exposes SSNs and criminal history for every candidate ever screened through your platform, not just your customers' data.
Vendor Risk Factor | Assessment Question | Red Flag |
|---|---|---|
Data sensitivity handled | What PII/PHI-adjacent data does this vendor touch? | Vendor can't enumerate data fields shared |
Own attestation coverage | Does the vendor hold a current SOC 2 (or equivalent)? | No report, or report older than 12 months |
Subcontractor chain | Does the vendor use its own subservice organizations? | Undisclosed fourth-party processors |
Breach notification terms | What's the contractual SLA for notifying you of a breach? | No SLA, or SLA exceeding 72 hours |
Data residency commitments | Where is data physically stored/processed? | Vendor can't confirm region |
Termination/offboarding data handling | What happens to shared data when the contract ends? | No documented deletion/return process |
Build this into a formal annual (at minimum) vendor review cycle, and make background-check, payroll-tax, and benefits-carrier vendors subject to more frequent review than your general SaaS-tooling vendors — the data sensitivity justifies it, and auditors increasingly expect to see risk-tiered vendor review cadences rather than a flat annual checklist applied uniformly.
Retention and Disposal: How Long Is Too Long?
P4.0's retention-and-disposal mandate is where HR platforms accumulate the most quiet risk, because "just keep everything, storage is cheap" is the path of least resistance — and the wrong one. Every extra year of retained candidate data no one asked to keep is pure liability with no corresponding business value.
Data Type | Common Statutory Minimum | Recommended Platform Default | Disposal Method |
|---|---|---|---|
Rejected candidate application (US) | 1 year (EEOC guidance) | 2 years, then auto-purge | Hard delete |
Payroll records | 3–7 years (varies by jurisdiction) | Per jurisdiction, automated by region | Archival then hard delete |
I-9/right-to-work documents | 3 years after hire or 1 year after termination, whichever is later | Automated calculation per employee | Hard delete |
Background check results | Varies (FCRA: no federal max, state limits apply) | Aligned to hiring decision + short buffer | Hard delete or cryptographic erasure |
Benefits enrollment records | 6 years (ERISA-adjacent contexts) | Per plan type | Archival then hard delete |
Terminated employee full record | Varies widely by jurisdiction | Tiered: active fields purged sooner, tax-relevant fields retained per statute | Field-level tiered deletion |
The tiered-deletion approach in the last row is the maturity marker auditors look for: rather than treating "employee record" as one all-or-nothing retention clock, mature platforms apply different retention timers to different fields within the same record — a terminated employee's performance reviews might purge in 2 years while their W-2-relevant payroll data is retained for 7. This requires retention logic at the field or module level, not just the record level, which is a real engineering investment but a defensible one.
Special Category Data: Health, Background Checks, Biometrics
Three data types deserve individual callouts because they consistently generate the highest-severity findings in HR-tech SOC 2 engagements.
Health-adjacent data. Benefits enrollment, FMLA/leave certifications, and ADA accommodation requests aren't full HIPAA-regulated PHI in most HR-platform contexts (that depends on whether you're acting as a plan administrator vs. an employer's HR system), but they carry equivalent sensitivity and often equivalent legal protection under state and disability law. Treat this data as Restricted-tier regardless of whether HIPAA technically applies — a background check that includes a drug-test result belongs in the same bucket.
Background checks. Governed federally by FCRA and by a growing patchwork of state "ban the box" and salary-history laws, background-check data requires documented consent, a defined permissible purpose, and — critically — an adverse-action process if a hiring decision is made based on the results. Your platform doesn't need to run this process, but if you store the results, your access controls need to reflect that this is among the most legally sensitive data in the system.
Biometric data. Timeclock fingerprint or facial-recognition data is subject to some of the strictest state statutes in the US (biometric privacy laws carrying statutory damages per violation, independent of proven harm), plus GDPR special-category treatment in the EU. If your platform offers biometric time-and-attendance features, this alone can justify a dedicated Confidentiality control set — informed consent capture, separate storage from other HR data, and a documented destruction schedule tied to employment termination, not just general retention policy.
Special Category | Primary Legal Driver | Minimum Control Expectation |
|---|---|---|
Health/accommodation | ADA, state disability law, GDPR special category | Segregated access role, no manager visibility into diagnosis |
Background check results | FCRA, state ban-the-box | Consent record retained, summary-only access for non-HR roles |
Biometric | State biometric statutes, GDPR | Explicit consent, separate storage, short retention post-termination |
Union/organizing activity | NLRA, GDPR special category | No employer-visible tracking of organizing communications |
Immigration status | INA, GDPR special category | Restricted to immigration-case-team role only |
Incident Response and Breach Notification Across Jurisdictions
An HR platform's incident response plan has to account for the fact that a single breach can trigger notification obligations in dozens of jurisdictions simultaneously, each with different timelines, thresholds, and required content. See SOC 2 Incident Response: Security Event Management and Reporting for the general framework; the HR-specific layer is jurisdictional mapping.
Jurisdiction Type | Notification Trigger | Typical Timeline | Complication for HR Tech |
|---|---|---|---|
US state breach notification laws | Unencrypted PII exposed (varies by state definition of PII) | "Without unreasonable delay," some states specify 30–90 days | 50 states, 50 different PII definitions and timelines |
GDPR (EU) | Risk to rights and freedoms of individuals | 72 hours to supervisory authority | Employee data often triggers mandatory notification given sensitivity |
Sector-specific (background-check adjacent) | FCRA-related mishandling | Contractual, not statutory in most cases | Layered on top of general breach law |
Contractual (customer DPAs) | Often stricter than law requires | Frequently 24–48 hours to customer | Must notify the employer customer, who then notifies their own employees |
The layered-notification structure is the piece HR-tech incident responders miss most often: you notify your customer (the employer), and the employer — not you — typically owns notifying the affected employees, because they're the data controller in most B2B HR-tech arrangements. Your incident-response runbook needs a customer-notification template ready well before an actual incident, because "we'll draft something once we know more" costs you the regulatory clock your customer is already running against.
Building the Control Environment: Policies You Actually Need
Auditors testing Privacy and Confidentiality will ask for a specific set of documented policies, distinct from (though overlapping with) your general Security policy set.
Policy | Purpose | Typically Owned By |
|---|---|---|
Privacy policy (external) | Notice to candidates/employees (P1.0) | Legal/Privacy |
Data classification policy | Defines sensitivity tiers and required controls | Security/Privacy |
Data retention and disposal schedule | Field/module-level retention timers | Privacy + Legal |
Access control policy | Role definitions, approval workflow, review cadence | Security |
Vendor/subservice organization risk policy | Assessment and monitoring of subservice orgs | Vendor management/Security |
Incident response and breach notification plan | Jurisdictional notification workflow | Security + Legal |
Data subject rights procedure | Access, correction, deletion, portability handling | Privacy |
Background check data handling policy | FCRA-aligned consent, access, retention | HR/Legal/Privacy |
Cross-border data transfer policy | SCC/IDTA usage, data residency commitments | Legal/Privacy |
A common failure at first-time HR-tech SOC 2 engagements isn't the absence of controls — it's the absence of documentation that ties controls together into named, versioned, owned policies an auditor can test against. If your retention rules live only in application code with no policy document describing the intended behavior, an auditor has nothing to test the code against, and that shows up as a design-deficiency finding even when the underlying engineering is sound.
Case Study: TalentBridge's Candidate Data Reckoning
TalentBridge, a mid-market applicant tracking system serving roughly 900 corporate customers, went through its first SOC 2 Type II with Privacy in scope after a customer's legal team flagged that rejected-candidate resumes were still retrievable four years after rejection. The engagement surfaced three findings: no automated purge for rejected-candidate records, a demographic self-ID field visible to hiring managers (rather than restricted to EEO-reporting roles only), and no documented consent-capture flow for background-check authorization on the mobile application version of the product.
TalentBridge's remediation took four months: they built field-level retention automation tied to application-status changes, moved demographic self-ID data behind a dedicated EEO-reporting role invisible to hiring managers, and rebuilt the mobile consent flow to match the web flow's audit trail. Their Type II observation period restarted after the fixes, adding roughly five months to their original timeline, but the resulting report — Security, Confidentiality, and Privacy, unqualified opinion — became a standard attachment in every enterprise deal from that point forward, and their average enterprise sales cycle shortened by roughly three weeks once procurement teams stopped requesting supplemental privacy questionnaires.
"The purge-automation finding was embarrassing because we'd talked about doing it for two years and just never prioritized it against feature work. The audit forced the prioritization decision for us. In hindsight I wish we hadn't needed a finding to make that call." — Jordan Kwiatkowski, Head of Trust, TalentBridge
Case Study: GlobalPay Works and the 41-Country Subservice Map
GlobalPay Works runs payroll and benefits administration for multinational employers across 41 countries, which meant its SOC 2 scoping conversation was dominated by subservice organizations from day one — in-country payroll processors, local tax filing agents, and regional benefits brokers in every market they serve. Their auditor's early gap assessment found that 14 of their 41 in-country processors had no current third-party attestation on file, and GlobalPay's own vendor risk register hadn't been updated in over 18 months.
Rather than trying to bring every in-country processor into an inclusive-method report (impractical at that scale), GlobalPay restructured around the carve-out method with a formalized complementary-subservice-organization-controls program: each processor now has an annual risk review, a documented data-sharing agreement specifying exactly which fields are transmitted, and a contractual breach-notification SLA. GlobalPay also built a data-residency map showing customers, region by region, exactly where their employees' payroll data physically lives and which entity processes it — a document that became one of the most-requested items in their sales due-diligence packet. Their Chief Privacy Officer estimated the full subservice-organization remediation program took nine months and required dedicated headcount, but it converted their most frequently cited sales blocker (cross-border data-handling uncertainty) into a competitive differentiator.
"Once we could hand a prospect's legal team a country-by-country data map with named subservice organizations and their attestation status, the conversation changed completely. We went from defending our data-handling practices to demonstrating them." — Fatima Al-Sayed, Chief Privacy Officer, GlobalPay Works
The System Description: Telling Your HR Data Story to Auditors
Your SOC 2 system description is the narrative document that frames everything an auditor tests. For an HR platform with Privacy and Confidentiality in scope, a generic "we are a SaaS company that stores customer data securely" description is inadequate — the description needs to name the specific categories of personal information processed, the system boundary, the subservice organizations relied upon, and the commitments made to data subjects.
System Description Element | HR-Tech-Specific Content Needed |
|---|---|
Types of services provided | ATS, HRIS, payroll, benefits admin — named per module in scope |
Principal service commitments | Specific Privacy/Confidentiality commitments (e.g., "candidate data purged within X days of rejection") |
System boundary | Which modules, environments, and geographic infrastructure are in/out of scope |
Subservice organizations | Named, with carve-out or inclusive treatment specified |
Complementary user entity controls | What the employer customer must do (e.g., configure retention settings correctly) |
Data subject categories | Employees, candidates, dependents, beneficiaries — each named separately |
Getting this document right early saves enormous rework later — auditors test against what the description says, so an incomplete description either under-scopes your testing (leaving gaps a customer will later notice) or creates a mismatch between what's described and what's actually tested, which itself becomes a finding.
Common Audit Findings in HR Tech SOC 2 Engagements
Drawing from patterns across first-time HR-tech Privacy/Confidentiality engagements, a handful of findings recur often enough to be worth naming explicitly.
Finding Category | Frequency (Illustrative) | Root Cause |
|---|---|---|
Over-retention of rejected-candidate data | Very common | No automated purge tied to application status |
Over-broad internal access to health/accommodation data | Common | Flat HR-admin role without leave-specific sub-role |
Missing/incomplete subservice organization attestation tracking | Common | No formal vendor risk register update cadence |
Stale data-flow diagrams (undocumented new regions/vendors) | Common | Diagram updates not tied to infrastructure-change process |
No field-level retention logic (record-level only) | Moderate | Retention treated as a database-table concern, not a field concern |
Inconsistent consent-capture across web/mobile | Moderate | Feature parity gap between platforms |
Undocumented complementary user entity controls | Moderate | System description written without customer-configuration inventory |
Demographic/EEO self-ID visible beyond reporting role | Less common but high severity | Default role permissions not revisited after feature launch |
Treat this table as a pre-audit self-assessment checklist. Walking through each row honestly, before an auditor does it for you, is the single highest-leverage use of a few hours in the run-up to a Privacy/Confidentiality-scoped engagement.
Type I vs Type II for HR Platforms
The general Type I vs. Type II decision applies to HR platforms the same way it applies elsewhere, with one wrinkle worth flagging: because so much of Privacy testing (P4.0 retention, P8.0 monitoring) is inherently about behavior over time rather than a point-in-time control design, a Type I report for an HR platform tends to satisfy fewer enterprise buyers than a Type I in other verticals. A design-only opinion on "we have a retention policy" says little about whether purges actually ran on schedule for six months.
Factor | Type I | Type II |
|---|---|---|
What's tested | Control design at a point in time | Operating effectiveness over a period (commonly 3–12 months) |
HR-tech buyer acceptance | Often insufficient alone for Privacy-sensitive deals | Generally expected, especially by regulated-industry buyers |
Best use case | First-time engagement, fast initial proof point | Ongoing customer trust, renewal cycles |
Typical HR-tech sequencing | Bridge report while building evidence for Type II | Standard annual deliverable |
Most mature HR-tech companies use a Type I as a bridge — useful for closing a deal that can't wait a full observation period — but plan from day one to convert to Type II within the following cycle, because that's what sustains trust at renewal and in RFPs from larger, more privacy-mature buyers.
Cost and Timeline for an HR Tech SOC 2 Program
Adding Privacy and Confidentiality to an existing Security-only program, or building all three from scratch, both take longer and cost more than a Security-only engagement — largely because of the policy documentation, retention-engineering, and subservice-organization work described above.
Program Scope | Illustrative Timeline | Illustrative Cost Range | Key Cost Drivers |
|---|---|---|---|
Security only, Type II | 6–9 months to first report | $30K–$60K audit fees | Standard Common Criteria evidence |
Security + Confidentiality, Type II | 8–11 months | $45K–$80K | Confidentiality commitment documentation, classification tooling |
Security + Confidentiality + Privacy, Type II | 10–14 months | $60K–$110K | Retention automation, DSR tooling, subservice-org attestation chase |
Adding Privacy/Confidentiality to existing Security-only report | 5–8 months | $20K–$40K incremental | Remediation of gaps like TalentBridge's retention findings |
These figures cover audit and readiness-consulting fees only — they exclude internal engineering time for retention automation, access-control rework, and data-flow documentation, which for a platform the size of OrbitHR or GlobalPay Works can meaningfully exceed the audit fee itself. Budget for the engineering lift as the larger line item, not the smaller one.
A Phased Roadmap to Audit Readiness
Phase | Duration (Illustrative) | Key Activities |
|---|---|---|
1. Data mapping and classification | 4–6 weeks | Inventory every PII field across ATS/HRIS/payroll/benefits modules; assign classification tiers |
2. Gap assessment against P1–P8 and Confidentiality | 3–4 weeks | Compare current state to Privacy/Confidentiality criteria; produce prioritized finding list |
3. Policy and documentation build | 4–8 weeks | Draft/update the policy set from the table above; get legal sign-off |
4. Technical remediation | 8–16 weeks | Retention automation, access-role rework, encryption gaps, DSR tooling |
5. Subservice organization program | Runs in parallel, 8–12 weeks | Vendor risk register refresh, attestation chase, data-sharing agreements |
6. Readiness assessment / mock audit | 3–4 weeks | Independent pre-check against likely testing procedures |
7. Type II observation period | 3–12 months (customer-driven minimum usually 6) | Controls operate; evidence collected continuously |
8. Fieldwork and reporting | 4–6 weeks | Auditor testing, draft report review, final issuance |
A readiness assessment before committing to a Type II observation period is worth the extra few weeks for HR platforms specifically, because restarting an observation period mid-way (as TalentBridge had to) is far more costly in calendar time than catching the same finding in a pre-audit mock.
Employee Data Flow Through an HR Platform
flowchart LR
A[Candidate applies] -->|Consent captured| B[ATS module]
B -->|Hiring decision| C[Background check vendor]
C -->|Results, summary only| B
B -->|Hire| D[Core HRIS record]
D --> E[Payroll module]
D --> F[Benefits module]
E -->|Tax filing| G[Payroll tax processor]
F -->|Enrollment feed| H[Benefits carrier]
D --> I[Leave/accommodation case]
I -->|Restricted access| J[Leave administrator role only]
D -->|Termination| K[Offboarding]
K -->|Field-level retention timers| L[Tiered archive/purge]
B -->|Rejection, no hire| M[Automated purge on schedule]This flow illustrates the core structural point of this article: personal data doesn't move through an HR platform in one straight line with one uniform control — it forks into subservice organizations (background check, tax processor, benefits carrier), narrows into restricted-access cases (leave/accommodation), and terminates on different schedules depending on whether the individual was hired, rejected, or offboarded. A Privacy and Confidentiality control program has to be designed against this branching structure, not a simplified single-database mental model.
Working With Your Auditor: Questions to Expect
Auditors scoping Privacy and Confidentiality for an HR platform for the first time will typically probe in a consistent pattern. Preparing answers to these in advance shortens fieldwork meaningfully.
Question Area | Sample Auditor Question |
|---|---|
Notice | "Show me the exact privacy notice a candidate saw at the point of application six months ago." |
Consent | "How do you prove a candidate consented to a background check before the check ran?" |
Collection | "Walk me through every field on your application form and its business justification." |
Retention | "Show me a rejected candidate's record and the system log of its deletion." |
Access | "Show me who has access to accommodation-request data and how that role was approved." |
Disclosure | "List every subservice organization that receives PII and what data each receives." |
Quality | "How does an employee correct an inaccurate record, and how is that logged?" |
Monitoring | "Show me evidence of your last internal review of Privacy control effectiveness." |
SOC 2 as a Growth Lever, Not Just a Gate
It's tempting to treat this entire body of work — data classification, retention engineering, subservice-organization chasing — as pure compliance overhead standing between OrbitHR and its next signature. That's the wrong frame, and it's not the one that ultimately won Priya her Meridian Foods renewal. What won it was OrbitHR's ability to hand Meridian's privacy office a report that named, specifically, how candidate resumes get purged, how accommodation data is walled off from managers, and which named subservice organizations touch payroll tax data in each country Meridian operates in. That specificity is a sales asset in a market where every serious HR-tech competitor is being asked the same questions by the same increasingly sophisticated buyers.
The platforms winning enterprise HR-tech deals in 2026 aren't the ones with the most features — they're the ones that can answer a privacy questionnaire in one document instead of six weeks of back-and-forth email. Build the Privacy and Confidentiality program as a permanent product capability, not a once-a-year audit scramble, and it compounds: faster security-review cycles, fewer surprise findings, and a genuine trust advantage over competitors still shipping Security-only reports to buyers who've started asking the harder question.
If your team is scoping this work now, PentesterWorld's SOC 2 Readiness Checklist is a solid starting point for the gap-assessment phase, and the SOC 2 Trust Services Criteria Mapping Template helps translate P1–P8 and Confidentiality into a working control matrix specific to your data map. For teams building the policy set from scratch, the SOC 2 Policy Pack gives you editable starting drafts rather than a blank page, and our "Are You SOC 2 Ready?" quiz is a fast gut-check before you commit budget to a full readiness assessment. And if you're weighing SOC 2 against a parallel ISO 27001 investment — a common question for HR-tech platforms selling into both US and EU enterprise buyers — ISO 27001 vs SOC 2: which one do you need and Running ISO 27001 and SOC 2 Together both walk through that decision in depth. PentesterWorld's assessment teams work with HR-tech platforms specifically on Privacy- and Confidentiality-scoped SOC 2 readiness — reach out when you're ready to scope the work.