main logo icon

Published on

June 24, 2025

|

11 min read

PCI-DSS Audit Process: Best Practices

PCI DSS audit process explained: the 6 steps, how long it takes, what a Level 1 QSA audit costs, and what changed under PCI DSS 4.0.1 for 2026.

Arafat Afzalzada

Arafat Afzalzada

Founder

Web App SecurityNetwork Security

Summarize with AI

ChatGPTPerplexityGeminiGrokClaude

TL;DR

Protecting customer payment data is essential, and PCI-DSS compliance helps businesses secure sensitive information while avoiding significant fines and breach costs. The PCI-DSS audit process involves defining the scope, reviewing documentation, conducting on-site testing, and addressing compliance gaps. Best practices for preparation include regular gap analyses, maintaining up-to-date documentation, and implementing continuous monitoring. Organizations that prioritize ongoing compliance and proactive security measures will enhance their data protection efforts and build customer trust. Stingrai's penetration testing supports your PCI DSS compliance program with the internal, external and segmentation test evidence assessors ask for, retest included.

Protecting customer payment data is non-negotiable. PCI-DSS compliance helps businesses secure sensitive credit card information, avoid fines (up to $100,000 per month), and reduce the risk of costly breaches (the global average data breach hit a record US$4.99 million in 2026, per IBM's Cost of a Data Breach Report). Here’s what you need to know about the audit process:

Quick answer: A PCI DSS audit moves through scope definition, documentation review, on-site control testing, remediation and reporting, and it goes smoothly when preparation is continuous: regular gap analyses, current documentation, ongoing monitoring and penetration testing. The post walks through the six steps, how long an audit takes, what a Level 1 QSA audit costs and what changed under PCI DSS 4.0.1. Stingrai's penetration tests supply the internal, external and segmentation testing evidence Requirement 11.4 asks for, with a retest included.

Key Steps of the PCI-DSS Audit Process:

  • Scope Definition: Identify all systems, processes, and people handling cardholder data.

  • Documentation Review: Ensure security policies, network diagrams, and training records are accurate and up to date.

  • On-Site Testing: Auditors conduct vulnerability scans, test controls, and interview staff.

  • Remediation and Reporting: Address compliance gaps, finalize reports, and receive certification.

Preparation Tips:

  • Conduct regular gap analyses to find and fix vulnerabilities early.

  • Keep documentation current to avoid audit delays.

  • Use continuous monitoring and penetration testing to maintain compliance year-round.

What is a PCI DSS audit?

A PCI DSS audit is a formal assessment that verifies whether an organization storing, processing, or transmitting payment card data meets every applicable control in the Payment Card Industry Data Security Standard. For Level 1 merchants and many service providers, a Qualified Security Assessor (QSA) performs the assessment and issues a Report on Compliance (ROC) and an Attestation of Compliance (AOC); smaller merchants who qualify may instead complete a Self-Assessment Questionnaire (SAQ). The audit covers all 12 PCI DSS requirements, so it is broader than any single testing mandate. For the testing requirement specifically, see our guide to PCI DSS penetration testing under Requirement 11.4, and for how testing maps to wider mandates, our overview of compliance-driven penetration testing.

PCI DSS audit process: the 6 steps

  1. Define and validate scope: Map every system, process, and person that stores, processes, or transmits cardholder data, and confirm the boundary of the cardholder data environment (CDE).

  2. Run a gap analysis: Measure current controls against the 12 PCI DSS requirements to find where the environment falls short before the formal assessment.

  3. Remediate the gaps: Fix missing or weak controls, update policies, and collect the supporting evidence the assessor will expect.

  4. Complete the QSA assessment: The assessor reviews documentation, interviews staff, and validates controls, including the vulnerability scans and Requirement 11.4 penetration tests PCI DSS requires. Deliver the kind of test evidence auditors accept so each control can be validated first time.

  5. Produce the ROC and AOC: The QSA documents results in a Report on Compliance and issues the Attestation of Compliance once all applicable requirements are met.

  6. Sustain compliance: Keep controls in force year round with continuous monitoring, quarterly ASV scans, and an annual reassessment so the next audit starts from a known-good state.

A well-organized audit process is crucial for maintaining PCI-DSS compliance and safeguarding cardholder data. The audit takes a methodical approach, covering every aspect of your cardholder data environment.

Setting the Audit Scope

The first step in a PCI-DSS assessment is defining the scope of the audit. This involves pinpointing which systems, processes, and personnel fall under review. Getting this right from the start can save time and resources down the line.

The scope includes all systems, people, and technologies that either handle cardholder data (CHD) or could affect its security. Your organization must identify every payment channel and method for handling cardholder data, from collection to disposal. This means mapping out every point where card data is processed or stored.

Systems are typically categorized as:

  • In-scope systems: Those that directly handle cardholder data.

  • Connected-to systems: Systems that do not process cardholder data but are networked to those that do.

  • Out-of-scope systems: Systems with no connection to the cardholder data environment.

Key activities during the scoping phase include:

Activity

Description

Identify CHD entry points

Map all payment channels and methods for accepting CHD, from collection to destruction or transfer.

Document data flows

Track CHD movement and identify processes, people, and technologies involved in storing, processing, and transmitting it.

Identify connected systems

Locate systems and personnel that interact with or influence the cardholder data environment.

Implement segmentation controls

Restrict unnecessary connectivity between the cardholder data environment (CDE) and other systems.

Apply PCI requirements

Ensure all in-scope components meet relevant PCI DSS standards.

Establish monitoring

Set up processes to maintain effective controls and ensure the scope remains accurate as changes occur.

Once the scope is defined, auditors review it through detailed documentation to confirm its accuracy.

Documentation Review

After scoping, auditors dive into your documentation to ensure your policies and practices align with PCI DSS requirements. This phase checks whether your written policies reflect actual operations.

Auditors evaluate a range of documents, including security policies, network diagrams, system configurations, and training records. They look for accuracy, completeness, and evidence that your organization follows these documented procedures.

Up-to-date diagrams, change management logs, access control records, and staff training documentation are all expected. Any outdated information can lead to compliance gaps or expand the audit scope unnecessarily.

On-Site Assessment and Testing

During this phase, Qualified Security Assessors (QSAs) perform hands-on evaluations at your facilities. They review documentation, interview staff, and inspect technical and physical security controls.

Technical testing includes vulnerability scanning and penetration testing, both required under PCI DSS. The objective is to validate whether your implemented controls are functioning as documented and if any overlooked risks exist in your infrastructure.

This is also where real-world simulations uncover weaknesses that cannot be identified through paperwork alone.

Audit Reporting and Remediation

The final phase summarizes the audit findings and identifies gaps. If any requirements are unmet, a remediation plan must be developed to close those gaps. The QSA may guide the remediation efforts and verify their effectiveness.

Once remediation is complete, the QSA issues an Attestation of Compliance (AOC), confirming full adherence to the PCI DSS requirements.

The remediation timeline generally follows this format:

  • Initial report issued with findings

  • Remediation activities within 30 days

  • Final review and AOC issued within 60 days

Following remediation, targeted reassessments validate whether the corrective actions were effective.

How long does a PCI DSS audit take?

A PCI DSS assessment usually takes a few weeks of active QSA fieldwork, but the full journey from scoping to a signed Attestation of Compliance commonly runs three to six months for organizations that need remediation, and longer where scope is large or controls are immature. PCI DSS compliance is an annual cycle: the ROC or SAQ is renewed each year, ASV scans run quarterly, and Requirement 11.4 penetration tests are performed at least annually and after any significant change. Teams that keep controls validated year round, rather than scrambling in the weeks before an assessment, move through each audit far faster.

How much does a PCI DSS audit cost?

Cost tracks merchant level and scope. Smaller merchants who qualify for a Self-Assessment Questionnaire may spend little on the assessment itself, while a QSA-led Level 1 Report on Compliance commonly runs from the low tens of thousands into six figures as environment complexity grows. Budget separately for quarterly ASV scanning, remediation work, and the internal and external penetration tests Requirement 11.4 mandates; our penetration testing cost guide breaks down the testing portion for 2026. Choosing a CREST-accredited testing provider helps ensure the pentest evidence holds up during the assessment.

PCI DSS 4.0.1: what changed for audits

PCI DSS v4.0.1 is the current version of the standard and a limited revision of v4.0, correcting errata and clarifying intent without adding new requirements. The change that matters most for audits is timing: the future-dated requirements that were best practice under v4.0 became mandatory on 31 March 2025, so assessors now test all of them (PCI Security Standards Council). Expect closer scrutiny of the customized approach and its targeted risk analyses, expanded multi-factor authentication, payment-page script and HTTP header management, and automated log reviews. The penetration testing requirement was renumbered to 11.4, which the offensive security section below covers in detail.

Best Practices for PCI-DSS Audit Preparation

Conduct Regular Gap Analyses

Gap analyses allow you to proactively evaluate your current state against PCI DSS requirements. This includes mapping CHD data flows, reviewing the 12 control categories, and identifying discrepancies.

Engage a cross-functional team from IT, Legal, Operations, and Security. Document each gap with supporting evidence, assign ownership, and prioritize fixes based on risk impact.

Tools like vulnerability scanners, access control audits, and endpoint compliance checks can aid this process. Maintain a log of resolved issues to track long-term improvement.

Keep Documentation Up to Date

Accurate documentation is critical. Network diagrams must match your infrastructure, and access control policies should reflect current roles and permissions. Inconsistent or outdated documentation may signal non-compliance.

Use automated tools to collect logs, maintain change records, and centralize storage of audit artifacts. Assign a documentation steward to maintain consistency across all records.

Establish Continuous Monitoring

PCI DSS v4.0 places greater emphasis on continuous security validation. Implement tools that provide real-time logging, access control validation, and policy enforcement.

Use SIEM systems and centralized dashboards to maintain an audit trail and generate alerts for anomalies. This ensures early detection and response to threats and supports ongoing readiness for assessments.

Offensive Security for PCI-DSS Compliance

Why Penetration Testing Matters

Penetration testing goes beyond vulnerability scanning. It simulates real-world attacks on the cardholder data environment to identify exploitable weaknesses.

PCI DSS Requirement 11.4 (v4.0.1) requires both internal and external penetration tests, having replaced the Requirement 11.3 numbering carried over from v3.2.1. The test scope must include all in-scope systems, including segmentation controls if segmentation is used to isolate the CDE.

Black-box, white-box, and gray-box methodologies provide insight into different threat perspectives. Testing frequency should be aligned with your risk profile. For budgeting, our guide covers what PCI DSS penetration testing costs in 2026 alongside the other compliance mandates.

Sustaining Long-Term Compliance

Year-round compliance reduces the need for rushed remediation. Frequent testing identifies security gaps early and supports iterative improvements.

Invest in purple teaming exercises, simulate attack paths, and incorporate threat intelligence to prioritize efforts based on risk rather than theoretical CVSS scores.

PCI DSS v4.0 encourages organizations to move from checklist-driven compliance to a maturity-based model supported by metrics and threat-informed validation.

Conclusion and Key Takeaways

The PCI-DSS audit is not just a requirement; it is a framework for building trust with customers and reducing risk exposure. The four audit stages scoping, documentation, testing, and remediation each play a critical role in maintaining data security.

Organizations that embrace continuous compliance through offensive security, automation, and real-time validation will outperform those relying on point-in-time checks.

Final Recommendations:

  • Regularly test segmentation controls and CHD boundaries

  • Train employees on security and PCI requirements

  • Integrate offensive testing into the development cycle

  • Maintain clear, current, and accessible documentation

  • Use modern platforms for real-time compliance validation

A proactive, well-documented, and continuously validated approach is essential to avoid fines, reduce audit fatigue, and maintain secure handling of cardholder data.

Frequently Asked Questions

Who needs a PCI DSS audit, and when is a self-assessment questionnaire enough?

Any organization that stores, processes, or transmits cardholder data must validate PCI DSS compliance. Level 1 merchants (broadly, those above six million card transactions a year) and many service providers need a Qualified Security Assessor to perform the audit and produce a Report on Compliance. Smaller merchants who meet the eligibility criteria can instead complete the applicable Self-Assessment Questionnaire, though a QSA or internal security assessor can still help validate the answers.

What’s the difference between in-scope, connected-to, and out-of-scope systems in a PCI-DSS audit?

In-scope systems directly process, transmit, or store cardholder data. Connected-to systems do not handle the data but are networked with in-scope systems and can affect their security. Out-of-scope systems are completely isolated and do not impact cardholder data environments.

How do continuous monitoring and penetration testing support ongoing PCI-DSS compliance?

Continuous monitoring ensures real-time visibility into systems handling cardholder data. Penetration testing simulates real-world attacks, validating the effectiveness of controls. Together, they support PCI DSS v4.0’s emphasis on sustained security.

What should an organization do if they discover gaps in PCI-DSS compliance during an audit?

Conduct a thorough review to assess the root cause and scope. Create a remediation plan with deadlines and ownership, implement fixes, document all changes, and request reassessment from your QSA.

40 views

1

X

Related reading

Supabase: Powerful, but One Misconfiguration Away From Disaster
Network SecurityWeb App Security

Supabase: Powerful, but One Misconfiguration Away From Disaster

The Supabase anon key is safe to expose only with Row Level Security enabled. See what service_role bypasses and the 2026 publishable key deadline.

11 min read

The Perils of Premature Vulnerability Reporting: A Case Study in Off-by-One Analysis
Web App SecurityNetwork Security

The Perils of Premature Vulnerability Reporting: A Case Study in Off-by-One Analysis

A suspected OpenVAS heap off-by-one overflow turned out to be a false positive. See the canary-byte testing and math that proved the allocation was correct.

8 min read

Adversary Simulation in Telecom: Case Study
Web App SecurityNetwork Security

Adversary Simulation in Telecom: Case Study

Explore how adversary simulation helps telecom networks identify and address critical vulnerabilities, enhancing cybersecurity against evolving threats.

8 min read

Contents

X