When the Payment Card Industry Data Security Standard (PCI DSS) was first introduced in December 2004, the intent was to bring together guidance from the
While a single go-to document sounds like a fantastic idea in theory, it has proven to be impossible to support in practice. Emerging technologies, self-assessment questionnaires, and standards for devices outside of the original scope of PCI DSS, such as PIN-entry devices (PEDs), have led to a mini-explosion of supporting documents. The result is confused customers who aren’t always sure which documents they require or even where to start looking.
Security solution providers can help their customers navigate through the multiple PCI DSS documents by using this quick reference guide, which is divided into two parts. Part 1, below, contains descriptions of the most commonly needed documents, with links to the documents for quick access. It also contains descriptions of the self assessment questionnaires that solution providers may use to help customers determine their PCI levels.
2 of this quick reference guide covers PCI
documents related to emerging technologies and upcoming changes, as well as other documents and
resources that will be helpful to security solution providers.
PCI DSS and the Security Standards Council
The Security Standards Council website is the best place to start for all things PCI. The Council “is responsible for the development, management, education and awareness of the PCI Security Standards” and maintains a library of all the PCI documents. Regardless of the size of the company or the types of devices in use, if users store, process or transmit digital cardholder data, they need to be familiar with the PCI DSS itself. The standard includes both the requirements and the security assessment and testing procedures and presents them in a side-by-side columnar format. For Level-1 merchants (over 6 million single card brand transactions annually), the testing procedures describe what a Qualified Security Assessor (QSA) or approved internal auditor will complete during the Report On Compliance (RoC) assessment process.
To start helping your customer with PCI DSS compliance, you first need to determine which merchant level your customer is in. You can find out by referencing the MasterCard or Visa merchant-level pages.
For Level-1 merchants who accept MasterCard and choose to perform their RoC using internal resources, the auditors must complete the PCI Security Standards Council Internal Security Assessor (PCI SSC ISA) Program by June 30, 2011. Level-2 merchants (between 1 million and 6 million single card brand transactions) are eligible to perform SAQs (Self-Assessment Questionnaires) in lieu of RoCs, but must also complete the appropriate Security Standards Council (SSC) training. MasterCard provides an overview of the process in The Internal Security Assessor (ISA) Program document. More detailed information and a calendar of upcoming training classes are available at the SSC PCI ISA Training Program page.
Companies that process fewer than 6 million single card brand payments per year are eligible to complete the Self-Assessment Questionnaires (SAQ) and SAQ AOC.
Figuring out which SAQ to complete can be tricky. There are five SAQs: SAQ A, SAQ B, SAQ C, SAQ C-VT, and SAQ D. The best place to begin is with the SAQ Instructions and Guidelines. This document details the differences between the different SAQs, provides guidance on how entities can determine which SAQ they qualify for (check out page 17 “Which SAQ Best Applies to My Environment?”), and gives a good overview of the self-assessment process. SAQ also has its own AOC: AOC SAQ A, AOC SAQ B, AOC SAQ C, AOC SAQ D for Merchants, AOC SAQ D for Service Providers.
About the author:
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.
This was first published in June 2011