The Copay problem: Where HIPAA ends and PCI DSS begins

Hackers hitting a hospital also go after patients' card numbers. Here is what PCI DSS v4.0.1 asks of digital health teams and what real cases show about where they fall short.

On May 20, 2025, a ransomware attack took down systems across all 14 medical centers of Kettering Health in Ohio. Scheduled procedures were cancelled, emergency departments went on diversion and staff went back to pen and paper. Within hours, scammers started calling patients. They posed as Kettering staff and asked for credit card payments for medical bills. Kettering had to announce that it would stop taking payments over the phone until further notice (The HIPAA Journal).

That detail stays with me. The attack began as a clinical crisis and within a day it had become a payment fraud problem aimed at the same patients.

Healthcare technology teams usually split data protection into two lanes: HIPAA for clinical records and PCI DSS for the checkout page. Patients don't experience it that way. A patient who opens a portal at night to read lab results and pay a $150 copay is trusting one platform with their medical history and their financial identity at the same time.

I work as a HIPAA Privacy and Security Officer for US pharmacies, clinics, nursing homes and home health providers and that overlap is where I spend most of my time.

Why healthcare is a target

Healthcare has become one of the most attacked sectors. According to The HIPAA Journal's 2025 Healthcare Data Breach Report, large breaches have levelled off at 700 to 750 a year, about two a day. At least 61.5 million people had their health information exposed in 2025. The report also cites BlackFog data showing that healthcare accounted for 22% of confirmed ransomware attacks in 2025, more than any other sector.

The data stolen in these incidents often goes well beyond clinical records. Breach notices across 2025 list payment card numbers and financial account details next to diagnoses and insurance information. A portal that collects both hands attackers two valuable datasets in one breach.

The line that matters most: cardholder data vs. sensitive authentication data

PCI DSS divides payment data into two classes with very different rules.

Cardholder data (CHD) covers the Primary Account Number (PAN), cardholder name, expiration date and service code. You may store PAN only if it has been made unreadable through strong cryptography, truncation, tokenization, or one-way hashing.

Sensitive authentication data (SAD) covers full track data from the stripe or chip, the CVV/CVC code and PINs or PIN blocks. You may not store SAD after authorization, not even encrypted. Once the gateway returns an approval or a decline, it has to be gone.

Teams sometimes assume that a card number and expiry date on their own are low-risk. A UK court recently disagreed. In DSG Retail v Information Commissioner (February 2026), malware on the retailer's systems had captured data from more than 5.6 million payment cards, mostly just PANs and expiry dates. The Court of Appeal held that the retailer's duty to protect that data applied even though the attackers couldn't link the cards to named people (Inside Privacy). The case was decided under UK data protection law, not PCI DSS, but the logic is the same: what matters is what the data means to you, not what an attacker can do with it.

A related mistake is assuming that encryption takes a system out of scope. Under PCI DSS v4.0.1, any component that decrypts card data, manages the keys, or routes encrypted card data remains in scope.

The 12 requirements, grouped into six goals

1. Build and maintain a secure network. Deploy network security controls and remove vendor default passwords.
2. Protect account data. Encrypt stored cardholder data and protect PAN sent over public networks.
3. Manage vulnerabilities. Defend against malware, patch promptly and code securely.
4. Control access. Limit access to people with a business need, enforce MFA and secure physical sites.
5. Monitor and test. Log all access to cardholder environments, review the logs and run regular penetration tests.
6. Keep an information security policy. Maintain formal policies, risk assessments and vendor oversight.

The browser is now part of your attack surface

Few healthcare portals build their payment processing from scratch. They embed third-party payment frames, tag managers and analytics scripts. Each of those scripts runs inside the patient's browser and each one can see what the patient types.

Healthcare has already learned this through tracking pixels. Blue Shield of California reported a breach affecting 4.7 million people that involved tracking tools on its website sending information to third parties such as Meta and Google. Catholic Health System and Northwell Health have settled class actions over pixels on their sites (The HIPAA Journal). Card skimming works through the same route, except the attacker is the one receiving the data.

PCI DSS v4.0.1 addresses this with two requirements:

• 6.4.3: Keep an inventory of every script on your payment pages, with each one authorized and justified and confirm its integrity using tools such as Content Security Policy (CSP) or Subresource Integrity (SRI).
• 11.6.1: Use automated change and tamper detection on payment page scripts and HTTP headers, so that unauthorized changes trigger an alert.

Privacy regulators are moving in the same direction. When California's privacy agency fined PlayOn Sports $1.1 million in 2026, the settlement required regular scans to inventory tracking technologies (Hunton). Whether the rule comes from PCI, HIPAA, or state privacy law, the expectation is the same: know every script running on your pages.

Where teams trip up

They don't watch the logs. Between 2018 and 2022, attackers repeatedly logged into Warby Parker customer accounts using passwords stolen from other sites. The exposed data included names, addresses, prescription information and some payment card details for nearly 198,000 people. OCR found that Warby Parker had failed to conduct an accurate risk analysis, to reduce risks to a reasonable level and to regularly review system activity. It imposed a $1.5 million penalty (HHS). MFA and log review, PCI Goals 4 and 5, are aimed at exactly this kind of attack.

They skip or rush the risk analysis. According to The HIPAA Journal, 76% of OCR enforcement actions in 2025 included a penalty for risk analysis failures. PCI DSS v4.0.1 also relies on documented risk analysis for many of its controls. A single, honest analysis covering both ePHI and card data serves both frameworks.

They treat vendors as someone else's problem. In 2025, 35.8% of reported healthcare breaches happened at business associates. The payment processor, the portal vendor and the analytics provider are all part of your risk.

They let marketing scripts onto authenticated pages. This is how the pixel cases started and it's the gap 6.4.3 is meant to close.

From annual scramble to business as usual

PCI DSS v4.0.1 expects payment security to run as a continuous cycle: assess, remediate, report, then monitor and maintain. Pair that cycle with Zero Trust principles (verify every access request, enforce least privilege, log every data access) and you can protect card transactions and medical records under one defensive posture instead of two.

The bottom line

Kettering's patients didn't care which framework their data fell under. They needed their care restored and their card numbers kept away from scammers. Compliance isn't the goal. Patient trust is. When product and security teams build PCI DSS controls into everyday development, compliance stops being a yearly crisis and becomes what naturally happens on a platform designed to protect people.