Cloud migration does not transfer security responsibility to the vendor. HR teams own data classification, access permissions, encryption key custody, retention schedules, and incident response — regardless of a vendor’s SOC 2 certification. These 9 controls define the customer-side obligations that determine whether employee data stays protected.

The most expensive HR data incidents do not start with a vendor failure. They start with an assumption — that moving to a SaaS HRIS meant the security problem moved too. One mid-market healthcare organization learned this during a cloud migration covering 600 employees. Their vendor held a SOC 2 Type II certification. Their HR director assumed that covered the organization. It did not. What followed was a gap audit that uncovered 14 over-permissioned accounts, two active logins belonging to former employees, no signed Data Processing Agreement, and an incident response plan written for on-premise servers that no longer existed.

The breach was avoided — but only because the gaps were found before someone else found them first. Understanding where HRIS configuration decisions create liability is the starting point. So is knowing which HRIS default settings expose HR teams that never reviewed them. The controls below map every customer-side obligation in plain language.

For the broader architecture connecting access management, retention policy, and regulatory posture, see the HR operations cleanup framework for small and solo teams. Teams building automation on top of their HRIS stack should also review what automation-first design looks like before adding AI.

The Shared Responsibility Model: What the Vendor Owns vs. What HR Owns

The shared responsibility model divides cloud security into two non-negotiable domains. Vendors own security of the cloud: physical data centers, server hardware, hypervisors, core networking, and availability guarantees. Customers own security in the cloud: every configuration decision made inside that environment and every piece of data placed there.

For HR teams on SaaS platforms — the standard deployment model for HRIS, payroll, and ATS systems — the customer-managed layer is where all regulatory exposure lives.

A vendor’s SOC 2 report documents their controls. It does not extend to how your team configures the platform, who has access, or whether your retention schedule meets regulatory requirements. These are distinct and non-transferable obligations.

What Are the 9 Cloud HR Security Controls HR Teams Own?

1. Identity and Access Management (IAM) Review

IAM is the highest-impact control on this list. Every HR system contains sensitive employee data — compensation, SSNs, performance records, benefits elections — and access to that data is governed entirely by the configurations HR sets, not the vendor.

The healthcare organization in this case completed migration with 14 administrator-level accounts active. Two belonged to former employees. Neither had been deprovisioned. A Gartner analysis of cloud security incidents consistently identifies misconfiguration — not infrastructure failure — as the primary risk vector, and IAM gaps are the leading form of misconfiguration in HR cloud deployments.

What this control requires:

• Quarterly access reviews: who has what permissions, and is each permission still justified
• Separation of duties: payroll access and performance data access should not default to the same role
• Immediate deprovisioning triggers tied to offboarding workflows — not manual memory
• MFA enforced for all administrator accounts, not offered as optional
• Role-based access aligned to job function, not inherited from the previous admin’s setup

Teams that have not formalized offboarding as a process — not just a checklist — face recurring IAM drift. The same workflow discipline that compresses onboarding applies to access deprovisioning on exit.

2. Data Classification Schema

Without a data classification schema, every piece of HR data sits at the same access tier. SSNs, payroll records, performance reviews, benefits enrollment, emergency contact information — all of it accessible to anyone with any form of HR system access.

Classification assigns sensitivity tiers to data categories and links those tiers to access rules, retention schedules, and handling requirements. The practical effect: a manager with self-service access to their team’s PTO balances cannot reach compensation data for the entire organization.

A functional three-tier schema for HR:

• Restricted: SSNs, bank account details, compensation history, medical/benefits data — access limited to HR and payroll administrators with documented business need
• Confidential: Performance reviews, disciplinary records, promotion history — access limited to HR and direct management chain
• Internal: Job titles, department assignments, work locations — accessible to managers and appropriate cross-functional users

Classification is also the prerequisite for defensible retention schedules. You cannot build a compliant retention policy for data you have not categorized.

3. Encryption Key Custody

Most SaaS HRIS platforms enable encryption at rest by default. This is the vendor-managed baseline and it provides meaningful protection against physical infrastructure compromise. What it does not provide: protection in scenarios where the vendor’s own systems are compromised, or in scenarios where HR data needs to be portable and auditable independent of the vendor relationship.

