Before we go into detail on PCI compliance, we'd like to paint a quick picture of an entire payment card “ecosystem” (see Fig. 3.1).

Figure 3.1 shows all the entities in payment card “game”:

The primary focus of PCI DSS requirements is on merchants and MSPs. This is understandable since this is exactly where most of the data is lost to malicious hackers. Whether TJX in 2005 to 2007 (45 or 90 million cards stolen, depending on the source) or Heartland Payment Systems in 2008 to 2009 (more than 100 million cards stolen), merchants, and service providers have let cards be stolen from them without incurring any of the costs to themselves and without having a motivation to improve their security even to low levels prescribed by PCI DSS. While the merchants were letting the card data “run away,” the issuing banks were replacing them at their own cost and incurring other costs as well. Thus, PCI DSS was born to restore the balance to the system by making sure that merchants and service providers took care of protecting the card data.

In light of what is mentioned above, PCI DSS is here to reduce the risk of payment card transactions by motivating merchants and service providers to protect the card data. Whether this goal is worthy, whether there are other secondary goals, or even whether this goal is being achieved by a current version of the data security standard is irrelevant. What matters is that PCI is aimed at reducing the risk of transaction and it seeks to accomplish that by making merchants and service providers to pay attention to many key aspects of data security, from network security to system security, application security, and security awareness and policy. What is even more important, it encourages merchants to drop the data and conduct their business in a way that eliminates costly and risky data storage and on-site processing, whenever possible. Reduction of fraud is expected to be a natural result of such focus on security practices and technologies. One of the original PCI creators has also described PCI as the following: “the original intent was to design, implement, and manage a comprehensive, cost effective and reliable security effort”[4] and not a patchwork of security controls.

It is interesting to note that the “Ten Common Myths of PCI DSS” document from the PCI Council presents the six domains of PCI DSS as its goals [5]:

While the above six domains can be seen as tactical goals while implementing PCI DSS, the strategic focus of PCI DSS is card data security, payment card risk reduction, and ultimately the reduction of fraud losses for merchants, banks, and card brands.

Overall, while motivating security improvements and reducing the risk of card fraud, PCI DSS serves an even higher goal of boosting consumer confidence in what is currently the predominant payment system – credit and debit cards. While we can debate whether cash is truly on the way out, the volume of card transactions is still increasing at an impressive 20 to 40 percent rate annually. If anything – whether malicious hackers, insiders, or any other threat – can hinder it, major implications to today's economy may be incurred. Thus, PCI DSS defends something even bigger than “bits and bytes” in computer systems, but the functioning of the economic system itself.

It is likely that the statements about accepting card data or processing, storing, and transmitting payment card data will likely sound tiresome by the time you are finished reading our book; it is worthwhile to remind you that PCI DSS applies to all organizations that do just that, and there are no exceptions. Our Chapter 15, “Myths and Misconceptions of PCI DSS” covers some of the common delusions and clarifies that the above PCI applicability is indeed the reality and not the myth.

While the applicability of PCI DSS to organizations that deal with card data is certain and all the DSS requirements apply, the question of validating or proving PCI compliance is a bit different. It differs for merchants and service providers; it also differs by card brand and by transaction volume.

First, there are different levels of merchants and service providers. Table 3.1 and Table 3.2 show the breakdown.

As we mentioned above, these levels exist for determining compliance validation that is discussed in the next section. The levels are also sometimes used by the card brands to determine which fines to impose upon the merchant for noncompliance.

Now that we touched upon the compliance basics, it is time to face the painful fact: all the PCI DSS compliance deadlines are in the past (See Table 3.3). This means that now is the time to be compliant. There are additional dates for various other related requirements (such as card brand dates for Payment Application Data Security Standard [PA-DSS] compliance), but all core PCI DSS dates have indeed passed.

Some of you recall receiving a letter from your company's bank or a business partner many years ago that had a target compliance date. Such letters are rare since the dates for PCI DSS compliances have actually passed. This date may or may not be aligned with the card brands' official dates. This is because the card brands may not have a direct relationship with you and are working through the business chain of acquiring banks. When in doubt, always follow the guidance of your legal department that has reviewed your contracts.

