Running a PCI DSS Gap Assessment Before a QSA Audit

A gap assessment before your formal QSA engagement is not about gaming the audit. It is about using the time you have to fix known problems rather than discovering them during fieldwork when the remediation window is gone. The merchants who sail through PCI assessments are almost always the ones who did a serious internal review three to six months before the QSA arrived.

The hard part is choosing where to focus. The DSS 4.0 control set contains hundreds of requirements and sub-requirements. A small compliance team cannot practically review every item with equal attention, and it does not need to. Industry practice consistently points to four requirement families with the most repeat findings: Requirement 1 (network controls), Requirement 6 (patching and software security), Requirement 8 (access management), and Requirement 10 (logging). Starting with these captures most remediable findings before your QSA reviews them.

Structuring a Self-Directed Gap Assessment

Organizing the assessment by requirement family is more useful than arranging it by risk tier or business process. QSAs move through the ROC template requirement by requirement, so your evidence must follow that structure. Mirroring it during the internal review makes the move into the formal assessment more direct.

Each requirement family should produce three lists: sub-requirements with complete, verifiable evidence; those with partial or uncertain compliance; and those with a clear gap. The middle list matters most. "Partial or uncertain" often means, "I believe we comply, but I cannot prove it to a QSA." That is a finding waiting to happen, and correcting the documentation gap is often easier than correcting the control itself.

A bootstrapped team conducting this internally should plan about three focused days for each requirement family. Requirement 6 may need more time because 4.0 now includes TRA documentation for every patch decision. Allow a full two weeks for the four families before reviewing secondary requirements.

Requirement 1: Network Controls

For Requirement 1, center the review on three questions: Is the CDE boundary accurately defined in a network diagram that matches the actual layout? Are firewall rules documented with business justification for every allowed path? Do you have a 12-month record of firewall change reviews?

Requirement 1.2.4's network diagram requirement is often underestimated. The diagram must show every connection between the CDE and other network zones, including cloud infrastructure, third-party connections, and remote access paths. If the documented diagram differs from what a traceroute would show, that is a finding. Compare it with the actual infrastructure and confirm that it reflects reality.

Requirement 1.3.2 on firewall rule justification exposes environments where rules accumulated over years without a recorded business reason for each allow rule. For every rule permitting traffic into or out of the CDE, can you document why the traffic is needed? Remove rules that cannot be justified. For justified rules, attach the documentation to the rule in your change management system.

Requirement 6: Patching and Software Security

Under DSS 4.0, Requirement 6 has two gap assessment components that were absent from 3.2.1.

First, confirm that vulnerability management includes targeted risk analysis documentation for non-critical patch decisions. For deferred medium or low-severity items in the patch backlog, is there a documented reason for each deferral? If not, create TRA documentation retroactively when the reasoning remains defensible, or escalate the item for immediate patching when it does not.

Second, DSS 4.0 Requirement 6.2 requires bespoke and custom software developed for CDE use to follow a secure development lifecycle. Ask whether security review occurs before production deployment. If your team develops or maintains custom code that handles cardholder data, retain evidence of code reviews covering security checks, not only functional correctness.

Requirement 8: Access Management

Requirement 8 produces more repeat findings than any other requirement family because access controls drift. Controls that were correct at the last assessment often degrade during the following 12 months through role changes, incomplete termination processing, shared accounts created for convenience, and temporary privileged access that was never revoked.

For Requirement 8, the most useful activity is a complete review of CDE access: active accounts, owners, last login dates, permission levels, and MFA status. Compare the active account list with your current employee and contractor roster. An account without a current authorized user is a finding. A privileged account without MFA is a finding under Requirement 8.4.2.

DSS 4.0 Requirement 8.6.3 requires passwords for application and system accounts to be managed against exposure. If a system account's credentials are compromised or expired, a defined rotation process must exist. Include CDE service accounts and API keys used in integrations in the access review, not only human accounts.

Requirement 10: Logging

Requirement 10 has three review parts. First, confirm that log sources from every CDE component reach the centralized log store. Logging may be configured on primary systems but incomplete on ancillary CDE components such as jump hosts, authentication servers, or internal firewalls. Check that every in-scope system sends logs.

Second, check retention. Pull the oldest available log from the retention store and review its date. If it is less than 12 months old, the retention policy is not working. Confirm the three-month immediate-availability requirement by checking the query response time for a log from 75 days ago.

Third, confirm that daily log review produces documented output. Requirement 10.4.1 requires daily review of critical-system logs. When a SIEM automates that review, pull a week of SIEM alerts and confirm they were reviewed and actioned. No alerts during a week in a production CDE is suspicious and may indicate poorly calibrated alerting rules.

After the Assessment: Prioritizing Remediation

A thorough gap assessment should end with a prioritized remediation list. Rank items by the likelihood that a QSA will find the gap and the effort needed to fix it. Items with high finding likelihood and low remediation effort, such as missing documentation for a completed access review or a network diagram that needs updating, should be handled immediately. High-effort, high-likelihood items, such as a logging architecture overhaul or retiring a legacy system that cannot support MFA, need project plans with realistic timelines.

Be realistic about what can be fixed before the assessment window. If a genuine gap needs three months of infrastructure work, you may need a compensating control documented in a Requirement 3.3 or higher-risk exception format. Otherwise, start the project immediately rather than waiting for the assessment. QSAs notice when merchants spend six weeks before fieldwork cleaning up documentation but do none of the actual remediation.

A well-run gap assessment does more than surface findings. It creates internal alignment: everyone responsible for formal-assessment evidence knows what is expected, and the team enters the QSA engagement with a shared view of its compliance posture instead of discovering gaps during interviews.