Customer-managed encryption keys (CMEK) shift key custody to the organization. If the vendor is compromised or subpoenaed, the organization retains cryptographic control over its data. This is not a feature available on every plan tier, but for organizations handling HIPAA-adjacent benefits data or operating under GDPR as a data controller, it is a requirement worth forcing into vendor negotiations.

At minimum, HR teams should:

• Confirm which encryption standard is in use (AES-256 is the current baseline)
• Determine whether keys are vendor-managed or customer-managed
• Document key management responsibility in the Data Processing Agreement
• Understand the vendor’s key rotation schedule and incident notification obligations

4. Data Processing Agreements (DPAs)

A Data Processing Agreement is a legally binding document that specifies how a vendor processes personal data on the organization’s behalf. Under GDPR, executing a DPA with every data processor is a legal requirement, not a best practice recommendation. Under CCPA and many state-level equivalents, equivalent contractual protections are required.

The healthcare organization in this case completed their HRIS migration with no signed DPA. The vendor had standard contract terms that addressed general service levels. Those terms did not cover data subject rights obligations, subprocessor disclosure, breach notification timelines, or data deletion requirements on contract termination.

A compliant DPA for an HRIS vendor must address:

• The purpose and legal basis for processing employee personal data
• Data categories in scope and prohibited uses
• Subprocessor list and notification obligations when subprocessors change
• Breach notification timeline (GDPR requires 72 hours to supervisory authority)
• Data return or deletion obligations upon contract termination
• Employee data subject rights (access, rectification, erasure) and how the vendor supports fulfillment

If a vendor refuses to execute a DPA, that refusal is itself a compliance disqualifier. It belongs in vendor selection criteria, not contract negotiation.

5. Role Configuration Hygiene

Role configuration hygiene is the ongoing management discipline that prevents IAM from drifting back into over-permissioned chaos after an initial cleanup. Most HRIS platforms ship with default role templates — Administrator, Manager Self-Service, Employee Self-Service — that HR teams accept without reviewing what each template actually permits.

Default role templates are designed for the average organization, not for regulatory compliance. The Administrator role in most platforms grants access to every data category in the system. When 14 people hold that role — including former employees and employees who needed it once for a specific task — the organization’s actual access posture bears no relationship to its intended one.

Role configuration hygiene requires:

• A documented role inventory: role name, permissions granted, number of current holders
• Business justification for each role assignment — not inherited from the previous administrator
• Custom roles where default templates grant more access than the job function requires
• Annual role review tied to the organization’s access review cycle
• Change management process: role changes require documented approval, not informal requests

The connection between role configuration and operational risk is direct. The $27K overpayment documented in the David HRIS data entry case traces to a configuration environment where access controls did not match job-function boundaries.

6. Retention Schedule and Deletion Policy

Data you do not have cannot be breached. This is the operational logic behind retention schedules — not just regulatory compliance, but active risk reduction through structured data minimization.

HR data retention requirements vary by data category and jurisdiction. Federal requirements under FLSA mandate payroll records for three years. EEOC regulations require certain hiring records for one year. ERISA benefit plan records require six years. State-level requirements layer on top of federal minimums and sometimes exceed them.

The failure mode is not usually intentional retention — it is passive retention. Data that was collected for one purpose, never classified, never scheduled for deletion, accumulating in the HRIS indefinitely because no one built the deletion workflow.

A functional retention program includes:

• Retention schedule mapped to data category and governing regulation
• Legal hold process: how active litigation or investigation suspends scheduled deletion
• Deletion verification: documented confirmation that data was actually deleted, not just flagged
• Backup and archive coverage: retention rules apply to backups, not just primary records
• Vendor deletion obligations documented in the DPA, including post-termination timelines

7. Incident Response Plan (Cloud-Adapted)

The healthcare organization’s incident response plan was last updated in 2019. It was written for an on-premise environment — physical server isolation, local IT escalation paths, network segmentation procedures that assumed the infrastructure was in the building. None of that applied to their post-migration SaaS environment.

A cloud-adapted incident response plan addresses a fundamentally different threat landscape: account compromise rather than server intrusion, API key exposure rather than cable disconnection, vendor-side incidents that affect customer data without direct customer involvement.

