{"data":{"id":"SP-026","slug":"pci-full-environment","joomla_id":315,"title":"PCI Full Environment","description":"Security architecture for a fully PCI DSS compliant cardholder data environment. Covers CDE scoping and segmentation, cardholder data protection with encryption and key management, access control for payment systems, audit logging and monitoring, vulnerability management, and physical security for payment processing infrastructure.","url":"https://www.opensecurityarchitecture.org/patterns/sp-026","metadata":{"release":"26.02","classification":"Data & Privacy","status":"published","type":"pattern","datePublished":"2013-06-09","dateModified":"2026-02-06","authors":["Aurelius","Vitruvius"],"reviewers":[],"provenance":"Derived from hands-on experience conducting PCI DSS assessments of major card brand environments. The control selections and implementation guidance reflect lessons learned from real-world compliance programmes in payment processing infrastructure."},"diagram":{"svg":"/images/patterns/13_05_Pattern_026_01_PCI_Full.svg","png":"/images/OSA_images/patterns/13_05_Pattern_026_01_PCI_Full.png"},"content":{"description":"The PCI Full Environment pattern addresses the security architecture required for organisations that store, process, or transmit cardholder data and must achieve and maintain compliance with the Payment Card Industry Data Security Standard (PCI DSS). This is the most comprehensive of the PCI-related patterns -- it applies where the organisation operates a full Cardholder Data Environment (CDE) without scope reduction through tokenisation or outsourcing to a third-party payment gateway. The pattern maps NIST 800-53 controls to the practical requirements of building, operating, and demonstrating compliance for a payment processing environment.\n\nScoping is the single most consequential decision in PCI compliance. The CDE includes every system component that stores, processes, or transmits cardholder data, plus every system that is connected to or could impact the security of the CDE. Getting scope wrong -- either too narrow (creating compliance gaps and assessment failures) or too broad (inflating the cost and complexity of compliance) -- is the most common and most expensive mistake organisations make. Accurate network diagrams showing all system components within the CDE and all data flows for cardholder data are not optional documentation exercises; they are the foundation upon which the entire compliance programme rests. The Qualified Security Assessor (QSA) will verify these diagrams against actual network configurations and traffic flows during the assessment.\n\nData protection is at the heart of PCI DSS. Cardholder data must be protected at rest and in transit using strong cryptography. PAN (Primary Account Number) is the defining data element -- where PAN is present, all twelve PCI DSS requirements apply. Encryption key management is frequently the most technically challenging aspect of compliance: key generation must use approved algorithms and sufficient key lengths, keys must be stored securely with split knowledge and dual control, key rotation must occur at defined intervals and upon suspected compromise, and the entire lifecycle from generation through destruction must be documented and auditable. Organisations that treat encryption as a simple technical control and neglect key management invariably struggle during assessments.\n\nThe pattern demands defence in depth across network, system, application, and physical layers. Network segmentation via firewalls with deny-all default rules isolates the CDE from untrusted networks and limits the scope of the assessment. System hardening through documented build standards eliminates vendor defaults and unnecessary services. Application security, particularly for web-facing payment applications, requires secure development practices and regular testing. Physical access controls restrict entry to areas housing CDE components. Each layer must be documented with current standards, tested through regular assessments, and evidenced through repeatable processes -- PCI DSS compliance is not a point-in-time achievement but a continuous operational discipline.\n\nMonitoring and testing validate that controls are operating effectively. All access to cardholder data and all access to network resources in the CDE must be logged and monitored. Logs must be reviewed daily, retained for at least one year (with three months immediately available), and protected against tampering. Quarterly vulnerability scans by an Approved Scanning Vendor (ASV), annual penetration testing, and regular wireless scanning provide ongoing assurance. File integrity monitoring detects unauthorised changes to critical system files. These requirements reflect the reality that attackers are persistent and controls degrade over time -- compliance depends on continuous verification, not annual assessments alone.","keyControlAreas":["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."],"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.","typicalChallenges":"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.","indications":"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.","contraIndications":"Do not use this pattern where you plan to reduce compliance scope using tokenisation or remove the environment from scope entirely by using a third-party payment services gateway. 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.","threatResistance":"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."},"examples":{"Payment security and tokenisation":["Thales CipherTrust for data-at-rest encryption and key management in CDE","Voltage SecureData for format-preserving encryption of PAN","AWS Payment Cryptography for cloud-based payment HSM services","Futurex VirtuCrypt for payment HSM and key management as a service"],"PCI compliance and assessment tools":["Qualys PCI Compliance module for ASV scanning and SAQ management","Tenable.io for internal vulnerability scanning and compliance assessment","Coalfire and Trustwave as Qualified Security Assessor (QSA) firms","SecurityMetrics for PCI compliance scanning and assessment services"],"Logging and file integrity monitoring":["Splunk Enterprise for centralised log management and daily log review","Tripwire Enterprise for file integrity monitoring (PCI DSS 11.5)","LogRhythm for SIEM with PCI DSS compliance reporting","OSSEC for open-source file integrity monitoring and log analysis"],"Network segmentation and firewalls":["Palo Alto Networks next-generation firewalls for CDE segmentation","Illumio for microsegmentation of cardholder data environment","Cisco Firepower for CDE boundary protection with IPS","AlgoSec for firewall rule analysis and PCI DSS compliance verification"],"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."]},"references":[{"title":"PCI DSS v4.0.1: Payment Card Industry Data Security Standard","url":"https://www.pcisecuritystandards.org/document_library/","note":"The definitive standard. All twelve requirements with detailed testing procedures and guidance. Version 4.0.1 introduces the customised approach as an alternative to the defined approach for meeting requirements."},{"title":"PCI SSC Information Supplements and Guidance Documents","url":"https://www.pcisecuritystandards.org/document_library/","note":"Supplementary guidance on specific topics including network segmentation, cloud computing, scoping, penetration testing, and multi-factor authentication. Essential for interpreting complex requirements."},{"title":"NIST SP 800-53 Rev 5: Security and Privacy Controls","url":"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final","note":"NIST 800-53 provides the control framework used in this pattern. Mapping NIST controls to PCI DSS requirements enables organisations to maintain a single control framework that satisfies multiple compliance obligations."},{"title":"PCI SSC Guidance for Scoping and Segmentation","url":"https://www.pcisecuritystandards.org/document_library/","note":"Detailed guidance on identifying CDE boundaries, segmentation techniques, and scope validation. The most critical reference for the architectural foundations of this pattern."},{"title":"Verizon Payment Security Report","url":"https://www.verizon.com/business/resources/reports/payment-security/","note":"Annual analysis of PCI DSS compliance trends, common control failures, and the correlation between sustained compliance and breach resistance. Provides industry benchmarking data."},{"title":"NIST SP 800-57: Recommendation for Key Management","url":"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final","note":"Comprehensive guidance on cryptographic key management including key generation, distribution, storage, rotation, and destruction. Directly applicable to PCI DSS Requirement 3 encryption key management."}],"relatedPatterns":["SP-013","SP-018","SP-025","SP-010","SP-017"],"relatedPatternNames":["Data Security","Information Security Management System","Advanced Monitoring and Detection","Identity Management","Secure Network Zone Module"],"threats":[{"id":"T-PC-001","name":"Cardholder Data Theft at Rest (Database Compromise, Backup Theft)","mitigatedBy":["SC-13","SC-12","AC-06","MP-06"]},{"id":"T-PC-002","name":"Cardholder Data Interception in Transit (Network Sniffing, MITM)","mitigatedBy":["SC-09","SC-13","SC-07","SI-04"]},{"id":"T-PC-003","name":"Web Application Attacks (SQL Injection, XSS, Magecart-style Skimming)","mitigatedBy":["SI-07","SI-06","SI-09","CM-02"]},{"id":"T-PC-004","name":"POS Malware and Memory Scraping","mitigatedBy":["SI-03","CM-02","SC-07","SI-07"]},{"id":"T-PC-005","name":"Exploitation of Default Credentials and Misconfigurations","mitigatedBy":["CM-02","CM-03","AC-02","AC-06"]},{"id":"T-PC-006","name":"Insider Threat (Privileged User Data Exfiltration)","mitigatedBy":["AC-06","AU-02","AU-06","PS-03"]},{"id":"T-PC-007","name":"Unpatched Vulnerabilities in CDE Systems","mitigatedBy":["RA-05","SI-02","SI-05","CM-08"]},{"id":"T-PC-008","name":"Inadequate Network Segmentation (Scope Expansion)","mitigatedBy":["SC-07","CA-07","CM-08","RA-03"]},{"id":"T-PC-009","name":"Audit Log Tampering or Gaps","mitigatedBy":["AU-09","AU-08","AU-06","AU-02"]},{"id":"T-PC-010","name":"Physical Unauthorised Access to CDE Infrastructure","mitigatedBy":["PE-03","PE-07","MP-03","MP-06"]}],"controls":[{"id":"AC-02","name":"Account Management","family":"AC","emphasis":"critical"},{"id":"AC-06","name":"Least Privilege","family":"AC","emphasis":"critical"},{"id":"AC-18","name":"Wireless Access","family":"AC","emphasis":"standard"},{"id":"AC-19","name":"Access Control for Mobile Devices","family":"AC","emphasis":"standard"},{"id":"AU-02","name":"Event Logging","family":"AU","emphasis":"critical"},{"id":"AU-06","name":"Audit Record Review, Analysis, and Reporting","family":"AU","emphasis":"critical"},{"id":"AU-08","name":"Time Stamps","family":"AU","emphasis":"important"},{"id":"AU-09","name":"Protection of Audit Information","family":"AU","emphasis":"important"},{"id":"CA-02","name":"Control Assessments","family":"CA","emphasis":"important"},{"id":"CA-07","name":"Continuous Monitoring","family":"CA","emphasis":"important"},{"id":"CM-02","name":"Baseline Configuration","family":"CM","emphasis":"critical"},{"id":"CM-03","name":"Configuration Change Control","family":"CM","emphasis":"important"},{"id":"CM-08","name":"System Component Inventory","family":"CM","emphasis":"important"},{"id":"IR-01","name":"Policy and Procedures","family":"IR","emphasis":"important"},{"id":"MP-03","name":"Media Marking","family":"MP","emphasis":"standard"},{"id":"MP-06","name":"Media Sanitization","family":"MP","emphasis":"important"},{"id":"PE-03","name":"Physical Access Control","family":"PE","emphasis":"important"},{"id":"PE-07","name":"Visitor Control","family":"PE","emphasis":"standard"},{"id":"PS-03","name":"Personnel Screening","family":"PS","emphasis":"standard"},{"id":"RA-03","name":"Risk Assessment","family":"RA","emphasis":"important"},{"id":"RA-05","name":"Vulnerability Monitoring and Scanning","family":"RA","emphasis":"critical"},{"id":"SC-07","name":"Boundary Protection","family":"SC","emphasis":"critical"},{"id":"SC-09","name":"Transmission Confidentiality","family":"SC","emphasis":"critical"},{"id":"SC-12","name":"Cryptographic Key Establishment and Management","family":"SC","emphasis":"critical"},{"id":"SC-13","name":"Cryptographic Protection","family":"SC","emphasis":"critical"},{"id":"SI-02","name":"Flaw Remediation","family":"SI","emphasis":"important"},{"id":"SI-03","name":"Malicious Code Protection","family":"SI","emphasis":"important"},{"id":"SI-04","name":"System Monitoring","family":"SI","emphasis":"important"},{"id":"SI-05","name":"Security Alerts, Advisories, and Directives","family":"SI","emphasis":"standard"},{"id":"SI-06","name":"Security and Privacy Function Verification","family":"SI","emphasis":"standard"},{"id":"SI-07","name":"Software, Firmware, and Information Integrity","family":"SI","emphasis":"important"},{"id":"SI-09","name":"Information Input Restrictions","family":"SI","emphasis":"standard"}],"controlFamilySummary":{"AC":4,"AU":4,"CA":2,"CM":3,"IR":1,"MP":2,"PE":2,"PS":1,"RA":2,"SC":4,"SI":7}}}