Common challenges for SAQ A/e-commerce merchants and how to resolve them
E-commerce merchants, by definition, accept card payments. So, they’re subject to the PCI DSS (Payment Card Industry Data Security Standard).
This standard, currently at v4.0.1 (a limited revision to PCI DSS v4.0), contains 277 sub-requirements. However, you can reduce your scope to drastically lower the number of requirements you must meet, thereby significantly reducing your compliance burden.
Example: Online merchants can aim for SAQ A
This SAQ (self-assessment questionnaire) contains just 31 questions (1 per applicable sub-requirement). To qualify, you must fully outsource your account data functions.
As an online merchant, that means:
- Your website must be entirely hosted and managed by a PCI DSS-compliant third party; or
- You need to set up a web page redirect or iframe via a compliant TPSP (third-party service provider).
Many online merchants use a third party to host their website, and usually qualify for SAQ A.
However, as I’ve seen with some recent clients (I’m a PCI QSA – Qualified Security Assessor), they expect the process to be straightforward because they qualify for a shorter SAQ.
Then they’re surprised when problems or challenges arise.
The redirect is in scope
Usually, if a system component stores, processes and/or transmits account data, it’s within the PCI DSS scope. However, for merchants whose website qualifies for SAQ A by using a redirect or an iframe, the PCI DSS has an exception.
Even though the website or web server that causes the user’s browser to redirect to the payment page, or load the iframe, doesn’t directly touch card data, the website/web server is in scope.
So, how might that cause problems?
Scenario #1: The merchant uses a third party to host its website
Some organisations don’t manage their own web server, but use a third party to host their website. Sometimes, that third party lacks an AoC (Attestation of Compliance) or other proof of their PCI DSS compliance.
That’s not necessarily a problem.
However, the service provider then comes into scope for the merchant’s own PCI DSS assessment and must provide evidence of compliance with some parts of the following:
- Requirement 2: Apply secure configurations to all system components.
- Requirement 6: Develop and maintain secure systems and software.
- Requirement 8: Identify users and authenticate access to system components.
Often, such service providers have limited knowledge of the PCI DSS. In fact, some protest that they don’t store, process or transmit cardholder data, so aren’t in scope.
When the merchant, or a QSA on its behalf, then explains the PCI DSS rules to them, some web hosts will be helpful and engage with the QSA to provide the evidence needed.
Others can be difficult, or slow to respond.
I’ve even had one company saying it wasn’t ‘competent’ to meet the PCI DSS requirements! The merchant had to take down the store and find a new host. Fortunately, the store wasn’t a large part of its overall business.
Scenario #2: The merchant outsources its entire e-commerce function
Other merchants outsource their entire e-commerce function to a third party specialising in hosted e-commerce applications. This external party usually provides this service using a SaaS (Software-as-a-Service) or PaaS (Platform-as-a-Service) model.
As service providers, they typically have PCI DSS certification.
So, merchants think: ‘Great! I’ve outsourced both the payment handling and web hosting. All that’s left for my PCI compliance are requirements 12.8.X around managing the service providers.’*
That may be the case.
Equally, it might not be that straightforward:
- Can the merchant customise the code on the payment page?
- If yes, who’s responsible for new sub-requirements 6.4.3 and 11.6.1?
- Is the merchant responsible for updating the e-commerce application?
- Does the service provider take responsibility for ASV (Approved Scanning Vendor) scanning?
In a full SaaS model, the service provider will likely be responsible for all the above points.
But if the provider leaves much of the web page under the merchant’s control, the above could all be down to the merchant.
In other cases, the responsibility is shared between provider and customer. So, conduct your due diligence.
*Requirements 12.10.X, around responding to security incidents that could impact the CDE (cardholder data environment), might also remain the merchant’s responsibility. It’s best to check this on a case-by-case basis.
Want to better understand the relationship between Cloud customers and providers?
Our free green paper, Cloud Security – Who is responsible?, explains in more detail:
- How the Cloud provider–customer relationship works
- Where your respective responsibilities lie
- Security challenges of using the Cloud
- And more!
Broad outline of security responsibilities in Cloud relationships
by security control and service type; taken from page 3.
How can a merchant address these challenges?
The answer is already in the PCI DSS. Specifically, sub-requirement 12.8.3 (emphasis added):
An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.
Often, merchants seek to achieve this “proper due diligence” through standard financial checks. They may also request to view the supplier’s AoC, if it claims to be PCI compliant.
But more is needed.
When seeking a new service provider, a merchant should consider the following:
- A contractual requirement for the service provider to have its own PCI DSS compliance certification, or at least that it’ll meet all applicable PCI requirements.
- A contractual requirement for the TPSP to cooperate with any merchant audit or assessment, and provide evidence as requested for the merchant’s assessment.
- If the service provider does have its own PCI DSS compliance, check exactly which requirements are covered (sub-requirement 12.8.5). The AoC on its own doesn’t have enough detail for this.
- Note: Some service providers may have a responsibility matrix, but even this doesn’t always provide sufficient detail. Ask specifically about sub-requirements 6.4.3, 11.6.1 and 11.3.2 (ASV scans).
- Include within the contract (or obtain a separate statement) an acknowledgement from the service provider of their responsibility for the security of the merchant’s data (sub-requirement 12.8.2).
Doing this in advance avoids surprises at assessment time. It also ensures that much of the burden of compliance is shifted to the service provider.
Need help with your PCI DSS compliance?
Our team of PCI DSS advisors can help quickly determine your goals, and advise on a programme that meets your organisation’s needs and expectations.
We take a collaborative approach when delivering PCI DSS assessments. Our QSA consultants work closely with customers to understand their business, cardholder data flows, technologies and corporate culture.
We first published a version of this blog in March 2015.