Common PCI DSS Misconceptions

August 30, 2019 Claranet Limited

PCI DSS can be a complex beast. That's because many businesses are not clear whether PCI applies to them or do not have a clear understanding of what they are looking at. Our Principle Security Consultant, Wayne Murphy explains the common misconceptions and problem areas that our Qualified Security Assessors (QSA) often encounter.

After working on PCI DSS projects over the past six years, I’ve seen some common misconceptions arise time and time again. I thought it would help those about to go through the process to share some of the most common ones, namely:

  • "PCI DSS doesn’t apply to me as I don’t store cardholder data (CHD)”
  • “Everything is encrypted; therefore, PCI DSS doesn’t apply”
  • Completing the wrong SAQs
  • Incorrectly completing SAQs

“PCI DSS doesn’t apply to me as I don’t store CHD”
A prevalent one this, but unfortunately PCI DSS applies to all entities that store, process or transmit cardholder data or can impact upon the security of the cardholder data or the cardholder data environment (CDE). Typically, a Merchant taking any form of Credit or Debit Card payment will have some PCI DSS obligations, even if it is just Requirement 12.8 when the whole payment channel is outsourced.  Service providers that can impact their customers CDE or the cardholder data within the environment (stored or transmitted) will be in-scope of PCI DSS as a service provider.  

 

“Everything is encrypted therefore PCI DSS doesn’t apply"

Clients sometimes believe that encrypted cardholder data is not in scope for PCI DSS.  Unfortunately, this is often not the case. PCI DSS still applies to encrypted cardholder data that is being stored or transmitted. The reason for this is that the decryption keys are often held within the environment where the encrypted cardholder data is.

There are some exceptions to this, but these will be because the decryption keys are not accessible by the environment where the encrypted data is being stored or transmitted.


Completing the wrong self-assessment questionnaires (SAQs)
PCI DSS compliance reporting can be achieved using the self-assessment questionnaires. However, it’s vital to use the right one for each payment channel. We sometimes find clients have been incorrectly told which SAQ to complete by their Acquirer or a third-party company acting on the Acquirers behalf or have selected the wrong one on the list (understandable with 9 to choose from!).  

Acquirers often use a process by which the correct SAQ is recommended to you, but this is based on a set of questions and incorrect answers to this, often results in the wrong SAQ being identified. The eligibility criteria within the SAQs (apart from SAQ D and SAQ D for Service Providers) provide the requirements which must be met before an SAQ can be used. Please see my full blog for more information on this.


Incorrectly Completing SAQs
Organisations will often complete the self-assessment questionnaires incorrectly. An essential step is to accurately identify the cardholder data environment (CDE) and the scope for PCI DSS assessment activities for the payment channel. Once done, this will help to determine the correct SAQ and to identify which systems are in scope for the assessment activities. Each SAQ contains an “Expected Testing” column describing what actions should be performed to validate each requirement is in place BEFORE selecting the “Yes” response against each requirement.  We often come across organisations that make assumptions that requirements are in place and select the “Yes” response, or that don’t fully understand the requirement and select the “Yes” response anyway.

An example I often give is with anti-virus (AV).  Although AV is not necessarily as effective as it once was, AV is still a requirement of PCI DSS and is security 101 for most organisations.  For this reason, organisations will make assumptions that the PCI DSS requirement covering AV is in place and will tick “Yes” for Requirement 5 and all its sub-requirements.  It is quite common to find issues with AV deployments that are either not working correctly, the service is no longer starting, or signature updates are not working.  It is therefore still crucial that the expected testing is carried out to identify where there may be gaps in these PCI DSS controls which can be fixed before selecting the “Yes” response.

To learn more about how to protect your cardholder data and secure your business, check out our latest eBook.

No Previous Articles

Next Flipbook
Claranet Cyber Security Brochure
Claranet Cyber Security Brochure

Stay secure and compliant