It’s day one on the job, and you work at a healthcare company that accepts credit cards. This means you’ve likely heard a lot about HIPAA and PCI DSS, and it’s not even lunchtime yet. Both of these are incredibly important security frameworks that are going to be essential to your work.
Today, we’ll visit what each framework is for, how they differ, where they’re the same, and what we have to do to reach compliance.
Right from the beginning, you should know that HIPAA is a federal law. It was signed into law by Congress in 1996, and it’s enforced by the Office for Civil Rights. Fines start at $141 per violation and can reach $2.1M per violation type. HIPAA is taken very seriously. In fact, if someone intentionally mishandles patient data, they could face jail time.
PCI DSS, on the other hand, is an industry framework that’s put in place by the payment card brands like Visa and Mastercard. There’s no law that says you must follow PCI DSS. Failure to do so, however, can result in fines from your bank starting from $5K to $10K, increasing all the way to $100K if you’re slow to respond to the issue. The ultimate penalty for failure to comply is that you’ll be cut off from accepting credit cards entirely. So while it’s not a law, the consequences to your company could be quite severe.
HIPAA focuses on PHI, Protected Health Information. These are things like identifiable patient information (such as the patient’s name), diagnosis information, and billing information. This definition is pretty broad, mostly because of how vast and interconnected healthcare data is. What this means in practice is that you’re often left to make a judgement call on what’s “reasonable and appropriate” security for the data at hand. PCI, on the other hand, is very prescriptive about what data is covered.
PCI is focused on cardholder data. These are things like the 16-digit PAN (Primary Account Number), expiration date, and especially the CVV code. In addition to being very detailed on what data is covered, PCI is also very prescriptive. PCI tells you exactly how to configure your firewall, which encryption algorithms to use, and enforces daily log audits.
There’s a good chance that you’re reading this article because your company needs to comply with both. For example, you’re a telehealth platform processing copays, or you’re a medical device company with a subscription model.
Being HIPAA compliant doesn’t make you PCI compliant, or vice versa. Both frameworks put a different emphasis on different aspects of data security. For example, HIPAA’s risk analysis requirement goes way beyond PCI’s checkbox approach, while PCI’s network segmentation requirements are much more specific than HIPAA’s vague “technical safeguards” requirement.
This gets a tad more involved when you start thinking about your actual operations in the cloud. For example, your Kubernetes pods need network policies strict enough for PCI’s segmentation requirements and comprehensive logging for HIPAA’s audit controls.
So, how should you think about this? In general, HIPAA covers more data but in a less strict manner; meanwhile, PCI is more strict, but with a smaller subset of data. Accordingly, being both HIPAA and PCI compliant requires broad security and strong security. Practically speaking, complying with both means closely following PCI’s prescriptive checklist, while keeping in mind HIPAA- specific requirements like the “risk analysis”.
HIPAA’s Security Rule mandates three categories of safeguards: Administrative Safeguards, Physical Safeguards, and Technical Safeguards. Admin safeguards are the policies, procedures, and actions to manage security. Physical safeguards protect the physical facilities and equipment. Technical safeguards are the technology controls that need to be put in place. This last category of technical controls is what we care about most here.
HIPAA’s technical safeguards range from authentication to encryption.
HIPAA also requires a “comprehensive risk analysis”. This isn’t a pentest or vulnerability scan. Rather, it’s a formal assessment of every threat to ePHI in your environment. Even if you’re in compliance with all of the previous technical controls, if you don’t have the Risk Analysis, you’re not fully compliant with HIPAA.
PCI DSS v4.0 gives you 12 requirements with hundreds of sub-requirements. Here's what actually moves the needle:
Segmentation is the cardinal rule for network security in PCI compliance. Any systems that contain cardholder data are considered a Cardholder Data Environment (CDE). The CDE must fully comply with PCI requirements. What this means in practice is that teams typically try to keep the CDE as small as possible in order not to burden the rest of their infrastructure with PCI requirements. For example, PCI requires a formal firewall configuration review every six months. This becomes much easier if your CDE is a tightly confined subset of your overall infrastructure.
When it comes to data protection, PCI DSS draws hard lines in the sand. Sensitive authentication data like CVV codes, PINs, or magnetic stripe data must never be stored after authorization. I've seen companies try to argue they need it for "customer convenience". Don't be that company. This data should never be stored by a non-payment processor. Not encrypted, not hashed, not “just for 24 hours”, not console logged for debugging, nothing. The rest of the card’s information, such as the Primary Account Numbers (PANs), can be stored, but you can only display the first six and last four digits at a maximum.
Requirement 10.6.1 mandates a daily review of security logs. Daily log reviews sound excessive until you realize automated alerts count. Set up proper monitoring and let your SIEM do the heavy lifting. Additionally, there are two scanning requirements. Every quarter, you'll need vulnerability scans from an Approved Scanning Vendor (ASV), and annually, you're looking at full penetration testing.
Version 4.0 brought some significant changes that reflect the current threat environment. Password requirements jumped to 12 characters minimum, and MFA is now required for all CDE access, not just administrative functions.
If you’re reading all of this and thinking it’s a huge hassle, you’re right. An alternative is to use a payment processor, and let them handle this complexity. With this method, when the customer enters their card information on your checkout page, that information is sent directly to your payment processors. This means it never touches your servers. Your payment processor returns a token that looks like "tok_1234567890”. This isn’t considered cardholder data. You store that token as a way to reference this particular card that was used without having the burden of PCI.
Alternatively, you can use network tokens, which are tokens that represent a PAN, issued directly by the payment network. Network tokens are versatile and are ideal for organizations that need to use multiple payment processors across different geographies.
The best way to wrap your head around HIPAA and PCI DSS is to understand the fundamental philosophy behind each framework. HIPAA asks you to think like a risk manager, constantly evaluating threats and implementing appropriate controls. PCI DSS hands you a detailed blueprint and expects precise execution.
Your architecture decisions today will echo through years of audits and security reviews. Start with the strictest requirements (usually PCI's prescriptive controls), layer in HIPAA's broader protections, and document everything. When in doubt, remember that both frameworks exist for the same reason: protecting sensitive data from ending up in the wrong hands. Get that right, and the compliance certifications will follow.
