Further underscoring the gravity of the situation, notice the amount of records stolen is rapidly increasing every year. Not only does this equate to bad publicity, but it also lends itself to increasing consumer costs. Hence, the quagmire merchants find themselves in: Do I assume status quo will repel hackers – and PCI auditors or, do I make an investment to help ensure a secure network? In the end, protecting consumer data is less costly than dealing with a security breach and precisely why the PCI Council was formed.

The PCI DSS specifies security requirements across many domains, from documentation and physical security to network encryption and software design, all designed to ensure the safe storage, transmission, and use of sensitive cardholder information.

As defined by the PCI Data Security Standard V1.1, “These security requirements apply to all ‘system components.’ System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that processes cardholder data or sensitive authentication data.”

This definition has indeed caused some heartburn among merchants, as they refer to these standards as too broad in scope — or too narrow in some instances — to actually comply with. In essence, there are 12 requirements and approximately 178 sub requirements to deal with.


Furthermore, organizations are required by credit card companies to comply with all these security requirements or face stiff penalties. Case-in-point: Under the new penalties issued by VISA last year, acquirers will be fined between $5,000 and $25,000 a month for each Level 1 or Level 2 merchant that is not validated PCI compliant by September 30, 2007, and December. 31, 2007, respectively.

However to add a twist, there is also an interesting cavetto to the all-or-nothing approach PCI mandate, found in Appendix B of the PCI Data Security Standard v1.1 requirements called, Compensating Controls. According to PCI Security Council’s Glossary, “Compensating controls may be considered when an entity cannot meet a requirement as explicitly stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement [3.4] through implementation of other controls.”

Requirement 3.4 deals with the Primary Account Number (PAN), or the payment card number that identifies the issuer and the particular cardholder account. The compensating controls may consist of either a device or combination of devices, applications and controls that meet all of the following conditions:

1. Provide additional segmentation
2. Provide ability to restrict access to cardholder data based on:
1. IP/MAC Address
2. Application Service
3. User Accounts/Groups
4. Data Type
3. Restrict logical access to the database
4. Prevent/detect common application or database attacks

Given all the routine daily tasks that must be performed by the IT personnel, no wonder it’s a seemingly impossible task to interrupt and implement PCI DSS. So it stands to reason why VISA recently reported that only 40% of Level 1 and one-third of Level 2 merchants have validated PCI compliance.