The Payment Card Industry Data Security Standard (PCI DSS) details security requirements for members, merchants and service providers that store, process or transmit cardholder data. It originally began as five different programs from five credit card schemes who all had similar intentions: To create an additional level of protection for consumers by ensuring that merchants meet minimum levels of security when they store, process and transmit cardholder data.
However, while the intentions were similar, the standards of the five schemes often conflicted. This created an unreasonable burden – and increased security risk – for merchants.
The Payment Card Industry Security Standards Council (PCI SSC) was formed as a neutral body to address conflicts among the credit card schemes in developing a single standard, releasing the PCI DSS in December 2004.
But that’s not where the trouble ended. Today, many merchants are still unclear about their responsibilities and requirements under PCI DSS, leaving them at an increased risk of being found non-compliant and facing hefty fines. Today, we’re clearing up the most common myths and misconceptions, so you can be sure your business is protecting your customers’ privacy and your financial health.
The big cost of non-compliance
Although the individual credit card schemes are now aligned under one standard, it is still common for merchants not to know what the policy actually states. There are many challenges or barriers that can inhibit correct understanding of the PCI DSS Standards, including:
If cardholder data is compromised and an organisation is found to be non-compliant (or has not completed a PCI DSS compliance assessment), they could face significant PCI compliance penalties. This could have a major effect on cash flow, financial health and/or reputational damage.
Even though it is the responsibility of issuers and acquirers (e.g. banks) to ensure all of their service providers, merchants and merchants’ service providers comply with the PCI DSS requirements, it is ultimately the merchants who wear the cost of non-compliance. While the payment brands may fine an acquiring bank for PCI compliance violations, the banks will most likely pass this fine along until it eventually hits the merchant and service providers.
While penalties are not openly discussed, they can be between $5,000 to $100,000 per month. An amount that can have serious, long-term effects on small to medium size businesses.
Beyond fines, there are a broad range of consequences associated with breaching the regulations, including:
It is the responsibility of every organisation to know their PCI DSS obligations, implement controls and assess PCI compliance annually.
The requirements of merchants and service providers under PCI DSS are determined by your ‘level’ which is set by your amount of annual transactions. To find out what level you fall under, visit this link.
Common Misconceptions about PCI DSS
Information overload, misinterpretations and misinformation are rife when it comes to the PCI DSS. Here, we’re laying out both the misconceptions and facts.
Misconception 1: Outsourcing card processing makes e-commerce merchants compliant
Fact: Outsourcing all processing of cardholder data may simplify the PCI compliance. However, it does not automatically provide compliance.
Merchants must ensure that all third parties handling storage, processing, and/or the transmission of cardholder data are PCI DSS compliant. Merchants must maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data.
There is a requirement to conduct an annual self-assessment against the applicable Self-Assessment Questionnaire (SAQ). The exception is Level 1 merchants that must undergo a full PCI Report on Compliance (RoC).
Misconception 2: We are a small merchant who only allows a handful of card types, so we do not need PCI
Fact: Merchants must be PCI complaint if they take non-cash payment through any of these five cards:
Misconception 3: PCI DSS is applicable for credit card data only
Fact: Any payment card, including credit, debit, prepaid, stored value, gift or chip, that shows the logo of one of the PCI Security Standards Council’s five founding payment brands, is required to be protected as prescribed by the PCI DSS.
Misconception 4: I can wait for PCI compliance until my acquirer/bank asks me to do it or until my business grows
Fact: The PCI DSS applies to all business sizes, and waiting could be costly. The penalty and compensation costs levied by the banks could be substantial, particularly if a business is compromised and found to be non-compliant. Businesses are responsible for making sure that they are aware of their PCI compliance obligations.
Misconception 5: We did not sign anything saying that we would be PCI compliant, so we do not need to be compliant
Fact: When a business opens a merchant account with an acquirer or bank, the agreement says that VISA / MasterCard / Other Regulations must be adhered to. As such, businesses are required to implement and regularly assess their PCI controls.
Misconception 6: PCI applies to bank account data too
Fact: PCI DSS applies to the protection of cardholder data (Primary Account Number (PAN), cardholder name, service code and expiration date) and sensitive authentication data (full track data from the magnetic stripe or equivalent data on the chip, CAV2/CVC2/CVV2/CID, and PIN/PIN block), from payment cards from any of the founding PCI payment.
Bank account data, such as branch identification numbers, bank account numbers, sort codes, routing numbers, etc., are not considered payment card data. As such, PCI DSS does not apply to this information.
However, if a bank account number is also a PAN or contains the PAN, then PCI DSS applies.
Misconception 7: PCI DSS does not apply to “hot cards,” expired, cancelled or invalid card account numbers
Fact: PCI DSS applies to any Primary Account Number (PAN), including active, expired, or cancelled PAN, except where the organisation can provide documentation which confirms that the PAN is inactive or otherwise disabled, and no longer poses a fraud risk to the payment system. However, if the PAN is later reactivated, PCI DSS again applies.
Misconception 8: PCI requires us to hire a Qualified Security Assessor (QSA)
Fact: Many merchants have complex IT environments, so they hire a QSA to undertake an on-site security assessment as required by PCI DSS. Engagement of a QSA also makes it easier to develop and get approval for compensating controls.
However, PCI DSS provides the option of doing an internal assessment with internal sign-off if the business’ acquirer and/or merchant bank agrees. In this context, mid-sized and smaller merchants may use a Self-Assessment Questionnaire (SAQ) to assess themselves. This is usually best done by an information security professional.
Misconception 9: You must be PCI compliant with most, not all, criteria
Fact: The pass mark for PCI is 100 per cent. If a business fails even one of the criteria, they are not PCI compliant. The logic is that failure to achieve even one of the requirements means that a business is failing to meet a basic standard for handling cardholder information.
Misconception 10: We have internal corporate credit cards used by employees for company purchases like travel or office supplies, so we do not come under the scope of PCI DSS
Fact: PCI DSS applies to any entity that stores, processes, or transmits cardholder data.
In those instances where a business holds cardholder data relating to their own corporate cards, there may still be a need to validate compliance. This is determined by each payment brand individually.
It is suggested that business contact applicable payment brands directly for more information.
Misconception 11: As per PCI DSS, quarterly vulnerability scans mean that we can perform vulnerability scans at any time during the quarter
Fact: The intent of “quarterly” vulnerability scans, as defined in PCI DSS Requirement 11.2, is to conduct them as close to three months apart as possible, to ensure vulnerabilities are identified and addressed in a timely manner. To meet this requirement, a business is required to complete their internal and external scans, and perform any required remediation, every three months.
Three months, or 90 days, is considered the maximum amount of time that should be allowed to pass between quarterly vulnerability scans. If unforeseen circumstances occur that impact a business’ ability to complete scheduled scans, every effort should be made to perform scans as soon as possible (e.g. within a day or two) of the scheduled scan date.
Where a business has advance notice of factors that may delay scans or impede their ability to address vulnerabilities (e.g. scheduled system downtime, or predefined no-change windows that prevent system updates), the entity should strive to schedule scans before the 90 day period is reached.
In the case of legitimate technical or documented business constraints, and where the business has sufficiently implemented other controls to mitigate the risk associated with not meeting the requirement, the business may use a Compensating Controls Worksheet to document how they have addressed the intent of Requirement 11.2.
Simplify PCI DSS with expert input and advice
While it’s not always easy to understand, it’s in every merchant’s best interest to remain PCI DSS compliant. The risks and costs of a mistake far outweigh the resources required for compliance.
The best way to avoid the above misconceptions and PCI fines and penalties, is to involve qualified PCI DSS professionals that can help your organisation to understand its PCI DSS obligations correctly and assist with cost-effective and optimal compliance.
Centium has extensive experience partnering with clients to achieve their PCI DSS compliance. As a leading cyber security audit firm, our QSA professionals will guide you in definition and reduction of your scope, support and implementation, as well as an assessment of your PCI environment in accordance with PCI DSS requirements.
For assistance with PCI DSS compliance or accessing a QSA, click here.