Minimizing PCI DSS Scope for SoftPOS and Tap-to-Pay Systems

SoftPOS and Tap-to-Pay solutions are changing how merchants accept contactless card payments across Europe. Instead of relying on dedicated payment terminals, these models can use smartphones or tablets with NFC capabilities to accept payments. This creates a different payment architecture, with security responsibilities distributed across mobile applications, device controls, backend platforms, payment processors, APIs, cloud infrastructure, and third-party services.

For organizations operating these environments, PCI DSS scoping is an important consideration. The objective is not to exclude systems from PCI DSS simply to reduce assessment effort. The objective is to accurately identify the systems, applications, networks, people, and processes that store, process, transmit, or can affect the security of payment account data, while using appropriate isolation and data protection mechanisms to prevent unnecessary scope expansion.

PCI SSC states that PCI DSS applies to entities that store, process, or transmit cardholder data or sensitive authentication data, as well as entities that could impact the security of the cardholder data environment. For SoftPOS providers and payment service providers, this makes architecture and data-flow decisions particularly important.

Strengthen cardholder data security with a PCI DSS v4.0.1 assessment from INTERCERT. Contact us today.

What PCI Scoping Means for SoftPOS and Tap-to-Pay

PCI DSS scoping determines which components of a payment environment fall within the assessment boundary. In a SoftPOS or Tap-to-Pay architecture, this can include the mobile payment application, backend services, APIs, payment processing infrastructure, security monitoring systems, administrative interfaces, and other connected components depending on how the solution handles payment account data.

The scope cannot be determined simply by whether a payment application runs on a smartphone. It depends on the actual transaction architecture, data flows, security controls, and relationships between system components. PCI SSC identifies merchants, processors, acquirers, issuers, and service providers among the entities that can fall within PCI DSS applicability.

SoftPOS PCI DSS Assessment

A SoftPOS PCI DSS assessment examines the parts of the environment that fall within the defined PCI DSS scope and evaluates the applicable controls against the relevant PCI DSS requirements. The assessment boundary depends on how the SoftPOS solution captures, processes, transmits, or otherwise interacts with payment account data.

SoftPOS should also be distinguished from PCI SSC's mobile-specific standards. PCI Mobile Payments on COTS, or MPoC, is designed for mobile payment acceptance solutions operating on commercial off-the-shelf devices and builds on the earlier SPoC and CPoC standards. A provider may therefore need to consider PCI DSS alongside applicable PCI mobile payment standards rather than treating them as interchangeable.

PCI DSS Assessment for Mobile Payments

PCI DSS assessment for mobile payments requires a clear understanding of the complete payment flow. A mobile application may communicate with backend APIs, tokenization services, payment gateways, acquirers, fraud systems, logging platforms, cloud services, and administrative systems.

Each connection should be evaluated based on the data exchanged and whether the connected component can affect the security of the cardholder data environment. A mobile payment architecture should therefore be assessed according to its actual technical design rather than its product label.

Why PCI Scope Matters for Mobile Core Infrastructures

A broad PCI DSS scope can increase the number of systems, applications, processes, personnel, and controls that need to be considered during an assessment. For a European payment technology provider operating across multiple merchants or markets, this can become more complex as transaction volumes, integrations, cloud services, and operational teams expand.

Accurate scoping creates a clearer assessment boundary while maintaining appropriate security controls. PCI SSC's scoping material emphasizes that incorrectly identifying where payment data is present or where systems can affect payment security can create security and compliance risks.

Impact on Audit Effort and Assessment Cost

The size and complexity of the PCI DSS environment can influence the amount of evidence, testing, system review, and assessor activity required. A payment platform with numerous interconnected systems can require more extensive assessment work than an architecture where payment-related components are appropriately isolated.

Scope reduction should not be treated as a way to avoid applicable PCI DSS requirements. Instead, organizations should establish technically defensible boundaries through measures such as segmentation, restricted connectivity, reduced payment data retention, and controlled interfaces.