A cloud-adapted HR incident response plan must include:

• Incident classification matrix: what constitutes a breach vs. a security event vs. a policy violation
• Account compromise response: steps for immediate access revocation when a credential is compromised
• Vendor escalation path: who to contact at the vendor, how, and within what timeframe
• Regulatory notification triggers: which incident types require notification to regulators (72 hours under GDPR), affected individuals, and legal counsel
• Evidence preservation: how to capture audit logs before they are overwritten or expire
• Post-incident review process: what changed, what is being fixed, who is accountable

Incident response plans that exist only as documents are not incident response plans. They require tabletop exercises — walk-through simulations of breach scenarios — at least annually to verify that the process works and that the people responsible know their roles.

8. Third-Party Integration Security

HRIS platforms rarely operate in isolation. Payroll processors, benefits carriers, ATS systems, background check vendors, and automation platforms all connect to the core HR system via API integrations. Each integration point is an expansion of the attack surface that the HR team owns — not the HRIS vendor.

An API key generated for a payroll integration and stored in a shared spreadsheet, never rotated, belonging to a service account with administrator-level permissions — this is not a hypothetical. It is the actual configuration state of a significant percentage of mid-market HR technology stacks.

Integration security controls HR teams must own:

• Integration inventory: every system connected to the HRIS, with data flow documentation
• Least-privilege API access: integration credentials scoped to the minimum permissions required for the specific integration function
• API key rotation schedule: credentials rotated at defined intervals and immediately on personnel change
• Vendor security review: third-party integration vendors assessed against the same security standards as the primary HRIS vendor
• Integration audit logs: evidence of what data moved between systems, when, and in what volume

Teams using Make.com for HR automation workflows should document each scenario’s data access scope and apply the same least-privilege logic to Make connections as to direct API integrations. The framework for HR teams building automations with Make and AI covers connection scoping in practical terms.

9. Audit Log Ownership and Review

Audit logs are the forensic record of what happened in an HR system — who accessed what data, when, from where, and what they did with it. Most SaaS HRIS platforms generate audit logs automatically. What they do not do automatically: retain those logs for compliance-required periods, make them accessible in formats usable for regulatory investigations, or alert HR when anomalous access patterns occur.

Audit log ownership means taking deliberate control of log retention, review, and anomaly response — not assuming the vendor’s default settings are sufficient.

Audit log control requirements:

• Retention period confirmed and documented: most regulatory frameworks require one to three years of audit log retention; verify the vendor’s default against your actual requirement
• Log export capability: the ability to pull audit logs into formats accessible outside the vendor platform (critical if the vendor relationship ends during an investigation)
• Anomaly review process: periodic review of access logs for patterns inconsistent with job function — after-hours bulk exports, access from unrecognized locations, access by accounts that should have been deprovisioned
• Incident trigger: defined access events that automatically generate HR team notification
• Log integrity verification: confirmation that logs cannot be modified by users with elevated system access

Audit logs are also the primary evidence in employment disputes, regulatory investigations, and breach liability assessments. An organization that cannot produce clean audit logs for a defined period is at a material disadvantage in any of those scenarios.

How These 9 Controls Worked Together in the Case

The healthcare organization’s 60-day remediation addressed all nine domains. The sequence mattered:

1. IAM review first — closed three over-permissioned roles, deprovisioned two former-employee accounts, enforced MFA across administrator tier
2. Data classification second — established the schema that made retention scheduling and role design coherent
3. DPA executed with HRIS vendor — addressed subprocessor disclosure, breach notification, and deletion obligations
4. Encryption key review — confirmed AES-256 at rest, documented key management responsibility, flagged CMEK upgrade for next contract cycle
5. Role configuration audit — rebuilt custom roles aligned to job functions rather than inherited default templates
6. Retention schedule drafted — mapped to FLSA, EEOC, ERISA, and applicable state requirements
7. Incident response plan rebuilt — cloud-adapted, tested via tabletop exercise before the 60-day mark
8. Integration inventory completed — six third-party connections documented, credentials scoped to least privilege, rotation schedule set
9. Audit log controls formalized — retention confirmed at 24 months, anomaly review process assigned to a specific role

