Is PCI DSS Compliance Enough?

In the wake of yet another massive data breach, media outlets around the world are asking a lot of questions.  More questions, it seems, than are the victims of the data breach.  People seem to have become numb to loss of sensitive data.  But while individuals seem to carry on as though nothing has changed, businesses need to be cognizant of the consequences of data breach, beyond simply the penalties associated with a violation of the PCI DSS.  The consequences of data breach can be swift and severe.  In fact, a class action suit has already been filed against Marriott stating that the breach should have been detected four years ago.  Further, companies that fall victim to hackers can expect to play host to government regulators, state attorney generals, forensic investigators and other third parties for a significant length of time. So what is a company to do to protect its data?

I once had a self-proclaimed “grey hat hacker” tell me, “your company has to find and fix every single hole in the environment.  I just need to find one.  And I’ll spend 24/7 to do it.”  That demonstrates the reality that data security in the online world, our world, can be a tremendous task.  However, as with all types of crime, there are methods that can be employed to increase the work factor for criminals in compromising your environment and to make your business a hard, or at least a harder, target.  Those criminals looking for just an “opportunity” may determine that there are easier targets and move on.

The most obvious step to be taken is compliance with the PCI DSS. The Standard has been in place since 2006 and serves as an excellent baseline of security.  All companies that store, process, or transmit cardholder data (or can otherwise impact the security of the transaction) must comply with the Standard.   Though compliance must be validated once a year, it is important to maintain compliance throughout the year through the implementation of a robust compliance monitoring program. It will require ongoing management to ensure that a company doesn’t inadvertently fall out of compliance without taking a corrective action.  Further, failing to comply can result in financial penalties. It’s important to note, though, that PCI DSS only applies to credit and debit card numbers.  Its scope does not include any other form of potentially sensitive information.

As we’ve seen from countless headlines this year, data breaches don’t just involve payment card numbers.  They often include data such as email addresses, usernames, passwords, physical addresses, social security numbers and other similarly sensitive data that aren’t contemplated by the PCI DSS.  What should companies do then?  Well, the PCI DSS still serves as a useful launching pad.  But before determining how far to extend those protections and controls enumerated in that standard, it helps to conduct and exercise known as a data inventory.

Simply put, a data inventory is an exercise in which each functional area of the company examines the data that it uses and why, how it’s collected, stored and shared, and how the data is destroyed or disposed of when it’s no longer needed.  These exercises can be eye-opening and are extremely useful.  It is not uncommon to unearth data collection or use practices that were not widely known in the organization.  These data knowledge gaps can lead to critical holes in the control environment, exposing companies to risks of which there were not even aware.  More importantly, it can help organizations make informed, risk-based decisions about the type of information that it collects (i.e. do we, as an organization, need to collect this data element to fulfill our business objectives?  If so, what types of protections must we afford that data?  Is it ultimately worth the investment?) Once the data inventory is complete, you may find it helpful to see how or if it is feasible to extend PCI DSS controls that are already in place to cover these additional data elements and the larger data environment.

Further, it may be discovered during this inventory, that the organization may have additional regulatory obligations as a result of the data it collects.  For example, is the company storing data related to healthcare, education, or financial accounts?  Doing the inventory can assist and support the organization in its regulatory risk assessment.  Proactively identifying potential compliance gaps is always better than having such gaps identified by auditors, regulators, or clients. If these additional regulatory obligations are discovered, it can be helpful to map controls between those PCI requirements that the organization is meeting to the newly identified regulatory requirements.  There will still be gaps to be addressed, but by extending the PCI DSS control environment, organizations may be able to significantly reduce the cost of expanding those protections to other forms of data and other data environments.

Granted, the discussion presented here is more nuanced and robust than the constraints of a blog post may allow, but it does provide us all food for thought.  If the only data that is possessed by an organization is payment card data, then perhaps PCI DSS compliance is sufficient protection.  However, such an organization, to use the popular language of the day, is something of a unicorn.  Most organizations host a wide variety of data – data that is regulated and data that a company may simply want to protect, such as proprietary code, formulas, or business plans.  For those organizations, compliance with PCI DSS is just the tip of the iceberg.  I’ll leave you with this direct quote from the PCI DSS v 3.2.1: “PCI DSS comprises a minimum set of requirements for protecting account data, and may be enhanced by additional controls and practices to further mitigate risks, as well as local, regional and sector laws and regulations. Additionally, legislation or regulatory requirements may require specific protection of personal information or other data elements (for example, cardholder name). PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements.”