Thus, barring unusual circumstances, the effective compliance deadlines have long passed. Various predecessor versions of the PCI 1.2 standard had unique dates associated with them, so if your compliance efforts have not been aligned to the card brand programs, you are way behind the curve and will not likely get any sympathy from your bank.

As far as additional dates by card brands, please refer to the following resources:

As we mentioned before, depending on your company's merchant or service provider level, you will either need to go through an annual on-site PCI assessment by a Qualified Security Assessor (QSA), or complete a Self-Assessment Questionnaire (SAQ) to validate compliance. In addition to this, you will have to present the results of the quarterly network perimeter scans that had to be performed by an approved scanning vendor (ASV).

In particular, while SAQ validates PCI compliance, there needs to be evidence that validates that the questions in the SAQ are answered truthfully.

When submitting a SAQ, it will have to be physically signed by an officer of your company. ² At the present time, there is no court precedent for officer liability as a result of false attestation. However, industry speculation is that this person may be held accountable in a civil court, especially if he or she commits an act of perjury while certifying.

If you are planning on submitting a Report on Compliance (ROC) instead of the SAQ, you will need to follow the document template outlined in the PCI DSS Security Audit Procedures document. After the SAQ has been filled out or the ROC has been completed, it must be sent along with all the necessary evidence and validation documentation to the acquirer, to the business partner, or to the card brand directly. It depends on who requested the compliance validation in the first place.

It is a common misconception that the compliance requirements vary among the different levels. Both merchants and service providers must comply with the entire DSS, regardless of the level. Only verification processes and reporting vary. Visa Web site explains it like this: “In addition to adhering to the PCI DSS, compliance validation is required for all service providers”[6].

The validation mechanisms, as of the time of this writing, are given in Table 3.4.

Further, the exact scope of PCI DSS validation differs based on the exact way the organization interfaces with card data. Specifically, quoting from the PCI Council Web site, the circumstances that affect what sections of the SAQ the merchant should complete for validation are provided in Table 3.5.

So, to summarize, the exact scope of any one's PCI DSS validation depends on the following:

Also, it is important to note that the specifics of validation requirement might change. For example, in June 2009, MasterCard announced that Level 2 merchant will not need to be validated via an on-site assessment. Expect validation requirements to become stricter in the future.

It is worthwhile to note that it is possible for a company to be a merchant and a service provider at the same time. If this is the case, the circumstances should be noted, and the compliance must be validated at the highest level. In other words, if a company is a Level 3 merchant and a Level 2 service provider, the compliance verification activities should adhere to the requirements for a Level 2 service provider.

One of the notable PCI assessors, Walt Conway, relates the following educational story about merchant and provider validation:

To better understand the PCI DSS role, its motivation and its future, it is useful to look at its origins and history.

PCI DSS has evolved from the efforts of several card brands. In the 1990s, the card brands developed various standards to improve the security of sensitive information. In the case of Visa, different regions came up with different standards since European countries and Canada were subject to different standards than the US. In June 2001, Visa launched the Cardholder Information Security Program (CISP). The CISP Security Audit Procedures document version 1.0 was the granddaddy of PCI DSS. These audit procedures went through several iterations and made it to version 2.3 in March 2004. At this time, Visa was already collaborating with MasterCard. Their agreement was that merchants and service providers would undergo annual compliance validation according to Visa's CISP Security Audit Procedures and would follow MasterCard's rules for vulnerability scanning. Visa maintained the list of approved assessors and MasterCard maintained the list of ASVs.

This collaborative relationship had a number of problems. The lists of approved vendors were not well-maintained, and there was no clear way for security vendors to get added to the list of each particular card brand. Also, the program was not endorsed by all card brand divisions. Other brands such as Discover, American Express, and JCB were running their own programs as well. The merchants and service providers in many cases had to undergo several independent assessments by different “certified” assessors just to prove compliance to each brand, which was clearly costing too much and not resulting in quality assessments either. For that and many other reasons, all card brands came together and created the PCI DSS 1.0, which gave us the concept of PCI compliance.

