What actually happens during a PCI DSS assessment: A QSA perspective

Your First PCI DSS Assessment

Most people who book in their first PCI DSS assessment (certification) are braced for the wrong thing. They picture an auditor turning up to catch them out, going line by line through 300-odd sub requirements looking for a reason to fail them (I call this “audit-by-witchcraft”). That is not really how it goes. The hard part of an assessment is rarely the testing. It is working out what is actually in scope, and that conversation usually tells you more about an organisation's security than any single requirement/control ever will.

I have assessed retailers, Airlines, Banks, e-commerce platforms, payment service providers, call centres, hospitality groups, SaaS businesses and a fair number of organisations that were genuinely surprised to learn they were handling card data at all. The requirements are the same on paper for all of them. What happens in practice is shaped almost entirely by how the business is built, where the data flows, and how honest people are willing to be early on. This is an attempt to describe the real shape of an assessment rather than the brochure version.

A bit of background, because it explains the friction

PCI DSS exists because the card brands got tired of carrying the cost of fraud and breaches on their own. Visa, Mastercard, American Express (Amex), Discover and JCB each ran their own security programme in the early 2000s, which meant a merchant could be told three different things by three different brands. In 2006, they formed the PCI Security Standards Council and folded those programmes into one standard. That history matters for one reason: PCI DSS is not law. It is a contractual obligation that flows down from the card brands, through the acquiring banks, to you. Nobody from the Council audits you directly. Your acquirer or the brands decide whether you need to validate, and how.

This is why my usual answer to "do I have to do this?" is so often "it depends on who you signed with". And it is why an assessment is not a regulator's inspection. It is independent validation that you are meeting a contract you agreed to, carried out by a Qualified Security Assessor (QSA) whose own work is reviewed by the Council.

We are now assessing against PCI DSS v4.0.1. Version 3.2.1 retired in March 2024, and the 51 future-dated requirements from v4.0 stopped being best practice and became mandatory on 31 March 2025. So, any assessment running in 2026 has every one of those requirements fully in scope. If your last validation was under 3.2.1, or you scraped through in 2024 without implementing the future-dated items, your next report will find the gaps. There is nowhere left to defer them to, on a lighter note.

Scoping: The part that decides everything else

Before anyone tests a single firewall rule, we have to agree what the assessment covers. The cardholder data environment (CDE), is every system that stores, processes or transmits cardholder data, plus everything connected to it that could affect its security. That second half is where most arguments happen.

People want a small CDE because a small CDE means a cheaper, faster, less painful assessment. That is a perfectly reasonable goal, and reducing scope through tokenisation, point-to-point encryption or outsourcing the payment page is genuinely good security. What is not reasonable is drawing a tidy box on a diagram and hoping the connected systems do not count. A jump server that administrators use to reach the CDE is in scope. The Active Directory domain that authenticates those administrators is in scope. The monitoring platform pulling logs out of the CDE is in scope. The moment a system can influence the security of card data; it is part of the assessment whether anyone wants it to be or not.

Good scoping starts with data flows, not network diagrams. I want to know where a card number enters the business, every system it touches on the way through, where it comes to rest, and where it leaves. Card data has a habit of turning up in places nobody designed for it: a spreadsheet a finance team built years ago, call recordings nobody thought to mask, an email inbox where customers send their details because someone once told them to. Finding those before the assessment formally begins is the single most useful thing a readiness review does.

This is also where we settle which validation route applies. Merchants fall into levels based on transaction volume, service providers into their own levels, and the volume decides whether you self-assess with a Self-Assessment Questionnaire or need a full Report on Compliance signed off by a QSA. Picking the right SAQ matters more than people think. An e-commerce merchant who assumes they qualify for the lightest questionnaire, when their payment page can actually influence the transaction, has chosen the wrong route entirely and will find that out at the worst possible moment.

What the assessment itself involves

Once scope is agreed and is usually documented, the work is methodical rather than dramatic. For every applicable requirement, a QSA has to do more than ask whether a control exists. We have to validate it through evidence, and the standard tells us what counts. That means four things, used in combination:

Documentation review, where we read the policies, procedures, network diagrams, data flow diagrams and inventories and check they describe what the business actually does rather than what someone downloaded from a template five years ago.

Interviews, where we talk to the people who run the controls. You learn a great deal from asking an engineer to explain how patches get deployed and watching whether the answer matches the written procedure.

Observation, where we watch a process happen. Someone provisioning a new user, someone responding to a simulated alert, a visitor being signed into a data centre.

Configuration and technical review, where we look at the actual settings: firewall rulesets, system hardening, logging configuration, access control lists, encryption settings. This is where claims meet reality.

We do not look at every system. We sample. If you have 400 servers built from the same hardened image, I select a representative set across the types and locations and test those. The sample has to be defensible, which means the more consistent and automated your environment is, the smaller and easier the sample. Organisations that build everything by hand, each box slightly different from the last, make their own assessment harder because nothing can be assumed from one system to the next.

