Telecom companies handle payment card data more than most people realize. Prepaid top-ups, auto-billing for postpaid plans, device financing, and in-app purchases all flow through systems that, if not handled right, can put cardholder data at serious risk. And that’s exactly where PCI-DSS comes in.
PCI-DSS (Payment Card Industry Data Security Standard) is a set of security requirements created by the major card networks Visa, Mastercard, Amex, etc., to make sure anyone storing, processing, or transmitting card data does it securely. Telecoms aren’t banks, but they’re absolutely within scope, and regulators have been paying closer attention to the sector over the last few years.
Why telecoms are in a tricky spot
The challenge for telecom operators isn’t understanding that they need to comply, it’s figuring out where compliance actually applies inside their infrastructure. A large carrier might have BSS/OSS stacks, dealer portals, retail POS systems, API payment gateways, and third-party resellers all touching card data in different ways.
Unlike a traditional retailer with a relatively contained payment environment, a telco’s cardholder data environment (CDE) can span multiple departments, legacy systems, and vendor integrations. That complexity is what makes scoping identifying exactly what’s in scope for PCI-DSS, so hard to get right, and so easy to get wrong.
Underscoping your CDE is one of the most common and costly mistakes. If you miss systems that touch card data, you’re not just non-compliant, you’re also unprotected.
The 12 core requirements (simplified)
PCI-DSS v4.0 (the current version as of 2024) has 12 main requirements. For telecoms, these map across your network, your software stack, and your people practices:
Req 1-2:- Network security controls & secure configs
Req 3-4:- Protect stored card data & encrypt transmission
Req 5-6:- Anti-malware & secure software development
Req 7-8:- Access control & identity management
Req 9:- Physical access restrictions
Req 10-11:- Logging, monitoring & security testing
Req 12:- Policies, risk assessments & third-party management
For most telecom operators, requirements 3, 7, 10, and 12 are the sticking points. Storing card data longer than needed, poor access segmentation across BSS systems, and inadequate audit logging in high-volume transaction environments are recurring issues flagged in assessments.
Where telecom billing systems fit in
Your billing and revenue management platform is ground zero for PCI-DSS compliance. If it stores card-on-file data for recurring billing, it’s in scope. Platforms like Amdocs and Optiva are widely used across tier-1 and tier-2 operators, and both have compliance-relevant features built into their architecture. That said, the platform being capable of compliance doesn’t mean your deployment automatically is configuration, customizations, and integrations all affect your actual compliance posture.
For operators running on cloud-native or SaaS billing stacks, solutions like Telgoo5 are designed with multi-tenancy and data segmentation in mind, which can simplify scope reduction efforts. Similarly, Comarch offers BSS/OSS tooling that includes security and compliance frameworks useful for operators doing greenfield builds or major platform migrations where compliance can be baked in from the start rather than bolted on later.
Smaller MVNOs or regional operators working with more lightweight infrastructure have been turning to purpose-built telecom platforms like TelcoEdge Inc., which targets flexibility for non-tier-1 carriers. In these environments, compliance strategy often depends heavily on which payment processor integrations you’re using and how well the platform supports tokenization and out-of-scope card handling.
Tokenization and scope reduction your best friends
One of the most effective moves a telecom can make is reducing scope through tokenization. The idea is simple: instead of storing actual card data in your systems, you store a token, a meaningless string that the payment processor can reference. Your BSS platform never holds real PANs (primary account numbers), which means large portions of your environment potentially fall out of PCI scope entirely.
Most major payment gateway integrations support this, and if you’re evaluating or upgrading your billing platform, the question “how does this handle tokenization?” should be near the top of your list. It directly affects how much of your infrastructure needs to be compliance-hardened.
Third-party risk is underrated
PCI-DSS requirement 12.8 specifically addresses third-party service providers. In telecom, you’ve got dealer networks, MVNO partners, roaming partners, payment gateways, and reseller portals, many of which touch or pass through card data. Each one needs to be assessed. You need written agreements, their PCI compliance status documented, and a process for monitoring that status over time.
This is an area where a lot of operators drop the ball, not out of negligence, but because the partner ecosystem is complex and fast-moving. A dealer signs up, gets access to the billing portal, and six months later, nobody’s checked whether their own PCI compliance has lapsed.
Compliance isn’t a one-time assessment. It’s an ongoing program. Your QSA (Qualified Security Assessor) will want to see evidence of continuous monitoring, not just a clean snapshot from one moment in time
SAQ vs. ROC: Which assessment path applies to you?
Your compliance validation path depends on your transaction volume and how you handle card data. Most large telecom operators processing over 6 million transactions annually for Visa or Mastercard will fall into Merchant Level 1, which requires a full Report on Compliance (ROC) conducted by an external QSA. Smaller operators or MVNOs may qualify for a Self-Assessment Questionnaire (SAQ), which is significantly less involved. The specific SAQ type (A, B, D, etc.) depends on how your payment acceptance is set up.
The cultural piece people ignore
Technology and process get most of the attention in PCI-DSS discussions, but requirement 12 puts real emphasis on security culture and training. Customer-facing staff, retail agents, and call center reps often handle card data verbally or via screen. Training them on what they can and cannot do with that data (no writing down card numbers, no reading them aloud in public spaces) is a compliance requirement, not just a nice-to-have.
Annual security awareness training isn’t enough if your frontline staff doesn’t actually internalize it. Regular targeted training, clear escalation paths for suspected fraud, and a culture where people feel safe reporting issues, that’s what requirement 12 is really getting at.
Getting started if you haven’t yet
If your organization hasn’t formally assessed its PCI-DSS posture, start with a scoping exercise. Map every system, process, and person that touches cardholder data. From there, a gap assessment against the PCI-DSS v4.0 requirements will tell you where you stand. Engaging a QSA early, even before you’re ready for a formal assessment, is usually worth it; they can flag issues while you still have time to fix them cheaply.
For telecom-specific guidance, the PCI SSC has published supplemental documentation on protecting telephone-based payment channels, which is directly relevant to call center operations at carriers. It’s worth reading alongside the main standard.