Top 5 common pitfalls of PCI DSS compliance

Scope creep

The PCI DSS defines the cardholder data environment (CDE) as all of the systems, processes, people and technologies that handle cardholder data and this includes systems that secure and support the CDE (i.e. connected-to systems).  On numerous occasions, we have found organisations that have overlooked some aspect of the systems and functions including domain controllers, key management servers, firewalls, intrusion detection / prevention systems (IDS/IPS), log management, security information and event management (SIEM) and antivirus (AV) management servers, amongst others.  Our best advice on addressing the issue of scoping is to maximise your network segmentation.  Isolating the ‘in-scope’ systems from the rest of the environment will greatly reduce the number of supporting systems and functions you will need to consider.

Lack of understanding where and in what form the organisation retains CHD

It is impossible to design defence strategies on how to protect the CHD stored by an organisation if there isn’t a comprehensive understanding of what type of data is being held and in what format it is retained.  As per the age-old QSA mantra ‘if you don’t need it, don’t store it’.  If the type of service that an organisation provides dictates that some elements of CHD must be retained, ensure that data retention is well defined and that data is deleted/stored/tokenized/archived according to PCI DSS requirements.

Lack of effective vulnerability management

PCI DSS requires organisations to perform internal and external vulnerability scans and any vulnerabilities that are found need to be addressed.  Failure to do so not only complicates an organisation’s attempts to recertify, but it can leave CHD vulnerable and increases the chance of a breach. Organisations looking to comply for the first time only needs to have one clean scan, i.e. no ‘High / Critical’ rated vulnerabilities from the last quarter.  In order to achieve compliance in subsequent years, a clean scan from each quarter from the previous twelve (12) months is mandatory.

‍

Lack of firewall rule reviews and associated six-monthly segmentation tests

In addition to reviewing firewall rules every 6 months, service providers must also conduct internal segmentation testing twice a year.  While most organisations remember to perform the annual penetration testing leading up to the audit, we often come across occurrences of segmentation testing being neglected.  These compliance milestones, along with the many other time-based requirements, should be recorded in an operational security ‘calendar of events’, to ensure they are not overlooked at the appropriate time.

Lack of commitment to PCI DSS compliance efforts ‘offseason”

Unfortunately, many organisations regard PCI as a ‘once a year’ exercise and fail to incorporate the necessary behaviours into their ‘business as usual’ (BAU) processes.  To minimize risk and to reduce the stress of the annual re-compliance process, the PCI programme should be followed and managed throughout the year.  This includes, amongst others, staying on top of security testing, patching, user management, logging and 3rd party vendor management.

‍