Two pieces of technical work usually sit alongside the QSA's testing. Penetration testing has to demonstrate that your scope is real, which means testing the segmentation that keeps the CDE separate from the rest of the network. If a tester can step from the corporate network into the CDE, the boundary you drew during scoping does not exist, and the scope expands to match reality. Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) also have to show clean results, or evidence that findings were remediated and rescanned.

Version 4.0.1 added two routes to meeting a requirement. The defined approach is the traditional one: meet the requirement exactly as written. The customised approach lets a mature organisation meet the stated objective of a requirement using controls of their own design, provided they document a targeted risk analysis and prove the control works. It offers real flexibility, but it shifts a heavy evidentiary burden onto the entity and onto the QSA, who has to design bespoke testing to validate it (QSAs do not enjoy this approach). In practice it suits organisations with genuine security maturity and good documentation. For most, the defined approach is still the sensible path. Compensating controls remain available too, for the narrower case where a genuine constraint stops you meeting a requirement and you can put something of equivalent strength in its place.

What changes from one sector to the next

The requirements do not change between industries. Everything around them does.

A bricks-and-mortar retailer lives or dies on its point-of-sale estate and the physical security of its stores. The interesting questions are about how terminals are deployed, how they are protected from tampering, and how the till network is kept away from everything else. An e-commerce business has none of that and a completely different problem: the security of the payment page and the scripts running on it. The v4.x requirements around payment page script management and change detection exist because attackers worked out that skimming a checkout page is easier than breaking into a data centre. For an online merchant, that is now one of the sharper parts of the assessment.

Call centres are their own world. The moment an agent reads a card number aloud, or a customer reads one out, that audio is card data. So, the assessment looks hard at call recording: whether it pauses and resumes around card capture, or whether Dual-Tone Multi-Frequency (DTMF) masking keeps the digits out of the recording and out of the agent's earshot entirely. I have walked into operations that recorded everything, retained it for years, and had no idea they were sitting on a vast store of cardholder data and sensitive authentication data they were contractually forbidden to keep.

Hospitality tends to combine the worst of several worlds: card-present terminals at the desk, card-not-present bookings over the phone, third-party booking platforms, and staff turnover that makes consistent process genuinely difficult. Service providers and SaaS businesses, by contrast, carry the weight of everyone who depends on them. When your platform handles other people's transactions, your scope and your responsibilities multiply, and the assessment spends real time on how responsibilities are split between you and your customers, and whether that split is written down anywhere both parties have actually seen.

Infrastructure shifts the work as much as sector does. A legacy on-premise environment means physical inspection, hardware inventories and the slow archaeology of working out what a fifteen-year-old system actually does. A cloud-native environment means reading the shared responsibility model carefully, because the cloud provider secures some controls and you secure others, and the boundary is not always where people assume. The provider's own attestation covers their side of the line. It does not cover your misconfigured storage bucket, for example. Hybrid environments, which is most of them, require holding both pictures in your head at once and making sure nothing falls down the gap between them.

Where assessments actually go wrong

After enough of these, the failures cluster. Scope is discovered to be larger than declared, almost always because of a data flow nobody mapped. Documentation describes an organisation or process that no longer exists. A control is in place, but nobody can produce evidence it has been running all year, which under v4.x matters more than ever, because the standard now expects security to be a continuous business-as-usual activity rather than a thing you assemble in the fortnight before the assessor arrives. Logging is configured but never reviewed. Access for leavers is revoked eventually rather than promptly. None of these are exotic. They are the ordinary consequences of treating compliance as an annual event instead of an operating habit.

The organisations that find assessments straightforward are not the ones with the biggest security budgets. They are the ones who know exactly where their card data is, keep their documentation honest, and can show their controls working on any given day rather than just on assessment day. That is the whole game, and it is why the most valuable conversation we have is almost always the first one, long before any testing starts.

If you are not certain where your card data lives, or whether the scope you have been validating against still matches the business, that is the place to start. It is a far cheaper question to answer in a readiness review than to discover halfway through a Report on Compliance assessment.

If you are preparing for your first PCI DSS assessment, moving from PCI DSS v3.2.1 to v4.0.1, or trying to work out whether your current scope still makes sense, the best time to get help is before the formal assessment begins.

Conclusion

Our PCI DSS specialists can support you with scoping, readiness reviews, gap assessments, SAQ selection, evidence preparation and full QSA-led assessments. We help you understand what is genuinely in scope, where the likely issues are, and what needs to be fixed before it becomes a problem in the report.

Find out more about our PCI DSS services here.

Whether you need a full assessment or just a clearer view of where you stand, we can help you approach PCI DSS with less uncertainty and a much better plan.