If you, or a third party on your behalf, touches cardholder data, you have compliance obligations. Those obligations are specifically related to the Payment Card Industry Data Security Standard (PCI DSS) requirements. The key to handling these requirements is understanding what applies to you, how to reduce that scope, and then how to comply with what remains. The goal is to meet compliance requirements while maintaining an excellent customer experience.
This article is the first part in a broader journey through collecting card data and remaining compliant. We’ll lay the groundwork in this article by covering:
As you read, you’ll see callouts like this one that we’re going to use to provide commentary from a business’s point of view. This fake company is called GetLost, and they’re an online travel agency (OTA). They’re still in the “build phase” and don’t have a live product yet. They’re evaluating their options for collecting and using card data, and they know PCI DSS will apply to them in some way, but they don’t know to what extent yet. They want to understand their options for collecting and using card data, and the compliance implications of those options.
The PCI Security Standards Council (PCI SSC) published PCI DSS in 2005. It’s a global security standard that applies to any entity that stores, processes, or transmits cardholder data (CHD). The standard was agreed upon between the major card brands to reduce the volume of fraud involving stolen cards.
Today, PCI DSS is mandated by six major card brands (Visa, Mastercard, JCB, AmEx, Discover, and Union Pay) and contractually enforced by acquiring banks. If you’re a merchant and have signed an acquiring contract with a bank since 2005, you’re likely contractually required to be PCI DSS compliant.
If you’re a service provider, PCI DSS applies to you too. Merchants often ask for an Attestation of Compliance (AoC), and you could possibly lose business if you don’t have it. Card brands manage compliance for service providers as well, and they often maintain publicly available lists that include each service provider’s type (e.g., payment facilitator, merchant servicer, etc.) and validation type (this is where PCI DSS is noted). You can also see how much longer a service provider’s validation will be active.
Complying with PCI DSS is essentially a pass-fail designation. You have to demonstrate that you meet the requirements that are in scope for you, and failing a single requirement or control results in an overall failure. While you can reduce your overall scope, there’s no middle ground or partial compliance for remaining requirements.
Account data is a core aspect of the PCI DSS requirements. Understanding it in more depth will help you make decisions later on, so let’s cover that first.
Account data has two subcategories: cardholder data (CHD) and sensitive authentication data (SAD).
If you collect, process, or transmit this data, it brings your business into scope for PCI DSS requirements. And if you rely on a third party for managing any type of account data, you need to ensure the third party is compliant with PCI DSS. Exact requirements can vary depending on how account data is processed. For example, you might only collect the cardholder name and then use a third party to collect PANs. This would change which requirements apply to you, and which apply to the third party.
We’ll go into more detail on the requirements later, but for now, know that if you have systems that interact with account data, you’re in scope for PCI DSS in some way. To start narrowing down the impact, you need to know if your business is considered a merchant or a service provider.
We’ll of course need to interact with this data so we can charge customers, but we also have downstream partners that need card information. In those situations, we’ll need a way to securely forward card information to them. As for being a merchant or service provider, that’s something we’re still trying to understand.
There are different assessments and requirements for merchants and service providers under PCI DSS. This includes transaction volume thresholds that can change your compliance obligations, so you need to figure out if your business qualifies as a merchant, a service provider, or both. The difference largely has to do with how you handle cardholder data. To start, ask yourself:
If you plan to work with third parties to collect or process card data, you should find out from them as well whether they’re a service provider, and what their PCI level is.
With a better idea of which your business is, it may help to review PCI SSC’s definitions for merchants and service providers. We’ll share their definitions and then provide summaries to help clarify each term.
For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any PCI SSC Participating Payment Brand as payment for goods and/or services.
A merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.
Merchants are businesses that accept payment for goods and services they directly provide to customers, and typically have their own merchant ID (MID).
Examples: Online retailers that sell directly to customers
Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data (CHD) and/or sensitive authentication data (SAD) on behalf of another entity. This includes payment gateways, payment service providers (PSPs), and independent sales organizations (ISOs). This also includes companies that provide services that control or could impact the security of CHD and/or SAD. Examples include managed service providers that provide managed firewalls, IDS, and other services as well as hosting providers and other entities.
Service providers are entities directly involved in the processing, storage, and transmission of cardholder data on behalf of another entity, or an entity that may impact the security of another in scope entity.
Examples: Stripe, Shopify, online travel agencies, cloud service providers
There are many businesses that qualify as both a merchant and service provider. Ecommerce platforms and payment facilitators are common examples. Users pay these businesses directly to use their platforms, giving those businesses a merchant designation. But these businesses also facilitate payments from customers on behalf of merchants, making them a service provider too. Businesses like these generally focus on complying with service provider requirements because they’re more comprehensive, and it covers them on the merchant side as well.
It looks like we’ll actually be both a merchant and a service provider. Travel booking can get pretty complex. There will be scenarios where we charge for the entire booking and pay out to partners separately, and other situations where we only charge for our services and our partners charge customers directly for their portion of the booking.
It’s time to go a little deeper on what’s in scope for PCI DSS. In straightforward terms:
At the broadest level, the cardholder data environment (CDE) and system components are under evaluation. The CDE is everything that goes into processing cardholder data, which includes system components, but also people and processes. This includes components that don’t process cardholder data but have unrestricted connectivity to ones that do. Additionally, any system components, people, or processes that could potentially impact the security of the CHD, are also in scope.
The PCI DSS requirements go into more detail on what system components are, but they include cloud infrastructure, cart management, network devices, code repositories, and more. You’ll need to do some internal research and mapping to define what your CDE and system components look like. This scoping and segmentation guide might be useful to have on hand while you start this process.
This has a potentially huge impact for us. We’ll have numerous microservices that run in the cloud that could be in scope. We’ll have to do more digging on systems that “could potentially impact the security of CHD”.
Each CDE is unique but there are general actions you can take to figure out what parts are in scope. You can start by identifying the services your business provides that might involve cardholder data or have access to it. This might include:
With that list, roughly map out how data flows between the systems, as well as the people and processes involved. It might help to show flows from the customer’s point of view, as well as from an internal perspective. When you have a general idea of what’s involved, you can engage with your engineering, IT, and security teams to identify the underlying infrastructure pieces that support those core business services, or that have access to them. This can at least get you started in determining the scale of what might be in scope.
Mapping our ecommerce flow first makes the most sense. It’ll have the highest throughput of transactions, and it’s the most vulnerable since it’s obviously available on the open internet. Our infrastructure is in AWS, primarily in US East 1 and EU West 1, with multiple availability zones (AZs). Our ecommerce model is fairly typical, with our primary API consuming card data directly from customer mobile apps and our web app. The high level flow looks like this (red arrows indicate cardholder data flows).
After mapping the data flow, it’s clear that our API is directly used for payment processing, as well as for providing customer facing and back office management. It’s all linked together and it looks looks like our entire AWS account infrastructure is in scope.
Our next step is to figure out what that means in terms of applying controls. Given the scope, we can already see this is going to be a pretty large and disruptive piece of work.
There’s a tiered way to look at the framework. At the highest level are six goals. These are short but broad definitions of what the security standard achieves. Next are the 12 requirements that you need to meet (or descope from) to achieve the goals. At the lowest level, there are 300+ controls, which you put in place (or descope from) to meet the 12 requirements. We’ll cover the goals and requirements in more detail in a subsequent piece, but here they are for reference.
Not every business has to implement all 300+ controls. We’ve mentioned descoping a few times now, and what that means is that there are different approaches to handling CHD and building your CDE. How you compose those pieces, and whether you’re a merchant or a service provider (or both), will change the requirements for you.
How you report on or attest to your compliance depends on whether you’re a merchant or service provider, as well as transaction volume thresholds. Before determining your assessment type, there are a few terms you need to know. Some of these may not apply to your business, but they help contextualize the table later in this section.
This is a form that either you or an assessor fills out to attest to the results of a PCI DSS assessment.
This is an assessor that is qualified by the PCI SSC to validate an entity’s adherence to PCI DSS requirements.
This is a reporting tool that’s used to document detailed results from an entity’s PCI DSS Level 1 assessment.
This is a questionnaire you fill out to attest to your compliance. There are a few different types of SAQs.
E-commerce merchants with fully outsourced payment processing
E-commerce merchants with partially outsourced payment processing
Card-present merchants using imprint machines or standalone dial-out terminals
Card-present merchants using standalone IP-connected terminals
Merchants using web-based virtual terminals
Merchants with connected payment applications
All other merchants and all service providers
With your merchant or service provider designation, and your rough transaction volume, you can figure out what level you are and the associated assessment type. It’s worth noting that QSAs and RoCs aren’t involved until you hit higher transaction volumes. So at a minimum, you’re likely looking at an SAQ and an AoC.
| Merchant Level | Transaction Volume | Assessment Type |
|---|---|---|
| Level 1 | >6 million transactions/year or high-risk | ROC by QSA + AOC |
| Level 2 | 1M–6M transactions/year | SAQ (varies) + AOC |
| Level 3 | 20k–1M e-comm transactions/year | SAQ (varies) + AOC |
| Level 4 | <20k e-comm or <1M total transactions/year | SAQ (varies) + AOC (optional) |
| Service Provider Level | Transaction Volume | Assessment Type |
|---|---|---|
| Level 1 | >300k transactions/year | ROC by QSA + AOC |
| Level 2 | ≤300k transactions/year | SAQ D + AOC |
If you need help determining what SAQ type applies to you, there’s some PCI DSS documentation that has a couple of diagrams that walk you through the process (pages 24 and 25). It’s more straightforward for businesses that are solely service providers (always SAQ-D). For merchants, it depends a lot more on how you’re storing and interacting with cardholder data. It’s also important to engage your acquirer to agree what attestation type is acceptable, and understanding these concepts allows you to drive the conversation.
We’re going to be a merchant and service provider, but we don’t have past transaction volumes to go off of yet since we’re still in the build phase. Our forecasts make us think we’ll need to be level one compliant but we’ll need to look into this more.
While its origin is outside of PCI DSS, merchant of record (MoR) is something to be aware of. MoR sprung out of ecommerce growth and the need to have a legal entity for a business that handles the payment process on behalf of other businesses. The MoR is whoever:
It’s of course possible to be a MoR if you’re a merchant, but also if you’re a service provider. Who the MoR is matters because they’re responsible for PCI DSS compliance for:
Complying with PCI DSS is just part of handling cardholder data. While the Security Standard Council defines the requirements, they don’t actually enforce the rules. Card networks and acquiring banks are primarily responsible for this. It works kind of like this:
If you don’t comply, card networks and acquiring banks may:
There isn’t a single place to look up the fees you might be charged, or how card networks determine when to block transactions. The amounts and rules vary by card network and acquirer, but you can review Mastercard’s rules for some context. If you look at the section for Payment System Integrity noncompliance (section 2.1.4, category A), you can see they might charge you on a per violation basis: up to USD 25,000 for the first violation, up to USD 50,000 for the second violation within 12 months, etc. They can also charge on a variable occurrence basis, which means they might charge you a fee for every credit card impacted by noncompliance. Regardless, total fine amounts can get quite high. If you’re non-compliant, there’s usually a remediation process you can follow to regain compliance, but fees may continue to accrue while you go through the process.
For some teams, compliance involves a near constant cross-team effort. If your scope is narrower, you might be able to handle it with a smaller group but it’s important to know that multiple teams are usually involved. Engineering (across the stack), compliance, security, and product teams might all be involved at some point.
Our business case for reducing PCI DSS scope goes into more detail, but a company using their own datacenters and implementing controls for all 12 requirements might face estimates like this.
| Requirement | Effort/cost | Complexity | FTE (Days) |
|---|---|---|---|
| Firewall configuration | Medium | High | 15 |
| Secure configurations | Medium | High | 20 |
| Protect stored data | High | Very High | 20 |
| Encrypt transmissions | Medium | Medium | 10 |
| Malware protection | Medium | Medium | 15 |
| Secure systems/applications | Very High | Very High | 45 |
| Access restrictions | Medium | High | 15 |
| Identify/Authenticate access | High | High | 15 |
| Physical access control | Medium | Medium | 10 |
| Logging and monitoring | Very High | High | 40 |
| Security testing | High | High | 25 |
| Information security policy and IR | Medium | Medium | 20 |
| Total: 250 |
We also wrote about PCI DSS from just a developer point of view. Again, the impact depends on what you’re in scope for, but the effort can quickly snowball into a project that takes your team away from building your core product.
Regardless of the approach, you’ll need to account for compliance in your own internal roadmaps and product planning. After you have everything in place and complete your initial assessment, there’s still ongoing attestation to do. The best thing you can do to ease the burden on your team and remain compliant is to reduce your compliance scope.
We realize those estimates in the example are on the high end but we don’t plan to manage everything in-house regardless. Our team is fairly lean and isn’t really built at this time to manage a huge compliance burden. Just looking at server hardening (part of requirement two) would be a big lift. We’d currently expect to have ~200 servers in scope with a mix of stacks. Hardening these to Center for Internet Security (CIS) benchmarks in production would be months of effort, and the risk of something going wrong is significant.
Descoping is the process of evaluating your CDE and making changes to it that reduce your compliance requirements and the number of controls you need in place. You can’t descope from PCI DSS entirely, but you can significantly reduce the number of controls you need in place. For something to be considered out of scope:
Your PCI scope largely has to do with how you collect and store card data. Handling it yourself means broader scope and more applicable controls. Using a third party to handle card data on your behalf, for parts or all of the payments process, reduces scope and applicable controls.
Reducing compliance scope is beneficial but what it really translates to is more time spent on building your core products and improving your customer experience. Compliance is important, and it can even be a selling point for your company, but we’re guessing you’d rather grow your garden than spend time building the fences around it.
At this point, you hopefully have a better understanding of PCI DSS and its implications. Much of the groundwork laid in this article was in preparation for our next section on the different options for collecting and storing card data. None of what we covered was meant to intimidate you. The goal is education and that involves going deep into topics and being straightforward about the implications. While it can seem like a lot, Evervault was built for this space and its complexities. Much of the compliance burden we just covered can become our burden instead, which frees you up to build your company’s future.
The summary for us:
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.