How to Prepare for a PCI DSS Compliance Audit in 2026

Most organizations fail their PCI DSS audit not because their policies are wrong, but because their architecture is unscoped. Here is what assessors are actually testing, and where compliance teams consistently get caught.

A PCI DSS compliance audit is an independent evaluation of every security control, policy, and system your organization uses to process, store, or transmit cardholder data. The common assumption among enterprise buyers in regulated industries is that if they have the right documentation and pass the SAQ, they've done PCI DSS compliance correctly. In reality, the assessor's job is not to confirm that your binder is organized.

It is to prove, through evidence and technical inspection, that your entire environment is identified, secured, and controlled. That distinction matters more than most compliance teams realize until a QSA is already in the room asking questions nobody prepared for. The stakes are concrete.

See our voice AI for how this works in practice.

14.3% of organizations achieve full compliance at their interim assessment. That means the overwhelming majority walk into an independent review believing they are ready and discover they are not. Clean documentation does not explain that gap. Unscoped architecture does. A PCI DSS compliance audit validates that the Cardholder Data Environment (CDE) is fully identified and that every system inside it meets the standard's 12 requirements. The assessor interviews staff, inspects network diagrams, reviews access logs, and tests controls.

If a system touches cardholder data and is absent from your scope documentation, that absence is a finding, not a footnote. The audit is trying to prove architectural control, not policy intent. Per the PCI DSS framework, the audit must validate that the entire environment, including outsourced and third-party systems, adequately protects cardholder data across all requirements.

Policies describe what you intend. Architecture describes what actually happens. PCI DSS scope expands silently.

Recurring billing integrations, patient portals, custom payment APIs, and third-party telephony platforms all create CDE surface area that compliance teams frequently miss. A common assumption is that routing payments through a third-party processor removes compliance obligations. In practice, it reduces scope but does not eliminate it.

The same logic applies to voice AI platforms handling payment intake calls: routing audio through a third-party AI provider reduces your direct processing footprint but does not remove PCI DSS obligations for that vendor relationship or its infrastructure.

14.3% of organizations achieve full interim compliance

Key takeaways#

• PCI DSS auditors trace data flows; they don't grade documentation. If a system touches cardholder data and isn't on your scope map, it becomes a finding, not a footnote.
• Merchant level is set by annual transaction volume, and getting it wrong before a QSA walks in means you've built your entire compliance posture on the wrong framework.
• Most telephony infrastructure goes unreviewed until a QSA asks the question nobody prepared for, and several of the 12 PCI DSS requirements apply directly to voice workflows.
• Routing call audio through a cloud-hosted voice AI platform is a scoping decision, not just an IT one. Under PCI DSS 4.0, that vendor's infrastructure becomes part of your Cardholder Data Environment the moment data flows through it.
• The penalty for a failed audit isn't a one-time fine; it's a monthly charge that keeps running until every finding is closed, and voice AI gaps are among the fastest ways to generate findings.
• Self-hosted voice AI keeps call audio inside your own infrastructure, which removes the vendor node from your CDE entirely instead of adding one. Bland.ai's self-hosted architecture is built on exactly that principle: your audit surface stays where you drew it.

Merchant Levels and How Annual Transaction Volume Determines Your Audit Requirements#

Before you can determine what a PCI DSS audit actually requires of your organization, you need to know which merchant level applies to you, because that classification dictates whether you face a full on-site assessment by a QSA or can satisfy compliance through a self-assessment questionnaire. The distinction is driven entirely by annual transaction volume, and misidentifying your level is one of the most consequential mistakes a vendor can make, directly affecting how you scope your environment and what you submit as evidence of compliance. For AI-driven communication platforms like Bland.ai that touch payment card data through voice interactions, getting this classification right from the start is the foundation everything else depends on.

The Four Merchant Levels Defined#

Merchant level is determined by annual transaction volume, and each level triggers a different validation path. As established across the broader payment security ecosystem, reflected in the Site Data Protection Program and corroborated by Visa's independent compliance framework, the thresholds break down as follows:

Compliance practitioners report that vendors frequently misunderstand their own merchant or service provider level, which leads to improper scoping of the self-assessment — a direct risk when SAQs are used to demonstrate compliance under 12.8.4.

Merchant Level

Annual Transaction Volume

Primary Validation Method

Level 1

Over 6 million transactions

QSA on-site assessment, Report on Compliance (RoC)

Level 2

1 million to 6 million transactions

Self-Assessment Questionnaire (SAQ) + Attestation of Compliance (AoC)

Level 3

20,000 to 1 million e-commerce transactions

SAQ + AoC

Level 4

