Modern payment acceptance platforms are distributed systems. A typical SoftPOS solution may combine an NFC-enabled device, a mobile application, backend APIs, transaction services, cryptographic components, cloud infrastructure, and external payment providers.
For engineering and security teams, one of the most important tasks is determining which components fall within PCI DSS scope and how architectural decisions affect the assessment boundary.
Model the Complete Payment Flow
Start with a data-flow diagram that follows the transaction from the mobile device through the relevant backend services and external payment entities.
Document:
- Where payment account data enters the environment.
- Which services receive, process, or transmit it.
- Where data is stored, if applicable.
- Where cryptographic operations take place.
- Which systems administer or monitor the environment.
- Which third-party services can affect payment security.
The purpose is to describe the actual architecture, not simply the intended logical design.
Distinguish Data Handling From Security Impact
Systems that store, process, or transmit cardholder data are directly relevant to the cardholder data environment. Other systems may also be in scope if they can affect CDE security or provide relevant pathways into it.
For example, a shared administrative platform might not handle payment account data directly but could control access to payment infrastructure.
Cloud environments require the same careful analysis. Separate accounts or subnets can help establish boundaries, but the security of management interfaces, identity systems, routing, and shared services must also be considered.
Use Architecture to Reduce Unnecessary Scope
A number of engineering practices can support a more manageable assessment boundary:
Segmentation: Use appropriate network controls to restrict communication between payment and non-payment environments.
Data minimisation: Avoid sending payment account data to services that do not need it.
Tokenization: Where suitable, use tokens for downstream business processes instead of exposing the original account data.
Access control: Apply least-privilege permissions and tightly manage privileged access.
Validation: Test segmentation and review whether unexpected routes or administrative pathways undermine the intended separation.
These practices can reduce exposure, but no single control automatically removes all related systems from scope.
Avoid Treating Encryption as a Scope Shortcut
Encryption is an important security measure, but encrypted data flows do not by themselves establish that a system is out of scope. The determination depends on the system's role, access, security responsibilities, and relationship to the cardholder data environment.
The same caution applies to tokenization and cloud hosting.
Account for PCI Mobile Payment Standards
PCI DSS and PCI SSC's MPoC standard address different aspects of payment security. MPoC is designed for mobile payment acceptance on commercial off-the-shelf devices.
Engineering teams should identify the standards applicable to the product rather than treating their requirements as interchangeable.
Reviewing PCI DSS requirements and scope can help teams connect architecture decisions with the appropriate assessment requirements.
Finally, scoping should be treated as an ongoing process. Changes to APIs, service boundaries, identity platforms, or remote administration can alter the security relationships between components. Keeping diagrams and technical evidence current makes scope decisions easier to explain and validate.
Top comments (0)