CCPA still applies to many healthcare organizations, even when HIPAA covers the clinical side. If you run a hospital, health plan, digital health company, or vendor in California, your website data, marketing data, HR records, app telemetry, and tracking tools may still fall under CCPA.

Here’s the short version:

  • HIPAA and CMIA do not exempt your whole company. They exempt specific data, like PHI and certain medical information.
  • CCPA usually picks up the rest, such as web analytics, cookies, marketing lists, wellness app data, and employee data.
  • This is not just a legal footnote. California has already acted against healthcare groups over tracking and ad-related data use, including settlements of $4.2 million and $1.55 million.
  • Penalties add up fast: up to $2,500 per violation or $7,500 per intentional violation or one tied to minors. Data breach claims can also bring $100 to $750 per person, per incident.
  • CPRA added more work, including correction rights, sensitive personal information rules, and tighter limits on use and retention.
  • Your program needs clear workflows for access, deletion, correction, opt-out requests, GPC signals, vendor notices, and security controls for non-PHI data.
  • Vendors matter too. If ad tech, analytics, cloud tools, HR platforms, or wellness vendors touch California personal information, your contracts and review process need to reflect that.

If I had to sum it up in one line, it would be this: healthcare privacy compliance now depends on sorting data by type, system, and use case - not by assuming HIPAA covers everything.

To make that easier, this guide walks through:

  • when CCPA applies
  • what data is exempt and what is not
  • how patient, consumer, and employee rights differ
  • what CPRA changed
  • which request workflows healthcare IT teams should build
  • what “reasonable security” looks like for non-PHI data
  • how to handle third-party risk across your vendor stack

A simple way to think about it: your EHR may be exempt, but your website may not be.

When CCPA Applies in Healthcare

CCPA coverage turns on statutory thresholds, not HIPAA status.[14] In plain English: a healthcare organization can still fall under CCPA even if much of its data sits inside HIPAA-regulated systems.

A healthcare organization qualifies as a CCPA business if it does business in California and meets at least one statutory threshold:

  • Annual gross revenues over $25 million
  • Buying, receiving, selling, or sharing personal information at the statutory volume threshold for California consumers, households, or devices
  • Deriving 50% or more of annual revenue from selling consumers' personal information[14]

Many large health systems, national health plans, and digital health startups hit at least one of those marks. So healthcare IT teams need to map CCPA thresholds by entity, not by enterprise brand.

Which Healthcare Entities and Data Fall Under CCPA

Integrated delivery networks, regional hospital systems, large physician groups, telehealth companies, and life sciences organizations running patient engagement portals or trial recruitment sites can all qualify.[15][6][18] And CCPA defines personal information in broad terms: any data that identifies, relates to, or could reasonably be linked to an individual or household.[15][6][20]

For healthcare organizations, that often means more than medical records. It can include website analytics, marketing data, HR data, wellness program data, and consumer app telemetry.[17][21]

That’s why CIOs and chief AI officers should inventory:

  • Subsidiaries
  • Joint ventures
  • Branded digital properties

The goal is to figure out which ones independently meet CCPA thresholds and need their own notices, workflows, and contracts.[17][6]

Once scope is clear, the next step is matching each data type to the right notice and response workflow.

How CCPA Rights Differ Across Patients, Consumers, and Employees

The same person can show up in your data ecosystem in more than one role, and CCPA rights depend on that context.[12][5] Someone may be a patient in EHR data, a consumer in web and app data, and an employee in HR data. Same person, different treatment under CCPA.

A patient’s clinical record maintained as PHI is exempt. But that same person’s activity on your marketing website or in a wellness app is not.[12][5][8]

That creates a practical split across systems. Your EHR, CRM, HRIS, and consumer websites and apps do not carry the same duties. Website visitors and app users are entitled to notices at collection, opt-out mechanisms where needed, and timely responses to access, deletion, and correction requests.[15][18][20] Employees and job applicants are covered too; the temporary employment exemption expired on December 31, 2022.[15][13]

CPRA then raised the bar by adding sensitive personal information and correction rights.

What CPRA Changed for Healthcare Privacy Programs

The biggest day-to-day shift is the introduction of sensitive personal information as its own category.[16][10][20] This includes precise geolocation, racial or ethnic origin, biometric data, and health-related data and inferences.[16][7]

That last piece matters. Wellness app data and AI-derived health inferences can move into a higher-protection tier, which means tighter limits on use, disclosure, and retention.[20][7]