Fewer than 20,000 e-commerce transactions, or up to 1 million total

SAQ + AoC

Note that Visa and Mastercard maintain independent programs, so thresholds can vary slightly by card brand. Always confirm your level directly with your acquiring bank. One of the most persistent, and costly, mistakes at this stage is misidentifying your own level.

When a vendor does not correctly understand their merchant or service provider classification, the self-assessment gets scoped improperly. That misscoping is itself a compliance gap, not just an administrative error. Getting the level right before you touch an SAQ is the single highest-leverage step in the entire process.

Level 1 Merchants#

For any merchant processing more than 6 million transactions annually, a Qualified Security Assessor (QSA) conducts a formal on-site assessment. The output is a Report on Compliance (RoC), a detailed document that evidences every control tested across the full cardholder data environment. Achieving a RoC typically takes several months depending on CDE complexity.

There is no self-certification shortcut at this level: the transaction volume signals that a breach here affects millions of cardholders. At this scale, compliance work generates a continuous stream of internal coordination, evidence collection calls, vendor attestation follow-ups, and control-owner interviews that can overwhelm internal teams. High-volume, high-stakes phone outreach of exactly this kind is where AI calling infrastructure proves its value: automating the routine touchpoints so compliance and security staff can focus on the substantive assessment work rather than scheduling and follow-up logistics.

Levels 2 Through 4#

Merchants below the 6 million threshold validate compliance through a Self-Assessment Questionnaire (SAQ) and submit an Attestation of Compliance (AoC), consistent with what SDP Program guidance prescribes across the market. The SAQ comes in multiple variants — A, B, B-IP, C, C-VT, and D — each mapped to a specific payment channel configuration. Your acquiring bank assigns the appropriate type based on how you accept and process card payments, and selecting the wrong variant is itself an audit finding.

The practical risk here is well understood by teams that work through this process regularly: misidentifying your level leads directly to choosing the wrong SAQ variant, which means controls go untested and the AoC you submit misrepresents your actual environment. Confirming your level with your acquiring bank, before selecting an SAQ type, is not a formality; it is the foundation the rest of your validation rests on. See Paytia's PCI DSS levels reference for a plain-language breakdown of how each level maps to specific questionnaire variants.

The 12 PCI DSS Requirements Every Audit Measures Against — Including the Ones Voice Workflows Violate#

Several of the 12 PCI DSS requirements are responsible for the majority of telephony-related audit findings, yet most compliance teams spend their pre-audit weeks focused on database encryption and firewall rules, leaving voice infrastructure unreviewed until a QSA asks the question nobody prepared for. Every one of the 12 requirements applies to any system that stores, processes, or transmits cardholder data. That includes your IVR platform, your SIP trunks, your call recording server, and any AI phone agent handling payment intake calls.

One upstream pressure that compounds this risk: small startups building in-house card-handling UIs are forced into higher PCI DSS compliance tiers — SAQ A-EP or SAQ D requiring a full Report on Compliance — because raw card data flows through their own systems, directly triggering stricter requirements across all 12 controls. Every architectural decision that routes spoken card numbers through your own voice infrastructure is a scope-expansion event, not just a technical detail.

1. Requirement 1 — Network Security Controls: Where Voice Gateways Create Invisible CDE Exposure#

Requirement 1 covers every network component in scope, including SIP trunks, session border controllers, and voice gateways. If they connect to systems that touch cardholder data, they belong inside your CDE boundary map. The most common failure here is a network diagram that stops at the web application layer, treating the telephony stack as a separate, unscoped environment. QSAs do not accept that boundary.

Any unscoped voice gateway connected to a payment workflow is an immediate finding. Bland.ai's Enterprise plan runs on dedicated infrastructure, a dedicated orchestration server rather than shared multi-tenant routing, so that every network boundary your QSA maps is cleanly owned, documented, and defensible. Compliance documentation is available under NDA, which means your security team has the artifacts they need before the QSA walks through the door, not after.

2. Requirement 2 — Secure Configurations: Default Credentials on IVR Platforms Are a Guaranteed Audit Failure#

IVR platforms and SIP-connected hardware ship with vendor default usernames and passwords. Requirement 2 prohibits their use in any in-scope system. In practice, telephony equipment is provisioned by a telecom team, not a security team, and default credentials are left in place for months or years.

A QSA who tests a voice gateway and finds factory-default login credentials will document it as a critical control failure regardless of how clean the rest of the environment looks. Bland.ai avoids this failure mode by design. The platform ships with integrations available across plans, from the Start tier through Enterprise, meaning your AI phone agents slot into existing toolchains without requiring you to stand up and harden bespoke SIP hardware that a telecom contractor provisioned and forgot.

