One could be forgiven for thinking that the Payment Card Industry Data Security Standard – PCI DSS – applies primarily to payment gateways. After all, they are the ones that handle all data and process transactions on customers’ behalf.
This however is not entirely correct as PCI DSS applies to any entity which in some way or another processes, stores or transmits credit card data. This definition widens the scope of PCI DSS significantly and incorporates merchants, software suppliers, IT support suppliers, data storage entities and any other third party with whom clients share their data. Understanding the intent of PCI DSS and its requirements helps determine obligations and compliance requirements.
A common misconception is that encryption is the silver bullet to all PCI problems. Despite it being a requirement, and a very important one, encryption is only one of a number of technical and procedural controls that one has to implement to achieve full compliance.
Encryption as a requirement is also more complex than merely making data unreadable since PCI DSS mandates strong encryption algorithms, encrypting the keys that encrypt the data, rotation of encryption keys, split knowledge of passphrases and much more. Without wanting to make compliance seem like an impossible feat, one should not underestimate the complexity and resources required to successfully follow through this project.
The PCI standard is made up of 12 high-level requirements, each split into sub-requirements. Well over 250 sub-requirements make up the PCI DSS. With so many requirements, ensuring that the project is adequately scoped is of paramount importance. ‘Scoping’ is the process of identifying those systems which process, transmit, or store credit card data and to segregate them from other systems thereby defining what is termed the ‘cardholder data environment’. It therefore follows that the narrower the scope of the cardholder data environment, the less complex and expensive efforts to comply with the requirements.
Merchants and service providers are classified into categories and credit card brands have laid down validation requirements for each. These categories are based on the volume of transactions and type of processing carried out. In other words, not only are you expected to comply with all the requirements of PCI DSS but you also have the obligation to validate your compliance annually, either through a self-assessment questionnaire or through an onsite assessment carried out by an external Qualified Security Assessor.
One of the common stumbling blocks for companies attempting to comply with PCI DSS is undoubtedly related to the application software in use. In most cases, the software is a critical component in running a successful operation and, rightly so, companies go to great lengths and expense to ensure that these systems never break down and continue to provide a reliable service to their users. However, very little of the existing software in use today meets all the requirements of PCI DSS.
In order to satisfy such stringent requirements, application software would have to be updated. However management is usually not keen on changing what is not broken, especially when the software is a legacy system. There are also cost factors to consider, not to mention potential disruption of operations. Things get even more complicated and costly if the software has not been developed in-house but acquired through a software supplier. In such cases, it is the responsibility of the software supplier to ensure the software is PCI compliant.
The downside however, is that you cannot achieve full compliance until your supplier implements all the changes required to meet the applicable requirements of PCI. This applies to any service which is considered to fall within the scope of PCI.
Last year saw some changes in the PCI standard. While most have been improvements to existing requirements in an attempt to clarify any interpretation issues, other requirements have been made more specific and consequently more detailed.
Whether you are re-validating your compliance status or just starting your compliance efforts, the new version is out and has been effective as of January 1. However, entities will be allowed to use the older version up until the end of this year.
Mr Axiak is a director of Kyte Consultants Ltd and a Qualified Security Assessor.