Unfortunately, the issue of ownership still was not fully addressed, and a year later, the PCI Security Standards Council was founded, and its Web site www.pcisecuritystandards.org was created. Comprised of American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International, PCI Council (as it came to be known) maintains the ownership of the DSS, most of the approved vendor lists, training programs, and so on. There are still exceptions, as the list of approved payment application assessors only recently has been transferred from Visa PABP to PCI Councils' PA-DSS. Also, incident forensics is still handled by the card brands themselves and not by the PCI Council. For example, Visa still runs its Qualified Incident Response Assessor (QIRA) certification.

Even today, each card brand/region still maintains its own security program beyond PCI. These programs go beyond the data protection charter of PCI and include activities such as fraud prevention. The information on such programs can be found in Table 3.6. In certain cases, PCI ROC needs to be submitted to each card brand's program office separately.

PCI Council or, fully, PCI Security Standards Council or PCI SSC, describes itself as “an open global forum for the ongoing development, enhancement, storage, dissemination, and implementation of security standards for account data protection”[8].

PCI Council charter provides oversight to the development of PCI security standards (including PCI DSS, PA-DSS, and PIN Entry Devices [PED]) on a global basis. It formalizes many processes that existed informally within the card brands. PCI Council published the updated DSS, at the time of this writing at version 1.2.1, which is accepted by all brands and international regions; it also updates the supporting documents such as “PCI Quick Reference Guide” and recent “Prioritized Approach for DSS 1.2” (March 2009) and “PCI SSC Wireless Guidelines” (July 2009) documents.

PCI Council now controls the companies that are allowed to conduct on-site DSS compliance assessments. These companies, known as QSAs, ³ have gone through the application and qualification process, having had to show compliance with tough business, capability, and administrative requirements. QSAs also had to invest in personnel training and certification to build up a team of assessors, also called QSAs.

QSAs have to recertify annually and have to retrain their internal personnel. The exact qualification process and the requirements are outlined on PCI Council Web site; however, of particular interest are the insurance requirements. QSAs are required to carry high coverage policies, much higher than typical policies for the professional service firms, which becomes important later. A recent lawsuit (“Merrick Bank v. Savvis,” see more details in [9]) presents an example risk that QSA faces; in this suit, the bank is suing the assessor who validated CardSystems, a target of a massive card data breach, as PCI compliant. Please use Google to find out how the lawsuit progressed and who won; the results will not be known before the book goes to print.

The QSA is a certification established by PCI Co. Individuals desiring this certification must first and foremost work for a QSA or for a company in the process of applying to become a QSA. Then, they must attend official training administered by PCI Council and pass the test. They must also undergo annual requalification training to maintain their status. An individual may not be a QSA, unless he or she is presently employed by a QSA company; however, a QSA can carry the certification between QSA companies when changing jobs.

We cover the tips on working with your QSA in Chapter 11, “Don't Fear the Assessor.” If there is one thing to remember when engaging a QSA, the QSA should be your partner. Treating your QSA like an auditor will only lead to a painful process whereby both parties end up frustrated and disillusioned.

As you know, PCI DSS validation also includes network vulnerability scanning by an ASV.

To become an ASV, companies must undergo a process similar to QSA qualification. The difference is that in the case of QSACs, the individual assessors attend classroom training on an annual basis, whereas ASVs submit a scan conducted against a test network perimeter. An organization can choose to become both QSA and ASV, which allows the merchants and service providers to select a single vendor for PCI compliance validation.

It is important to note that ASVs are authorized to perform external vulnerability scans from the Internet, but PCI DSS also mandates internal vulnerability scans (performed from inside the company network), which can be performed by anybody – internal security team or consultant.

We cover all the tips on working with your ASV in Chapter 8, “Vulnerability Management.”

One of the key challenges for any security standard is to change fast enough to follow the threat changes (and those change literally every day since criminal computer underground has to evolve to stay in business) and to change slow enough to still be considered a technical standard (and not simply advise to “do the right thing”). For prescriptive technical standards that directly call out security controls, such as firewalls, network intrusion prevention, and vulnerability scanning, the challenge is even more extreme.

