According to the National Conference of State Legislatures (www.ncsl.org), “forty-five states, the District of Columbia, Puerto Rico, and the Virgin Islands have enacted legislation requiring notification of security breaches involving personal information”[1]. That's right, only five states (Alabama, Kentucky, Mississippi, New Mexico, and South Dakota) have not enacted laws that fall into this class, but rest assured, they most likely will. These laws are primarily used as a vehicle to prosecute companies that are irresponsible with their residents' data. In most cases, the laws do not limit themselves to companies that have physical locations in their state, but instead focus on the resident. In other words, if you do not have a store in Montana, but someone from Montana does business with you and you lose their information, you are required to follow the process in their law (Mont. Code Section 30-14-1701 et seq., 2009 H.B. 155, Chapter 163). Neither author is a lawyer, so understand that you should perform a formal risk analysis (if you have not already) on these laws to understand what your liability is, and where they fall.

Dealing with this many institutions seems like a horrible prospect, especially if you ever spend time reading any of these regulations – they are an insomniac's saving grace! But there are some commonalities that most of the regulations share that are relevant for comparison with PCI.

As of this writing, the ISO27000 series (www.27000.org) are devoted to Information Security. For those of you who are not new to Information Security, you may remember BS7799 or ISO17799 as security framework standards that you may have assessed against. Those have been updated and are now part of the ISO27000 series of standards. Those standards are as follows:

More standards and documents are still under development, but for the purposes of this book, we will only focus on ISO27002 which most closely represents commonalities with PCI as an information security framework. According to the framers of PCI DSS, they will informally tell you that ISO17799 was a significant consideration when developing PCI DSS, and in fact, if you review the last iteration of Visa's Cardholder Information Security Program (CISP) you will see an even closer relationship with ISO17799.

At a high level, ISO27002 has 12 domains (PCI DSS has six domains, 12 requirements). Those are as follows:

At first glance, you will notice several things that are unique to ISO27002 not included in PCI DSS. ISO27002 is an information security standard and framework, where PCI DSS only concerns itself with one specific type of data, cardholder data. Most experts agree, if you have a mature ISO27002 program, PCI is eezy-cheezy.

Let's take a moment to explore what ISO27002 will give you that PCI DSS will not. ISO27002 details a process for risk assessments, while PCI just requires that they are performed in various parts of the standard. ISO27002 gives much more guidance to Asset Management and Human Resources Security, as well as the Organization of Information Security, Communications and Operations Management, and Information Security Incident Management. In some cases, ISO27002 addresses things you don't see at all in PCI like Business Continuity.

While a deep dive of ISO27002 is outside the scope of this book, security professionals will tell you that a mature ISO27002-based information security program will provide better protection than most of the industry or government regulated standards with which merchants and service providers might need to comply. The mere maturity of the program will provide for an easier path to PCI DSS compliance.

The Sarbanes–Oxley Act of 2002 (SOX) was enacted as a result of the numerous public company accounting scandals of the late 1990s and early 2000s in the United States such as Enron, Tyco International, and Worldcom. Accounting firms defrauded millions of investors, and bankrupted the retirement plans of many employees. These scandals along with the events of September 11 kicked off a market slide and impacted investors globally.

While many IT workers grumble just as loudly when you mention SOX as they do when you mention PCI DSS, SOX is not an IT regulation. In fact, most of the consternation created around SOX comes from one element of Section 404. Although the entire piece of legislation is substantial in size, Section 404 comprises two subsections (a and b) that kicked off this entire frenzy. The two relevant subsections under Section 404a are as follows:

Did you realize that it was only these two sections made such a big mess? It's humorous when you think about it. SOX's spending far exceeds that of PCI DSS, yet PCI DSS's requirements take up so much more space than SOX!

Part of the reason for this is that Section 404 does two things that generated a ton of work for large accounting firms. The first part of sub-bullet 1 requires that companies define a control set. PCI DSS does that for you – it's the standard. Where SOX becomes easier to manage from an IT control perspective over PCI DSS is that you are allowed to define your own controls that are sufficient to protect your financial data. PCI DSS does not afford you that luxury. You must comply with their predefined control set. The second part of SOX requires companies to be audited against that control set. That's similar to hiring a Qualified Security Assessor (QSA) to assess and validate your compliance with PCI DSS.

If you are a company subject to SOX, hopefully you are far along in your control framework maturity, and do not have problems passing your audits. If it takes 10 signatures to order a ream of paper, you might have a mature SOX program!

Although the SOX and PCI DSS teams attack different problems, there are things that each can learn from each other. For one, it makes more sense to manage to a common set of company controls, and then map those controls into each standard you might have to follow. For example, if you have password and authentication controls defined, you should be able to map those back into PCI DSS during an assessment of PCI DSS, and if PCI DSS changes, you should be able to go the other direction and make sure your controls are sufficient. Given the choice, most companies would prefer to manage to a common set of controls that address all compliance frameworks versus managing the four to five different compliance frameworks directly. If you can get your company focused on controls instead of requirements, you will have a better chance of maintaining compliance, and spending less with new compliance directives.

The matrix below (Table 14.1) illustrates some of the overlap and commonalities between PCI and other major compliance or security initiatives. One of three possible entries is listed in each cell. Cells with the term “Yes” in them means that there is a direct correlation, or that most implementations would require a similar control to be put in place. Cells with the marque “?” designate a possible match, but it depends on the implementation or specific control set. Cells with the term “No” in them means there is not a direct match between the initiatives, but depending on other areas (such as a security policy requirement), you may end up with overlap. Instead of comparing the Data Breach Notification Laws, we'll see how the new Massachusetts Data Breach Laws (thought to be the most aggressive today) compare to PCI DSS.

Based on everything we have covered, are you surprised that PCI and ISO27002 are so closely matched? If anything, this graphic could be used as the argument to invest in an ISO27002 program so that you don't have to chase all these individual initiatives!

PCI DSS has much in common with many of the existing security practices or laws and regulations with which your company might have to comply. We explored how PCI DSS shares similarities with State Data Breach Notification Laws, and briefly touched on new data breach related laws that are ever increasing in number and scope. We compared PCI DSS to ISO27002 and showed you how implementing and maturing something like ISO27002 would most likely exceed the base requirements of PCI DSS (and most other compliance initiatives). We discussed SOX, how it came to cause such a big mess, tips to use when dealing with both, and some of the dangers you might run into if you hand your PCI DSS compliance program over to those teams.

Data breaches are not going away, and as long as companies lag in protecting the information of constituents, expect laws to continue to be drafted and the landscape to become more complicated. The best thing you can do is step back and implement a solid information security program, ensuring that your base control set and framework meets the requirements of PCI DSS (and any other initiative you may be facing), and manage to that.