PCI Full Environment

Key Control Areas

• Network Segmentation and Boundary Protection (SC-07, CA-07): Network segmentation is the primary mechanism for defining and limiting PCI DSS scope. The CDE must be isolated from untrusted networks and non-CDE systems through properly configured firewalls with documented rule sets, deny-all default policies, and business justification for every permitted connection. SC-07 requires that all inbound and outbound traffic is explicitly authorised and that no direct connections exist between untrusted networks and the CDE. Continuous monitoring (CA-07) ensures that segmentation controls remain effective over time -- regular penetration testing of segmentation controls (PCI DSS 11.4.5) must verify that isolation is maintained. DMZ architecture should separate public-facing systems from internal CDE components, and all wireless networks must be evaluated for CDE connectivity.
• Cardholder Data Encryption and Key Management (SC-12, SC-13, SC-09): These controls address the core PCI DSS requirement to render cardholder data unreadable wherever it is stored (Requirement 3) and protect it during transmission over open public networks (Requirement 4). Use of cryptography (SC-13) must employ industry-accepted algorithms with adequate key strength -- AES-256 for data at rest, TLS 1.2 or higher for data in transit. Cryptographic key management (SC-12) is the operational backbone: implement formal key management procedures covering generation using approved random number generators, secure distribution, protected storage with split knowledge and dual control, defined cryptoperiods with regular rotation, and secure destruction. Transmission confidentiality (SC-09) ensures that PAN is never sent in cleartext over public networks or via end-user messaging technologies. Document the entire encryption architecture including which data elements are encrypted, where encryption and decryption occur, and what key management procedures are in place.
• Access Control and Least Privilege (AC-02, AC-06, AC-18, AC-19): PCI DSS Requirement 7 mandates that access to cardholder data is restricted to personnel with a legitimate business need. Account management (AC-02) requires unique IDs for all users, prohibition of shared and group accounts for CDE access, and documented procedures for granting, modifying, and revoking access. Least privilege (AC-06) ensures that user access rights are limited to the minimum permissions required for their job function, with quarterly reviews to verify ongoing appropriateness. Wireless access restrictions (AC-18) address PCI DSS Requirement 11.2 -- all wireless access points must be inventoried, authorised, and tested quarterly for rogue devices. Mobile device controls (AC-19) address the growing use of mobile payment terminals and the risks of portable devices accessing the CDE.
• Audit Logging and Log Management (AU-02, AU-06, AU-08, AU-09): PCI DSS Requirement 10 is one of the most prescriptive in the standard. Auditable events (AU-02) must include all individual user access to cardholder data, all actions by anyone with root or administrative privileges, access to audit trails, invalid logical access attempts, use of identification and authentication mechanisms, initialisation of audit logs, and creation/deletion of system-level objects. Time stamps (AU-08) must be synchronised to a reliable time source using NTP to enable accurate event correlation -- a common QSA finding is clock drift across CDE systems. Audit monitoring and reporting (AU-06) requires daily review of logs and security events, with automated alerting for suspicious activity. Protection of audit information (AU-09) ensures logs cannot be altered or deleted by anyone including administrators, typically implemented through centralised log management with write-once storage or SIEM forwarding.
• Vulnerability Management and System Integrity (RA-05, SI-02, SI-03, SI-04, SI-05, SI-06, SI-07): PCI DSS Requirements 5, 6, and 11 demand comprehensive vulnerability management. Vulnerability scanning (RA-05) requires quarterly ASV scans of all externally-facing IP addresses and URLs, plus quarterly internal vulnerability scans with rescanning to confirm remediation. Flaw remediation (SI-02) requires that critical security patches are installed within one month of release, with risk-ranked prioritisation for all identified vulnerabilities. Malicious code protection (SI-03) requires anti-malware on all systems commonly affected by malware, with regular updates and periodic scans. System monitoring (SI-04) implements intrusion detection or prevention at the CDE perimeter and at critical points within the CDE. File integrity monitoring (SI-07) detects unauthorised modification of critical system files, configuration files, and content files, with alerts generated and investigated at least weekly. Security functionality verification (SI-06) validates that security controls are operating as intended.
• Physical Access and Media Protection (PE-03, PE-07, MP-03, MP-06): PCI DSS Requirement 9 requires physical restriction of access to cardholder data. Physical access control (PE-03) implements appropriate facility entry controls for the CDE: badge readers or locks on data centre doors, visitor escort requirements, and access logs retained for at least three months. Visitor control (PE-07) ensures visitors are identified, authorised, escorted in sensitive areas, and that visitor logs are maintained. Media labeling (MP-03) requires classification of media containing cardholder data so its sensitivity is apparent. Media sanitization (MP-06) mandates secure destruction of cardholder data when no longer needed -- cross-cut shredding for paper, cryptographic erasure or physical destruction for electronic media, with certificates of destruction maintained for audit evidence.
• Risk Assessment, Change Control, and Asset Management (RA-03, CM-02, CM-03, CM-08, IR-01, PS-03): PCI DSS Requirement 12 establishes the governance framework. Risk assessment (RA-03) must be performed annually and upon significant environmental changes to identify threats, vulnerabilities, and their potential impact on the CDE. Baseline configuration (CM-02) implements documented build standards for all CDE system components that address all known security vulnerabilities and vendor defaults (PCI DSS Requirement 2). Configuration change control (CM-03) ensures all changes to CDE systems are formally authorised, tested, documented, and include rollback procedures. Component inventory (CM-08) maintains an accurate list of all hardware and software within the CDE, which is essential for accurate scoping. Incident response (IR-01) requires a documented, tested incident response plan ready for immediate deployment in the event of a breach. Personnel screening (PS-03) requires background checks for personnel with access to the CDE.

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.