Welcome to the PCI
Security Standards Council's
Services & Professionals area!
The PCI DSS 3.0 and PA-DSS Version 3.0 Now Available!The latest version of the PCI DSS and PA-DSS is designed to provide greater clarity and flexibility to facilitate improved understanding of the requirements and eased implementation for merchants. Version 3.0 becomes effective on January 1, 2015.
Protecting Cardholder Data Is Good For Your Business
March 17, 2014
4th April - 5th April:ISA Training: Las Vegas, NV, United States.
6th April - 7th April:QSA Training: Las Vegas, NV, United States.
10th April - 12th April:P2PE Training: Las Vegas - NEW, NV, United States.
15th April - 16th April:ISA Training: Dallas, TX, United States.
22nd April - 23rd April:ISA Training: London, United Kingdom.
23rd April - 24th April:ISA Training: Porto Alegre, Brazil.
24th April - 25th April:QSA Training: London, United Kingdom.
27th April - 28th April:PA-QSA Training: London, United Kingdom.
29th April - 1st May:P2PE Training: London, United Kingdom.
Do QSAs and ASVs need to send reports of compliance (ROCs) or scanning results to the PCI Security Standards Council directly?
No. QSAs and ASVs do not send reports of compliance or scanning results to the PCI Security Standards Council, and they should continue to follow the payment brand specific procedures.
The requirements for Payment Application Data Security Standard (PA-DSS) are derived from the Payment Card Industry Data Security Standard (PCI DSS). This document details what is required for a merchant to be PCI DSS compliant (and therefore what a payment application must support to facilitate a merchant's PCI DSS compliance). Traditional PCI DSS compliance may not apply to payment application vendors since most vendors do not store, process, or transmit cardholder data. However, because these payment applications are used by merchants to store, process, and transmit cardholder data, and merchants are required to be PCI DSS compliant, payment applications should facilitate, and not prevent, merchants' PCI DSS compliance. Just a few of the ways payment applications can prevent a merchant's compliance are: 1) storage of magnetic stripe data in the merchant's network after authorization; 2) applications that require merchants to disable other features required by PCI DSS, such as anti-virus software or firewalls, and; 3) vendors that use unsecured methods to connect to the application to provide support to the merchant.
How will the PCI Security Standards Council evaluate assessors and scanning vendors and communicate approved providers to the marketplace?
The PCI Security Standards Council will maintain a robust evaluation program for approved security providers. The PCI Security Standards Council will regularly evaluate new QSAs for consideration within specified time frames during the course of a calendar year. Businesses that meet these qualifications and are approved will then be listed on the PCI Security Standards Council Web site. Information on how new QSAs should contact the PCI Security Standards Council can also be found on the PCI Security Standards Council Web site. In addition, the Web site will contain information about renewal processes for existing QSAs that wish to remain listed on the PCI Security Standards Council Web site. New ASV participation requests will continue to be evaluated during the course of a calendar year. Businesses that meet these qualifications and are approved will also be listed on the PCI Security Standards Council Web site. Renewal processes for ASVs will also be documented on the PCI Security Standards Council Web site.
PCI DSS requirement 3.3 requires that the PAN be masked when it is displayed (for example, on screens, logs, reports, receipts), unless the viewing party has a specific need to see the full card number. Business needs may exist to validate if the appropriate numbers were entered properly prior to completing the transaction (for example, for customer service representatives). To compensate for not masking the PAN on the screen for these types of transactions, controls such as Time To Live (TTL) or webpage "timeouts" should be deployed so that the screen does not display the card numbers indefinitely. Additionally, as should all websites that transmit cardholder data, the website which displays the PAN should be SSL enabled to ensure the data is secured as it is entered and validated.