For organizations on Enterprise, the forward-deployed engineering team scopes, builds, and gray/red/green-team tests the environment before go-live, giving security teams a hardened baseline rather than a default-credential landmine. According to cloud security research, misconfigured systems and default credentials remain among the most exploited vectors in cloud and telephony breaches, a risk Bland's managed deployment model is built to eliminate.

3. Requirement 3 — Cardholder Data Storage: Why Call Recordings Are a Ticking Compliance Bomb#

Requirement 3 prohibits storing sensitive authentication data after authorization, including spoken card numbers captured in call recordings. Unredacted audio files containing full PANs represent one of the most widespread Requirement 3 violations in enterprise contact center environments, a finding documented consistently across breach and audit data. Encryption, masking, tokenization, or hashing are all acceptable controls, but they must be applied before the recording is written to storage, not retroactively.

Most call recording platforms do not do this by default. Bland.ai's approach supports continuous sentiment capture and interaction analysis, measuring and improving customer sentiment across every call at scale, without requiring operators to retain raw audio containing card data to extract that intelligence. The platform's real-time transcription (included in the per-minute rate across all plans) means insights are derived from the conversation stream, not from a stored audio file that becomes a compliance liability the moment a spoken PAN hits it.

For Enterprise customers, the on-prem / VPC deployment option and data residency controls give compliance teams direct authority over where transcription data lands and how long it persists.

4. Requirement 4 — Encryption in Transit: Unencrypted SIP Trunks Transmitting Card Data Fail Immediately#

A voice AI platform transmitting call audio containing card numbers to a cloud provider over an unencrypted SIP trunk violates Requirement 4 on its face. Encrypted transmission of cardholder data in transit is non-negotiable under Requirement 4. Any voice AI platform handling payment-related call audio must enforce TLS or SRTP across every connection; unencrypted paths are a direct finding regardless of other controls in place.

Cloud security data confirms that data-in-transit exposure remains a leading category of breach across cloud-connected telephony environments. Here is where architectural choice has direct audit consequences. Every call that goes unanswered because a business underinvested in its AI voice layer is also a call that may have been handled by a less hardened fallback channel — a human agent on an unencrypted softphone, or a legacy IVR with no SRTP enforcement.

Bland.ai maintains a 99.9% uptime SLA across every plan tier, ensuring that the hardened, compliant path is always the live path. The Enterprise plan adds JWT signatures and custom dialing controls, giving security architects the transmission-layer guarantees Requirement 4 demands, and the audit evidence to prove them.

5. Requirement 5 — Anti-Malware Controls: Softphone Endpoints Are Frequently Excluded from AV Scope#

Requirement 5 requires anti-malware protection on all systems commonly affected by malicious software, including those in or connected to the CDE. Agent workstations running softphone clients are frequently omitted from endpoint protection inventories because they are managed by telecom teams rather than IT security. A PCI DSS compliance audit will enumerate every endpoint in scope; a softphone workstation without current, monitored anti-malware is a straightforward finding with no compensating control path.

6. Requirement 6 — Secure Development: Voice Bot and IVR Application Code Rarely Undergoes PCI-Required Review#

Requirement 6 mandates secure development practices, vulnerability management, and change-control processes for all in-scope applications. Custom IVR flows, voice bot scripts, and telephony middleware are software that processes cardholder data, yet they are almost never subjected to the code review, vulnerability scanning, or change-management rigor applied to web applications. Auditors increasingly treat these as in-scope applications, and organizations without documented SDLC evidence for voice application changes will face findings.

7. Requirement 7 — Access Control: Broad Agent Access to Call Recordings Containing PANs Violates Least Privilege#

Requirement 7 enforces need-to-know access restrictions on cardholder data, permitting access only to the minimum necessary for job function. Call recording repositories that store audio containing spoken card numbers are frequently accessible to entire contact center teams, supervisors, and QA staff without role-based restrictions. During a PCI DSS compliance audit, QSAs will review access control lists on recording systems; blanket read access across a contact center workforce is a clear least-privilege violation.

8. Requirement 8 — Identity and Authentication: Shared Agent Login Credentials on Phone Systems Undermine Accountability#

Requirement 8 mandates unique IDs for every user, multi-factor authentication for remote access, and strong password policies across all in-scope systems. Contact centers routinely assign shared queue credentials or generic agent logins to telephony platforms, making individual accountability impossible. Auditors will request user account inventories for every system in scope; shared credentials on any CDE-adjacent voice platform are a direct Requirement 8 failure with no straightforward compensating control.