Outcome: audit-ready posture within 60 days, no breach, no regulatory exposure from the migration period. The gaps that existed were real — two live former-employee accounts in an HRIS holding HIPAA-adjacent benefits data is a reportable incident waiting for a trigger. The controls framework closed those gaps before the trigger occurred.

Where HR Teams Get the Shared Responsibility Model Wrong

Three misreads account for most of the customer-side exposure in HR cloud deployments:

Misread 1: The vendor’s SOC 2 covers the organization. It does not. SOC 2 documents the vendor’s internal controls. It says nothing about how the customer configures the platform, who has access, or whether the customer’s data handling practices are compliant.

Misread 2: Security is IT’s problem. In organizations without dedicated IT security staff — the majority of mid-market HR environments — HR owns the configuration decisions. Waiting for IT to handle HRIS access reviews is waiting for something that will not happen on a schedule that protects the organization.

Misread 3: The initial setup is enough. IAM drift, role creep, and integration sprawl are ongoing phenomena. The controls above require scheduled review cycles, not one-time implementation. The access review that was thorough at go-live will be stale within 12 months without a maintenance process.

For HR teams managing inherited systems where the baseline was never clean, the HR triage risk mapping framework provides a structured approach to sequencing cleanup work. The 11 warning signs of a bleeding HR operation identifies which symptoms map to which underlying control failures.

Frequently Asked Questions

Does a vendor’s SOC 2 Type II certification mean our organization is compliant?

No. A SOC 2 Type II report documents the vendor’s internal security controls — their data center security, change management practices, and availability commitments. It does not cover how the customer configures the platform, manages access, classifies data, or handles retention. Customer-side compliance obligations exist independently of vendor certifications.

What is the first cloud HR security control to address after a migration?

Identity and access management. Start with a full account audit: who has access, at what permission level, and whether each account belongs to a current employee with an active business need. Former-employee accounts and over-permissioned roles are the highest-probability breach vector in post-migration HR environments.

Is a Data Processing Agreement required even if the HRIS vendor is US-based?

If the organization processes personal data of EU or UK residents — including employees in those jurisdictions — a DPA is legally required under GDPR regardless of where the vendor is headquartered. Many US state privacy laws require equivalent contractual protections. Beyond legal obligation, a DPA defines breach notification timelines and data deletion responsibilities that are operationally essential regardless of jurisdiction.

How often should HR teams review access permissions in a cloud HRIS?

Quarterly access reviews are the standard for regulated environments. At minimum, access reviews should occur annually and immediately following any workforce reduction, merger or acquisition, or significant role change. Deprovisioning should be triggered by the offboarding workflow — not a periodic review — for any departing employee with system access.

What happens to audit logs if the organization terminates the HRIS vendor contract?

Most SaaS vendors delete customer data within 30 to 90 days of contract termination. If audit logs need to be retained beyond that window — for regulatory compliance, pending litigation, or insurance purposes — the organization must export and store those logs before contract termination. This obligation belongs in the DPA and should be confirmed before signing any HRIS contract.

Additional Reading

• 9 HRIS Configuration Defaults Every Small HR Team Should Change
• HRIS Required Fields vs Manual Data Validation: Which Is Safer for Small HR Teams?
• The $27K Overpayment: How One HRIS Data Entry Mistake Cost a Manufacturer a Year of Salary
• What Is HR Triage Risk Mapping? How HR Leaders Prioritize Inherited Messes
• 11 Warning Signs Your Inherited HR Operation Is Bleeding Money
• Drowning in Admin: How Solo and Small HR Teams Can Fix Broken HR Operations Without Burning Out
• In-House HR Cleanup vs Fractional HR Consultant: 2026 Decision Guide
• How to Build a 90-Day HR Triage Plan Your CEO Will Sign
• What Is a Minimum Viable HR Process? A Plain-Language Definition
• HR of One Survival FAQ: Inherited Operations Questions Answered
• How Sarah Compressed a 45-Minute Onboarding Process to Under 4 Minutes
• How a Non-Technical HR Team Started Building Their Own Automations With Make + AI
• 9 EEOC AI Compliance Requirements HR Teams Must Meet in 2026
• What Is Automation-First? Why You Should Automate Before You Add AI
• How TalentEdge Saved $312K with HR Process Standardization