Risks of an Oversized Cardholder Data Environment

An unnecessarily large cardholder data environment can increase the number of systems that must be protected and monitored. It can also create additional pathways through which a compromise of a connected system could affect payment security.

PCI SSC explains that systems connected to the cardholder data environment may become relevant to PCI DSS scope when adequate segmentation is not present. The effectiveness of segmentation must also be verified rather than assumed.

For SoftPOS providers, this is particularly relevant because the payment application may coexist with merchant applications, device-management platforms, APIs, analytics systems, and administrative services.

Understanding the SoftPOS and Tap-to-Pay Architecture

SoftPOS architectures vary considerably between providers. A typical environment can include the merchant's mobile device, a payment acceptance application, backend services, payment APIs, processing infrastructure, security monitoring, and connections to payment processors or acquirers.

PCI SSC's CPoC material describes a COTS device with an NFC interface, a payment acceptance application, and backend systems that provide functions such as monitoring, integrity checks, and payment processing.

The newer MPoC standard provides a broader framework for mobile payment acceptance on COTS devices and supports different payment acceptance and consumer verification scenarios.

Mobile Device and Application Layer

The mobile layer can include the smartphone or tablet, operating system, NFC functionality, payment acceptance application, SDKs, libraries, and device security mechanisms.

The exact PCI DSS scope depends on how the application handles payment account data and how it interacts with other components. Organizations should also distinguish between the merchant device used to accept payments and a consumer's personal device used solely to enter their own payment information. PCI SSC notes that different circumstances can produce different scope outcomes.

Backend and Core Payment Infrastructure

The backend may contain payment APIs, transaction services, authentication services, cryptographic services, monitoring platforms, databases, message queues, administrative applications, and interfaces with processors or acquirers.

Where these systems store, process, or transmit payment account data, they require consideration within the PCI DSS assessment boundary. Systems that can affect the security of the CDE may also be relevant even when they do not directly handle cardholder data.

Third-Party Services and Connected Systems

SoftPOS platforms frequently rely on external providers for cloud hosting, payment processing, tokenization, device management, analytics, identity services, fraud detection, or other functions.

Third-party involvement does not automatically remove a provider's PCI DSS responsibilities. The organization needs to understand which party performs each payment-related function, what data is exchanged, and which security responsibilities remain with each entity.

PCI SSC also states that service providers that can impact the security of payment account data may have PCI DSS scope even when they do not directly store, process, or transmit that data.

How to Identify Systems in PCI DSS Scope

The most reliable starting point for PCI scoping is the actual payment transaction flow. Organizations should document where payment account data enters the environment, which systems receive or process it, where it is transmitted, whether it is stored, and which systems can influence the security of those components.

The resulting scope should reflect the real architecture rather than an assumed boundary based on application ownership or infrastructure location.

Mapping Cardholder Data Flows

Cardholder data-flow mapping should follow the transaction from the point of payment acceptance through the relevant backend services and external payment entities.

For SoftPOS environments, the mapping can include NFC interaction, the mobile payment application, encrypted communications, APIs, payment servers, processors, acquirers, tokenization services, and transaction-management systems.

The mapping should also identify where sensitive authentication data is handled because its treatment is subject to specific PCI DSS requirements.

Classifying In-Scope, Connected and Out-of-Scope Systems

System classification should be based on the role each component plays in the payment environment. Components that store, process, or transmit cardholder data are directly relevant to the CDE. Other components may also fall within scope when they can affect the security of the CDE or provide a pathway into it.

A system should not be considered out of scope merely because it does not store cardholder data. PCI SSC explains that connected systems can remain relevant to scope when adequate segmentation is not established.

This distinction is especially important for cloud environments, shared infrastructure, administrative systems, monitoring platforms, and remote-access technologies.

Strategies to Minimize PCI Scope in SoftPOS and Tap-to-Pay Environments