9. Requirement 9 — Physical Access Controls: Unmonitored Agent Workstations in Remote Work Environments Expand Audit Scope#

Requirement 9 governs physical access to systems that store, process, or transmit cardholder data, including workstations used by agents handling phone-based card transactions. The shift to remote and hybrid contact center models has created thousands of agent endpoints in uncontrolled physical environments. Auditors will ask for physical security controls — screen locks, clean-desk policies, and device management — for every remote agent workstation in scope, and most organizations have significant documentation gaps here.

10. Requirement 10 — Audit Logging: Voice Platform Event Logs Are Routinely Missing from SIEM Scope#

Requirement 10 mandates logging of all access to cardholder data and system components, with log retention of at least 12 months and three months immediately available. IVR platforms, call recording servers, and VoIP gateways generate event logs that are almost never forwarded to the organization's SIEM or log management system. During a PCI DSS compliance audit, QSAs will verify log completeness across all in-scope systems; missing voice platform logs are a common and easily avoidable finding.

11. Requirement 11 — Vulnerability Testing: Telephony Infrastructure Is Systematically Excluded from Penetration Test Scope#

Requirement 11 requires regular vulnerability scanning and annual penetration testing of all in-scope systems and network segments. Penetration test scopes are almost universally defined by web and network teams who exclude telephony infrastructure as outside their domain. QSAs reviewing penetration test reports will identify scope gaps; a SIP gateway or IVR server that processes card data but was excluded from the pen test is a Requirement 11 finding that can delay certification by months.

12. Requirement 12 — Security Policies: Absence of a Voice-Specific Data Handling Policy Signals Systemic Governance Failure#

Requirement 12 mandates a comprehensive information security policy that addresses all components of the PCI DSS program, including acceptable use, incident response, and vendor management. Organizations rarely have a documented policy governing how agents handle card data over voice channels — what to say, what not to record, how to escalate a suspected breach on a live call. Auditors treat the absence of voice-specific policy as evidence of systemic governance immaturity, compounding findings across other requirements.

QSA-Led Audits vs. Self-Assessment Questionnaires — What Each Actually Requires From You#

Pick the wrong SAQ type before a QSA walks in the door, and you haven't just filled out the wrong form. You've drawn the wrong map of your entire cardholder data environment, and every system you left off that map becomes a finding waiting to happen. The true cost asymmetry of a QSA audit versus an SAQ is not the upfront fee differential; it is the scope-expansion penalty triggered mid-assessment when an unscoped voice AI vendor is discovered, converting a self-administered SAQ into a mandatory QSA engagement with remediation costs that dwarf the original compliance budget. In other words, the wrong SAQ selection doesn't just create a paperwork problem; it creates a financial exposure that only materializes once a QSA is already in the room.

One pressure point worth naming directly: small merchants and lean teams often feel overwhelmed by PCI DSS documentation written for large enterprises with dedicated security teams. When you're running high call volumes without a compliance department, it's genuinely hard to identify which controls actually apply to your environment and which SAQ type is the right starting point. That ambiguity is where scope mistakes get made. Bland.ai's Enterprise plan addresses this head-on: compliance documentation is available under NDA, and a forward-deployed engineering team scopes, builds, and goes live with your first agent within 30 days, so the boundaries of your voice AI environment are established before a QSA ever reviews them, not discovered during the assessment.

What a QSA-Led Audit Actually Demands#

A Qualified Security Assessor (QSA) conducts far more than a document review. QSAs perform on-site visits, staff interviews, and technical evidence review across every system in scope, then issue a formal Report on Compliance (RoC). RoC assessments run between $15,000 and $200,000+ depending on the complexity of your cardholder data environment.

That range isn't driven by the QSA's hourly rate. It's driven by scope. Every third-party vendor your QSA discovers mid-assessment that wasn't pre-scoped extends the engagement and the invoice.

Demonstrating measurable ROI from your voice infrastructure to leadership becomes significantly harder when compliance costs are unpredictable. Bland.ai captures structured data from every call, feeding analytics and CRM systems automatically, and captures customer sentiment at scale across every interaction. The platform gives compliance and operations teams the documented call-level evidence that QSAs request as part of technical evidence review. That structured record exists regardless of call volume, which matters whether you're running high concurrent call volumes on the Scale plan or operating at concurrency sized to your volume on Enterprise.

How SAQ Types Are Assigned#

SAQ type is determined by your payment channels, not your transaction volume. Card-not-present e-commerce, face-to-face terminals, telephony, and IVR environments each map to different SAQ variants. The critical detail: telephony and IVR channels do not qualify for SAQ A, which is reserved for fully outsourced card-not-present e-commerce with no electronic cardholder data storage. If your payment flow touches a phone call, including AI-handled inbound or outbound calls, that distinction forces a materially different answer than most compliance teams expect.