CPRA also added the right to correct inaccurate personal information. It also gave consumers the ability to restrict how sensitive personal information is used beyond what is necessary and proportionate.[20][7] So systems holding health-adjacent sensitive personal information, such as workforce analytics tools and wellness apps tied to employer programs, now need correction and restriction workflows.[19][20]

The California Privacy Protection Agency can bring independent enforcement actions. That means documented compliance is now expected, including data mapping, risk assessments, and reasonable security controls.[16][7][21]

With scope and rights defined, the next issue is how CCPA aligns with HIPAA and CMIA exemptions.

How CCPA Intersects with HIPAA and CMIA

CCPA vs. HIPAA vs. CMIA: Healthcare Data Privacy Comparison

CCPA vs. HIPAA vs. CMIA: Healthcare Data Privacy Comparison

Once you’ve mapped user rights, the next step is to split exempt clinical data from CCPA-covered operational data.

CCPA's healthcare exemption is data-specific, not entity-specific: only PHI and CMIA medical information handled under HIPAA or CMIA rules are exempt.[22][4][1][5]

That distinction matters more than it may seem at first. A hospital, health plan, or vendor might handle some data that sits outside CCPA and other data that falls squarely inside it. So the line is not drawn at the company level. It’s drawn at the data level.

What Is Exempt and What Is Not

CCPA expressly exempts PHI collected or maintained by a HIPAA covered entity or business associate in accordance with the HIPAA Privacy, Security, and Breach Notification Rules.[1][5][2] It also exempts medical information under CMIA - individually identifiable information about a patient's medical history, conditions, or treatment held by providers, health plans, or their contractors. Managing these third-party risks is critical for maintaining compliance across both HIPAA and CCPA.[1][5][24][4]

There’s also a narrow same-manner exception. In plain English, some patient data may be exempt when it is handled with PHI-equivalent controls.[5][24][25][4][26] This can come up in certain care-management tools or ancillary patient support programs tied into clinical workflows. But this is a tight carveout, not a blanket pass.

On the other hand, marketing, web-tracking, wellness, and HR data will usually still fall within CCPA scope.[3][8][9] That’s where many teams get tripped up. The same organization may run a patient portal under one set of rules and a marketing site under another.

Deidentified data can sit outside both regimes, but the tests are not the same. HIPAA and CCPA each use their own standard.[23][28][29] And CCPA still bars reidentification except where the law allows it.[23][28][29] If that data is reidentified for operational use, it can move back into HIPAA or CCPA scope.[8][23]

CCPA vs. HIPAA vs. CMIA: A Side-by-Side Comparison for Healthcare IT

Regime Data Covered Who Is Covered Key Healthcare Exemptions
HIPAA PHI: individually identifiable health information created or received in connection with care, payment, or operations Covered entities and their business associates PHI collected or maintained in HIPAA-regulated contexts is exempt from CCPA
CMIA Medical information: individually identifiable data about a patient's medical history, condition, or treatment California health care providers, health care service plans, and their contractors CMIA medical information is separately exempt from CCPA
CCPA/CPRA Personal information and sensitive personal information about California residents, including health-related data that is not PHI or CMIA medical information Businesses that meet CCPA thresholds and do business in California PHI, CMIA medical information, and patient information maintained with PHI-equivalent controls

Use this split to route requests and controls by system, not by enterprise.

HIPAA and CMIA are relationship-based. They follow the clinical or plan relationship. CCPA works more like a consumer privacy law, reaching data types and business activities that HIPAA and CMIA were never built to cover.[8][9][11]

The enforcement picture is split too. HIPAA is enforced by HHS/OCR. CMIA falls to California regulators. CCPA enforcement sits with the California Privacy Protection Agency and the Attorney General.[8][9]

Putting CCPA Rights and Security Controls into Practice

Knowing what is exempt and what is not gets you only part of the way. The next step is the day-to-day work: setting up systems that can handle consumer rights requests the same way every time, within the deadline, and across every place where CCPA-covered data lives.

Build Workflows for Access, Deletion, Correction, and Opt-Out Requests

Put access, deletion, correction, and opt-out rights into day-to-day workflows. Treat non-discrimination differently: it belongs in policy and staff rules, not in a request queue.

Every request starts with intake. Give people more than one way to reach you, such as:

  • a web form
  • a dedicated email address
  • a toll-free number
  • a portal option

Each channel should be plainly listed in your privacy notice. Once a request comes in, log it in one central ticketing or case management system. Send an acknowledgment within 10 business days and provide the full response within 45 calendar days. You can use one 45-day extension if you give notice.[37][39][41][35] A simple rule helps here: one intake path and one case record for each request.

