I’ve been through several PCI DSS Level 1 audits over the years and never failed one. What follows comes from actual experience in the room with actual QSAs, not a rehash of compliance vendor marketing. If you’re heading into a Level 1 audit, here’s what actually matters.
Key Takeaways#
- Level 1 applies if you process more than 6M card transactions annually, more than 300K as a service provider, or experienced a breach at any size — and means annual on-site QSA assessment
- Scope is the whole game: the jump server admins use to reach payment systems is in scope; the shared workstation with RDP access to anything in the CDE is in scope; the logging platform ingesting CDE events is probably in scope
- PCI DSS v4.0 extended MFA to all CDE access (not just admin or remote), mandates WAFs on all public-facing web applications, and requires credentialed internal vulnerability scans — teams that treated v4.0 as incremental are behind
- Payment page script management (Req 6.4.3) catches e-commerce teams flat-footed: every third-party script on a checkout page must be authorized, integrity-verified, and inventoried — a direct response to Magecart-style attacks
- QSAs are assessing whether you’ve been secure for the past year — organizations that treat PCI as a seasonal scramble are visible to experienced assessors
First, Know What You’re Walking Into#
A Level 1 audit is the most rigorous form of PCI compliance validation. It applies to merchants processing more than six million card transactions annually across all channels, to service providers processing more than 300,000 transactions per year (that’s Visa’s threshold; it varies by card brand), and to any organization that has experienced a cardholder data breach regardless of size. The result is an annual on-site assessment by a Qualified Security Assessor (QSA), quarterly external scans from an Approved Scanning Vendor (ASV), and penetration tests, all culminating in a Report on Compliance (ROC) and a signed Attestation of Compliance (AOC).
The current governing standard is PCI DSS v4.0.1, which became the only active version after v4.0 was retired on December 31, 2024. As the PCI Security Standards Council has confirmed, v4.0.1 is a limited revision that corrects typos and clarifies intent. There are no new or removed requirements relative to v4.0. But v4.0 itself introduced 64 new requirements over v3.2.1, and if your team hasn’t fully digested those yet, you’re already behind.
Scope is the Whole Game#
If there’s one thing I’d drill into anyone preparing for a Level 1 audit, it’s this: controlling your scope is the single most valuable thing you can do. Everything else flows from it.
Your Cardholder Data Environment (CDE) is defined as the systems, people, and processes that store, process, or transmit cardholder data or sensitive authentication data, plus any system connected to those systems that could impact their security. That last clause is where organizations get burned. The jump server that admins use to manage your payment database? In scope. The logging platform that ingests events from your payment systems? Probably in scope. The shared workstation that happens to have RDP access to something in the CDE? In scope.
The PCI SSC’s own guidance recommends assuming everything is in scope until you can prove otherwise. That’s the right mental model to start with, but it’s not where you want to end up. A bloated scope can significantly inflate your audit costs and timelines, and it means more systems where something can go wrong.
Network segmentation is your primary tool for reducing scope. By isolating the CDE from the rest of your infrastructure using firewalls, VLANs, and strict access controls, you shrink the footprint that needs to satisfy every PCI requirement. As Strike Graph’s compliance researchers note, modern logical segmentation has largely replaced physical separation, but the principle is the same: prove that systems outside the CDE cannot reach systems inside it.
Tokenization is the other major lever. Replacing Primary Account Numbers (PANs) with tokens means your internal databases no longer hold actual cardholder data, which moves those systems out of scope. But as security reviewers at SecurityReview.ai rightly point out, a QSA will push hard on your tokenization claims. You need verifiable evidence that boundaries are enforced, access is limited, and everything is logged. Claiming tokenization without the architecture to back it up is worse than not claiming it at all.
Point-to-Point Encryption (P2PE) takes it even further. When card data is encrypted at the point of interaction and only decrypted by the processor, your network never sees the raw data, and the scope reduction can be dramatic, sometimes shrinking a complex audit down to a handful of applicable controls.
Whichever approach you use, document it thoroughly. Your QSA will want data flow diagrams showing exactly how cardholder data enters your environment, every system it touches in transit, and how it exits. If you can’t draw that diagram confidently before the audit begins, you’re not ready.
What’s Actually New in v4.0 That Will Catch People Off Guard#
A lot of organizations treated v4.0 compliance as incremental. It isn’t. The standard grew from roughly 370 to over 500 requirements, and some of the changes are genuinely disruptive to how teams have historically operated.
MFA for all CDE access. Under v3.2.1, MFA was required only for administrators accessing the CDE remotely. Under v4.0 requirement 8.4.2, MFA is required for all access into the CDE, regardless of role. That means your developers, analysts, support staff, anyone who touches those systems, needs a second factor. And MFA for remote access that terminates outside the CDE doesn’t satisfy this requirement; you need MFA enforced at the CDE boundary itself.
Password length increases. Requirement 8.3.6 raises the minimum password length from seven to twelve characters. The only exception is legacy systems that genuinely cannot support twelve characters, in which case eight is the floor. Accounts that are only password-protected (no MFA) still require changes every 90 days.
Mandatory Web Application Firewalls. Requirement 6.4.2 now mandates that public-facing web applications be protected by an automated technical solution, a WAF, that continually detects and prevents web-based attacks. The old option of performing periodic manual application reviews is gone. The WAF must be actively running, kept up to date, and generating audit logs.
Payment page script management. This one catches e-commerce teams off guard. Requirement 6.4.3 requires that all scripts on payment pages be authorized, their integrity verified, and an inventory maintained. This is a direct response to web skimming attacks (think Magecart-style compromises where malicious JavaScript is injected into checkout pages). If you have third-party scripts running on payment pages, you need to know exactly what they are and be able to prove none of them have been tampered with.
Authenticated vulnerability scanning. Requirement 11.3.1.2 now requires internal scans to be authenticated (credentialed). Unauthenticated scans only show you what’s visible from the network perimeter. Authenticated scans show you what an attacker could do once they’re inside. The credentials used for these scans should be treated as highly privileged and protected accordingly.
Annual scope confirmation. Requirement 12.5.2 mandates that merchants formally document and confirm their PCI DSS scope at least once every 12 months or after significant changes. For service providers, that cadence increases to every six months. This might seem administrative, but it has a practical purpose: environments drift, and what was accurately scoped a year ago may not be accurate today.
The Pre-Audit Gap Analysis is Non-Negotiable#
Before your QSA sets foot in the building, you should already know where you stand against every requirement. Running an internal gap analysis, or bringing in a QSA acting in a consulting (not assessment) capacity, gives you the map before the territory starts being evaluated.
This is especially valuable with v4.0. The standard introduced a new “Customized Approach” that lets organizations meet security objectives using their own controls rather than the prescriptive ones in the standard. It sounds appealing, but it requires a full Targeted Risk Analysis, extensive documentation, and QSA validation of your methodology, and it’s only available through a full ROC process, not through SAQs. For most Level 1 organizations sticking to the Defined Approach, the gap analysis is about checking your existing controls against documented requirements and finding holes before the assessor does.
If you want an outside set of eyes on this, it’s worth engaging an independent advisor who knows the standard well and isn’t also the one writing your ROC. That’s actually a service we offer at Greymantle Risk Advisory: pre-audit gap assessments that give you a clear remediation roadmap before your QSA engagement begins.
The gap analysis should produce a remediation list. Work through it before assessment week. Don’t carry open items into the audit and expect to explain them away. Your QSA’s job is to validate compliance, not to grant extensions.
Your QSA Relationship Matters More Than You Think#
A Level 1 audit is not an adversarial process, but it becomes adversarial when organizations treat it like one. The QSA’s role includes assessing your environment but also includes helping you understand requirements and work through ambiguities. If you’re engaging your QSA only during assessment week, you’re leaving value on the table.
The best working relationships I’ve seen, the ones that lead to clean audits, involve treating the QSA like a technical partner throughout the year. Questions about how a new architecture decision affects your scope? Ask before you build it. Uncertainty about whether a compensating control will be accepted? Have that conversation early. Show up to assessment week with no surprises, and you’re most of the way there.
Documentation: The Thing That Keeps Coming Up#
The audit process involves interviews with staff, configuration reviews, and testing of controls. But it also involves a lot of documentation review. Your QSA will want to see:
Your network diagrams and data flow diagrams. Your written security policies and procedures. Evidence that quarterly ASV scans have been completed and any findings remediated. Penetration test results. Access review records (under v4.0, human accounts must be reviewed at least every six months). Change management records. Security awareness training completion logs. Evidence of log review, patch management, and vulnerability remediation.
The important thing about documentation is that it needs to reflect reality, not aspirational policy. If your written procedure says you patch critical vulnerabilities within 30 days but your actual patching cadence runs 90 days, that’s a finding waiting to happen. Keep your documentation in sync with your actual operations year-round, not just in the weeks before the audit.
Compliance is a Year-Round Job#
This is the part that separates organizations that consistently pass from organizations that scramble through assessments. PCI DSS compliance doesn’t exist only during assessment season. Your quarterly ASV scans need to be clean year-round. Your internal scans need to run on schedule and findings need to be tracked and remediated. Your logs need to be reviewed. Your access reviews need to happen. Your incident response plan needs to be tested.
As Tenable’s PCI guidance notes, vulnerability scanning is mandatory at least once every three months, with more frequent scanning recommended for complex environments. If you’re only thinking about scans when an audit is approaching, you’re building a compliance theater rather than a security program, and experienced QSAs can tell the difference.
The organizations that consistently pass Level 1 audits are the ones that have made PCI controls part of their normal operating rhythm. They’re not proving they were secure during assessment week. They’re showing that they’ve been secure for the past year. That’s what the ROC is actually documenting, and it’s what makes the difference.
Quick Reference: Things Most Likely to Trip You Up#
- Scope creep: systems added to your environment without evaluating their CDE connectivity
- MFA gaps: failing to extend MFA to all CDE access, not just admin or remote access
- Payment page scripts: no inventory or integrity verification for third-party scripts on checkout pages
- WAF coverage: public-facing applications without WAF protection, or WAFs that are present but not properly logging
- Stale documentation: policies that don’t match actual procedures
- Evidence gaps: quarterly scans completed but not retained, or access reviews done verbally but not logged
- Segmentation validation: segmentation not tested via penetration testing as required by Requirement 11.4.5
Get these right, and a Level 1 audit is a process, not a crisis.
Greymantle Risk Advisory helps organizations prepare for PCI DSS audits before the QSA shows up. We provide independent gap assessments, remediation roadmaps, and compliance readiness support so your audit is a confirmation, not a discovery.