Let’s Start with the Basics
Confide understands that PCI can be difficult whether you’ve been working on it for one week or ten years. This is often because not only does the Standard change, but also risks change. At Confide, we work with PCI on a daily basis. We use the knowledge, skills, and information that we gain from this experience and use it to help you in your PCI journey, wherever you are at.
In our PCI Basics pages, we look at some of the most common areas where there are questions and confusion to help you understand and reach PCI compliance.
But let’s start with the most basic question, “What is PCI DSS”?
The Payment Card Industry Standard (or PCI DSS) is a set of twelve high-level requirements that all merchants and service providers who take card payments or manage systems involved in transactions are required to follow. You can read more about the high-level requirements here.
Our PCI Basics series was updated in August 2023 to help you prepare for PCI DSS v4.0.
Who Does PCI DSS Apply To?
PCI DSS applies to any organisation that accepts or processes payment cards from Visa, MasterCard, Discover, JCB, American Express, or UnionPay.
It also applies to service providers who store, process, or transmit cardholder/account data on behalf of merchants or other service providers OR who have the ability to affect the security of their customers’ PCI DSS compliance.
What’s Covered on This Page?
The PCI Journey
If you’re just starting out with PCI, you probably have questions about how you get from where you are to fully compliant.
When you first start out, the compliance journey might look and feel a little something like this:
You might not know what questions to ask. You might start out by focusing on what you have to report on before understanding your scope. You might try to fix gaps in your processes before really understanding what gaps PCI DSS is looking for you to fix. In short, sometimes the PCI journey is a bit of a winding road.
What usually happens if you go in unprepared is that you spend a lot of time jumping between the various parts in the journey. And quite often it means asking the same question multiple times.
At Confide, we want to help take you from the winding road of PCI compliance and help you find a smooth path to get from where you are (at whatever stage), through to PCI compliance.
In an ideal world, that journey might look a bit more like the diagram below, which follows a much straighter path through your compliance processes.
First you start by getting an understanding of what PCI is, figuring out where you fit into the PCI requirements by understanding whether you are a merchant or a service provider, and then by working through the requirements and finding out where there are gaps that you need to fix.
While you may still have to revisit certain areas, we hope that with some of the information below you’ll be able to go into your PCI journey well prepared for the steps along the way.
To start you out on this journey, we’ve put together some articles which might help with some of the basics. We won’t be able to answer every question here, but we hope it will help get you started in thinking about your own PCI journey.
Where to Start?
The first place to start is to understand why you have to be PCI DSS complaint. Here’s a hint – you probably agreed to it when you signed your merchant banking agreement, we recommend taking a look there first.
Next, you’ll probably want to understand whether you’re a merchant or a service provider because this will mean you have some slightly different requirements to comply with and some different reporting requirements.
And if you’re wondering what the real difference in requirements is between merchants and service providers, and service providers and multi-tenant service providers, here’s a few key numbers around the total number of potentially applicable requiremetns:
- Merchants: Up to 234 requirements
- Service Providers: Up to 251 requirements (17 more than merchants)
- Multi-Tenant Service Providers: Up to 259 requriements (8 more than service providers who are not multi-tenant service providers)
So the overall number of requirements isn’t that many more. The key difference is that merchants have the ability to use different SAQs depending on their payment channels and the number of annual transactions) while service providers can only use SAQ D or a Report on Compliance. And in PCI DSS v4.0, the distinction between the SAQ D for Service Providers and the RoC has gotten even smaller.
You can read more about how reporting works in PCI DSS in these posts.
Where to Next?
Once you understand why you need to be PCI DSS complaint and whether you’re a merchant or service provider, you probably found yourself with even more questions. In this part of our basics page, we cover off some of the most common topics that apply to everyone.
Network and Data flow Diagrams – What You Need to Know
Network and data flow diagrams are fundamental not only to you being able to understand your environment and your scope but also to being able to explain this to your QSA. As QSAs we rely heavily on your diagrams and documentation because nobody knows and understands your environment better than you do. So even if you don’t have to have a diagram as part of your reporting, having a diagram you can use to document and define your scope is vital to everyone.
There are three different types of diagrams you may need for your compliance depending on your reporting requirements. These are:
- High-level network diagram
- Detailed network diagram
- Cardholder data flow diagrams
You can go more in-depth into these in our page on what needs to be included in each type of diagram.
Understanding Your Risks
In PCI DSS v4.0, the standard moved away from a more general risk assessment to more specific risk assessments called “Targeted Risk Assessments” or TRAs.
This doesn’t mean that you shouldn’t take a holistic view of your risks, but you also need to include some specific considerations. PCI DSS v4.0 includes the following types of risk assessments that you need to be doing (depending on your scope):
- TRA for each requirement that is performed at a “periodic” frequency – this is specifically where PCI DSS says “periodic” and does not overrule any other defined timeframes.
- TRA for any customised approach you use – you cannot use a customised approach on a SAQ, you can only use it if you are doing a ROC
- Review of cryptographic cipher suites and protocols to ensure that you have a migration plan in place to respond to anticipated changes
- Review of hardware and software to make sure it supports your PCI compliance and remains in support for receiving security updates
What Makes a Change Significant?
One of the things that people struggle with is how to know when a change is considered as “significant”. Thankfully PCI DSS v4.0 helps make this clearer – but keep in mind it will always depend on your environment, so a change that is not significant to someone could still be significant to you. The Requirements and Testing Procedures state that the following activities, at a minimum, must be considered a significant change for the purposes of PCI DSS:
- New hardware, software, or networking equipment added to the CDE
- Any replacement or major upgrades or hardware and software in the CDE.
- Any changes in the flow or storage of account data.
- Any changes in the boundary of the CDE and/or to the scope of the PCI DSS assessment.
- Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging and monitoring).
- Any changes to third-party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.
The impact of the significant changes will also vary in terms of what you need to actually do for PCI DSS compliance. It could range from doing a new ASV scan to having to undertake a full assessment.
What’s the Difference Between Penetration Testing and Vulnerability Scanning?
Penetration testing and vulnerability scanning are two terms that often get confused and used interchangeably. In fact, this happens so often that the PCI SSC even published an information supplement that details the specific differences between them.
In the simplest of terms, the main difference si that penetration testing is primarily a manual process by a skilled individual while vulnerability scanning is an automated process. It’s not always as simple as that, but it’s a start.
What Do I Have to Scan?
PCI DSS talks about a few different types of scanning. And the biggest catch is that they are all different types of scans. So what kinds of scans might you have to do for PCI DSS?
| Scan Type | Required or Optional | PCI DSS v4.0 Ref | PCI DSS v3.2.1 Ref |
|---|---|---|---|
| Web Application Vulnerability Scans | Optional | 6.4.1 – until 2025 | 6.6 |
| Scanning for Rogue Wireless Access Points | Required | 11.2.1 | 11.1 |
| Internal Vulnerability Scans | Required | 11.3.1 | 11.2.1 |
| External Vulnerability Scans | Required | 11.3.2 | 11.2.2 |
| Cardholder Data Scanning | Optional | 12.5.2 | – |
Web Application Vulnerability scans have been able to be used as an alternative to a Web Application Firewall (WAF), but as of 2025 this will no longer be an option.
Cardholder data scanning is one option that’s suggested in the Guidance of Requirement 12.5.2 as a way for you support your documented scope and show that you have no cardholder data that is outside of the CDE.