PCI scope can often be reduced through architecture and data-handling decisions made during the design and operation of the payment environment. These decisions should be documented and technically validated because scope reduction depends on the effectiveness of the controls involved.

Network Segmentation of the Mobile Core

Network segmentation can separate payment-related infrastructure from systems that do not need access to the cardholder data environment.

PCI SSC states that effective network segmentation can reduce PCI DSS assessment scope when it properly isolates systems that store, process, or transmit cardholder data from systems that do not.

Segmentation may involve internal firewalls, access control lists, VLANs, security groups, routing restrictions, or other technologies. The specific architecture should reflect the organization's environment, and the effectiveness of the segmentation should be verified during the PCI DSS assessment.

Reducing Cardholder Data Storage and Transmission

Reducing unnecessary storage of cardholder data can simplify the environment and reduce the number of locations requiring protection.

SoftPOS providers should examine whether payment account data needs to enter each backend service or whether particular services can operate using tokens, transaction identifiers, or other data that does not expose the underlying account number.

Data minimization should not be confused with automatically removing a system from PCI DSS scope. The actual data flow and security relationships still determine scope.

Tokenization and Encryption in Payment Flows

Tokenization can replace payment account data with a token for particular business processes, while encryption protects data during transmission or storage. These technologies can reduce exposure, but they do not automatically make an entire environment out of scope.

The security architecture should clearly identify where payment account data is present, where cryptographic operations occur, who controls the relevant keys, and which systems can access the original data.

Isolating the Cardholder Data Environment

A clearly defined CDE can make PCI DSS boundaries easier to manage. Isolation should cover not only network connectivity but also administrative access, authentication pathways, remote access, system management, monitoring, and other mechanisms that could affect the CDE.

The objective is to establish a defensible separation between payment infrastructure and unrelated business systems without creating hidden pathways that could reconnect the environments.

PCI DSS Compliance for Payment Service Providers

Payment service providers can have complex PCI DSS environments because they may process transactions for multiple merchants while operating shared applications, cloud infrastructure, APIs, and administrative platforms.

PCI DSS scope for a service provider depends on the services provided and how those services interact with payment account data and customer environments. PCI SSC states that a service provider's scope can include people, processes, and technology involved in providing services that can impact payment account data security.

For European PSPs, accurate scoping becomes particularly important when a single platform serves merchants across different countries, currencies, acquirers, and payment channels.

PCI DSS Compliance for Tap-to-Pay Providers

Tap-to-Pay providers should assess the specific architecture behind their mobile acceptance service. The term Tap-to-Pay does not itself determine PCI DSS scope.

Depending on the architecture, the payment environment may involve the mobile application, device controls, backend payment services, APIs, cryptographic services, processors, acquirers, and third-party platforms.

The PCI SSC MPoC standard is particularly relevant to modern mobile payment acceptance scenarios because it provides a framework covering PIN and contactless payment acceptance on COTS devices.

PCI DSS Compliance for Fintech Companies

Fintech companies offering payment acceptance, acquiring technology, payment gateways, wallets, merchant platforms, or related services should define PCI DSS scope around their actual payment architecture.

As fintech platforms expand, additional integrations can introduce new connections to the CDE. A scope review should therefore consider new APIs, cloud services, applications, administrative interfaces, third-party providers, and payment channels whenever the architecture changes.

SoftPOS PCI DSS Audit: What Assessors Examine

A SoftPOS PCI DSS audit focuses on the defined assessment boundary and the applicable PCI DSS requirements. The assessor considers the organization's payment architecture, system components, controls, processes, evidence, and testing results relevant to the scope.

The precise assessment procedures depend on the applicable PCI DSS requirements and the validation method being used.

Scope Validation and Segmentation Testing

Scope validation determines whether the systems identified as in scope accurately reflect the payment environment. Where segmentation is used to reduce scope, the assessor evaluates whether the controls actually isolate the relevant environments.