SAQ A vs. SAQ B vs. SAQ D for Voice and IVR#

The three SAQ variants most relevant to voice and IVR environments differ significantly in scope and applicability. SAQ A applies when card processing is entirely outsourced and your systems never touch cardholder data. SAQ B applies to merchants using imprint machines or standalone dial-out terminals with no electronic cardholder data storage. SAQ D is the broadest variant and applies to any merchant whose environment does not fit a more specific SAQ type, including most telephony and IVR deployments that handle card numbers over the phone.

Different PCI DSS Self-Assessment Questionnaire (SAQ) types apply depending on how your organisation handles cardholder data:

• SAQ A – Applies when card processing is fully outsourced and your systems never handle cardholder data. It is not suitable for voice or IVR environments, as it is intended for fully outsourced card-not-present e-commerce.
• SAQ B – Designed for businesses using imprint machines or standalone dial-out terminals that do not electronically store cardholder data. It does not apply to IP-connected or software-based telephony systems.
• SAQ D – Used when an environment does not qualify for a more specific SAQ category. It covers the broadest range of PCI DSS security and compliance requirements.

Yes, applies to most telephony and IVR deployments that handle card numbers over the phone

If your voice AI platform receives spoken card numbers, SAQ D is almost certainly your required form, and the controls it demands are materially more extensive than SAQ A or B. For organizations operating AI phone calling at scale, whether through Bland.ai's native platform or via Amazon Connect integration for teams already managing inbound and outbound call flows there, the SAQ D control surface is the correct planning assumption. Bland.ai's Enterprise plan is specifically structured for this environment: dedicated infrastructure, on-prem or VPC deployment options, data residency controls, BAA availability, SSO, JWT signatures, and compliance documentation available under NDA mean that the vendor's posture can be documented and presented to a QSA as part of your scoping package, rather than surfaced as an unscoped finding mid-assessment.

Key takeaway: The single most effective way to contain audit cost is to define scope before the assessment begins, not during it.

The Hidden PCI Audit Risk in 2026 — How Voice AI Quietly Expands Your Cardholder Data Environment#

Routing claim intake calls through a cloud-hosted voice AI platform feels like an operational decision, not a compliance one. The common assumption is that if we have the right documentation and pass the SAQ, we've done PCI DSS compliance correctly, and that assumption is exactly what turns a routine QSA interview into a 90-day remediation crisis. Under PCI DSS 4.0, scope is determined by data flow, not intent, and the moment a caller reads a card number into an AI-handled line, that vendor's infrastructure is part of your cardholder data environment whether your compliance team documented it or not.

Why Routing Claim Intake Calls Through a Cloud AI Vendor Automatically Triggers CDE Expansion#

PCI DSS v4.0 expanded the CDE definition to include any system component that can affect the security of cardholder data. According to Clearly Payments' 2025 compliance analysis, this explicitly pulls third-party cloud vendors that touch, transmit, or process payment-related data into scope automatically. A cloud-hosted voice AI platform that receives call audio, transcribes it, and routes it through a shared LLM layer is processing cardholder data by definition.

Your QSA will reach that conclusion in the first hour of interviews, regardless of whether your vendor relationship was intentional or incidental. The practical consequence is scope expansion mid-audit. An insurance enterprise using a cloud-hosted voice AI for claim intake co-pay collection discovers during QSA interviews that the vendor has no data residency documentation and no BAA-equivalent.

The result is a formal finding, a remediation window, and a delayed certification. The deeper structural problem is one that enterprises we work with encounter repeatedly: a dependence on third parties for data privacy and control that was never explicitly chosen; it was inherited the moment a general-purpose cloud AI vendor was onboarded without compliance vetting. This is where the architecture of the platform matters.

Bland.ai's Enterprise tier is built around dedicated infrastructure, not a shared multi-tenant environment, with compliance documentation available under NDA and data residency controls that give your QSA a concrete, auditable answer to the scope question. Bland.ai integrates directly into existing inbound and outbound call flows, meaning you can add compliant AI voice handling without migrating your telephony stack and without expanding your CDE to an unvalidated third-party cloud layer.

The Documentation Gap That Blindsides Compliance Teams at Audit TimePCI DSS Requirement 12.8 places explicit responsibility on organizations to document and validate every third-party service provider that handles cardholder data, requiring written agreements and evidence that each provider meets applicable requirements. As Clearly Payments notes, generic cloud AI voice platforms are rarely equipped to satisfy that burden on audit timelines. What most teams report is that general-purpose cloud AI vendors cannot produce an Attestation of Compliance, infrastructure architecture diagrams, or data residency proof within the timeframes a QSA demands.

