In previous pieces, we introduced PCI DSS and some of the most common approaches to collecting card data. While implementing your solution, it’s natural to compare what you build to the requirements you’re in scope for, as well as what compliance will look like at an operational level. The requirements and testing procedures document is useful for this, but it’s a lot to process.
Instead of just covering what’s in the PCI DSS documentation already, this guide outlines some operational commonalities, and then summarizes the principal requirements. The goal is to provide a way of thinking about or processing the requirements before you go deep on each one. We’ll also highlight requirements that you need to pay attention to while you integrate your card collection solution, as well as topics that are more relevant to maintenance and ongoing compliance. While there’s some overlap with the PCI DSS documentation, this guide hopefully provides a bridge to that content.
This guide touches on all 12 requirements and highlights some of the controls you need in place. Remember that you can descope from some of these requirements and controls depending on how you implement card collection. In most cases, unless you decide to build your own solutions for collecting and storing raw card information, you don’t have to implement all 300+ controls.
The PCI DSS requirements are organized by top level principals or goals:
To achieve each of those, there are common activities your team undertakes to make sure you meet each requirement. There’s usually:
Requirements 1 and 2 cover installing and maintaining secure networks and systems. These are of course big considerations before and after you go live, since these networks and systems (in part) define your cardholder data environment (CDE). While not a complete list, you’ll need to do things like:
Requirements 3 and 4 focus on protecting stored and in-transit account data. Similar to the first two requirements, these are important elements both before and after you go live with a card collection solution. While there are common subitems for creating and maintaining processes, procedures, and roles, you also need to do things like:
If you use cryptography in your CDE, there are specific requirements for that as well. Keys need to be properly secured, protocols need to be in place that ensure secure PAN transmission, etc.
Your vulnerability management plan includes protecting your systems against malicious software, and building and maintaining secure infrastructure. Requirements 5 and 6 have the details, but similar to other requirements, you need to define, document, and communicate the plan, as well as:
Access controls ensure only approved users have access to your CDE and cardholder data (CHD). This is often achieved by only allowing users access to specific data, or only granting them the permissions they need to do their jobs. With your information security policy, they define who has access to what, to what level they have access, and tooling or automation to ensure access is granted correctly.
Requirements 7, 8, and 9 define what you need to have in place, but in summary, you have to:
Requirements 10 and 11 define how your systems and networks need to be regularly tested, fixed, and retested. There are some automated solutions we’ll cover later, but you need to:
Vulnerability scan requirements are defined under 11.3.2 and specifically relate to Approved Scanning Vendor (ASV) scans. These scans identify security weaknesses and other flaws in public-facing systems. 11.3.2 requires you to submit a passing ASV scan every three months or 90 days depending on your compliance obligations. Evervault recommends completing your scan well ahead of the deadline. Many of our customers submit monthly to enhance security and to allow for ample time to resolve any issues. We have a post about ASV scans that explains what they are, when you need them, and how they work if you want to know more.
There are many vendors that provide ASV scanning services. Most of these providers use legacy solutions that are clunky and inefficient, so complete your due diligence before choosing a provider. Evervault’s solution is a fresh take that’s user friendly and:
These policies define how you protect your CDE and CHD. They establish what components need to be protected, how they’re secured, who has access to them, and they define a process for maintaining the policies and procedures themselves. Requirement 12 covers each element in detail, but in short, you have to:
As a part of requirement 12.10, you need to define, review, and update an incident response plan. This plan should outline roles, responsibilities, procedures, etc. that relate to managing and tracking incidents. If you have existing incident response processes in place, you’re likely meeting some of the requirements already. You should still review the PCI DSS requirements thoroughly and update your existing processes as needed. There are specific requirements related to on-call, your CDE, external notifications, updating your plan, etc.
Payment page security requirements are largely defined in sections 6.4.3 and 11.6.1 of the PCI DSS requirements. They’re designed to ensure payment page security at a general level, but they have specific requirements related to scripts and preventing eskimming. Many of the options we covered in our previous piece use an iframe to collect card information. Those iframes are often served using a script through the browser. This comes with some security concerns, which requirements 6.4.3 and 11.6.1 cover.
6.4.3 requires you to have some method for:
11.6.1 requires that you have a way to detect and respond to changes made to payment pages. You essentially need a way to track changes, and detect if a page has been tampered with. This includes inspecting security headers and alerting you to changes to them, as well as to script content. Depending on your specific requirements, these checks may need to be done weekly. While you can build functionality for this requirement, many third party providers have tooling you can use.
Evervault provides Page Protection as a part of our compliance suite. It addresses 6.4.3 and 11.6.1 requirements in a single solution. It’s a straightforward integration (a single line of code) that allows you to track changes, resolve issues, and set up alerting through a dashboard interface. You can use webhooks to receive alerts too. In addition to our tooling, Evervault has in-house PCI experts that can help with payment page compliance, and any other part of the attestation process.
After reading through this primer, we started looking into the specific requirements (we’re a merchant and a service provider so we looked at SAQ-D requirements). We have a better understanding now, but we might check on Evervault’s offering for help with the process. If it helps us go live quicker, minimizes risk, and reduces some of the workload on our team, it’s probably worth it.
So far, these guides have focused on collecting raw card details but there are other ways to accept card payments. These largely revolve around wallets like Apple and Google Pay, as well as network tokens. These payment methods have cards as the underlying payment mechanism but they don’t require customers to enter card details on your site (or a third party’s) every time time they make a purchase.
This content is for general information and educational purposes only. It shouldn't be taken as legal, compliance, or tax advice. Evervault doesn't guarantee the completeness or accurateness of this content, and you should always consult with a lawyer, qualified security assessor (QSA), accountant, or similar professional for advice on any of the topics covered.