Verification needs to happen fast, because it does not pause the 45-day deadline.[34][38][40][41] For access and deletion requests, match the person to known identifiers like email, phone, or portal login. When possible, add a second factor. Opt-out requests are different. The burden is lower, so the process should be low-friction. Accept opt-out methods that do not require account creation, including GPC, and honor Global Privacy Control (GPC) signals.[15][31][32][33][34]

After identity is confirmed, the search begins. Your data inventory should point to the systems that hold CCPA-covered data for that person across EHR-adjacent, patient-facing, workforce, and marketing tools. That often includes CRM platforms, marketing automation tools, web analytics, patient portal metadata, HR systems, and wellness or fitness app connections.[34][35][13] PHI inside the EHR remains outside CCPA scope because HIPAA covers it. But that same person’s newsletter signup, cookie profile, and portal usage metadata may still fall within scope.[36][13] And when someone asks for deletion, your job is not limited to your own systems. You also need to tell service providers and contractors to delete the matching records.[30][16][33][13]

Opt-out requests need even tighter execution. In practice, compliance should happen as soon as feasibly possible and generally within about 15 business days, with downstream recipients notified in that same window.[31][32][34] If that sounds like a lot to do by hand, that’s because it is. Your opt-out flag should move through ad networks, analytics vendors, and other recipients by default, not through manual follow-up.

Map each request type to a standard playbook across CRM, portals, HR, and analytics.

CCPA Rights-to-Controls Mapping Table for Healthcare IT Teams

CCPA Right Data Inventory Requirement Identity Verification Key System Actions Required Records
Right to Know/Access Identify all CCPA-covered systems holding non-PHI and adjacent data for the individual Match known identifiers and use a second factor where feasible Generate data extracts from CRM, HR, analytics, and web platforms; exclude HIPAA-exempt PHI Request date, systems queried, data categories disclosed, response date
Right to Delete Map data across CRM, marketing, analytics, HR, and vendor-hosted tools Verify identity before deletion Soft-delete or anonymize records; send deletion instructions to service providers and contractors Decisions made, exceptions applied, downstream notifications sent
Right to Correct Locate inaccurate data across EHR-adjacent, workforce, and marketing systems Verify identity and review supporting documentation Update records centrally and trigger downstream syncs to connected systems Evidence reviewed, changes made, systems updated, response date
Right to Opt Out of Sale/Sharing Identify all third-party data flows, including ad networks and analytics vendors Use lighter verification; honor GPC signals without requiring account creation Apply opt-out flags and halt data flows to downstream recipients Opt-out receipt, systems flagged, recipients notified, date of compliance
Right to Non-Discrimination N/A N/A Ensure no service denial, price change, or quality reduction tied to rights exercise Related changes and decisions

Reasonable Security for Non-PHI and Adjacent Healthcare Data

CCPA’s private right of action is tied straight to security lapses. Statutory damages of $100 to $750 per consumer per incident may apply when unencrypted, unredacted personal information is accessed without authorization because reasonable security was missing.[42][44]

The California Attorney General has linked reasonable security to applicable CIS Controls.[42][43] In healthcare, that reaches beyond PHI. It applies to CCPA-covered data like web tracking data, CRM records, donor databases, employee monitoring data, and wellness app connections.

Many healthcare IT teams already run strong programs around PHI. The practical move is to extend those same habits to the non-PHI data sets covered by CCPA: encryption at rest and in transit, least-privilege access, audit logging, secure configurations, set retention limits, and written incident response procedures.[42][44][47][48] This is where teams can get tripped up. A patient chart may be locked down, while a website analytics stream or marketing sync gets far less scrutiny.

Regulators and HHS OCR have also pointed to online tracking tools on patient websites and apps as high-risk when health-related data flows to ad or analytics platforms, even when that data is not PHI.[45][46][47][48] The $1.55 million CCPA settlement with Healthline Media LLC over online tracking technology on a health information website shows what that risk can look like in practice.[27]

Document controls by data flow, system, and vendor. Those records matter most where data moves to vendors, ad platforms, and analytics tools.

Managing Third-Party Risk and Program Governance with Censinet

CCPA risk often shows up through vendors that handle California resident data outside the clinical record. In practice, that means your compliance exposure doesn't rest ONLY on your own systems. It also depends on how outside vendors collect, use, store, and pass along nonclinical data. So the first gate is simple: classify the vendor correctly and lock down the contract language.

Third-Party Risk Controls Healthcare Organizations Should Document