In fact, today PCI DSS is sometimes criticized for being “constantly in flux” and for “not moving fast enough” at the same time, but by different people.

The changes are that the PCI standards are guided by the PCI Council document called “Lifecycle Process for Changes to PCI DSS”[10]. The document describes the following stages for each standard revision:

The overall process takes 24 months for each DSS revision (whether major from 1 to 2, which has not happened yet, or minor such as from 1.0 to 1.1) and always includes extensive public commenting and review periods to incorporate the input from all stakeholders.

Yvette's Evangelical Emporium is a small chain of 50 stores supplying religious supplies to local churches and individuals. Yvette started her business in 1990 with a single store. Throughout the 1990s, she was able to open several new stores in neighboring counties and states, eventually building a 10 retail location business by 2000. In 2002, she took advantage of a depressed economy, and using some capital from investors and a significant trust that matured, she expanded her operation to 25 stores in 3 years and continued to expand over the next 4 years to double her size.

In 2005, Yvette realized that she needed to formalize her IT division and hired Erin, a progressive and security-minded IT executive, as her chief information officer. Erin presented a plan to standardize and build out her infrastructure so that future growth could be done in a cookie-cutter fashion; thus, saving millions in deployment and maintenance costs.

By 2006, they crossed the threshold from a Level 2 Visa merchant to a Level 1 Visa merchant and knew they would quickly need to put a solid PCI compliance program in place. Erin knew from her previous experience that small companies struggled with information security and made it a point to build in basic information security fundamentals into her IT operations, but they did not meet the baseline PCI DSS requirements and needed to be reworked.

Because of her new reporting levels for PCI, Yvette hired Steve to serve as the chief information security officer, reporting directly to her. Steve's task was to build an information security program that addressed PCI immediately, but would expand to be more applicable to information security such that future regulation would only require minor tweaks to the program.

Steve and Erin worked closely together to build a common set of controls to be rolled out to the entire company. Steve knew that PCI was a priority but considered everything he did in light of the ISO security framework (ISO17799 at the time). In some cases, he found that ISO far exceeded specific PCI requirements like in Business Continuity and Risk Assessments, and he found unique parts of PCI that were much more granular than ISO, like the treatment of sensitive authentication data (PCI Requirement 3.2). Steve's efforts ultimately paid off in spades as his information security program matured. Recent changes and additions to restrictions on healthcare data (which Yvette housed as part of an employee self-insurance program) and state data breach notification laws were already addressed by the program as it matured, and Yvette's cost associated with protecting data was much less than her competitors who only chased standards with immediate noncompliance repercussions.

Garrett's Gas Guzzling Garage operates 800 car repair locations across the United States. Garrett's recently opened 20 locations in Mexico City to help maintain and upgrade the fuel efficiency of old cars. Garrett is considered a Level 1 merchant in the United States but set up a different entity in Mexico City, and processes and settles locally with Bancomer. Although Garrett authorizes and settles locally in Mexico City at his small regional headquarters, he shares the data with the US-based parent for backup and analysis purposes.

His business is booming in Mexico City, and that business quickly became a Level 2 merchant. According to MasterCard's new validation requirements, this would mean that Garrett must have a QSA perform an on-site assessment of compliance for both locations. He was already doing this in the United States based on his Level 1 status, but now faces additional costs for doing this locally in Mexico City.

“But wait,” some of you are saying, “What about Visa's rules?” Certainly glad you asked that! According to Visa, if a smaller, wholly owned subsidiary shares infrastructure and data with a parent company considered a Level 1, then that smaller subsidiary should also be viewed as a Level 1 and perform the same level of validation.

Back to Garrett, even though the 20 Mexico locations process through Bancomer, the data is shared with the US headquarters for backup and analysis. According to Visa's rules, the Mexican entity is considered Level 1 based on its relationship with the parent, and a Level 1 assessment must be performed.

As always, when in doubt, ask your acquirer what is expected of you. Your mileage may vary when it comes to some of these intricate rules. Some acquiring institutions may still treat certain subsidiaries as lower levels depending on the circumstances.