PCI DSS: 5 Guidelines for Gaining PCI Compliance
Step 1: An Introduction to PCI Compliance
Question: What can happen to you and/or your organization, if you fail to implement or adhere to, the Payment Card Industry Data Security (PCI DSS) compliance rules?
Answer: Ask TJX Companies Inc. (TJX).
Currently, the company-owner of T.J. Maxx and Marshall's department stores and other stores in North America and the United Kingdom-faces more than a dozen class action lawsuits in Alabama, California, Massachusetts, Puerto Rico and six Canadian provinces, for what has been hailed as the single largest data breach in United States history.
TJX revealed in March 2007 that hackers compromised at least 45.7 million credit and debit cards. From July 2005 until the discovery in December 2006, the bandits penetrated a supposedly secure network environment.
In a regulatory filing made with the Securities and Exchange Commission (SEC) after the violation, TJX stated that its computer systems were first hacked in July 2005 by one or more intruders who accessed information from customer transactions dating back to January 2003. TJX officials said that they didn't find out about the breach until about three months ago.
More troubling, however, is the fact that TJX believes that the hackers had access to the decryption tool for their encryption software, making PIN numbers, credit card numbers, and any other unique identifiers easy to see. The SEC filing also said another 455,000 customers who returned merchandise without receipts had their driver's license numbers stolen.
At this time, TJX is not sure whether it was a single breach, or multiple intrusions. The ripples of this breach are far reaching, including the addition of TJX's acquirer-Cincinnati-based Fifth Third Bancorp-as a defendant in some of the lawsuits. The bank processed some payment card transactions for TJX. TJX and its acquirer are not alone in not being cognizant of potential holes in their security systems, as there have been many examples of breaches that have compromised confidential information across several business sectors in the last decade alone. "Companies like LexisNexis, Citibank, ChoicePoint have all had breaches," says Khalid Kark, senior security analyst with Forrester Research. Kark is a leading expert in Security and Risk Management, compliance, best practices, and services.
"The issue is that it's not that the company doesn't have good security, it's just that they haven't really put in all of the effort and the time to understand all of the areas of threat and try to protect against those."
In order to address the threats to credit card information, the PCI Security Standards Council (PCI SSC) was formed in September, 2006.
Even with the guidelines, many organizations have not opted to pursue PCI Compliance, even when they may know that they need to be.
At the same time Visa U.S.A projects that 65 percent of all merchants will be PCI compliant by the end of 2007, and stiff penalties that target acquirers is one tool that the PCI SSC.
If an organization doesn't know that they need to be PCI compliant, or if an organization just doesn't want to be bothered by having to obtain PCI compliance, it soon will not matter. The goal is to have all merchants, regardless of their merchant level, compliant with PCI DSS.
"Being PCI compliant is a smart business decision, as far as securing their [merchants] Web property and Intellectual property," said Richard Stanton, CTO of ControlScan-a leading Internet security solutions company.
"With data being stored virtually, in accessible areas, PCI standards are set up to help businesses with better practices," he continued. "These better practices can begin with 'hey, do you have a lock on your door?' to 'do you have scanning procedures in place?'…being PCI compliant, without being forced to do it, just makes good business sense, period."
Answer: Ask TJX Companies Inc. (TJX).
Currently, the company-owner of T.J. Maxx and Marshall's department stores and other stores in North America and the United Kingdom-faces more than a dozen class action lawsuits in Alabama, California, Massachusetts, Puerto Rico and six Canadian provinces, for what has been hailed as the single largest data breach in United States history.
TJX revealed in March 2007 that hackers compromised at least 45.7 million credit and debit cards. From July 2005 until the discovery in December 2006, the bandits penetrated a supposedly secure network environment.
In a regulatory filing made with the Securities and Exchange Commission (SEC) after the violation, TJX stated that its computer systems were first hacked in July 2005 by one or more intruders who accessed information from customer transactions dating back to January 2003. TJX officials said that they didn't find out about the breach until about three months ago.
More troubling, however, is the fact that TJX believes that the hackers had access to the decryption tool for their encryption software, making PIN numbers, credit card numbers, and any other unique identifiers easy to see. The SEC filing also said another 455,000 customers who returned merchandise without receipts had their driver's license numbers stolen.
At this time, TJX is not sure whether it was a single breach, or multiple intrusions. The ripples of this breach are far reaching, including the addition of TJX's acquirer-Cincinnati-based Fifth Third Bancorp-as a defendant in some of the lawsuits. The bank processed some payment card transactions for TJX. TJX and its acquirer are not alone in not being cognizant of potential holes in their security systems, as there have been many examples of breaches that have compromised confidential information across several business sectors in the last decade alone. "Companies like LexisNexis, Citibank, ChoicePoint have all had breaches," says Khalid Kark, senior security analyst with Forrester Research. Kark is a leading expert in Security and Risk Management, compliance, best practices, and services.
"The issue is that it's not that the company doesn't have good security, it's just that they haven't really put in all of the effort and the time to understand all of the areas of threat and try to protect against those."
In order to address the threats to credit card information, the PCI Security Standards Council (PCI SSC) was formed in September, 2006.
Even with the guidelines, many organizations have not opted to pursue PCI Compliance, even when they may know that they need to be.
At the same time Visa U.S.A projects that 65 percent of all merchants will be PCI compliant by the end of 2007, and stiff penalties that target acquirers is one tool that the PCI SSC.
If an organization doesn't know that they need to be PCI compliant, or if an organization just doesn't want to be bothered by having to obtain PCI compliance, it soon will not matter. The goal is to have all merchants, regardless of their merchant level, compliant with PCI DSS.
"Being PCI compliant is a smart business decision, as far as securing their [merchants] Web property and Intellectual property," said Richard Stanton, CTO of ControlScan-a leading Internet security solutions company.
"With data being stored virtually, in accessible areas, PCI standards are set up to help businesses with better practices," he continued. "These better practices can begin with 'hey, do you have a lock on your door?' to 'do you have scanning procedures in place?'…being PCI compliant, without being forced to do it, just makes good business sense, period."
The Payment Card Industry (PCI) consists of the five major credit card brands:
- Visa
- MasterCard
- American Express
- DiscoverCard
- JCB International
The PCI Data Security Standard (PCI DSS) really began with each credit card issuer establishing their own proprietary programs to store and secure credit card data.
Merchant concerns and confusion concerning rival and intersecting card brand-specific requirements, along with the continuation of massive credit card data breaches at many high profile organizations, prompted the card issuers to come together to create a single standard for protecting credit card data.
In June 2005, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International founded the PCI Security Council. These requirements are based on ISO 17799-the internationally recognized standard for information security practices.
The main tasks of the council are:
- Creating, owning and managing PCI DSS for credit card data
- Classifying a common audit requirement to certify compliance
- Overseeing a certification process for security assessors and network scanning vendors
- Instituting minimum qualification requirements
- Retaining and publishing a list of certified assessors and vendors
Under the PCI DSS, a business or organization should be able to assure their customers that its credit card data/account information and transaction information is safe from hackers or any malicious system intrusion.
The PCI Security Standards Council is not a policing organization. It neither enforces the PCI DSS, nor determines the appropriate remediation for violations of the PCI DSS.
Enforcement is left the specific credit card companies and acquirers. PCI DSS does not replace the individual credit card company's compliance programs. Each credit card company separately determines who must be compliant, including any brand-specific enforcement programs.
Should Your Organization be Concerned about PCI Compliance?
Should Your Organization be Concerned about PCI Compliance?
The Payment Card Industry Data Security Standard (PCI DSS) applies to every organization that processes credit or debit card information, including merchants and third-party service providers that store, process or transmit credit card/debit card data.
If you are one of the above, PCI Compliance is not a request, or suggestion, it is now a requirement.
However, according to the PCI DSS documentation, "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply."
By the end of 2007, any organization that accepts payment card transactions must be in compliance with the standards.
Credit card companies and acquirer banks can levy stiff fines and remove the merchant's ability to process credit card transactions until the merchant is PCI compliant.
Basic rules on PCI DSS compliance:
"I get these questions all of the time," he commented.
"The rule of thumb is this: If you house credit card information, in whatever form, if you house the information in your server-the server that you own or you added-then you are basically responsible for complying with PCI DSS," Kark stated.
Even with a uniform standard for compliance, since the PCI DSS Standards Council instituted the new security standards, evidence suggests that there has not been a huge rush to comply. Many organizations have started to comply or audit in certain areas, but overall numbers seesaw depending on the each merchant level.
From data collected by Visa, in 2006 only 18 percent of Level 1 merchants-merchants with 6 million or more Visa transactions per year-were compliant with PCI DSS, as opposed to the 35 percent who are currently PCI compliant in 2007.
Another 51 percent have completed a report concerning where they are in terms of compliance, and 93 percent of the responding merchants certified that they are not storing PIN numbers, card verification numbers and other stored credit card data.
Only 26 percent of Level 2 merchants-merchants with 1 to 6 million Visa or MasterCard transactions per year-are PCI compliant at this time, but Level 3 merchants-merchants with Visa or MasterCard transactions totaling 20,000 to 1 million-have a higher level of compliance at 51 percent.
According to information gathered by Kark and Forrester Research, though organizations are spending a lot of money to become PCI compliant, it still is taking a long time for the organization to actually see the benefits of that compliance.
"We've found that over years, typically there is one year there is a push to get spending, or to have spending in terms of a specific regulation," Kark explained.
"In 2005, for government, it was VISMA [government compliance program] and there was a lot of spending in terms of getting the controls in place, getting the technology in place, and so on, and in 2006 we saw a similar trend in the retail industry where the retail industry spent a lot of money in terms of getting compliant with PCI."
Continuing, Kark said that implementing a PCI DSS compliance program is still a lengthy process.
"Once you start implementing technologies, once you start investing in security controls, then it takes a couple of years from implementation to realize the benefits of that spending," he said.
"And to be able to get to the fact of 'well, yes we are compliant completely, and yes we spent the money a couple of years ahead of time, but then we needed to put in processes and other things that we're kind of realizing the benefits of that spending.'"
From surveys conducted by Forrester Research, Kark believes that most companies will be compliant with PCI DSS within the next 6 to 12 months.
"That may be a little late for some companies, but that is the data that we find, at the moment," Kark said.
But just because an organization is currently PCI DSS compliant right now, does not mean that it will continue to be compliant indefinitely. Compliance to the PCI DSS rules will continue indefinitely, as new technologies and new ways of hacking personal data continue also.
"In general, compliance is 100 percent, but it's a certain point in time, so if you are compliant today, it doesn't necessarily mean you will be compliant tomorrow," Kark said.
"Being compliant means that at the time of the audit you [organization] were PCI compliant to 100 percent of the requirement in respect to whoever the auditor was…it's the auditor that makes the judgment, but it may not really remain 100 percent throughout."
Suggested Links
The Payment Card Industry Data Security Standard (PCI DSS) applies to every organization that processes credit or debit card information, including merchants and third-party service providers that store, process or transmit credit card/debit card data.
If you are one of the above, PCI Compliance is not a request, or suggestion, it is now a requirement.
However, according to the PCI DSS documentation, "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply."
By the end of 2007, any organization that accepts payment card transactions must be in compliance with the standards.
Credit card companies and acquirer banks can levy stiff fines and remove the merchant's ability to process credit card transactions until the merchant is PCI compliant.
Basic rules on PCI DSS compliance:
- PCI DSS compliance includes merchants and service providers who accept, capture, store, transmit or process credit and debit card data.
- As of September 2006, PCI DSS 1.1 includes 12 major requirements. A single violation of any of the requirements can trigger an overall non-compliant status.
- Each non-compliant incident will result in steep fines, suspension and revocation of card processing privileges.
"I get these questions all of the time," he commented.
"The rule of thumb is this: If you house credit card information, in whatever form, if you house the information in your server-the server that you own or you added-then you are basically responsible for complying with PCI DSS," Kark stated.
Even with a uniform standard for compliance, since the PCI DSS Standards Council instituted the new security standards, evidence suggests that there has not been a huge rush to comply. Many organizations have started to comply or audit in certain areas, but overall numbers seesaw depending on the each merchant level.
From data collected by Visa, in 2006 only 18 percent of Level 1 merchants-merchants with 6 million or more Visa transactions per year-were compliant with PCI DSS, as opposed to the 35 percent who are currently PCI compliant in 2007.
Another 51 percent have completed a report concerning where they are in terms of compliance, and 93 percent of the responding merchants certified that they are not storing PIN numbers, card verification numbers and other stored credit card data.
Only 26 percent of Level 2 merchants-merchants with 1 to 6 million Visa or MasterCard transactions per year-are PCI compliant at this time, but Level 3 merchants-merchants with Visa or MasterCard transactions totaling 20,000 to 1 million-have a higher level of compliance at 51 percent.
According to information gathered by Kark and Forrester Research, though organizations are spending a lot of money to become PCI compliant, it still is taking a long time for the organization to actually see the benefits of that compliance.
"We've found that over years, typically there is one year there is a push to get spending, or to have spending in terms of a specific regulation," Kark explained.
"In 2005, for government, it was VISMA [government compliance program] and there was a lot of spending in terms of getting the controls in place, getting the technology in place, and so on, and in 2006 we saw a similar trend in the retail industry where the retail industry spent a lot of money in terms of getting compliant with PCI."
Continuing, Kark said that implementing a PCI DSS compliance program is still a lengthy process.
"Once you start implementing technologies, once you start investing in security controls, then it takes a couple of years from implementation to realize the benefits of that spending," he said.
"And to be able to get to the fact of 'well, yes we are compliant completely, and yes we spent the money a couple of years ahead of time, but then we needed to put in processes and other things that we're kind of realizing the benefits of that spending.'"
From surveys conducted by Forrester Research, Kark believes that most companies will be compliant with PCI DSS within the next 6 to 12 months.
"That may be a little late for some companies, but that is the data that we find, at the moment," Kark said.
But just because an organization is currently PCI DSS compliant right now, does not mean that it will continue to be compliant indefinitely. Compliance to the PCI DSS rules will continue indefinitely, as new technologies and new ways of hacking personal data continue also.
"In general, compliance is 100 percent, but it's a certain point in time, so if you are compliant today, it doesn't necessarily mean you will be compliant tomorrow," Kark said.
"Being compliant means that at the time of the audit you [organization] were PCI compliant to 100 percent of the requirement in respect to whoever the auditor was…it's the auditor that makes the judgment, but it may not really remain 100 percent throughout."
Suggested Links
PCI DSS: The Visa CISP Program
For Visa, Inc., PCI DSS compliance includes following their Cardholder Information Security Program (CISP), along with the incorporated PCI DSS standards.
The CISP program includes compliance and validation requirements for the following entities:
The CISP program includes compliance and validation requirements for the following entities:
- Merchants-All merchants including retail (brick-and-mortar), mail/telephone order, and e-commerce.
- Service Providers-Visa identifies service providers as organizations that process, store, or transmit Visa cardholder data on behalf of Visa members, merchants, or other service providers.
- Payment Applications-Visa offers a "Best Practices" document for Payment applications, with the goal that the payment application must not retain full magnetic stripe data or CVV2 data. As well, as well the software must support a merchants and service providers' ability to comply with the PCI Data Security Standard.
For MasterCard Inc., compliance and validation includes following its Site Data Protection (SDA) Program, along with the incorporated PCI DSS standards.
The SDA program includes compliance requirements for the following entities:
The SDA program includes compliance requirements for the following entities:
- Merchants-All merchants must become PCI DSS compliant through completing the PCI Self Assessment, PCI Onsite Assessment and PCI Quarterly Network Scanning. While all merchants are required to comply with the Payment Card Industry Data Security Standard, merchants that store, process or transmit MasterCard account data may also be required to validate compliance with their acquirer.
- Service Providers-Third Party Processors (TPPs), Data Storage Entities (DSEs). Any service providers that store, process or transmit MasterCard account data on behalf of the merchant must also be compliant.
- Vendors-Master Card provides a list of Approved Scanning Vendors (ASVs), based on the testing requirements laid out in the PCI DSS standard for ASVs.
- Acquirers-MasterCard works with acquirers to help the acquirer's merchants obtain SDA certification, as well as PCI DSS certification. The acquirer does not have to go through an SDA certification process, but the acquirer must manage the SDA process for their merchants. The acquirer must certify the merchants' compliance validation tools, as well as registering the merchant with MasterCard.
Defining Merchant Validation Levels
In order to be PCI DSS compliant, each card issuer has its own criteria for assigning a merchant level and validation compliance classification level for a merchant, third party or service provider.
The merchant level is based on transaction volume for the organization. The validation compliance level is based on the merchant level, and includes the validation actions and who needs to carry out the validation actions, in order to be PCI DSS compliant.
For the majority of organizations, the standards set forth by Visa's CISP program and MasterCard's SDP program cover the qualifications for assigning both a merchant level and compliance level, along with incorporating PCI DSS.
American Express and Discover, at this time, do not have a stringent program in place like Visa or MasterCard, however both companies have a 'best practices' document, which coincides with the PCI DSS.
Currently, under PCI DSS 1.1, the emphasis of compliance is on the Level 1 and Level 2 merchants, service providers, vendors and payment applications.
The current Visa and MasterCard merchant levels and changes from PCI DSS 1.0 to PCI DSS 1.1 are as follows:
The merchant level is based on transaction volume for the organization. The validation compliance level is based on the merchant level, and includes the validation actions and who needs to carry out the validation actions, in order to be PCI DSS compliant.
For the majority of organizations, the standards set forth by Visa's CISP program and MasterCard's SDP program cover the qualifications for assigning both a merchant level and compliance level, along with incorporating PCI DSS.
American Express and Discover, at this time, do not have a stringent program in place like Visa or MasterCard, however both companies have a 'best practices' document, which coincides with the PCI DSS.
Currently, under PCI DSS 1.1, the emphasis of compliance is on the Level 1 and Level 2 merchants, service providers, vendors and payment applications.
The current Visa and MasterCard merchant levels and changes from PCI DSS 1.0 to PCI DSS 1.1 are as follows:
- Level 1-Visa U.S.A. and MasterCard World Wide transactions totaling 6 million and up, per year, and any merchants who experienced a data breach.
- Level 2-Visa and MasterCard transactions totaling 1 million to 6 million per year. (The new requirement expands the number of Level 2 merchants to include former Level 4 merchants.)
- Level 3-Visa and MasterCard e-commerce transactions totaling 20,000 to 1 million per year. (The new requirement expands Level 3 to include former Level 2 merchants who process fewer than 1 million e-commerce transactions per year.)
- Level 4-Visa and MasterCard e-commerce transactions totaling up to 20,000 per year. (The new requirement decreases the number of Level 4 merchants.), and all other merchants, regardless of acceptance channel, processing up to 1 million Visa or MasterCard transactions per year.
- Level 1-Visa/MasterCard-- Annual onsite review by merchant's internal auditor or a Qualified Security Assessor (QSA) or Internal Audit if signed by Officer of the company, and a quarterly network security scan with an Approved Scanning Vendor (ASV).
- Level 2-- Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV.
- Level 3-- Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV.
- Level 4-- Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV. Submit summary of PCI compliance plan, via acquirer, by July 30, 2007. If a breach has been reported, or found, Visa reserves the right to move the Level 4 merchant to a Level 1. If so, the Level 4 merchant must abide by the Level 1 validation requirements. (See Level 4 Merchant Compliance for more information)
PCI DSS Level 4 Merchant Compliance
As PCI DSS continues to be enforced as the standard for credit card data security, the emphasis of compliance mandates have focused, primarily, on Level 1, Level 2 and Level 3 merchants.
On paper, this is the best and most obvious move, in order to protect the credit card data of the maximum number of cards and cardholders, and in order to emphasize-first-those merchants clearing the largest volume of transactions per year.
But Level 4 merchants are now getting much more attention, as many of those merchants are now using integrated POS terminals connected to high speed Internet connections, instead of the usual stand alone, dial-up POS terminals, which cannot be accessed from the Internet.
This disparity, along with the fact that Level 4 run the gamut between small mom-and-pop merchants, with one dial-up POS terminal, to huge brick-and-mortar operations with high speed lines, leaves some of these merchants wide open for hackers.
According to Visa, Level 4 merchants handle fewer transactions than Levels 1,2 and 3, but they account for more than 99 percent of the merchants that accept Visa. This is an ultimate playground for hackers.
"Usually, Level 4 merchants do not have the technical expertise, nor the IT Staff, to properly secure card holder data," said Joan Herbig, CEO of ControlScan.
"For all data breaches, you have two main risks: The internal risk-an employee obtaining a file that they shouldn't have, and an external risk-a hacker," she explained.
"A hacker is going to look for the path of least resistance," she continued. "Level 1 and 2 merchants can afford to button up their IT infrastructure, because they have the money to do so; they can afford to staff a huge IT department, and they don't want to be a headline in the news."
"So, if I am a hacker, I'm going to go to the merchant that I know cannot afford the proper security or staff to mitigate that type of breach," she finished.
Herbig said that, even with the July deadline, Level 4 merchants and acquirers are becoming PCI compliant at a "trickle."
Though Level 4 merchants are not required by the PCI SSC, or by card issuers such as Visa and MasterCard, to submit to an onsite security assessment, it's up to the acquirer to make sure that its Level 4 merchants understand the need for being PCI compliant.
In order to spur this suggestion along, Visa, U.S.A., added a new, Level 4 Merchant Compliance Program in order to address data security issues for Level 4 merchants.
The new program, released in May 2007, requires acquirers to develop and submit a formal written compliance plan to Visa, which "identifies, prioritizes and manages overall risk within their Level 4 merchant populations," according to the CISP Bulletin.
Many acquirers have already developed, written and sent a summary of their plans to make their Level 4 merchants compliant, under Visa's PCI Compliance Acceleration Program (PCI CAP). (See Visa PCI CAP Program).
But for those acquirers who have not written and/or sent a summary of their plan, one must be emailed to Visa no later than July 31, 2007. Email summaries to cisp@visa.com. .
The Level 4 Merchant Compliance Program plan must consist of the following items:
On paper, this is the best and most obvious move, in order to protect the credit card data of the maximum number of cards and cardholders, and in order to emphasize-first-those merchants clearing the largest volume of transactions per year.
But Level 4 merchants are now getting much more attention, as many of those merchants are now using integrated POS terminals connected to high speed Internet connections, instead of the usual stand alone, dial-up POS terminals, which cannot be accessed from the Internet.
This disparity, along with the fact that Level 4 run the gamut between small mom-and-pop merchants, with one dial-up POS terminal, to huge brick-and-mortar operations with high speed lines, leaves some of these merchants wide open for hackers.
According to Visa, Level 4 merchants handle fewer transactions than Levels 1,2 and 3, but they account for more than 99 percent of the merchants that accept Visa. This is an ultimate playground for hackers.
"Usually, Level 4 merchants do not have the technical expertise, nor the IT Staff, to properly secure card holder data," said Joan Herbig, CEO of ControlScan.
"For all data breaches, you have two main risks: The internal risk-an employee obtaining a file that they shouldn't have, and an external risk-a hacker," she explained.
"A hacker is going to look for the path of least resistance," she continued. "Level 1 and 2 merchants can afford to button up their IT infrastructure, because they have the money to do so; they can afford to staff a huge IT department, and they don't want to be a headline in the news."
"So, if I am a hacker, I'm going to go to the merchant that I know cannot afford the proper security or staff to mitigate that type of breach," she finished.
Herbig said that, even with the July deadline, Level 4 merchants and acquirers are becoming PCI compliant at a "trickle."
Though Level 4 merchants are not required by the PCI SSC, or by card issuers such as Visa and MasterCard, to submit to an onsite security assessment, it's up to the acquirer to make sure that its Level 4 merchants understand the need for being PCI compliant.
In order to spur this suggestion along, Visa, U.S.A., added a new, Level 4 Merchant Compliance Program in order to address data security issues for Level 4 merchants.
The new program, released in May 2007, requires acquirers to develop and submit a formal written compliance plan to Visa, which "identifies, prioritizes and manages overall risk within their Level 4 merchant populations," according to the CISP Bulletin.
Many acquirers have already developed, written and sent a summary of their plans to make their Level 4 merchants compliant, under Visa's PCI Compliance Acceleration Program (PCI CAP). (See Visa PCI CAP Program).
But for those acquirers who have not written and/or sent a summary of their plan, one must be emailed to Visa no later than July 31, 2007. Email summaries to cisp@visa.com. .
The Level 4 Merchant Compliance Program plan must consist of the following items:
- Timeline of Critical Events--Timeline of completion dates and milestones, for overall strategy.
- Risk-Profiling Strategy--Prioritization of Level 4 merchants into subgroups, from merchants that post the greatest risk, to those that post little risk at all. Factors such as merchant category transaction volume, market segment, acceptance channel, number of locations can help the acquirer target compliance efforts for each subgroup.
- Merchant Education Strategy--Strategy designed to eliminate prohibited data from being stored; protect stored data, and securing the environment in accordance with PCI DSS. This includes ensuring that merchants are only storing data they truly require, by complying with PCI DSSs, and by making sure payment applications are compliant and any third-party agents are on Visa's list of CISP-Compliant Service Providers.
- Compliance Reporting--Monthly compliance reporting to executive or board management. Visa may also periodically request that the acquirer produce these reports.
Visa is the first credit card company to start a program that combines fines with incentives for acquirers to make their merchants PCI compliant, no matter the level.
Visa has invested over $20 million dollars in order to pay Level 1 and Level 2 acquirers a one-time payment, for each merchant, if each Level 1 and Level 2 merchant is compliant by March 31, 2007. Acquirers whose Level 1 and Level 2 merchants validate compliance after March 31 and prior to August 31, 2007 will be eligible to receive a reduced one-time payment for each qualifying merchant.
"Locking down cardholder data is an important security component that will benefit financial institutions and merchants, and is equally important to maintain consumer trust in Visa," said Michael E. Smith, senior vice president of Enterprise Risk and Compliance at Visa USA, in a Visa press release.
"By combining both incentives and fines, we expect acquirers to increase their efforts with merchants to accelerate their progress toward becoming PCI compliant and eliminating the storage of sensitive card data. Nothing is more important to Visa than securing commerce."
As well, under the CAP plan, acquirers are required to validate Level 1 and 2 merchant compliance with PIN security. This means that Level 1 and Level 2 merchants must not use payment devices such as PIN pads, and encourages the use of unique encryption keys for every device.
For Level 3 and 4 merchants, acquirers must establish a thorough compliance program for those merchants. According to Visa, as of October 1, 2007, acquirers whose transactions qualify for lower interchange rates available in the Visa and Interlink tiers must ensure that the merchants generating the transactions are PCI compliant in order to receive this benefit.
Suggested Links:
Visa has invested over $20 million dollars in order to pay Level 1 and Level 2 acquirers a one-time payment, for each merchant, if each Level 1 and Level 2 merchant is compliant by March 31, 2007. Acquirers whose Level 1 and Level 2 merchants validate compliance after March 31 and prior to August 31, 2007 will be eligible to receive a reduced one-time payment for each qualifying merchant.
"Locking down cardholder data is an important security component that will benefit financial institutions and merchants, and is equally important to maintain consumer trust in Visa," said Michael E. Smith, senior vice president of Enterprise Risk and Compliance at Visa USA, in a Visa press release.
"By combining both incentives and fines, we expect acquirers to increase their efforts with merchants to accelerate their progress toward becoming PCI compliant and eliminating the storage of sensitive card data. Nothing is more important to Visa than securing commerce."
As well, under the CAP plan, acquirers are required to validate Level 1 and 2 merchant compliance with PIN security. This means that Level 1 and Level 2 merchants must not use payment devices such as PIN pads, and encourages the use of unique encryption keys for every device.
For Level 3 and 4 merchants, acquirers must establish a thorough compliance program for those merchants. According to Visa, as of October 1, 2007, acquirers whose transactions qualify for lower interchange rates available in the Visa and Interlink tiers must ensure that the merchants generating the transactions are PCI compliant in order to receive this benefit.
Suggested Links:
Defining Service Provider Validation Levels
In addition to merchants, PCI DSS validation requirements extend to service providers as well.
According to Visa, service providers are defined as organizations that process, store, or transmit Visa cardholder data on behalf of Visa members, merchants, or other third parties. Card issuers and acquirers are responsible for making sure that their merchants utilize service providers that are compliant with the PCI DSS, even though there might not be a true contract between merchant service providers and acquirers.
MasterCard defines a service provider as an encompassing term for Third Party Processors (TPPs) and Data Storage Entities (DSEs).
According to the MasterCard Web site, Web merchants routinely contract with service providers to "facilitate many business functions, including, but not limited to, offering and selling their content online, payment services, hosting applications and processing."
Visa and MasterCard service providers are responsible for any liability that may occur as a result of non-compliance.
The current Service Provider Levels for Visa and MasterCard are as follows:
Any merchant or service provider, who continues to use non-compliant payment applications-applications that store magnetic strip, CVV or CVV2 and PIN data, is considered a High Risk.
If a merchant or service provider is considered High Risk, they will be contacted by the acquirer and no matter the merchant or service provider compliance level, will be subject to an onsite review by an internal auditor or QSA.
Competing Cards: American Express and Discover
As stated earlier in this article, American Express and Discover Card, as of now, do not have actual guidelines or procedures in place, such as Visa and MasterCard have, however they do direct their merchants to follow PCI DSS standards.
As a caveat within the CISP guidelines, Visa and MasterCard reserve the right to require merchants/service providers who process competing cards-most merchants process more than one credit card brand-to adhere to the CISP/PCI guidelines if Visa or MasterCard feels that the merchant has or is compromising credit card data in some way, that there is evidence of a previous hack or attack that compromised data, and if the competing card has transactions that equal a Level 1 merchant.
According to Visa, service providers are defined as organizations that process, store, or transmit Visa cardholder data on behalf of Visa members, merchants, or other third parties. Card issuers and acquirers are responsible for making sure that their merchants utilize service providers that are compliant with the PCI DSS, even though there might not be a true contract between merchant service providers and acquirers.
MasterCard defines a service provider as an encompassing term for Third Party Processors (TPPs) and Data Storage Entities (DSEs).
According to the MasterCard Web site, Web merchants routinely contract with service providers to "facilitate many business functions, including, but not limited to, offering and selling their content online, payment services, hosting applications and processing."
Visa and MasterCard service providers are responsible for any liability that may occur as a result of non-compliance.
The current Service Provider Levels for Visa and MasterCard are as follows:
- Level 1 Visa - All VisaNet processors (member and Nonmember) and all payment gateways--agent or service provider that stores, processes, and/or transmits cardholder data as part of a payment transaction.
- Level 2 Visa - Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.
- Level 3 Visa - Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.
- Level 4 Visa - Merchants processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel processing up to 1,000,000 Visa transactions per year.
- Level 1 MasterCard - All TPPs and DSE's that store account data on behalf of Level 1 or Level 2 merchants.
- Level 2 MasterCard - Includes all DSEs that store account data on behalf of level 3 merchants.
- Level 3 MasterCard - All other DSEs not included in Levels 1 and 2.
- Level 4 MasterCard - Any other merchant not covered in Level 1, Level 2 and Level 3 compliance qualifications.
- Level 1 Visa - Annual On-Site PCI Data Security Assessment and Quarterly Network Scan, validated by a quality Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV).
- Level 2 Visa - Annual On-Site PCI Data Security Assessment and Quarterly Network Scan, validated by a quality QSA and ASV.
- Level 3 Visa -Annual PCI Self-Assessment Questionnaire, validated by the service provider and a Quarterly Network Scan, validated by a quality ASV.
- Level 1 MasterCard - Annual onsite review by merchant's internal auditor or a QSA, and a quarterly network security scan with an ASV.
- Level 2 MasterCard - Annual onsite review by merchant's internal auditor or a QSA, and a quarterly network security scan with an ASV.
- Level 3 MasterCard - Annual PCI Self-Assessment Questionnaire, validated by the service provider and a Quarterly Network Scan, validated by a quality ASV.
Any merchant or service provider, who continues to use non-compliant payment applications-applications that store magnetic strip, CVV or CVV2 and PIN data, is considered a High Risk.
If a merchant or service provider is considered High Risk, they will be contacted by the acquirer and no matter the merchant or service provider compliance level, will be subject to an onsite review by an internal auditor or QSA.
Competing Cards: American Express and Discover
As stated earlier in this article, American Express and Discover Card, as of now, do not have actual guidelines or procedures in place, such as Visa and MasterCard have, however they do direct their merchants to follow PCI DSS standards.
As a caveat within the CISP guidelines, Visa and MasterCard reserve the right to require merchants/service providers who process competing cards-most merchants process more than one credit card brand-to adhere to the CISP/PCI guidelines if Visa or MasterCard feels that the merchant has or is compromising credit card data in some way, that there is evidence of a previous hack or attack that compromised data, and if the competing card has transactions that equal a Level 1 merchant.
Currently, under PCI DSS 1.1, the emphasis of compliance is on the Level 1 and Level 2 merchants.
It's up to the specific acquirer, along with the issuing credit card company, to educate and enforce their merchants, vendors, service providers, or any entity that stores or processes credit card data, to comply and validate PCI DSS and CISP standards.
If you are a merchant, vendor or service provider reading this information for the first time, it might be time-or past time-to question and contact your acquirer and credit card issuer.
To take it one step further, in 2006, Visa levied $4.6 million in fines, up from a 2005 total of $3.4 million, to its acquirers.
PCI DSS 1.1 sets an enforcement date for acquirers to validate PCI compliance for Level 1 and Level 2 merchants.
The enforcement dates are as follows:
As of March 31, 2007, if an acquirer has a Level 1 or Level 2 merchant who is still retaining full-track data, Card Verification Value (CVV2) or PIN data after the transaction authorization, Visa can fine the acquirer up to $10,000 a month per merchant, if progress toward compliance is not made in a timely manner.
According to the Visa Web site, Level 1 and 2 merchants must validate that prohibited data is not retained subsequent to authorization by submitting a completed Prohibited Data Retention Attestation form or Confirmation of Report Accuracy form to their acquirer by March 31, 2007.
It's up to the specific acquirer, along with the issuing credit card company, to educate and enforce their merchants, vendors, service providers, or any entity that stores or processes credit card data, to comply and validate PCI DSS and CISP standards.
If you are a merchant, vendor or service provider reading this information for the first time, it might be time-or past time-to question and contact your acquirer and credit card issuer.
To take it one step further, in 2006, Visa levied $4.6 million in fines, up from a 2005 total of $3.4 million, to its acquirers.
PCI DSS 1.1 sets an enforcement date for acquirers to validate PCI compliance for Level 1 and Level 2 merchants.
The enforcement dates are as follows:
- Level 1 Merchants-Enforcement date: September 30, 2007
- New Level 1 Merchants-Enforcement date: One year after identification as Level 1
- Level 2 Merchants-Enforcement date: December 31, 2007
- New Level 2 Merchants-Enforcement date: September 20, 2007
- Level 1 and 2 Merchants-Prohibited Data Retention Attestation form, or Confirmation of Report Accuracy to acquirer by March 31, 2007
- Level 3 Merchants-Contact acquirer or credit card company.
- Level 4 Merchants-Must have compliance plan submitted, via acquirer, to Visa by July 30,2007.
As of March 31, 2007, if an acquirer has a Level 1 or Level 2 merchant who is still retaining full-track data, Card Verification Value (CVV2) or PIN data after the transaction authorization, Visa can fine the acquirer up to $10,000 a month per merchant, if progress toward compliance is not made in a timely manner.
According to the Visa Web site, Level 1 and 2 merchants must validate that prohibited data is not retained subsequent to authorization by submitting a completed Prohibited Data Retention Attestation form or Confirmation of Report Accuracy form to their acquirer by March 31, 2007.
Calculating Merchant Transactions
According to the Visa, Inc. CISP Program Web site, merchants fall into one of the four merchant levels based on Visa transaction volume over a 12-month period. MasterCard's SDP is similar to Visa's CISP program.
Gathering the correct numbers for transaction volume can be confusing, but for Visa, Inc., the merchant's transaction volume is based on the aggregate number of Visa transactions-credit cards, debit cards, prepaid cards-from a merchant Doing Business As ("DBA").
For merchants and/or merchant corporations who operate more than one DBA, the aggregate volume of stored, processed or transmitted transactions by the corporate entity must be considered, to determine the validation level.
If the corporate entity does not store, process or transmit cardholder data on behalf of the multiple DBAs, members will continue to consider the DBA's individual transaction volume to determine the validation level.
Confusing?
Here is Kark's answer to the same question about how to calculate transactions for more than one merchant.
"If an organization has several merchants, you have to aggregate all of those [merchant transaction] numbers, in order to come up with a number that you have in terms of the credit card data that resides within your organization, and the amount of transactions that you are processing within your organization," said Kark.
Continuing, he said, "If you house credit card information, in whatever form, if you house it in your server, that you own or you added, then you are basically responsible for complying with PCI…merchants need to be added [to the transaction volume] if you are housing credit card information for the specific merchant."
Gathering the correct numbers for transaction volume can be confusing, but for Visa, Inc., the merchant's transaction volume is based on the aggregate number of Visa transactions-credit cards, debit cards, prepaid cards-from a merchant Doing Business As ("DBA").
For merchants and/or merchant corporations who operate more than one DBA, the aggregate volume of stored, processed or transmitted transactions by the corporate entity must be considered, to determine the validation level.
If the corporate entity does not store, process or transmit cardholder data on behalf of the multiple DBAs, members will continue to consider the DBA's individual transaction volume to determine the validation level.
Confusing?
Here is Kark's answer to the same question about how to calculate transactions for more than one merchant.
"If an organization has several merchants, you have to aggregate all of those [merchant transaction] numbers, in order to come up with a number that you have in terms of the credit card data that resides within your organization, and the amount of transactions that you are processing within your organization," said Kark.
Continuing, he said, "If you house credit card information, in whatever form, if you house it in your server, that you own or you added, then you are basically responsible for complying with PCI…merchants need to be added [to the transaction volume] if you are housing credit card information for the specific merchant."
PCI DSS: Visa and MasterCard Quick Reference Guide
Merchant, Service Provider and Compliance Level 1
Merchant Qualification Criteria for Visa and MasterCard:
Merchant, Service Provider and Compliance Level 2
Merchant Qualification Criteria:
Merchant and Service Provider Compliance Level 3
Merchant Qualification Criteria:
Merchant and Service Provider Compliance Level 4
Merchant Qualification Criteria:
Suggested Links:
Step 3: Attaining PCI DSS Compliance-Merchant
Merchant Qualification Criteria for Visa and MasterCard:
- Retail and eCommerce Merchants with greater than 6 million Visa and MasterCard transactions annually.
- Merchants that have suffered a hack or an attack that resulted in an account data compromise.
- Merchants that Visa and MasterCard determines should meet the Level 1 merchant requirements to minimize risk to the Visa system, or merchants identified by any other payment card brand as Level 1.
- Visa-All VisaNet processors (member and Nonmember) and all payment gateways--agent or service provider that stores, processes, and/or transmits cardholder data as part of a payment transaction.
- MasterCard-All TPPs and DSE's that store account data on behalf of Level 1 or Level 2 merchants.
- Visa-- Annual onsite review by a QSA or Internal Audit if signed by Officer of the company, and a quarterly network security scan with an ASV.
- MasterCard-Annual onsite review by merchant's internal auditor or a Qualified Security Assessor (QSA), and a quarterly network security scan with an Approved Scanning Vendor (ASV).
Merchant, Service Provider and Compliance Level 2
Merchant Qualification Criteria:
- E-Commerce merchants with 150,000 to 6 million Visa or MasterCard transactions annually.
- All merchants meeting the Level 2 criteria of a competing payment brand.
- Visa--Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.
- MasterCard--Includes all those DSEs that store account data on behalf of level 3 merchants.
- Visa-Annual onsite review by QSA and quarterly network security scan with an approved ASV.
- MasterCard-- Annual onsite review by QSA and quarterly network security scan with an approved ASV.
Merchant and Service Provider Compliance Level 3
Merchant Qualification Criteria:
- Visa-Merchants with annual e-commerce transactions greater than 20,000 but less than one million total transactions.
- MasterCard-Merchants with annual e-commerce transactions greater than 20,000 but less than one million total transactions, and all merchants meeting the Level 3 criteria of a competing payment brand.
- Visa- Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.
- MasterCard-All other DSEs not included in Levels 1 and 2.
- Visa-Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV.
- MasterCard-Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV.
Merchant and Service Provider Compliance Level 4
Merchant Qualification Criteria:
- Visa-Merchants processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants regardless of acceptance channel processing up to 1,000,000 Visa transactions per year. Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV. Acquirer submits summary of PCI compliance plan to Visa by July 30, 2007. If a breach has been reported, or found, Visa reserves the right to move the Level 4 merchant to a Level 1. If so, the Level 4 merchant must abide by the Level 1 validation requirements. (See Level 4 Merchant Compliance for more information).
- MasterCard-Any other merchant not covered in Level 1, Level 2 and Level 3 compliance qualifications. " Validation Requirement:
- Visa--Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV. Complete a
- MasterCard-Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV.
Suggested Links:
- https://www.pcisecuritystandards.org/pdfs/pci_saq_v1-0.pdf
- https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
- http://usa.visa.com/merchants/risk_management/
cisp_merchants.html?it=l2|/merchants/
risk_management/cisp.html|Merchants - http://usa.visa.com/merchants/risk_management/
cisp_service_providers.html?it=l2|/merchants/risk_management/
cisp_merchants.html|Service%20Providers - http://www.mastercard.com/us/sdp/merchants/
merchant_requirements.html - http://www.mastercard.com/us/sdp/serviceproviders/
serviceprovider_requirements.html
Security Audits: 12 Requirements
If a merchant, Independent Sales Organization (ISO) or service provider is at a Level 1 or Level 2, one of the major PCI DSS validation components is the Annual On-Site PCI Data Security Assessment, which is based entirely from the PCI DSS Audit Procedures document.
Merchants and service providers should select a Qualified Security Assessor (QSA) to perform the audit or-in the case of a Level 1 merchant or service provider-an internal audit, signed by the chief officer for the organization.
Visa and MasterCard offer a list of approved QSAs on their Web site. These assessors should strictly adhere to the Audit Procedures document and complete the mandatory Report on Compliance required for PCI certification and validation on behalf of the merchant or service provider.
According to the PCI Security Standards Council, all QSAs must attend a training class and pass an exam in order to have a basic knowledge and understanding of PCI DSS.
The actual PCI Data Security Standards include 12 major requirements for validation and certification under six main auditing areas or "control objectives".
All of the compliance areas include basic security rules that most merchants and service providers should already have in place, or have a familiarity with them when audited.
The six main control objectives for PCI DSS compliance and validation are as follows:
Merchants and service providers should select a Qualified Security Assessor (QSA) to perform the audit or-in the case of a Level 1 merchant or service provider-an internal audit, signed by the chief officer for the organization.
Visa and MasterCard offer a list of approved QSAs on their Web site. These assessors should strictly adhere to the Audit Procedures document and complete the mandatory Report on Compliance required for PCI certification and validation on behalf of the merchant or service provider.
According to the PCI Security Standards Council, all QSAs must attend a training class and pass an exam in order to have a basic knowledge and understanding of PCI DSS.
The actual PCI Data Security Standards include 12 major requirements for validation and certification under six main auditing areas or "control objectives".
All of the compliance areas include basic security rules that most merchants and service providers should already have in place, or have a familiarity with them when audited.
The six main control objectives for PCI DSS compliance and validation are as follows:
- Build and Maintain a Secure Network
- Protect Cardholder Data
- Maintain a Vulnerability Management Program
- Implement Strong Access Control Measures
- Regularly Monitor and Test Networks
Build and Maintain a Secure Network
In order to build and maintain a secure network, and to comply with the PCI DSS, system components, network components, and data elements related to authorization, data retention, data storage and data transmitting must be secure.
This article gives a high level overview of the PCI DSS and is a brief overview of the audit checklist. Please refer to the PCI DSS documentation and the PCI Security Standards Web site for a detailed breakdown of all requirements.
The scope of PCI DSS for Level 1 merchants includes the following areas:
POS needs its own category, because depending on the type of POS environment that exists for a merchant, that type will determine whether it needs to be included in the audit.
If the POS environment is IP-based, along with having external access via the Internet, wireless device, Virtual Private Network (VPN), dial-up connection, broadband connection, or with accessible machines like kiosks to the merchant location, the POS environment is required to be in the scope of the on-site review.
If the POS environment is neither IP-based, nor does it have an external connection or access to the merchant location, then the on-site audit begins at the point of connection into the authorization and settlement environment. Wireless Environments
According to the PCI DSS, Wireless environments and technologies are the least secure. The technologies are still considered fairly new, and caution is encouraged for any merchant or service provider who is considering using a wireless environment.
The rules, according to version 1.1 of PCI DSS, are as follows:
For merchants that outsource storage, processing or transmission of credit card data to third party service providers, separate Report on Compliance documents must explain the role of each service provider.
Conversely, all service providers are responsible for validating their own compliance with the PCI DSS requirements, independent of their customers' audits.
Merchants and service providers must work together, producing a contract to submit to all associated third parties, which states that the third-party service providers will agree to follow the PCI DSS.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data A firewall protects all traffic in and out of an organization's network, and it examines all network traffic, while blocking intrusive or unknown transmissions that do not meet the security criteria.
According to PCI DSS, installing and maintaining a firewall that protects the merchant or service provider from unauthorized access from the Internet by Internet-based access through desktops, employee email accounts and/or e-commerce are key protection mechanisms for any computer network.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf, 1.1-1.5.for more information.
Requirement 2: Don't use vendor-supplied defaults for system passwords and other security parameters
This requirement is pretty self-explanatory, as vendor-supplied defaults for system passwords are easily hacked. In the world of the hacker, it's the first and easiest way to infiltrate a network system.
Though there are many other checkpoints for auditing purposes, the gist of this requirement is to always change vendor-supplied defaults before installing a system on the network (for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts).
For wireless environments, the audit includes checking the vendor defaults, the wireless equivalent privacy (WEP) keys; default service set identifier (SSID), passwords and SNMP community strings.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf 2.1-2.5 for more information.
This article gives a high level overview of the PCI DSS and is a brief overview of the audit checklist. Please refer to the PCI DSS documentation and the PCI Security Standards Web site for a detailed breakdown of all requirements.
The scope of PCI DSS for Level 1 merchants includes the following areas:
- Cardholder Data-Primary Account Number, Cardholder Name, Service Code, Expiration Data, Full Magnetic Stripe, CVC2/CVV2/CID, PIN/PIN Block, including any data repository outside of the authorization environment, where more than 50,000 or more account numbers reside.
- System Components-Network components, servers or applications included or connected to cardholder data. Applications include all purchased and proprietary/custom applications, as well as internal and external Internet applications. (External connections into the merchant network like employee remote access, VisaNet and third party access for processing and maintenance).
- Network Components-Firewalls, switches, routers, wireless access points, network appliances and other security appliances. Server types include: Web, database, authentication, mail, proxy, network time protocol (NTP) and domain name server (DNS) (all connections to and from the authorization and settlement environment, such as connections for employee access or for devices such as firewalls and routers).
POS needs its own category, because depending on the type of POS environment that exists for a merchant, that type will determine whether it needs to be included in the audit.
If the POS environment is IP-based, along with having external access via the Internet, wireless device, Virtual Private Network (VPN), dial-up connection, broadband connection, or with accessible machines like kiosks to the merchant location, the POS environment is required to be in the scope of the on-site review.
If the POS environment is neither IP-based, nor does it have an external connection or access to the merchant location, then the on-site audit begins at the point of connection into the authorization and settlement environment. Wireless Environments
According to the PCI DSS, Wireless environments and technologies are the least secure. The technologies are still considered fairly new, and caution is encouraged for any merchant or service provider who is considering using a wireless environment.
The rules, according to version 1.1 of PCI DSS, are as follows:
- If wireless technology is used to store, process or transmit credit card data, Requirements and Testing Procedures for wireless environments apply and are mandatory.
- If a wireless local area network (LAN) is connected to, or is a part of the cardholder environment, Requirements and Testing Procedures for wireless environments apply and are mandatory.
- If a merchant wishes to use wireless technologies or environments, consider using wireless technologies for only non-sensitive data transmission.
For merchants that outsource storage, processing or transmission of credit card data to third party service providers, separate Report on Compliance documents must explain the role of each service provider.
Conversely, all service providers are responsible for validating their own compliance with the PCI DSS requirements, independent of their customers' audits.
Merchants and service providers must work together, producing a contract to submit to all associated third parties, which states that the third-party service providers will agree to follow the PCI DSS.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data A firewall protects all traffic in and out of an organization's network, and it examines all network traffic, while blocking intrusive or unknown transmissions that do not meet the security criteria.
According to PCI DSS, installing and maintaining a firewall that protects the merchant or service provider from unauthorized access from the Internet by Internet-based access through desktops, employee email accounts and/or e-commerce are key protection mechanisms for any computer network.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf, 1.1-1.5.for more information.
Requirement 2: Don't use vendor-supplied defaults for system passwords and other security parameters
This requirement is pretty self-explanatory, as vendor-supplied defaults for system passwords are easily hacked. In the world of the hacker, it's the first and easiest way to infiltrate a network system.
Though there are many other checkpoints for auditing purposes, the gist of this requirement is to always change vendor-supplied defaults before installing a system on the network (for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts).
For wireless environments, the audit includes checking the vendor defaults, the wireless equivalent privacy (WEP) keys; default service set identifier (SSID), passwords and SNMP community strings.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf 2.1-2.5 for more information.
Requirement 3: Protect stored card holder data
The basic tenet of Requirement 3 is to make sure that all sensitive cardholder data is unreadable, no matter where it is stored-portable media, backup media, logs, or wireless networks.
As well, storing sensitive credit card data such as the full magnetic strip track data, CVV and CVV2 is prohibited under PCI DSS.
However there is an exception to this rule. In instances where some of the data elements are needed from the magnetic stripe track data, storing the accountholders name, primary account number (PAN), expiration and service code is acceptable.
At no time should a merchant or service provider store the card verification code or PIN verification data elements.
Other methods of cardholder data protection include truncating cardholder data if full PAN is not needed, and not sending PAN in an unencrypted e-mail.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf 3.1--3.6 for more information.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
One of the major reasons TJX Companies, Inc. suffered the massive data breach that they did was due, in part, to faulty encryption security.
TJX management believes that hackers were able to get their hands on the decryption software, rendering the network system hostage to the hackers' whims.
If TJX had had a strong encryption program, the hackers could have gained access to the encrypted data, but they would not be able to read the data without the proper cryptographic keys.
Confusion abounds concerning this requirement, however one of the most reliable encryption algorithms is AES-256.
AES is the official encryption algorithm of the U.S. government, and information encrypted with it is considered secure until the year 2030. AES offers 128, 196 and 256 key lengths, making it very secure. Data stored with AES cannot be decrypted without the key.
A QSA assessor can research and decide on the effectiveness of AES and/or other algorithms.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf 4.1-4.2 for more information.
The basic tenet of Requirement 3 is to make sure that all sensitive cardholder data is unreadable, no matter where it is stored-portable media, backup media, logs, or wireless networks.
As well, storing sensitive credit card data such as the full magnetic strip track data, CVV and CVV2 is prohibited under PCI DSS.
However there is an exception to this rule. In instances where some of the data elements are needed from the magnetic stripe track data, storing the accountholders name, primary account number (PAN), expiration and service code is acceptable.
At no time should a merchant or service provider store the card verification code or PIN verification data elements.
Other methods of cardholder data protection include truncating cardholder data if full PAN is not needed, and not sending PAN in an unencrypted e-mail.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf 3.1--3.6 for more information.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
One of the major reasons TJX Companies, Inc. suffered the massive data breach that they did was due, in part, to faulty encryption security.
TJX management believes that hackers were able to get their hands on the decryption software, rendering the network system hostage to the hackers' whims.
If TJX had had a strong encryption program, the hackers could have gained access to the encrypted data, but they would not be able to read the data without the proper cryptographic keys.
Confusion abounds concerning this requirement, however one of the most reliable encryption algorithms is AES-256.
AES is the official encryption algorithm of the U.S. government, and information encrypted with it is considered secure until the year 2030. AES offers 128, 196 and 256 key lengths, making it very secure. Data stored with AES cannot be decrypted without the key.
A QSA assessor can research and decide on the effectiveness of AES and/or other algorithms.
See https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf 4.1-4.2 for more information.
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software
Across the board, whether merchant, service provider, or average citizen, up-to-date anti-virus software can protect systems from viruses and malicious intrusions.
The three main points of this requirement are:
Requirement 6: Develop and maintain secure systems and applications
Continuously updated, vendor-provided security patches and software patches can stop hackers from gaining access to network systems.
Attacks can come from not only hackers, but also employees and viruses.
The following PCI DSS requisites represent a sample of Requirement 6:
Across the board, whether merchant, service provider, or average citizen, up-to-date anti-virus software can protect systems from viruses and malicious intrusions.
The three main points of this requirement are:
- Deploy anti-virus software on all systems commonly affected by viruses-Personal computers and servers.
- Ensure that anti-virus programs are capable of detecting, removing, and protecting against other forms of malicious software, including spyware and adware.
- Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.
Requirement 6: Develop and maintain secure systems and applications
Continuously updated, vendor-provided security patches and software patches can stop hackers from gaining access to network systems.
Attacks can come from not only hackers, but also employees and viruses.
The following PCI DSS requisites represent a sample of Requirement 6:
- All systems must have the most recently released appropriate software patches to protect against exploitation by employees, external hackers, and viruses.
- Implement a process to identify newly discovered security vulnerabilities-Subscribe to alert services on the Internet, or via anti-virus software.
- Develop software applications based on industry best practices-Visa's Payment Application Best Practices (PABP), for payment applications.
- Test all security patches system and software configurations before deployment.
- Removal of custom application accounts, usernames and passwords before applications become active or are released to customers.
- Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.
Implement Strong Access Control Measures
Requirement 7: Restrict to cardholder data by business need to know
One of the most common, yet overlooked, vulnerability for any organization and for the systems within that organization, is a lax access control policy.
Many organizations still allow employees, with no direct connection with the data, to view sensitive cardholder data or to access network systems.
In order to adhere to Requirement 7, a merchant or service provider must do the following:
Requirement 8: Assign a unique ID to each person with computer access
In order to comply with PCI DSS, each computer user in your organization should be assigned a unique ID, before you allow the user to access your system and the cardholder data stored within your system.
The following PCI DSS requisites represent a sample of Requirement 8:
Requirement 9: Restrict physical access to Cardholder data
The lack of enforcing restrictions on an employee's physical proximity to sensitive data, such as credit card data, continues to be a very common and basic violation.
This requirement forces organizations to apply rules on access and proximity to the actual credit card data, and it develops procedures to identify employees and visitors.
The following PCI DSS requisites represent a sample of Requirement 9:
One of the most common, yet overlooked, vulnerability for any organization and for the systems within that organization, is a lax access control policy.
Many organizations still allow employees, with no direct connection with the data, to view sensitive cardholder data or to access network systems.
In order to adhere to Requirement 7, a merchant or service provider must do the following:
- Computing resources and cardholder information-Limit access to employees whose job requires that they have access to the data.
- Implement a "deny all" mechanism-For systems with multiple users, put in place a mechanism that automatically denies any employee who is not authorized to view the data.
Requirement 8: Assign a unique ID to each person with computer access
In order to comply with PCI DSS, each computer user in your organization should be assigned a unique ID, before you allow the user to access your system and the cardholder data stored within your system.
The following PCI DSS requisites represent a sample of Requirement 8:
- Employ either a password, token devices, or Biometrics.
- Use remote authentication, dial-in service, terminal access, controller access, controller system (TCACS) with tokens, or VPN with individual certificates for employees, administrators and third parties.
- Encrypt all passwords during transmission and storage on all system components.
Requirement 9: Restrict physical access to Cardholder data
The lack of enforcing restrictions on an employee's physical proximity to sensitive data, such as credit card data, continues to be a very common and basic violation.
This requirement forces organizations to apply rules on access and proximity to the actual credit card data, and it develops procedures to identify employees and visitors.
The following PCI DSS requisites represent a sample of Requirement 9:
- Restrict physical access to wireless access points, gateways and handheld devices.
- Restrict physical access to publicly accessible network jacks.
- Store media back-ups in a secure location, preferably an off-site facility.
- Physically secure all paper and electronic media-computers, electronic media, networking and communications.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor access to network resources and Cardholder data
The use of logging mechanisms and audit trials allow an organization to track user activities. According to the PCI DSS, having the ability to log and track helps to determine where a problem occurred.
The following PCI DSS requisites represent a sample of Requirement 10:
Requirement 11: Regularly test security systems and processes
Without continual testing of the security systems in place, hackers can capitalize on system-wide vulnerabilities within processes and custom software.
The following PCI DSS requisites represent a sample of Requirement 11:
Maintain an information security policy
Requirement 12: Maintain a policy that addresses information security
One of the most basic tools to combat a security breach is an actual written policy for all employees in the organization.
As the PCI DSS states, "A strong security policy sets the security tone for the whole company and informs the employees what is expected of them."
The following PCI DSS requisites represent a sample of Requirement 12:
Step 4: Finding a PCI DSS Approved Scanning Vendor (ASV)
The use of logging mechanisms and audit trials allow an organization to track user activities. According to the PCI DSS, having the ability to log and track helps to determine where a problem occurred.
The following PCI DSS requisites represent a sample of Requirement 10:
- Establish a process for linking all access to system components to each individual user.
- Implement automated audit trails for all system components, with administrative privileges to each individual.
- Secure audit trails so they cannot be altered.
- Limit viewing of audit trails to those with a job-related need.
- Promptly back up audit trail files to a centralized log server or media that is difficult to alter.
Requirement 11: Regularly test security systems and processes
Without continual testing of the security systems in place, hackers can capitalize on system-wide vulnerabilities within processes and custom software.
The following PCI DSS requisites represent a sample of Requirement 11:
- Quarterly Security Testing-Test all security controls, network connections and restrictions annually, and use a wireless analyzer at least quarterly to identify all wireless devices in use.
- Quarterly Vulnerability Scans-Run internal and external network vulnerability scans quarterly, especially after any change in the network.
- Penetration Testing-Once a year, perform penetration testing, especially after an operation system upgrade, a sub-network added to the environment, or a web server added to the environment.
Maintain an information security policy
Requirement 12: Maintain a policy that addresses information security
One of the most basic tools to combat a security breach is an actual written policy for all employees in the organization.
As the PCI DSS states, "A strong security policy sets the security tone for the whole company and informs the employees what is expected of them."
The following PCI DSS requisites represent a sample of Requirement 12:
- Establish, publish, maintain, and disseminate a security policy that addresses all of the requirements in the specifications.
- Develop daily operational security procedures that are consistent with requirements in this specification.
- Develop usage polices for critical employee-facing technologies to define proper use of these technologies for all employees and contractors.
- Prohibit cardholder data storage onto local hard drives, floppy disks, or other external media, when accessing cardholder data remotely via a modem.
In order to meet the quarterly network scanning requirements, merchants and service providers with a Level of 1, 2, 3, 4, need an ASV to facilitate the scanning.
Any merchant or service provider with annual transactions totaling 10,000 or more is required to have a quarterly network system scan.
According to the PCI Security Standards Council, the MasterCard ASV program was terminated on or about October 7, 2006, and Visa International's QSA certification program transitioned from October to December 2006 to revert to the PCI SSC's guidelines and ASV lists.
Currently, the PCI Security Standards Council administers all ASV contracts, and the PCI SSC also trains and certifies ASVs.
All scans must be conducted by an ASV and are required to conduct scans in accordance with the "Technical and Operational Requirements for Approved Scanning Vendors (ASVs)" procedures.
The main points of the technical and operational requirements for ASVs are as follows:
Any merchant or service provider with annual transactions totaling 10,000 or more is required to have a quarterly network system scan.
According to the PCI Security Standards Council, the MasterCard ASV program was terminated on or about October 7, 2006, and Visa International's QSA certification program transitioned from October to December 2006 to revert to the PCI SSC's guidelines and ASV lists.
Currently, the PCI Security Standards Council administers all ASV contracts, and the PCI SSC also trains and certifies ASVs.
All scans must be conducted by an ASV and are required to conduct scans in accordance with the "Technical and Operational Requirements for Approved Scanning Vendors (ASVs)" procedures.
The main points of the technical and operational requirements for ASVs are as follows:
- The normal customer environment is not to be impacted.
- The ASV should never penetrate or alter the customer environment.
- https://www.pcisecuritystandards.org/pdfs/asv_report.html
- https://www.pcisecuritystandards.org/
pdfs/pci_dss_
validation_requirements_for_approved_scanning_vendors
_ASVs_v1-1.pdf - https://www.pcisecuritystandards.org/pdfs/
pci_dss_technical_and_operational
_requirements_for_approved_scanning_
vendors_ASVs_v1-1.pdf
Merchant and Service Provider Scanning Requirements
PCI Security Scans provide merchants and service providers with invaluable information concerning their network system and work hand-in-hand with a comprehensive vulnerability management program.
PCI approved scans can help a merchant or service provider find misconfigurations of Web sites, applications and IT infrastructures with Internet-facing IP addresses
The results of a PCI approved scan can provide knowledge that can lead to efficient patch management and other security measures that can rectify problems and improve protection against future Internet attacks.
The following is an overview of the basic scanning requirements for merchants, service providers and ASVs:
In order to be PCI DSS compliant, or compliant with any card brand program, a scan must not contain any vulnerability concerning features or configurations that are a PCI DSS violation.
If the ASV determines that these exist, the ASV meets with the merchant or service provider to determine if these are really PCI DSS violations. If so, the ASV issues a noncompliant scan report.
High-level vulnerabilities are designated as level 3, 4, or 5.
Level 5 VulnerabilitiesLevel 5-Urgent-With this level of vulnerability, hackers can compromise the entire host. This vulnerability type allows hackers to have complete access to full file-system read and write capabilities, remote execution of commands as a root or administrator user, as well as the presence of backdoors and Trojans.
Level 4 Vulnerabilities
Level 4-Critical-Gives hackers partial access to file-systems and also provides them with remote user capabilities. These vulnerabilities expose highly sensitive information.
Level 3 Vulnerabilities
Level 3-High-Gives hackers access to information stored on the host, including security settings. It sets up misuse of the host by intruders. Examples include access to specific files, denial of service attacks, directory browsing, mail relaying.
Level 2 Vulnerabilities
Level 2-Medium-Gives hackers a chance to research attacks against the host, and access to some sensitive information from the host, such as exact versions of services.
Level 1 Vulnerabilities
Level 1--vulnerabilities expose information, such as open ports. Information can be obtained by hackers on configuration.
Suggested Links:
https://www.pcisecuritystandards.org/pdfs
/pci_scanning_procedures_v1-1.pdf
PCI approved scans can help a merchant or service provider find misconfigurations of Web sites, applications and IT infrastructures with Internet-facing IP addresses
The results of a PCI approved scan can provide knowledge that can lead to efficient patch management and other security measures that can rectify problems and improve protection against future Internet attacks.
The following is an overview of the basic scanning requirements for merchants, service providers and ASVs:
- Internet-facing IP Addresses--Merchants and service providers must scan their web sites or IT infrastructures that have externally facing IP addresses. If active IP addresses are found that were not originally provided by the customer, the ASV must consult with the customer to determine if these IP addresses should be in scope. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible.
- Domain-based virtual hosting-- Provide the ASV with a list of all domains that should be scanned if domain-based virtual hosting is used.
- Defining the scope of the scan-If an organization has a large number of IP addresses, but they only use a small number for card acceptance or processing, the ASV can help the merchant or service provider define the scope of the network scan.
- Applying segmentation-To reduce the scope of the network scan, an ASV can actually help the merchant or service provider segment the IP addresses in one of two ways: (1) by providing physical segmentation between the segment handling cardholder data and other segments, and (2) by employing appropriate logical segmentation where traffic is prohibited.
- Filtering devices-- The ASV must scan all filtering devices such as firewalls or external routers (if used to filter traffic). Firewalls and routers, used to establish a demilitarized zone (DMZ) must also be scanned for vulnerabilities.
- Web Servers-Internet users view Web pages, and/or buy merchandise through Web merchants via a Web server. Because these servers are fully accessible from the public Internet, scanning for vulnerabilities is essential.
- Application Servers-When a cardholder sends account numbers in a transaction with a merchant or service provider, the application server is the actual interface that allows data to be transferred in and out of a network via backend databases. The ASV must scan application servers, or the Web server itself, when it's configured to act as an application server.
- Domain Name Servers (DNS)-The DNS server is the server that translates domain names into IP addresses. A merchant or service provider either uses the DNS provided by an Internet Service Provider (ISP), or their own DNS. Either way, an AVS must scan all DNSs, because hackers can create a fake merchant or service provider Web site, and ask for and collect credit card data fraudulently on behalf of the organization.
- Mail Servers-ASVs must scan mail servers, as mail servers are routinely vulnerable to hacker attacks.
- Scan all Load Balancers-If merchants or service providers use a load balancer to spread the traffic load to more than one server, then they should scan all of the individual servers behind the load balancer.
- Virtual Hosts-If a merchant or service provider shares a server through a Web hosting company, then they are also sharing that server with the other customers of that Web hosting company. It's the merchant or service provider's responsibility to request that their hosting company provide a scan of their entire Internet-facing IP range and demonstrate compliance, while the merchant or service providers are required to have their own domains scanned by an ASV.
- Wireless Access Points-Wireless LANs (WLANs) set up data security risks-like misconfigurations-that need to be identified and resolved. The ASV must scan wireless access points in wireless LANs (WLANs), along with other wireless components that are connected to the Internet.
- Intrusion detection and prevention-Merchants and service providers must configure the intrusion detection system/intrusion prevention system (IDS/IPS) to accept the originating IP address of the ASV. If this is not feasible, the scan should originate in a location that prevents IDS/IPS interference.
Vulnerability Levels
Based on the results of the network scan, ASVs produce an exhaustive report that describes the following:- Vulnerability type or risk
- Diagnosis of issues linked to the vulnerability type
- Consult on how to fix or patch the isolated vulnerabilities
- Assign a rating for vulnerabilities
In order to be PCI DSS compliant, or compliant with any card brand program, a scan must not contain any vulnerability concerning features or configurations that are a PCI DSS violation.
If the ASV determines that these exist, the ASV meets with the merchant or service provider to determine if these are really PCI DSS violations. If so, the ASV issues a noncompliant scan report.
High-level vulnerabilities are designated as level 3, 4, or 5.
Level 5 VulnerabilitiesLevel 5-Urgent-With this level of vulnerability, hackers can compromise the entire host. This vulnerability type allows hackers to have complete access to full file-system read and write capabilities, remote execution of commands as a root or administrator user, as well as the presence of backdoors and Trojans.
Level 4 Vulnerabilities
Level 4-Critical-Gives hackers partial access to file-systems and also provides them with remote user capabilities. These vulnerabilities expose highly sensitive information.
Level 3 Vulnerabilities
Level 3-High-Gives hackers access to information stored on the host, including security settings. It sets up misuse of the host by intruders. Examples include access to specific files, denial of service attacks, directory browsing, mail relaying.
Level 2 Vulnerabilities
Level 2-Medium-Gives hackers a chance to research attacks against the host, and access to some sensitive information from the host, such as exact versions of services.
Level 1 Vulnerabilities
Level 1--vulnerabilities expose information, such as open ports. Information can be obtained by hackers on configuration.
Suggested Links:
https://www.pcisecuritystandards.org/pdfs
/pci_scanning_procedures_v1-1.pdf
Though the PCI SSC has assumed ownership and management of Visa and MasterCard's compliance reporting programs, it's still incumbent upon merchants and service providers to follow each card company's compliance reporting requirements, to ensure that the card company accepts and verifies their compliance status.
Compliance reports must be submitted according to each card's requirements. According to the PCI SCC, payment brands-MasterCard, Visa, American Express, Discover-will continue to focus on compliance of the security standards.
"Any entity that achieves PCI DSS compliance will need to continue sending the appropriate compliance validation documentation to the payment brands, financial institutes, or other agents that have a contractual relationship with the compliant entity," According to the PCI SSC FAQ.
"PCI SSC cannot be the central repository for this information. Our focus will remain on defining effective payment-related security standards, as well as educating and providing resources to the marketplace to drive awareness and adoption of these standards."
Qualified Security Assessors (QSA)
As with the ASVs, the Qualified Security Assessors (QSAs) conduct PCI validation assessments compliant with the PCI DSS. The skill level and competence of a QSA must meet the PCI SSC standards.
Individual QSAs, who perform PCI Data Security Assessments for merchants and service providers must be approved as a Qualified Security Assessor ("QSA") by the PCI SSC.
The PCI SSC defines the qualifications for QSAs and ASVs, as well as training, testing and certifying both. The PCI SSC Web sites, and the Visa and MasterCard Web sites, post the lists of qualified QSAs.
Suggested Links:
Compliance reports must be submitted according to each card's requirements. According to the PCI SCC, payment brands-MasterCard, Visa, American Express, Discover-will continue to focus on compliance of the security standards.
"Any entity that achieves PCI DSS compliance will need to continue sending the appropriate compliance validation documentation to the payment brands, financial institutes, or other agents that have a contractual relationship with the compliant entity," According to the PCI SSC FAQ.
"PCI SSC cannot be the central repository for this information. Our focus will remain on defining effective payment-related security standards, as well as educating and providing resources to the marketplace to drive awareness and adoption of these standards."
Qualified Security Assessors (QSA)
As with the ASVs, the Qualified Security Assessors (QSAs) conduct PCI validation assessments compliant with the PCI DSS. The skill level and competence of a QSA must meet the PCI SSC standards.
Individual QSAs, who perform PCI Data Security Assessments for merchants and service providers must be approved as a Qualified Security Assessor ("QSA") by the PCI SSC.
The PCI SSC defines the qualifications for QSAs and ASVs, as well as training, testing and certifying both. The PCI SSC Web sites, and the Visa and MasterCard Web sites, post the lists of qualified QSAs.
Suggested Links:
Level 1 Merchants
According to the Visa Web site, the template for the Report on Compliance is the actual Annual On-Site PCI Data Security Assessment document.
In order to complete the Report on Compliance, Level 1 merchants need a Qualified Security Assessor (QSA) to complete the Report on Compliance and present the report to the merchant/service provider's acquirer.
A merchant's acquirer may choose to accept the Report on Compliance from a Level 1 merchant, with a letter signed by a merchant officer within the organization, along with the report. Level 1 merchants must also submit the Confirmation of Report Accuracy form completed by their QSA to their acquirers.
Once the acquirer accepts the information, the acquirer must submit the Confirmation of Report Accuracy form and a letter accepting the merchant's full compliance validation to Visa upon receipt and acceptance of the merchant's validation documentation.
Level 1, 2 and 3 Merchants
According to the Visa Web site, acquirers are responsible for ensuring that the quarterly network security scans required of their levels 1, 2, and 3 merchants are performed by an ASV. The Quarterly Network Security Scan may be required of level 4 merchants as specified by their acquirer.
Level 2 and Level 3 Merchants
Level 2 and 3 merchants must complete the Annual PCI Self-Assessment Questionnaire. Level 4 merchants may be required to complete the PCI Self-Assessment Questionnaire as specified by their acquirer.
Level 1 and Level 2 Service Providers
Level 1 and 2 service providers must complete the Annual Self-Assessment Questionnaire and Annual On-Site PCI Data Security Assessment. The results from both must be supplied to the acquirer, and the documents may serve as the template for the Report on Compliance.
Levels 1 and 2 service providers must employ a (QSA) to complete the Report on Compliance.
Level 1, 2 and 3 Service Providers
Level 1, 2, and 3 service providers are accountable for ensuring that an ASV performs a quarterly network scan on the Internet-facing network perimeter systems.
Level 3 Service Providers
Level 3 service providers must complete the Annual PCI Self-Assessment Questionnaire.
According to the Visa Web site, the template for the Report on Compliance is the actual Annual On-Site PCI Data Security Assessment document.
In order to complete the Report on Compliance, Level 1 merchants need a Qualified Security Assessor (QSA) to complete the Report on Compliance and present the report to the merchant/service provider's acquirer.
A merchant's acquirer may choose to accept the Report on Compliance from a Level 1 merchant, with a letter signed by a merchant officer within the organization, along with the report. Level 1 merchants must also submit the Confirmation of Report Accuracy form completed by their QSA to their acquirers.
Once the acquirer accepts the information, the acquirer must submit the Confirmation of Report Accuracy form and a letter accepting the merchant's full compliance validation to Visa upon receipt and acceptance of the merchant's validation documentation.
Level 1, 2 and 3 Merchants
According to the Visa Web site, acquirers are responsible for ensuring that the quarterly network security scans required of their levels 1, 2, and 3 merchants are performed by an ASV. The Quarterly Network Security Scan may be required of level 4 merchants as specified by their acquirer.
Level 2 and Level 3 Merchants
Level 2 and 3 merchants must complete the Annual PCI Self-Assessment Questionnaire. Level 4 merchants may be required to complete the PCI Self-Assessment Questionnaire as specified by their acquirer.
Level 1 and Level 2 Service Providers
Level 1 and 2 service providers must complete the Annual Self-Assessment Questionnaire and Annual On-Site PCI Data Security Assessment. The results from both must be supplied to the acquirer, and the documents may serve as the template for the Report on Compliance.
Levels 1 and 2 service providers must employ a (QSA) to complete the Report on Compliance.
Level 1, 2 and 3 Service Providers
Level 1, 2, and 3 service providers are accountable for ensuring that an ASV performs a quarterly network scan on the Internet-facing network perimeter systems.
Level 3 Service Providers
Level 3 service providers must complete the Annual PCI Self-Assessment Questionnaire.
MasterCard and Compliance Reporting
Level 1 Merchants
For the annual onsite review, MasterCard allows the review to be conducted by either the merchant's internal auditor or a QSA.
Level 1, 2, 3 and 4 Merchants
To fulfill the network-scanning requirement, all merchants must conduct scans on a quarterly basis using an Approved Scanning Vendor.
Level 4 Merchants
Level 4 Merchants should consult their acquirer to determine if compliance validation is also required.
Level 1 and 2 Service Providers
For the annual onsite review, MasterCard Service Providers must use a QSA.
Level 1, 2 and 3 Service Providers
For the quarterly network-scanning requirement, all Level 1, 2 and 3 service providers must use an AVS.
MasterCard SDP Compliance
Along with following PCI DSS, MasterCard merchants must follow these steps:
Step 5: Completing the PCI DSS Self Questionnaire
For the annual onsite review, MasterCard allows the review to be conducted by either the merchant's internal auditor or a QSA.
Level 1, 2, 3 and 4 Merchants
To fulfill the network-scanning requirement, all merchants must conduct scans on a quarterly basis using an Approved Scanning Vendor.
Level 4 Merchants
Level 4 Merchants should consult their acquirer to determine if compliance validation is also required.
Level 1 and 2 Service Providers
For the annual onsite review, MasterCard Service Providers must use a QSA.
Level 1, 2 and 3 Service Providers
For the quarterly network-scanning requirement, all Level 1, 2 and 3 service providers must use an AVS.
MasterCard SDP Compliance
Along with following PCI DSS, MasterCard merchants must follow these steps:
- Associate the level classification in the SDP Program.
- Go through the PCI documentation and compliance validation tools.
- Make contact with an approved vendor, if needed, and follow the compliance procedures.
- Validate compliance with acquirer--the acquirer will register you with MasterCard on an annual basis, signifying compliance with the SDP Program.
Completing the PCI DSS Self Questionnaire
For Level 2, 3 and-in some instances-Level 4 merchants and service providers, responding to the PCI Self Questionnaire is one validation requirement that must be met.
It is divided into six sections based on the 12 PCI DSS requirements.
It serves as somewhat of a checklist, to make certain that a merchant has completed the PCI DSS security steps to protect credit card data.
The questionnaire identifies any area of non-compliance.
Preparing to Answer
In order to properly answer the questionnaire, make sure to read and review the PCI Data Security Standard.
If, after going through the PCI DSS documents, your organization already meets the PCI SSC requirements, do the following:
In order to send a valid PCI Self Assessment Questionnaire, merchants/service providers have to answer all of the questions with a 'Yes' or 'N/A' in order to be compliant per the PCI DSS.
If a merchant/service provider answers 'No' to any question, the organization is deemed 'Non Compliant.'
The security threat areas identified by the questionnaire must be resolved, in conjunction with recommendations from the selected ASV or QSA.
Organizations must continue to retake the questionnaire, until all questions can be answered with a 'Yes' or 'N/A.'
Step 5: Sending the PCI DSS Questionnaire
Once the requirements have been met and the questionnaire has been completed, it should be sent to the merchant's acquiring bank alongside a successful PCI scan report from an approved scanning vendor.
As well, if the organization's acquirer or credit card brand requires other certifying documentation in addition to the questionnaire, those accompanying documents must be sent to the acquirer.
Please check with your acquirer or credit card company for more information.
Suggested Links:
It is divided into six sections based on the 12 PCI DSS requirements.
It serves as somewhat of a checklist, to make certain that a merchant has completed the PCI DSS security steps to protect credit card data.
The questionnaire identifies any area of non-compliance.
Preparing to Answer
In order to properly answer the questionnaire, make sure to read and review the PCI Data Security Standard.
If, after going through the PCI DSS documents, your organization already meets the PCI SSC requirements, do the following:
- Fill out the PCI Self Questionnaire.
- Convert the questionnaire to a PDF file.
- Send the document to your acquiring bank.
- Print and distribute the questionnaire to the appropriate authorities within your organization to obtain accurate answers.
- Take the steps necessary to establish a set of correct answers.
- Complete the questionnaire.
In order to send a valid PCI Self Assessment Questionnaire, merchants/service providers have to answer all of the questions with a 'Yes' or 'N/A' in order to be compliant per the PCI DSS.
If a merchant/service provider answers 'No' to any question, the organization is deemed 'Non Compliant.'
The security threat areas identified by the questionnaire must be resolved, in conjunction with recommendations from the selected ASV or QSA.
Organizations must continue to retake the questionnaire, until all questions can be answered with a 'Yes' or 'N/A.'
Step 5: Sending the PCI DSS Questionnaire
Once the requirements have been met and the questionnaire has been completed, it should be sent to the merchant's acquiring bank alongside a successful PCI scan report from an approved scanning vendor.
As well, if the organization's acquirer or credit card brand requires other certifying documentation in addition to the questionnaire, those accompanying documents must be sent to the acquirer.
Please check with your acquirer or credit card company for more information.
Suggested Links:
