Protect HR Data in the Cloud: How Shared Responsibility Prevented a Six-Figure Breach

Cloud migration is not a security transfer. That distinction sits at the center of every HR data liability case worth studying — and it is the one that most HR leaders misread. This case walks through how one HR team discovered the gap, mapped their actual responsibilities under the shared responsibility model, and built the controls that keep employee data protected. It is part of our broader HR data security and compliance framework — the architecture that connects access management, retention policy, and regulatory posture into a defensible program.

Context and Baseline: What “Moving to the Cloud” Actually Changed

The organization in this case had operated a locally hosted HRIS for eight years. Physical servers, on-site IT, one administrator with full access to everything. Security was understood because it was visible — the servers were down the hall.

When they migrated to a SaaS HRIS platform, the physical infrastructure disappeared. The vendor assumed responsibility for the data center, the hypervisor, server patching, and network availability. What did not transfer: data classification, user access permissions, encryption configuration, retention schedules, and incident response obligations. The HR director’s working assumption — that the vendor’s SOC 2 Type II report meant the organization was covered — left a wide-open customer-side gap.

The baseline state at migration completion:

• 14 active user accounts with administrator-level access, including 2 former employees never deprovisioned
• No data classification schema — SSNs, payroll records, and performance reviews stored in the same access tier
• Encryption at rest enabled (vendor default) but encryption keys managed entirely by the vendor
• No signed Data Processing Agreement with the HRIS vendor
• Incident response plan last updated in 2019, written for on-premise scenarios

This is not an unusual baseline. Gartner research consistently identifies misconfiguration — not infrastructure failure — as the primary cloud security risk, and the SHRM data security community has flagged IAM gaps as a top vulnerability in HR cloud deployments. The problem is not the cloud platform. It is the assumption that the vendor’s security posture substitutes for the customer’s.

Understanding the Shared Responsibility Model: Where HR’s Obligations Begin

The shared responsibility model divides cloud security into two distinct domains. Cloud service providers own security of the cloud: physical data centers, server hardware, hypervisors, core networking infrastructure, and availability guarantees. Customers own security in the cloud: everything they place inside that environment and every configuration decision they make.

For HR teams operating on SaaS platforms — the most common deployment model for HRIS, payroll, and ATS systems — the vendor-managed layer is substantial. But the customer-managed layer is where all of the regulatory exposure lives.

The regulatory implication is unambiguous. Under GDPR, the employer is the data controller. Under CCPA/CPRA and HIPAA, accountability similarly attaches to the organization, not the technology vendor. A vendor’s certification audit does not substitute for the employer’s compliance obligations. Forrester and Deloitte research on cloud governance both reach the same conclusion: the customer-side controls gap is the primary source of cloud HR liability.

Approach: The Controls Gap Audit

The engagement began with a structured audit designed to make the shared responsibility boundary visible and actionable. The goal was not a theoretical framework — it was a specific list of gaps with owners and deadlines.

Step 1 — Map Every HR Data Type to Its Classification Tier

No security control is meaningful without knowing what you are protecting. The team inventoried every data category stored in or flowing through the HRIS:

• Tier 1 (Highly Restricted): SSNs, national identifiers, banking and payroll data, health and benefits information, immigration status
• Tier 2 (Restricted): Compensation history, performance reviews, disciplinary records, background check results
• Tier 3 (Internal): Job titles, department assignments, work location, standard contact information

This classification schema — previously nonexistent — became the foundation for every subsequent access and encryption decision. Our essential HR data security practices guide walks through how to build this schema for your organization’s specific data environment.

Step 2 — Audit Every Active User Account

The IAM audit produced the most immediate findings. Of 14 administrator accounts, 9 were legitimate current HR staff with a defensible need for elevated access. Three were general managers with permissions inherited from a legacy role structure that no longer reflected their actual data needs. Two were former employees — one terminated eight months prior, one who had resigned fourteen months earlier — neither deprovisioned after departure.

The principle of least privilege — granting users access only to what their role requires — is a baseline requirement, not an advanced security posture. Yet it is consistently the most violated control in HR cloud environments. UC Irvine research on attention and interruption has documented how process gaps compound over time when they lack a designated owner; the same dynamic applies to IAM hygiene when no one holds explicit accountability for deprovisioning.

Step 3 — Verify Encryption Key Custody

The HRIS vendor’s default configuration used vendor-managed encryption keys. For Tier 1 data — SSNs, banking information, health data — this meant the vendor held both the data and the keys. For organizations subject to HIPAA or operating in jurisdictions with strict data sovereignty requirements, this arrangement creates regulatory exposure even when the vendor is fully certified.

The team negotiated customer-managed key options with the vendor and migrated Tier 1 data encryption to a customer-controlled key management system. This step alone resolved a HIPAA-adjacent compliance gap that would have required disclosure in the next benefits audit. For context on how data residency intersects with these decisions, our guide on data sovereignty and employee data compliance covers the jurisdictional layer in detail.

Step 4 — Execute and Sign the Data Processing Agreement

GDPR Article 28 requires a signed DPA with every third-party processor of personal data. The organization had no executed DPA with its HRIS vendor — a gap that would constitute a direct GDPR violation if an EU data subject’s records were involved (relevant given one employee cohort working in a European subsidiary). The DPA was negotiated, reviewed by legal counsel, and executed within 30 days of the audit.

