Disclaimer: This articles is a part of my research into PCI-DSS, and is not a definitive source of information
Payment Card Industry Data Security Standard, PCI-DSS for short, is a standard for organizations that handle cardholder data of branded credit cards from the major card schemes including Visa, MasterCard, and American Express. It is maintained by the PCI Security Secuirty Standards Council.
Non-compliance to PCI-DSS can result in a range of consequences, including range of fines and liability implications.
PCI-DSS defines cardholder data as follows:
- Full PAN (primary account number)
When the full PAN is present, other sensitive data includes:
- Cardholder name
- Expiration date
- Service code
It is allowable that a PAN’s can be masked for display by showing the first six and last four digits.
Compliance Extend beyond IT
While IT can help to make it easier to manage processes, but there is no way to replace responsibility and ownership of critical customer data.
Even if IT solution is purchased from a vendor claiming that they have attained PCI-DSS compliance before, it actually cannot encompass all of the control objectives required by PCI-DSS when an organization uses an instance of such a vendor solution. There are many controls apply to business process rather than any IT implementation.
For example, just because a website is hosted on SquareSpace, it doesn’t mean they are automatically PCI-DSS compliant. I wonder how many organizations actually do the due diligence of reading into what compliance actually requires when given the complex jargon of the documentation and numerous IT requirements to actually be compliant.
Self-assessment questionnaires (SAQ) are validation tools provided by the PCI Security Standards Council intended to assist merchants and service providers in self-evaluating their compliance to PCI-DSS. The language of these SAQs would likely take an IT professional who has looked into PCI-DSS to see which one actually applies a particular e-commerce solution.
For e-commerce, one of SAQ A, SAQ A-EP or SAQ D would apply. Each contain a different set of validation criteria and recommendations an organization would have to meet, along with the significant cost differences to comply to each.
In general, a merchant must always be PCI-DSS compliant if they accept credit card payments, even if the card is entered on another site. Payment processors such as PayPal/Stripe/Recurly would typically recommend the merchant to completing SAQ A at minimum.
Just because the requirement is not a checkbox on the SAQ, it doesn’t mean that the merchant can ignore being responsible for implementing the requirements of the PCI-DSS. For example, they still need to make an effort to secure their network as well as show evidence of this. I am reading that experts who are evaluating solutions which would fall under SAQ A actually use the SAQ A-EP as much as possible to mitigate risks.
The following diagram provided by the PCI council tries to show the distinctions of which SAQ to use in various documents:
Vulnerability scans occurring every quarter from external ASVs (approved scanning vendors) are required in SAQ A EP, SAQ D, but not under SAQ A. The list of ASVs is maintained by the PCI Security Standards Council, and adds additional cost to operating an e-commerce solution.
Under SAQ A, the merchant server serving the redirect/iFrame is not in scope for PCI-DSS compliance because no part of the merchant’s server touches CHD (card holder data).
Types of Controls
|Control objectives||PCI DSS requirements|
|Build and maintain a secure network||1. Install and maintain a firewall configuration to protect cardholder data|
|2. Do not use vendor-supplied defaults for system passwords and other security parameters|
|Protect cardholder data||3. Protect stored cardholder data|
|4. Encrypt transmission of cardholder data across open, public networks|
|Maintain a vulnerability management program||5. Use and regularly update anti-virus software on all systems commonly affected by malware|
|6. Develop and maintain secure systems and applications|
|Implement strong access control measures||7. Restrict access to cardholder data by business need-to-know|
|8. Assign a unique ID to each person with computer access|
|9. Restrict physical access to cardholder data|
|Regularly monitor and test networks||10. Track and monitor all access to network resources and cardholder data|
|11. Regularly test security systems and processes|
|Maintain an information security policy||12. Maintain a policy that addresses information security|
From PCI-SSC quick guide, pulled from Wikipedia
Consider SaaS and Avoid Self-Hosting
Speaking from my own experience, IT professionals who know how to solve the problem of creating an e-commerce solution may not have knowledge about PCI-DSS compliance and pick the wrong solutions for your organization as a result. These organizations may have to find out the hard way via a data breach or fine to happen.
With any IT solution, ‘economy of scale’ results in products which meet more requirements at an affordable cost. Use well-known true software-as-a-service (SaaS) platforms which provide explicit documentation and support on how to operate a PCI-DSS compliant solutions.
For example, I would recommend the likes of SquareSpace and Shopify to provide a solution instead of self-hosting store-front using WordPress or Magento for organizations who cannot afford to have dedicated IT operations. Trusting off-the-shelf WordPress plugins to be part of a PCI-DSS compliant solution has the potential for pitfalls. There is a similar challenge with picking PCI-DSS compliant web hosting.
- PCI Security Standards Understanding PCI-DSS v3
- PCI Security Standards PCI-DSS v3 SAQ A
- Recurly – PCI-DSS Compliance