Skip to main content
August 17, 2015

Breaking Down HIPAA, PCI DSS and Third-Party Risk Management

Breaking Down HIPAA, PCI DSS and Third-Party Risk ManagementIf a problem or process is best served by its own named department, chances are it's pretty important.

Take compliance. While your company may or may not employ its own dedicated team of industry regulation experts, there's a good chance some product you build or service you offer brushes up against a set of outside rules — and if not, that the code or infrastructure you hire a third party to develop or maintain most certainly does.

The shrinking gap between third-party risk and first-party accountability is a serious area of concern in the compliance world, and with good reason: It's usually up to the first party to atone for the third party's sins, a fact that holds true whether you're talking intangible negatives (such as reputation) or very tangible ones (such as potential sanctions from regulatory bodies). By starting at the top when they assign responsibility for a mishap, regulators, spurned users and other related parties have a place to lay the blame when problems arise. What's more, it cuts back on the creative buck passing that'd undoubtedly happen if third parties shouldered the blame alone.

Keeping that in mind, here's a look at a two widely followed sets of regulations and what they have to say about the expanding world of third-party risk and security.


The Health Insurance Portability and Accountability Act (HIPAA) keeps patients' information on lockdown, giving first- and third-party entities alike a set of encompassing guidelines to follow when they handle what the Act calls PHI: Protected Health Information. Breaches — most of which center on the misuse or negligent treatment of PHI — can result in fairly stiff monetary penalties, giving organizations under HIPAA's purview even more reason to get secure.

That's especially true in the wake of recent changes to the act, which, according to The Privacy Advisor, place "renewed emphasis . . . on vendor security management." Working with a vendor that handles protective information in any capacity can result in the first party being held liable for mistakes — a big shift in the rules that mostly said the opposite prior to the change.

In practical terms, effectively handling data means thoughtful management of third-party risk from the start. While the nitty-gritty rules get dense really fast, the high-level gist is that first parties must have a good idea of what their vendors are doing with regard to security, and be able to prove frequent testing of those data-management capabilities. That's especially true with third parties like cloud storage providers, given the Act's focus on vendors that keep (as opposed to those that simply transmit) data.

Obtaining that information largely depends on what roles a vendor performs. Giving access-control measures serious thought is a good idea here, as is knowing (and documenting) exactly what will happen with stored data in the event of a contingency situation, such as the third party closing its doors or the sudden dissolution of the relationship. Testing a vendor's competence may also be wise, depending on its function.


In a world where credit card data is the most valuable information of all, regulations like the Payment Card Industry Data Security Standard (PCI DSS) are critical. Now on its third iteration, the rules recently added specific notes on handling third-party risk and effective vendor relationship management. As with HIPAA, a big part of satisfying its conditions comes down to extensive documentation and the vetting of vendors.

One secret to solid management, the standards say, is to craft a detailed agreement of all security-related functions at the beginning of the relationship. This gives both sides room to future-proof the vendor's contribution by defining roles and responsibilities from the onset, and encourages the use of transparency agreements, which give first parties tools for continued third-party risk monitoring.

The end result is equal parts risk prevention and covering yourself. By thoroughly vetting candidates and continually monitoring their security efforts, first parties can show investment in security while boasting an effective solution for motivating their vendors from a security standpoint. Then there are the direct benefits: Errors caught earlier are quicker and less expensive to fix, resulting in a cheaper, more secure product.

The PCI DSS may not be as restrictive or punitive as HIPAA, but it isn't meant to be. Simply putting an emphasis on third-party risk is enough for an organization with such clout to affect major changes in the industry's security practices — a smart move, considering how valuable that data can be.

Comply Secure

Compliance isn't something you prepare for right before audit time — it's a full-time responsibility. If you'd like to get your adherence to the rules and regs in line, check out CA Veracode's resources, or ask for a little expert help.

Photo Source: StockSnap

Evan Wade is a professional freelance writer, author, and editor from Indianapolis. His time as a sales consultant with AT&T, combined with his current work as a tech reporter, give him unique insight into the world of mobile/Web security and the steps needed to properly secure software products. Follow him on Twitter.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.