A repeatable vendor risk workflow is the starting point. Before you onboard any vendor that touches California resident data, document:

  • what categories of personal information the vendor receives
  • why the vendor receives that data
  • whether the vendor qualifies as a service provider or contractor

That classification shapes the contract terms you need.

California regulations require service provider and contractor agreements to spell out the specific business purposes for processing personal information. Generic services language isn't enough.[51][52][55] Contracts should also require vendors to comply with CCPA/CPRA and permit compliance verification. They should ban sale or sharing, limit secondary use, require security controls, and set rules for deletion or return of data at termination.[51][20][53][57] For contractors, CPRA interpretations also let businesses use ongoing reviews, scans, audits, or technical testing to verify compliance.[54][56]

Contracts give you the baseline. Ongoing review is what keeps that baseline from going stale.

The highest-risk vendors are often the ones outside the clinical record. Think tracking technologies, marketing databases, CRM systems, consumer engagement platforms, cloud services, AI tools, employee-facing SaaS applications, and health-adjacent tools that mix regulated and nonregulated data.[53][58] That's where things can get messy fast. One healthcare vendor-risk report found that 85% of practices experienced an operational disruption from a third-party vendor or vendor-of-vendor failure in the past 12 months.[49][50] So vendor risk can't sit as a one-time legal checkpoint. It needs to work as an active control.

Ongoing monitoring should include annual reassessments for higher-risk vendors, review of subprocessor changes, and a clear remediation tracking process that records findings, corrective actions, due dates, and closure evidence. If a vendor adds new tracking pixels or expands retention, that should trigger an immediate review.

How Censinet RiskOps™ Supports CCPA Risk Management

Censinet RiskOps™ gives teams one place to manage vendor questionnaires, standardize assessments, and track remediation across legal, IT, security, and procurement. It's built for healthcare, where CCPA governance overlaps with PHI, clinical applications, medical devices, and healthcare supply chain security challenges.

The main upside is a repeatable audit trail for assessments, risk ratings, mitigation plans, and executive reporting. Censinet AI™ can speed up questionnaires, evidence summaries, and risk reports with human oversight. That matters because automation can save time, but risk teams still need the final say. With configurable rules and review workflows, teams keep control while cutting some of the grunt work.

The table below maps those capabilities to the CCPA obligations they support.

Censinet Capability-to-Obligation Table

CCPA-Related Need Censinet Capability
Third-party vendor assessments and classification Censinet RiskOps™ - standardized, healthcare-specific risk assessments
Enterprise-wide governance and cross-team coordination Censinet One™ - on-demand risk management for enterprise-wide coordination
Secure vendor collaboration and information exchange Censinet Connect™ - shared vendor risk assessments across the network
AI-assisted evidence review, questionnaire completion, and risk reporting Censinet AI™ - accelerates assessment workflows with human oversight
Executive reporting on third-party risk posture Censinet RiskOps™ command center - risk visualization and benchmarking dashboards

FAQs

How do we tell which data is exempt from CCPA?

Healthcare organizations should keep PHI covered by HIPAA separate from other personal data. That line matters.

Under CCPA, PHI handled by HIPAA-covered entities or business associates for treatment, payment, or healthcare operations is exempt. But not all data a healthcare company touches falls into that bucket.

That’s where a data classification system helps. It can tag data as:

  • HIPAA-only
  • CCPA-only
  • Dual-regulated

In practice, medical records and clinical data are usually exempt from CCPA. On the other hand, website analytics, newsletter email addresses, and patient satisfaction survey feedback still need to meet CCPA rules.

It helps to think of it this way: just because an organization is in healthcare doesn’t mean every piece of data it collects is treated like a medical record.

Does CCPA apply if our organization already follows HIPAA?

Yes. CCPA can still apply even if your organization complies with HIPAA.

The key thing to know is that the HIPAA exemption applies to Protected Health Information (PHI). It does not give your whole organization a free pass from CCPA.

That means CCPA may still apply to data that falls outside PHI, including:

  • website analytics
  • marketing data
  • employee records
  • survey responses

If your organization meets the required business thresholds, those non-PHI data sets can still fall under CCPA. So even with HIPAA compliance in place, you may need separate compliance steps for non-health data.

What should healthcare IT teams fix first for CCPA?

Start by clearly separating PHI from other personal data. A data classification system helps keep PHI under HIPAA rules, while other personal information is managed under CCPA.

Then keep an up-to-date inventory of systems, devices, and vendors. From there, assess risks and gaps, enforce access controls, and automate repeat compliance work and breach response so you can meet deadlines like the 45-day window for consumer requests.

Related Blog Posts