HIPAA compliance does not create a blanket exemption from California privacy law. CPRA exempts only PHI, so personal information collected outside the HIPAA framework can still trigger notice, disclosure, and consumer rights obligations. That creates dual compliance pressure for organisations that operate websites, employ California residents, or process business-to-business records that are not part of treatment, payment, or operations.
Why HIPAA Compliance Does Not Cancel California Privacy Obligations
HIPAA and CPRA regulate different scopes, even when the same business handles both health-related and non-health-related information. HIPAA narrows its protections to PHI in covered workflows, while CPRA applies more broadly to personal information collected in other contexts, including many employee, applicant, vendor, and website interactions. That means one compliance program does not automatically satisfy the other.
The practical mistake is assuming “we are HIPAA compliant” equals “our data collection is exempt.” California privacy obligations attach to the data context, the role of the organisation, and the type of information collected. If the business runs a public website, recruits California workers, or keeps business records outside treatment, payment, or operations, those records can fall into CPRA scope even while HIPAA continues to govern PHI elsewhere.
Where Employee Data and Website Data Usually Fall
Employee and website data are often the first places the gap appears because they are usually collected outside the HIPAA framework. HR records, job applications, browsing analytics, lead forms, marketing cookies, support chats, and web account registrations are typically handled for ordinary business purposes, not as PHI in a covered health operation. Once that happens, CPRA notice, disclosure, retention, and consumer-rights questions can arise separately.
For practitioners, the core question is not whether the business is in healthcare, but whether the specific dataset is PHI or ordinary personal information. A HIPAA-covered entity can still have a California privacy obligation for a résumé, employee onboarding packet, website form submission, or cookie-linked profile if that material is collected and used outside the HIPAA-restricted data path. The data map has to be granular enough to separate those flows.
- Website tracking and marketing tools often collect personal information before any care relationship exists.
- Employee and applicant records usually sit in HR systems rather than HIPAA workflows.
- B2B contacts and vendor records may be personal information even when they are not PHI.
Risk and Threat Considerations
Dual-scope privacy obligations create a common failure mode: teams assume a healthcare control set covers all data, then under-disclose, over-retain, or mis-route requests for California-facing records. That can expose the business to notice failures, rights-request breakdowns, retention issues, and inconsistent deletion or access handling across systems.
Failure mechanism: The organisation classifies data by business function instead of by legal scope, so PHI is protected under HIPAA while non-PHI personal information in HR, marketing, and web systems is left unmanaged under CPRA.
Impact: That mismatch can create compliance exposure, customer or employee complaint risk, and operational confusion when privacy requests must be answered across multiple systems with different rules.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 3 — Data Protection | CPRA obligations depend on knowing where personal data lives and how it is handled. |
| CIS Control 6 — Access Control Management | Employee and website data often sits in non-HIPAA systems that still need controlled access. | |
| Recommendation — Classify and retain personal data by scope so HIPAA and CPRA records are handled separately. Restrict access to employee and website personal data based on business need and record type. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Organisations need a governance model that distinguishes HIPAA coverage from broader privacy obligations. |
| ID.IM-01 — Improvements are identified and actioned | Dual compliance gaps are usually found through assessment and remediation of data flows. | |
| Recommendation — Define a privacy governance strategy that explicitly separates HIPAA and CPRA scope. Review data flows and remediate privacy gaps where personal information is collected outside HIPAA. | ||
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | The same business may operate under different privacy obligations depending on data context. |
| 6.1 — Actions to address risks and opportunities | Dual-scope privacy creates a recurring compliance risk that needs planned treatment. | |
| Recommendation — Assess the organisational context to separate healthcare processing from ordinary personal-data processing. Treat mixed HIPAA and CPRA processing as a planned compliance risk with defined controls. | ||
Practitioner Guidance
What to verify: Build a data inventory that separates PHI from employee, applicant, website, and B2B personal information, then verify which systems collect California resident data outside HIPAA workflows.
Decision rule: If the record can exist and be used without treatment, payment, or healthcare operations, treat it as a separate privacy scope problem and test it against CPRA obligations on its own merits.
What practitioners underestimate: The hardest part is usually not the legal rule, but the boundary between systems, marketing platforms, HR tools, analytics, and support channels that were never designed to follow the same privacy lifecycle.
Practitioner takeaway: The right operating model is dual-scoped privacy governance, not “HIPAA first, everything else later.” When data leaves the HIPAA boundary, it needs its own classification, notices, request handling, and retention logic.
Related resources from NHI Mgmt Group
- Who is accountable when an employee-caused data breach triggers regulatory reporting obligations?
- Why do CPRA obligations create more risk for businesses that use targeted advertising and consumer profiling?
- Why do authorised employee actions still create ransomware and data theft risk?
- Why can encrypted data still create reporting obligations after a breach?