Our resource on third-party HR data security and vendor risk management covers the full DPA framework and what to require in vendor contracts beyond standard certifications.

Implementation: Building the Customer-Side Security Layer

With the gap audit complete, implementation followed a priority sequence based on regulatory exposure and breach probability — not organizational convenience.

IAM Restructure — Week 1

The two former-employee accounts were deprovisioned immediately. The three over-permissioned manager accounts were downgraded to Tier 3 read-only access aligned to their actual job functions. Multi-factor authentication was enforced organization-wide, not optionally enabled. A quarterly IAM review was assigned to the HR operations lead as a standing calendar commitment — not a one-time remediation.

When vetting HR software vendors for data security, the IAM capability of the platform — role granularity, MFA options, audit log depth, deprovisioning automation — should be a primary evaluation criterion, not a post-implementation discovery.

Incident Response Plan Rebuild — Weeks 2–4

The 2019 incident response plan assumed physical server access and on-premise containment steps. Cloud-specific failure modes — exposed API credentials, misconfigured storage permissions, compromised admin accounts — require different detection methods, different containment actions, and different notification timelines.

The rebuilt plan mapped directly to regulatory timelines: GDPR’s 72-hour supervisory authority notification window, HIPAA’s 60-day breach notification requirement, and CCPA/CPRA’s disclosure obligations. A tabletop exercise was conducted in week four using a simulated compromised admin credential scenario. Two gaps surfaced — neither existed in the written plan. Both were closed before the exercise concluded.

Encryption Migration — Weeks 3–6

Customer-managed key migration for Tier 1 data was the most technically complex step and the one requiring the most active vendor coordination. The implementation followed a phased approach: SSN and banking data first, health and benefits data second, with verification checksums at each phase before proceeding.

This work also surfaced a secondary finding: three third-party integrations (payroll processor, benefits administrator, background screening platform) were transmitting data without verified end-to-end encryption. Each integration was paused, remediated, and re-enabled with documented encryption confirmation. Our checklist of critical security questions for HR tech vendors includes the integration-level encryption questions that surface these gaps before a contract is signed.

Results: Before and After the Controls Audit

The organization entered its next benefits compliance review with a documented controls posture for the first time. No breach occurred. More precisely: the audit established that the exposure was real, the gaps were closeable, and the cost of closing them was a fraction of what a single GDPR enforcement action or HIPAA breach notification cycle would have required. McKinsey research on cloud security maturity identifies organizations with documented IAM and encryption controls as significantly less likely to face regulatory enforcement — the controls audit translates that principle into a specific, auditable outcome.

Lessons Learned: What We Would Do Differently

Transparency about what could have been done better is what separates a useful case study from a marketing document. Three specific improvements would accelerate outcomes in a repeat engagement:

1. Run the Controls Audit Before Migration, Not After

The audit was commissioned after go-live, which meant remediating live production systems — a higher-risk, higher-cost approach than designing the controls posture into the migration plan. A pre-migration shared responsibility mapping session adds two to four hours of planning work and eliminates weeks of post-migration remediation. The proactive HR data security blueprint covers exactly this sequencing.

2. Include Legal Counsel in Vendor Negotiation from Day One

The DPA negotiation required two rounds of revision because the vendor’s standard contract template contained data retention clauses inconsistent with the organization’s GDPR obligations. Earlier legal involvement would have surfaced this in the procurement phase, before signatures on the main service agreement constrained the negotiating position on the DPA.

3. Automate Deprovisioning at the Source

The two former-employee accounts existed because the offboarding process had no automated trigger to the HRIS admin. The fix — a workflow connecting the HRIS offboarding record to an automated deprovisioning action — is straightforward to build and eliminates the human dependency entirely. RAND Corporation research on insider threat vectors consistently ranks residual access as one of the highest-probability exposure pathways. Automation closes it without relying on anyone remembering to do it.

Applying This Framework to Your Cloud HR Environment

The shared responsibility model is not unique to this case. Every HR team running a cloud HRIS, payroll platform, ATS, or benefits administration system is operating inside this framework — whether they have mapped it or not. The question is whether the customer-side controls are built and verified, or assumed and untested.

The four highest-leverage starting points, in priority order:

1. IAM audit: Pull every active user account, verify current employment status, map permissions to actual job function, enforce MFA, and assign a standing quarterly review owner.
2. Data classification: Map every HR data type to a tier, document which systems hold which tier, and use classification as the basis for access and encryption decisions.
3. DPA execution: Confirm a signed DPA exists with every vendor who processes personal data on your behalf — HRIS, payroll, ATS, benefits, background screening.
4. Incident response rebuild: Replace any on-premise playbook with a cloud-specific plan tested against your actual regulatory timelines.

Building a data privacy culture in HR sustains these controls over time — the audit establishes the baseline, but the culture determines whether the controls remain enforced through staff turnover, platform changes, and regulatory evolution.

For ongoing audit cycles that validate and extend this posture, our HR data audits for compliance guide provides the repeatable framework. The shared responsibility model does not change. What changes is how well your team understands which side of the line they are standing on.