PCI SSC specifically notes that segmentation used for scope reduction must be verified by the assessor.

For SoftPOS environments, this can require examination of network paths, security groups, firewall rules, remote access, administrative connections, APIs, cloud configurations, and other pathways that could provide access to the CDE.

Evidence Assessors Request

Evidence varies according to the applicable PCI DSS requirements and the architecture being assessed. Depending on the environment, evidence can include network diagrams, data-flow diagrams, asset inventories, configuration records, access-control information, vulnerability-management records, security monitoring information, change records, testing results, policies, procedures, and relevant third-party documentation.

For mobile payment environments, evidence should demonstrate how the defined scope corresponds to the actual transaction architecture.

PCI DSS Certification for SoftPOS Providers

PCI DSS is a security standard, and organizations commonly validate compliance through the applicable PCI SSC validation documentation rather than treating a generic certificate as proof that every component of a product is compliant.

SoftPOS providers should also distinguish PCI DSS validation from validation under PCI MPoC or other PCI SSC standards. PCI SSC states that MPoC, SPoC, CPoC, and P2PE are separate standards designed for different use cases.

Assessment Process and Timeline

The assessment process and timeline depend on the organization's scope, environment complexity, validation requirements, applicable PCI DSS version, and the documentation and testing needed for the assessment.

A SoftPOS provider with a large shared payment platform and numerous integrations may require a broader assessment than a narrowly defined payment environment. Establishing the scope early can provide a clearer basis for determining the assessment activities and evidence required.

Maintaining Compliance After Certification

PCI DSS compliance requires ongoing attention rather than a one-time review. Changes to payment applications, cloud infrastructure, APIs, authentication mechanisms, network architecture, third-party services, and transaction flows can affect the defined scope and applicable controls.

SoftPOS providers should therefore review significant architectural and operational changes to determine whether the existing PCI DSS scope remains accurate.

Common Scoping Mistakes in SoftPOS and Tap-to-Pay Environments

One common mistake is assuming that only the mobile application is relevant to PCI DSS. In reality, backend systems and connected components may also fall within scope depending on their role in processing payment account data or influencing CDE security.

Another mistake is assuming that encryption automatically removes systems from scope. Encryption protects data, but the scope determination depends on where payment account data exists, how it moves through the environment, and which systems can affect its security.

Organizations can also incorrectly classify cloud services, administrative interfaces, monitoring systems, remote-access technologies, and APIs as out of scope without evaluating their connectivity to the CDE.

A further mistake is treating tokenization as an automatic scope-reduction mechanism. Tokenization can reduce the presence of cardholder data in certain systems, but the tokenization architecture, token service, original payment data, and connections between components still need to be evaluated.

Finally, relying on the term SoftPOS or Tap-to-Pay as a substitute for technical scoping can create inaccurate conclusions. Different products can use substantially different architectures, data flows, security controls, and third-party dependencies.

Build customer confidence through independent PCI DSS Assessment and assurance. Contact INTERCERT to discuss your requirements.

Choosing an Independent PCI DSS Assessment Partner

SoftPOS and Tap-to-Pay providers need an assessment organization that understands both PCI DSS requirements and the architecture of modern payment environments. For organizations operating in Europe, this includes understanding mobile payment applications, cloud infrastructure, APIs, payment processing environments, segmentation, third-party services, and the relationship between PCI DSS and mobile payment standards.

INTERCERT provides independent PCI DSS assessment services through qualified security assessment professionals. Its approach focuses on defining the applicable assessment boundary, evaluating relevant PCI DSS controls, reviewing evidence, and reporting assessment results based on the organization's actual payment environment.

For SoftPOS providers, payment service providers, fintech companies, and organizations operating Tap-to-Pay environments, an accurately defined PCI DSS scope can provide a clearer assessment boundary without weakening the security requirements applicable to payment account data.