PCI Full Environment

Key Control Areas

When to Use

Apply this pattern where you are a merchant or payment services processor that stores, transmits, or processes payment card data in your own infrastructure. This includes organisations operating their own payment terminals, e-commerce platforms processing card-not-present transactions, payment processors and acquirers, and any service provider that can affect the security of cardholder data on behalf of other entities. The pattern applies regardless of transaction volume, though compliance validation requirements vary by merchant level (Level 1 through Level 4). Organisations handling payment data for the first time should engage a QSA early in the design phase to ensure the architecture is built for compliance rather than retrofitted.

When NOT to Use

Do not use this pattern where you plan to reduce compliance scope using tokenisation (see SP-027 PCI Tokenisation) or remove the environment from scope entirely by using a third-party payment services gateway (see SP-028 PCI Third Party). If your organisation never stores, processes, or transmits cardholder data -- for example, if you use an iframe or redirect to a payment service provider's hosted payment page -- the full PCI DSS requirements do not apply and the SAQ A or SAQ A-EP may be sufficient. Applying this pattern where a scope-reduction approach is viable will result in unnecessary cost and complexity.

Typical Challenges

PCI DSS is a prescriptive and detailed security standard. The first and most persistent challenge is accurate scoping -- organisations must ensure they fully understand the boundaries of the Cardholder Data Environment with accurate network diagrams showing all relevant systems and cardholder data flows. Demonstrating these boundaries to the QSA requires evidence that control points (firewalls, remote access servers, segmentation controls) genuinely isolate the CDE. Documentation must be accurate and current, and many aspects are interlinked: build standards are needed for Requirement 2 (vendor defaults) but also play a critical role in implementing effective file integrity monitoring (Requirement 11.5). Providing evidence of ongoing control operation is essential -- quarterly security scans, daily log reviews, and annual penetration testing must be scheduled and executed consistently, not just prepared for assessment time. Encryption requirements can be technically challenging, particularly key management where split knowledge, dual control, and defined cryptoperiods must be implemented and evidenced. Scope creep is a constant risk as new systems and services are deployed, and maintaining segmentation requires ongoing vigilance. Compensating controls may be necessary where specific requirements cannot be met due to business process constraints, but these require additional documentation and QSA approval.

Threat Resistance

This pattern is designed to resist threats targeting payment card data and achieve compliance with PCI DSS. Theft of cardholder data at rest through database compromise, backup theft, or storage media loss -- mitigated by encryption, access controls, and media protection. Interception of cardholder data in transit through network sniffing or man-in-the-middle attacks on payment transactions -- mitigated by strong transmission encryption. Web application attacks against e-commerce platforms, including SQL injection, cross-site scripting, and payment page manipulation (Magecart-style attacks) -- mitigated by application security controls, file integrity monitoring, and content security policies. Exploitation of default credentials and misconfigurations on payment infrastructure -- mitigated by hardened build standards and configuration management. Malware and memory-scraping attacks on POS terminals and payment processing servers -- mitigated by anti-malware, application whitelisting, and network segmentation. Insider threats from employees with CDE access who abuse privileges to access cardholder data -- mitigated by least privilege, unique user IDs, and comprehensive audit logging. Non-compliance leading to fines, increased transaction fees, loss of card processing privileges, and brand damage -- mitigated by the comprehensive control framework and continuous monitoring approach.

Assumptions

The organisation has a working knowledge of PCI DSS requirements and has studied the standard in detail. The organisation is a merchant or payment services provider that stores, processes, or transmits cardholder data in its own environment rather than outsourcing payment processing entirely. The CDE has been clearly scoped with accurate network diagrams and data flow documentation. The organisation has access to a Qualified Security Assessor (QSA) for annual assessments and an Approved Scanning Vendor (ASV) for quarterly external scans. Budget and resources are available to implement and maintain the full range of controls required -- PCI DSS compliance is not a one-time project but an ongoing operational commitment. The organisation understands that compensating controls may be used where specific PCI DSS requirements cannot be met due to legitimate business or technical constraints, provided the QSA validates that the original control intent is satisfied.

Developing Areas

• PCI DSS v4.0 customised approach adoption is progressing slowly as both organisations and QSAs build confidence with the new methodology. The customised approach allows organisations to meet PCI DSS objectives through alternative controls that differ from the defined requirements, but it demands significantly more documentation, a formal targeted risk analysis per control, and QSA expertise in evaluating novel control implementations. Most organisations are defaulting to the defined approach for the majority of requirements and using the customised approach selectively, which limits the flexibility benefits the PCI SSC intended.
• PCI compliance for serverless and container environments challenges traditional scoping assumptions. Ephemeral compute resources that exist for milliseconds, auto-scaling container orchestration, and serverless functions that process cardholder data without persistent infrastructure make traditional CDE boundary definition and network segmentation approaches inadequate. The PCI SSC has published cloud computing guidance, but practical implementation for Kubernetes-orchestrated payment processing with dynamic pod scheduling and service mesh networking requires architectural patterns that are still being established by the community.
• Continuous compliance monitoring is replacing point-in-time QSA assessment as the operational model for PCI DSS, but the tooling and process maturity are uneven. PCI DSS v4.0 explicitly encourages continuous monitoring, and some QSA firms accept automated evidence from compliance platforms, yet the standard's testing procedures still assume periodic assessment. The industry is in transition between annual compliance snapshots and genuine continuous assurance, with the most mature organisations achieving near-real-time compliance dashboards while the majority still scramble to prepare evidence in the months before annual assessment.
• Tokenisation maturity for cloud-native architectures is advancing but introducing new scoping complexity. Network-level tokenisation appliances are being replaced by API-based tokenisation services that can operate at the application layer across cloud providers, but the question of whether tokenised data in transit between cloud services is in scope remains contentious among QSAs. Format-preserving tokenisation enables backward compatibility with legacy systems but may not provide sufficient randomness to satisfy future PCI DSS requirements around cryptographic strength.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.