Why do you need to comply with PCI if you’ve already taken care of HIPAA?

Tod Ferran, CISSP, QSA
By: Tod Ferran
Some are required to comply with both HIPAA (Healthcare Information Portability and Accountability Act) and the PCI DSS (Payment Card Industry Data Security Standard), namely, covered entities and business associates that accept credit, debit, or other payment cards. Many believe if they are compliant with one, it covers the other. Those people are mistaken.
HIPAA logo and PCI DSS logo

HIPAA and PCI are two distinct and different sets of requirements. Each is specifically designed for different types of information. HIPAA was designed by government committees trying to protect citizen data. PCI was designed by a private industry to reduce fraud-related costs regarding loss of card data.

The PCI standard

The PCI standards have gone through several clarifying iterations that create the current set of PCI requirements. These requirements are generally very specific and focused.

The HIPAA standard

Conversely, HIPAA regulations, even though they’ve existed for about as long, haven’t gone through a single iteration. Because they were created without a sound basis of the types of technology required to secure patient data, these standards are vague. Even after a thorough examination of the standard, it’s difficult to know what really must be implemented to meet each requirement.

While there is some overlap between the two, it is surprisingly not as much as one might expect.

Let me give an example.

HIPAA regulations never mention the word ‘firewall’ and instead include vague language such as “implement technical security measures to guard against unauthorized access...” What does that mean? Experienced security personnel can connect the dots and know it likely means firewall implementation. Covered entities, their office staff, and even lawyers probably wouldn’t be able to come to that conclusion on their own. On the opposing side, PCI has an entire section devoted to firewalls including frequency of firewall rule review, inbound/outbound restrictions and so forth.
For those who learn best by cold hard facts and statistics, here are numeric comparisons to help clarify the disparity between HIPAA and PCI.

Each requirement usually requires multiple validation points. A validation point is specific evidence needed to support the appropriate implementation of the requirement. For example, interviewing management and reviewing policy documentation are two different validation points.

HIPAA at a glance

  • The Security Rule contains 75 requirements with 254 validation points
  • The Breach Rule contains 10 requirements with 26 validation points
  • The Privacy Rule contains 72 requirements with 255 validation points

PCI at a glance

  • PCI DSS 2.0 contains 292 requirements with 1030 validation points

Overlap between HIPAA and PCI

  • 0 of 281 HIPAA Breach Rule/Privacy Rule validation points covered in PCI
  • 70 of 254 HIPAA Security Rule validation points covered in PCI
  • 316 of 1,030 PCI validation points are covered in HIPAA
I find that HIPAA assessors who have not performed PCI assessments typically don’t hold the overlapping HIPAA requirements to the higher, specific standards that a PCI assessor would.

The point is, if you are required to comply with both PCI and HIPAA mandates, you should understand they are distinct and require mostly different security procedures and protections. Just because you’re compliant with HIPAA, doesn’t mean your card processes are secure, and vise versa.

Was this post helpful? If so, please share!

Tod Ferran (CISSP, QSA) is a Mensa aficionado, Cancun expert, and Security Analyst for SecurityMetrics with over 25 years of IT security experience. In addition to his many speaking engagements and webinars, he provides security consulting, risk analysis assistance, risk management plan support, and performs security, HIPAA, and PCI compliance audits. Connect with him for recommendations on excellent places to stay, activities, and restaurants in Cancun, or check out his other blog posts here.