Healthcare organisations should map each data flow to determine whether it is protected health information or separate personal information subject to CPRA. PHI may remain exempt, but employee data, website data, and other non-PHI records still need CPRA notices, rights handling, and opt-out processes. The practical test is scope, not entity status, so governance must follow the data, not the business label.
Draw the boundary by data flow, not by organisation type
The cleanest way to separate HIPAA-covered information from CPRA-governed personal information is to classify each dataset and workflow at the point of collection, storage, transfer, and disclosure. A healthcare provider can hold both at once: PHI may sit inside clinical systems, while employee records, marketing records, portal telemetry, and website identifiers remain subject to CPRA because they are personal information outside the HIPAA covered use case.
The practical consequence is that one legal regime does not cancel the other. Teams often fail when they apply a single enterprise label, such as “we are a healthcare organisation,” instead of tracing which systems actually store, process, or share each record type. The boundary is created by the data relationship and use context, not by the brand or business unit.
That is why governance should maintain an inventory that distinguishes clinical data stores, workforce systems, consumer-facing systems, and third-party integrations. This is a data governance problem first, and a compliance problem second. For organisations trying to operationalise both regimes, the strongest control is a data map that shows where PHI ends and CPRA-covered personal information begins.
Operational controls that keep HIPAA and CPRA obligations from colliding
Once the boundary is defined, the next task is to make sure each system carries the right notice, rights handling, retention, and disclosure logic. HIPAA workflows may prioritise minimum necessary access and permitted use, while CPRA workflows may require notice at collection, access and deletion handling, correction pathways, and opt-out support where applicable. A single source record can still need both handling tracks if it feeds different workflows.
This is where classification errors become expensive. If a workforce or web-data stream is mistakenly treated as PHI, CPRA notices and consumer rights may be missed. If PHI is mistakenly treated as ordinary personal information, teams can over-disclose or over-respond in ways that create avoidable compliance and privacy risk. The control objective is consistent scoping, then policy branching based on that scope.
For practitioners, the most useful pattern is to make the data inventory actionable: tag systems by data category, document the legal basis or permitted purpose, and connect each category to the correct request-handling and disclosure workflow. Where the same platform serves both clinical and non-clinical use cases, the system should not inherit one privacy regime wholesale. Instead, the workflow should split by record type and business purpose.
NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives reinforces the broader governance lesson: auditability depends on being able to show which records are under which control model, not simply that the organisation has a policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 — Organizational Context | Sets governance based on business context and data use, which supports scoping HIPAA and CPRA handling by workflow. |
| GV.2 — Risk Management Strategy | Supports deciding different controls for PHI and CPRA data based on legal and operational risk. | |
| GV.5 — Roles, Responsibilities, and Authorities | Relevant because privacy scoping needs clear ownership across legal, privacy, security, and operational teams. | |
| Recommendation — Document data categories and business contexts so privacy controls follow actual processing scope. Assign separate risk treatments for clinical data and other personal information. Define ownership for data classification, consumer rights handling, and disclosure decisions. | ||
| CIS Controls v8 | 3 — Data Protection | Directly supports classifying sensitive data and applying the right handling rules to different data sets. |
| 5 — Account Management | Relevant where different identities and access paths govern clinical records versus employee or consumer records. | |
| 6 — Access Control Management | Supports limiting access according to the specific data class and permitted purpose. | |
| Recommendation — Classify data stores and apply distinct handling controls for PHI and personal information. Separate access paths so workforce and consumer data are not governed as a single dataset. Enforce access rules by data category and processing purpose, not by organisational label. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Useful where consumer or workforce requests require confidence in the requester before rights are fulfilled. |
| AAL — Authentication Assurance Level | Relevant to secure portals and request handling where stronger authentication reduces improper disclosure. | |
| Recommendation — Validate requester identity before fulfilling access, correction, or deletion requests. Require appropriate authentication strength for portals that expose personal or health-related records. | ||
Practitioner Guidance
What to verify: Confirm that your data map distinguishes PHI from non-PHI personal information at the workflow level, not just the application level. A patient portal, HR platform, analytics pipeline, or marketing tool can each carry different obligations even when they sit under the same corporate security stack.
Decision rule: If a record can support a HIPAA purpose, treat that as a scope question, then test whether the same record also feeds a CPRA-covered collection or processing purpose. When the answer is yes, build separate handling logic rather than assuming the stricter healthcare label resolves everything.
What practitioners underestimate: The hardest failures usually happen at the seams, especially when data moves into identity, HR, customer support, or web analytics systems. Those flows often contain personal information that is adjacent to care delivery but not part of PHI handling, so they need their own notices, rights response paths, and retention rules.
Practitioner takeaway: The durable model is to classify by data flow and purpose, then enforce different privacy controls by category. If you can explain why a record is PHI in one workflow and CPRA-covered personal information in another, your governance is probably aligned; if you cannot, the boundary is still too vague.
Related resources from NHI Mgmt Group
- How should organisations assess whether pseudonymized data is still personal data under GDPR?
- How should healthcare organisations classify data to determine what counts as PHI under HIPAA?
- How should organisations apply a risk-based approach when implementing cybersecurity controls for personal data under CPRA?
- How should organisations govern access to personal data under Quebec Law 25?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