The compliance team typically discovers this gap during evidence collection, two weeks before the formal assessment. The vendor's security team responds with a shared-responsibility matrix that doesn't address telephony data flows, and the QSA has no choice but to flag the vendor as an unvalidated CDE component. What compliance teams need at that moment is a vendor that connects voice interactions directly into back-end systems — work order platforms, CRMs, intake databases — so that every call translates into logged, auditable, actionable data with zero manual entry and a clear chain of custody.

That is not a feature gap that can be patched with a shared-responsibility matrix; it requires the platform to be built that way from the ground up. Bland.ai's Enterprise integrations platform does exactly that, and because the Forward Deployed Engineering team scopes, builds, and goes live within a defined deployment framework, including gray/red/green-team testing, the documentation your QSA needs is produced as a byproduct of the implementation process, not assembled retroactively under audit pressure. On-prem and VPC deployment options further eliminate the shared-infrastructure exposure that triggers CDE expansion in the first place.

PCI Audit Failure Rates and $4.4M Breach Costs in 2025#

Broader industry trends on PCI DSS violations and Clearly Payments' 2025 compliance analysis make clear that a significant share of businesses fail a compliance audit in any given cycle, and the average total cost of a data breach reached $4.4 million in 2024–2025 according to figures consistent across the market. For an enterprise already operating outside full PCI DSS compliance when a breach occurs, those two figures compound: remediation costs, forensic investigation fees, and breach-related losses run concurrently rather than sequentially. The compounding effect is not abstract for voice AI deployments.

When call audio and transcription data flow through an unvalidated vendor environment, the forensic investigation must reconstruct data flows across infrastructure you do not control, on timelines the vendor is not contractually obligated to meet. Bland.ai's Enterprise tier includes alarm and monitoring, a dedicated orchestration server, a priority call queue, and a Slack channel with the Bland team, meaning that if an incident occurs, your response team has direct access to the people and systems that can answer a QSA's forensic questions in hours, not weeks. A 99.9% uptime SLA and BAA availability ensure that the vendor relationship itself is documented to the standard the assessment requires.

The choice of voice AI vendor is, in this regulatory environment, a compliance decision. The platform's infrastructure model, documentation availability, and deployment architecture determine whether your next QSA interview is a one-hour confirmation or a 90-day remediation project.

How to Prepare for a PCI DSS Audit — Step-by-Step Actions Before Your 2026 Assessment#

Auditors evaluating your 2026 assessment will not grade you on how polished your policy binder looks. They will trace every system that touches cardholder data, follow each connection outward, and ask for evidence that your controls actually worked over time, not just on the day you submitted paperwork. Scoping errors are among the most common PCI DSS compliance failures, and organizations that compress preparation into the final weeks consistently surface gaps that no last-minute documentation sprint can close. The steps below are the preparation sequence that separates a defensible audit from a reactive one.

1. Define and Document Your Cardholder Data Environment Scope Before Anything Else#

Before your 2026 PCI DSS compliance audit, precisely mapping every system, network segment, and third-party connection that touches cardholder data is non-negotiable. Organizations that skip formal scoping exercises routinely discover mid-audit that their CDE is far larger than assumed, triggering costly remediation delays. The tradeoff: thorough scoping demands cross-functional time from IT, legal, and finance teams simultaneously.

2. Implement Network Segmentation to Shrink Your Audit Attack Surface#

Effective network segmentation isolates cardholder data systems from out-of-scope infrastructure, directly reducing the number of controls your QSA must validate during the PCI DSS compliance audit. This is the single highest-leverage technical action before a 2026 assessment. The real limitation is that poorly documented segmentation, even if technically sound, will still fail auditor scrutiny without supporting network diagrams and firewall rule evidence.

3. Conduct a Pre-Audit Gap Analysis Against All 12 PCI DSS v4.0 Requirements#

Running an internal or third-party gap analysis against every PCI DSS v4.0 requirement six to twelve months before your assessment gives security teams a prioritized remediation roadmap rather than a last-minute scramble. This step is especially critical for organizations upgrading from v3.2.1, where new customized approach requirements introduce unfamiliar documentation burdens. The tradeoff is cost: a credible gap analysis from an experienced QSA firm is not inexpensive.

4. Build and Maintain a Complete Hardware and Software Asset Inventory for Requirement 2.4#

