PCI DSS for BPOs: Scope, Levels, and What Auditors Actually Look At
Most BPOs that take payment data on behalf of a client are classified as Service Providers under PCI DSS, not Merchants. The thresholds are tighter, the audit is heavier, and the scope-reduction levers are different. A 2026 operator read of v4.0.1.
Sami Akhtar
Security & Compliance Advisor, FrontLine · Published May 21, 2026
A new client signs with the BPO (Business Process Outsourcing: a firm that runs contact-centre operations on behalf of other brands.). Financial services, mid-market, will route about 1,200 customer-service calls a day through the contact centre. Around 15% of those calls touch payment data: card-not-present updates, refund verifications, occasional new-purchase upsells handled mid-call. Until that contract, the BPO had never been in PCI scope. Six weeks later, the COO is reading a 47-page Self-Assessment Questionnaire and trying to figure out whether the call-recording platform he's been running for years is now a compliance problem.
This is the moment most BPOs cross into the PCI world. It usually happens with one client, often without much warning, and the answer to "are we PCI compliant" turns out to be more complicated than expected. The standard itself is reasonable. The classification rules and the scope question are where operators get caught.
What PCI DSS is, and which version applies
PCI DSS is the Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council (a consortium of Visa, Mastercard, American Express, Discover, and JCB). It is not a government regulation. It is a contractual standard enforced by the card brands through acquiring banks, applied to any organisation that stores, processes, or transmits cardholder data.
The current version is PCI DSS v4.0.1 , released in June 2024 as a clarifying revision of v4.0. The earlier v3.2.1 retired on March 31, 2024, and v4.0 retired on December 31, 2024. If your QSA is still referencing v3.2.1 controls in 2026, that's a flag.
The 51 "future-dated" requirements added in v4.0 became mandatory on March 31, 2025 . Anything assessed after that date has to meet the full v4.0.1 control set, including the new requirements around targeted risk analysis, customised approach controls, and several specific items on multi-factor authentication, malware on non-CDE systems, and authenticated internal vulnerability scans.
Merchant vs. Service Provider, and why BPOs are usually the second
PCI uses two main categories. A Merchant accepts payment cards as payment for its own goods and services. A Service Provider stores, processes, or transmits cardholder data on behalf of another entity. The PCI SSC glossary is the authoritative definition.
A BPO taking customer-service calls that touch payment data on behalf of a client is a Service Provider. The client is the Merchant. This distinction matters because the Service Provider levels are set at different transaction thresholds and the compliance expectations are heavier at every tier.
Service Provider Level 1. More than 300,000 combined Visa or Mastercard transactions per year processed on behalf of clients. Requires an annual Report on Compliance (ROC) produced by a Qualified Security Assessor , plus quarterly external vulnerability scans by an Approved Scanning Vendor .
Service Provider Level 2. Fewer than 300,000 transactions per year. Can submit SAQ-D for Service Providers , the only Self-Assessment Questionnaire available to Service Providers. The shorter SAQs (A, B, C) that some Merchants can use are not available at the Service Provider tier.
Two consequences operators miss. First, the 300,000 threshold is far lower than the Merchant Level 1 threshold (6 million Visa/Mastercard transactions for Merchants). A mid-sized BPO handling payment-touching calls for two or three clients can cross the threshold without realising it. Second, many enterprise clients contractually require a ROC regardless of card-brand level. "We're Level 2 so we just self-assess" is not always an option if a client's procurement team has written ROC-level attestation into the MSA.
Scope reduction is the actual lever
The number of PCI controls that apply to a BPO scales with the size and complexity of the cardholder data environment (CDE), the systems and processes that handle cardholder data. A BPO that lets agents see, type, or store card numbers is fully in scope on every workstation that touches a call. A BPO that routes payment portions of calls to a PCI-compliant payment processor (so agents never see or hear the digits) can dramatically reduce its scope.
The PCI SSC has published two information supplements that lay out what scope reduction actually looks like. The Scoping and Network Segmentation supplement covers network-level isolation. The Protecting Telephone-Based Payment Card Data supplement covers the contact-centre-specific patterns.
Three scope-reduction techniques are recognised and used widely in BPOs:
Tokenization at intake. When the agent collects payment information, it goes directly through a third-party payment gateway that returns a token. The token has no value if breached. The PAN never lands in the BPO's systems.
DTMF masking. When the customer needs to enter their card number, the system suppresses the DTMF tones from the call recording and routes them directly to a payment processor. The agent stays on the line for service but the digits never enter the BPO's CDE. The PCI SSC supplement on telephone payments explicitly identifies DTMF masking as the preferred modern approach, replacing legacy pause-and-resume on recordings (which is still recognised but called out as inferior).
Iframe / redirect to payment portal. For web-based interactions, the payment form is embedded from a PCI-compliant payment processor's domain. The BPO's web infrastructure never touches the card data.
The scope-reduction question every BPO should answer first is the cheapest control by an order of magnitude. A 300-agent contact centre that handles payment calls through DTMF masking and a tokenised gateway might run a Level 2 SAQ-D assessment with a few hundred applicable controls. The same operation taking the same calls without scope reduction might run a Level 1 ROC against the full standard. The difference is two engineers' work upfront and roughly a hundred thousand dollars a year in compliance overhead.
What auditors actually look at
The full v4.0.1 standard runs to 360 pages with around 250 requirements. The audit doesn't fail or pass on the standard in the abstract; it fails or passes on specific controls. For BPO contact centres, six areas account for most of the findings I've watched assessors land on.
Cardholder data discovery. The auditor runs (or asks you to run) a scan of every system that might contain PAN data: CRM notes fields, ticketing systems, call-recording archives, screen-recording capture, agent training material with anonymised-but-actually-real card numbers. Almost every BPO finds PAN data somewhere it shouldn't be on the first scan.
Network segmentation. If the BPO claims scope-reduced CDE, the auditor will test the segmentation. Can a non-CDE workstation reach a CDE system at the network layer? If yes, the segmentation isn't real and everything connected becomes in scope.
Access control. Who can access the CDE, with what credentials, and how do you prove that termination, role-change, and unused-account cleanup actually happen? Access reviews not consistently performed is a near-universal early finding.
Change management. Every change to the CDE, code deployments, firewall rules, server patches, needs a documented ticket trail. Verbal changes don't count.
Logging and monitoring. v4.0 added stricter requirements on log integrity, retention (one year minimum, with three months immediately available), and alerting. Many BPOs have logging but discover during their first audit that the retention or alerting isn't where it needs to be.
Incident response. A written, tested incident response plan with named roles, escalation paths, and forensic-handoff procedure. "We have a plan" is necessary but not sufficient, the auditor will ask when it was last tested.
Enforcement and the cost of getting it wrong
PCI DSS isn't enforced by a government regulator. It's enforced contractually, through the acquiring banks, who are themselves accountable to the card brands. Penalties for non-compliance are paid by the acquiring bank to the card brand and then passed through (often with markup) to the offending Merchant or Service Provider.
The industry-reported penalty range for non-compliance runs from $5,000 to $100,000 per month, escalating with the duration of non-compliance and the volume of data exposed. The PCI SSC itself does not publish the schedule. Penalty schedules are issued privately by card brands to acquirers, and a BPO finds out the specifics only when they're the entity owing the money. The $5K–$100K range is a useful planning number, not a published rate card.
A breach with confirmed CDE exposure triggers a separate process: the PCI Forensic Investigator (PFI) programme . When a card brand or acquirer suspects a compromise at a Service Provider, they can mandate engagement of a PFI from the SSC-certified list (about twenty firms globally). The PFI must be independent of the entity's existing QSA. Their output is a Preliminary Incident Response Report within roughly five business days and a Final Forensic Report to the card brands. The cost of a PFI engagement runs into the high six figures, and that's the cost of the investigation alone, separate from any fines, separate from any client-driven contract termination, separate from any consumer-side class action.
The cost of compliance, for context. Auditor fees for a first-year Level 1 ROC engagement at a small-to-mid BPO typically run $30,000–$200,000 just for the QSA assessment itself. Total program cost (remediation, tooling, internal staff time, ASV scans, training, ongoing maintenance) is usually several multiples of that in year one. Year two onward is lighter but still substantial. PCI SSC does not publish official cost benchmarks; the figures above are industry-reported ranges from QSA firms.
The operator's checklist
If you're a BPO that's just taken on a client whose contract drops you into PCI scope, the sequence below is the one that's worked.
Find out what level you actually are. Combined Visa and Mastercard transaction count per year, across all clients you process for, not just the new one. If you're over 300,000, you're Level 1. If under, you're Level 2 but check your client MSAs for ROC requirements that override.
Do a CDE scoping exercise before anything else. What systems, processes, and people touch cardholder data today? The honest answer is usually broader than the initial guess. Reducing scope before assessment is dramatically cheaper than expanding controls after.
Implement DTMF masking and tokenization if you haven't. These two controls alone often shift a BPO from "every workstation is in scope" to "only the payment gateway integration point is in scope." The engineering work is bounded; the compliance savings are recurring.
Pick a QSA who understands BPOs. The big assurance firms (the QSA arms of Big Four firms, plus the specialist QSA firms on the PCI SSC's published QSA list ) have very different track records on contact-centre engagements. A QSA who's never worked in a BPO will spend most of the engagement learning your business; one who has done five BPOs will land on the right controls faster and cheaper.
Treat the readiness assessment as the real work. The actual ROC engagement is the certification of work already done. The readiness assessment, the gap remediation, and the build of evidence packages is where compliance is built. A QSA who's worth what you're paying them will tell you what's missing in month one rather than letting you discover it in month nine.
Sources
PCI DSS is the Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council. Authoritative references below. Where a figure (penalty range, audit cost) cannot be sourced to PCI SSC directly, the article labels it as industry-reported.
The standard. PCI DSS v4.0.1, official document library . PCI SSC's document library page; v4.0.1 PDF is publicly downloadable without registration.
Version transitions. PCI DSS v4.0.1 release announcement (June 2024) and future-dated requirements deadline (March 31, 2025) . PCI SSC's own blog announcements.
Service Provider definition. PCI SSC Glossary . The authoritative definition of Service Provider and related terms.
Scope reduction guidance. PCI SSC Scoping and Network Segmentation supplement and PCI SSC Protecting Telephone-Based Payment Card Data supplement . Both are PCI SSC Information Supplements covering scoping practice and the contact-centre-specific patterns (DTMF masking, pause-and-resume).
Self-Assessment Questionnaire for Service Providers. SAQ-D for Service Providers, official PDF . The only SAQ available to Service Providers under v4.0.
Assessor and scanner lists. Qualified Security Assessors (QSA) , Approved Scanning Vendors (ASV) , PCI Forensic Investigators (PFI) . PCI SSC's published lists of certified firms.
Penalty schedule. PCI SSC does not publish the per-month penalty schedule; card brand penalty rates flow to acquirers privately and are passed through to the offending entity. The $5,000–$100,000 per month range cited in this article reflects industry-reported figures from QSA firms and security publications, not a PCI SSC-published rate card.
Cost benchmarks. PCI SSC does not publish QSA fee benchmarks. The $30,000–$200,000 range cited for first-year Level 1 ROC engagements reflects QSA firm price guidance from public sources and engagements I've observed. Treat as directional, not authoritative.
This article is not legal advice and not a substitute for a QSA engagement. Specific applicability to your operation requires assessment by a Qualified Security Assessor. The article is the operator's read from someone who's helped BPOs stand up scope-reduced payment flows. It's a starting point, not a substitute for the assessment itself.
Sami Akhtar
Security & Compliance Advisor, FrontLine
Security and compliance specialist with deep experience helping BPOs navigate PCI DSS, SOC 2, and cross-border privacy regimes. Writes the FrontLine compliance series.