PCI DSS Requirement 2.4 mandates a current, accurate inventory of all in-scope system components. Auditors routinely cite missing or stale asset inventories as a primary finding during PCI DSS compliance audits. Organizations should automate discovery tooling to continuously reconcile physical hardware, virtual machines, and cloud instances against their documented inventory. The limitation: automated tools often surface shadow IT assets that then require urgent classification decisions under audit pressure.

5. Establish Evidence Collection Workflows and Policy Documentation Libraries Early#

QSAs require evidence across hundreds of test procedures, log samples, configuration screenshots, policy documents, training records, and vulnerability scan reports. Organizations that build structured evidence repositories and assign clear ownership per requirement months before the PCI DSS compliance audit dramatically reduce auditor back-and-forth cycles. The tradeoff is ongoing maintenance discipline: evidence libraries become liabilities if they contain outdated or contradictory documentation at audit time.

6. Integrate AI-Assisted Continuous Monitoring to Satisfy New PCI DSS v4.0 Automated Controls#

PCI DSS v4.0 introduces stronger expectations around continuous monitoring, anomaly detection, and automated log review that manual processes struggle to satisfy at scale. Deploying AI-assisted SIEM and behavioral analytics tools before your 2026 assessment positions your organization to demonstrate real-time control effectiveness rather than point-in-time snapshots. The key limitation: AI tooling generates alert volumes that require skilled analyst triage, and false-positive fatigue can undermine the very controls auditors are evaluating.

What Happens If You Fail a PCI DSS Audit — and Why Voice AI Gaps Are the Fastest Path There#

Failing a PCI DSS audit feels manageable until you see the actual penalty schedule. The common assumption is that if we have the right documentation and pass the SAQ, we've done PCI DSS compliance correctly. Most compliance teams picture a remediation checklist and a 30-day window to clean things up. The reality is a monthly fine structure that keeps running until every finding is closed, and for healthcare platforms in particular, the audit surface area is already larger than most teams realize. Recurring billing modules, patient portals, third-party billing vendors, and custom payment APIs each pull additional systems into PCI scope, creating failure risk that compounds long before a QSA ever walks in the door.

Monthly Non-Compliance Fines: $5K–$100K From First Finding#

Non-compliance fines range from $5,000 to $100,000 per month, levied by card brands against acquiring banks, which pass those costs directly to the non-compliant merchant. There is no grace period built into that structure. The moment a QSA documents a finding, the meter starts. Remediation timelines for scope gaps can run for many months, which means even a single missed system — a legacy billing API, an undocumented patient portal integration — can generate substantial ongoing fines before re-certification is complete.

Beyond Fines — Increased Transaction Fees, Mandatory Forensic Audits, and Processing Suspension#

The fines are only the first layer. Beyond the monthly fine structure, non-compliance triggers a compounding set of consequences:

• Acquiring banks routinely add elevated per-transaction fees to non-compliant merchants, compounding the cost with every sale processed during remediation.
• If a breach occurs during the non-compliant period, a mandatory forensic investigation by a PCI Forensic Investigator (PFI) becomes a contractual requirement, carrying its own five- and six-figure price tags.
• At the far end of the escalation path, the acquirer can suspend card processing privileges entirely (Sprinto, 2024).

Key takeaway: A breach during an already-running remediation stacks a seven-figure incident cost on top of ongoing monthly fines, a compounding exposure that no compliance budget plans for and few organizations recover from without material operational disruption.

One practical but underappreciated scope-reduction lever is the voice channel. Every inbound call that touches payment card data — an agent reading back a card number, a caller providing billing details — is a system that must be documented, controlled, and audited. The Enterprise plan is built with exactly this kind of regulated environment in mind: it ships with dedicated infrastructure, compliance documentation available under NDA, data residency controls, BAA availability, on-prem/VPC deployment options, and JWT signature support.

It integrates directly into existing call flows, so AI voice agents can handle or deflect repetitive payment-adjacent inquiries without requiring a platform migration, reducing the number of human-agent touchpoints that need to appear on a PCI scope diagram. The forward-deployed engineering team scopes, builds, and goes live within a defined deployment framework, so the compliance documentation your QSA needs reflects a real, tested architecture rather than a future-state promise.

How Self-Hosted Voice AI Reduces PCI DSS Audit Scope Instead of Expanding It#

Most voice AI deployments expand PCI DSS audit scope before a single call is made, because the vendor architecture decision is also a scoping decision. Understanding how deployment model affects your CDE boundary, what self-hosted infrastructure actually changes for your QSA, and what documentation you should require before signing any voice AI contract gives compliance and procurement teams the clarity they need to evaluate platforms like Bland.ai on terms that matter to auditors, not just engineers.

Why Vendor Architecture Is a PCI Scoping Decision, Not an IT Detail#

The moment a third-party voice AI platform routes call audio through its own cloud, it becomes a node in your Cardholder Data Environment. According to industry research, third-party vendors that process, transmit, or store cardholder data automatically extend an organization's PCI DSS audit scope, and each new vendor connection must be separately documented, assessed, and included in the CDE boundary. That is not an IT configuration issue. It is a scoping decision with audit consequences, and it is made the day you sign the contract, not the day your QSA arrives.

Self-Hosted Deployment Keeps the AI Inside Your Existing CDE#

Self-hosted voice AI architecture converts a third-party vendor relationship into an internal system component. When the AI infrastructure runs inside your own VPC or on-premises environment, call audio never leaves your existing network boundary. The QSA assesses one CDE, not two. Your existing controls already cover the system, and the evidence collection process stays within your documented environment. That structural simplicity is most valuable when your organization already operates a contact center or CRM and wants to add AI calling without creating a new compliance perimeter to defend.

The Documentation Standard Enterprises Should Demand Before Signing Any Voice AI Contract#

PCI DSS requires organizations to maintain documented shared-responsibility matrices for every third-party service provider that touches cardholder data, including architecture diagrams, data residency attestation, and written compliance posture. Industry practitioners and compliance consultants consistently report that general-purpose voice platforms are rarely provisioned with audit-ready compliance packages, architecture diagrams, data residency attestation, and a BAA, and that obtaining them mid-audit cycle frequently extends assessment timelines. The practical standard before signing any voice AI contract: infrastructure diagrams, data residency proof, and a BAA, all available under NDA before deployment begins.

Next steps#

If your compliance team has assembled thorough documentation and still gets blindsided when a QSA traces a claim intake call through an unscoped cloud vendor, the path forward starts with treating voice architecture as a scoping decision, not an IT detail. Start with our voice AI.

Merchant level determines how your compliance is validated, not whether your cardholder data environment is fully scoped, which means a Level 3 or Level 4 merchant can be simultaneously compliant on paper and operating an undocumented attack surface carrying the same forensic liability as a Level 1 failure. Self-hosted voice AI architecture converts an uncontrollable third-party vendor relationship into an internal system component subject to your own documented controls, eliminating the TPSP validation burden entirely. Together, those two realities point to one practical action: evaluate your voice AI vendor against the same scoping criteria your QSA will apply before the assessment window opens.

Start with voice AI built for exactly this regulatory environment. Bland's Enterprise plan runs on dedicated infrastructure with compliance documentation available under NDA, a BAA, data residency controls, and on-prem or VPC deployment options that keep call audio inside your existing network boundary. The forward-deployed engineering team scopes, builds, and goes live within a defined framework, so the artifacts your QSA requests during evidence review reflect a tested architecture rather than a future-state promise.

Frequently Asked Questions#

Who actually needs to go through a full PCI DSS audit with a QSA, versus just filling out an SAQ?#

Any merchant processing more than 6 million transactions annually (Level 1) is required to undergo a formal on-site assessment conducted by a Qualified Security Assessor, with the output being a Report on Compliance. Merchants below that threshold validate compliance through a Self-Assessment Questionnaire and Attestation of Compliance instead, though picking the wrong SAQ type can itself trigger a mandatory QSA engagement mid-assessment.

Who actually performs a PCI DSS audit?#

A Qualified Security Assessor (QSA) performs the audit. QSAs conduct on-site visits, staff interviews, and technical evidence review across every in-scope system, then issue a formal Report on Compliance. The PCI Security Standards Council certifies QSAs through its own training and qualification program.

How much does a PCI DSS audit cost?#

RoC assessments run between $15,000 and $200,000+ depending on the complexity of your cardholder data environment. That range is driven primarily by scope: every third-party vendor discovered mid-assessment that wasn't pre-scoped extends both the engagement and the invoice.

Do I still have PCI DSS obligations if I route payments through a third-party processor?#

Yes. Routing payments through a third-party processor reduces your scope but does not eliminate your compliance obligations. The same logic applies to any third-party vendor relationship, including voice AI platforms handling payment intake calls, where the vendor's infrastructure still falls within your PCI DSS responsibilities.

Are call recordings a PCI DSS problem even if the audio is stored on a secure server?#

Yes. Requirement 3 prohibits storing sensitive authentication data after authorization, and that includes spoken card numbers captured in call recordings. Encryption, masking, tokenization, or hashing are all acceptable controls, but they must be applied before the recording is written to storage, not retroactively, making unredacted audio files one of the most widespread Requirement 3 violations in enterprise contact center environments.