All 12 PCI DSS requirements mapped to IBM Z controls — RACF, encryption, LPAR segmentation, SMF logging, and tokenization for 70–90% scope reduction
PCI DSS applies to every system that stores, processes, or transmits cardholder data — and IBM Z mainframes are no exception. PCI DSS 4.0.1 is now the only active version of the standard, with all future-dated requirements becoming mandatory as of March 31, 2025.
The 12 PCI DSS requirements map to specific z/OS controls: RACF, ACF2, and Top Secret for access control; SMF records for logging; LPARs for segmentation; ICSF for encryption; and tokenization for PCI DSS scope reduction.
Organizations that replace cardholder data with tokens can reduce their audit scope by 70–90%, because systems handling only tokens fall outside the Cardholder Data Environment (CDE).
The Payment Card Industry Data Security Standard (PCI DSS) is a global security framework that governs how organizations protect payment card data.
It is administered by the PCI Security Standards Council (PCI SSC) and enforced by Visa, Mastercard, American Express, Discover, and JCB.
Any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD) falls under PCI DSS compliance requirements.
The standard has evolved through several versions since its launch in 2004. Version 3.2.1 was retired on March 31, 2024. Version 4.0 followed in March 2022 with over 50 new technical requirements, and version 4.0.1 — released in June 2024 — is now the only active version of the standard.
It is important to distinguish between 4.0 and 4.0.1: version 4.0.1 did not add new requirements. It corrected formatting issues, fixed typographical errors, and clarified ambiguous language.
The 12 PCI DSS requirements themselves remain unchanged from the structure established in version 1.0, covering network security, data protection, vulnerability management, access control, monitoring, and information security policy.
PCI DSS 4.0 introduced a customized approach that lets organizations implement security controls suited to their own technology environment and risk profile. It also tightened rules on vulnerability remediation and mandated multi-factor authentication (MFA) for all access to the CDE.
It strengthened encryption requirements on trusted networks and introduced targeted risk assessments. For mainframe security teams, several of these changes carry particular weight.
The new authenticated vulnerability scanning requirements mean that organizations can no longer rely on external network scans alone. Mainframe security controls must be tested within the z/OS environment by validating RACF profiles, SMF logging configurations, and cryptographic settings.
The push toward software bill of materials (SBOM) requirements also creates new obligations for mainframe shops. They must now catalogue all z/OS products, PTFs, and APARs as part of their PCI DSS compliance programme.
PCI DSS 4.0 also introduced Requirements 6.4.3 (payment page script management) and 11.6.1 (payment page change detection). These matter when mainframe-backed applications serve web-facing payment pages.
Card fraud losses were projected to reach $13.8 billion by the end of 2024 — a key driver of these stricter PCI DSS requirements. For enterprises running payment processing on IBM Z, the combination of mainframe security solutions and web-layer protection is now essential.
IBM Z mainframes do not get a PCI DSS exemption. The standard applies to any system that stores, processes, or transmits CHD, regardless of the platform. As PCI QSA Branden Williams wrote directly on this point: mainframes do not get a pass.
A well-run mainframe supported by security-first role definitions will do just fine in a PCI DSS review, but simply running a mainframe is not enough. All 12 PCI DSS requirements apply in full, and meeting them demands mainframe-specific security controls and solutions.
The scale of mainframe exposure to PCI DSS is significant. Nearly all of the world's top 100 banks run core transaction processing on IBM Z, and mainframes support the vast majority of global card-transaction volume.
Common mainframe workloads that touch CHD include CICS transaction processing, IMS databases, Db2 cardholder records, batch settlement runs, and MQ message queuing to downstream systems.
The Cardholder Data Environment (CDE) includes all systems, network segments, and processes that store, process, or transmit CHD. On distributed systems, CDE boundaries are drawn using VLANs, firewalls, and access control lists. On mainframes, LPARs and z/OS network isolation serve the same purpose.
But the boundaries are harder to define. A single LPAR may host both cardholder data processing and non-payment workloads. Batch jobs may read CHD from Db2, process it, and write results to VSAM datasets or MQ queues — all within the same z/OS image.
This is why data classification and discovery must come before you can draw CDE boundaries on a mainframe.
It is also key to know the difference between IBM Z and IBM i. IBM Z runs z/OS. The world's largest banks use it for high-volume payment processing.
IBM i (the old AS/400) runs a different operating system with different security tools. This article covers IBM Z (z/OS) only. For IBM i PCI DSS compliance, see Precisely's Assure Security suite.
As mainframe data flows to AWS, Azure, or GCP for analytics, fraud detection, or AI model training, the CDE extends into those cloud environments. Data leaving the mainframe in cleartext creates PCI DSS compliance gaps that many organizations underestimate.
AWS publishes its own PCI DSS compliance guidance, and Azure and GCP have equivalent documentation — but none of them address the mainframe-to-cloud transit layer.
The optimal approach to mainframe security in hybrid architectures is to tokenize or encrypt sensitive fields before they leave the mainframe. Downstream systems then only ever handle surrogates.
This also simplifies PCI DSS compliance across cloud environments, because token-only systems in AWS or Azure fall outside the CDE entirely. For a detailed breakdown of this architecture, see DataStealth's guide to mainframe-to-cloud data pipelines.
No competitor has published a comprehensive mapping of all 12 PCI DSS requirements to z/OS-specific mainframe security controls. The table below fills that gap by matching each PCI DSS requirement to the mainframe tools and configurations that satisfy it.
Requirement 1 sets the rules for network security controls. On z/OS, these controls include Communications Server firewall rules, TCP/IP port restrictions, VTAM configuration, and LPAR-level network isolation.
Think of LPARs like VLANs on distributed systems. Each LPAR can run on its own network interface, keeping cardholder data processing separate from non-payment workloads. This is the starting point for mainframe security controls.
Requirement 2 calls for secure configurations and the elimination of vendor-supplied defaults. On z/OS, this means hardening system parameters, locking down RACF class settings, removing default TCP/IP configurations, and applying IBM security configuration best practices. Keeping SMP/E patch management current is also essential — any unpatched APAR represents a potential compliance gap.
Requirement 3 is where mainframe PCI DSS compliance gets nuanced. Among all PCI DSS requirements, Requirement 3.4 is the one that matters most for mainframe data protection — it requires organizations to render stored PAN unreadable.
The methods include encryption, tokenization, truncation, and one-way hashes. The PCI Council clarified that encryption is one method, not the only method. Strong RACF access controls that prevent any interactive login from accessing cleartext PAN can also satisfy Requirement 3.4, because the intent is to render data unreadable to unauthorized users.
On z/OS, encryption at rest is provided by DFSMS dataset encryption, Db2 column-level encryption, and IBM's Integrated Cryptographic Service Facility (ICSF). For a deeper comparison of these methods, see the data tokenization vs encryption breakdown.
Requirement 4 mandates encrypted transmission. On z/OS, this means TLS 1.2 or higher for all transmissions, enforced through AT-TLS (Application Transparent TLS), FTPS, SSH/SFTP, and MQ TLS channels. Data flowing from mainframe to cloud must be encrypted in transit — or, better yet, tokenized before transmission so that the payload itself carries no sensitive information.
Requirement 5 addresses anti-malware. Traditional anti-virus is not applicable to native z/OS — the operating system architecture prevents executable malware in a way that x86 systems experience it.
However, Linux on z (z/VM guests), Unix System Services (USS) environments, and Java workloads on z/OS do require anti-malware controls. As mainframe security practitioners have noted, z/VM virtualization creates an entirely new compliance surface that native z/OS alone does not.
Requirement 6 mandates secure systems and software development. On z/OS, this means maintaining current SMP/E patching with no critical or high unpatched APARs.
PCI DSS 4.0 also pushes toward software inventory requirements (SBOM), which for z/OS environments means cataloguing all products, PTFs, and APARs. Requirement 6.4.3 — which governs payment page script integrity — is less relevant for mainframe back-end processing but becomes critical when CICS or z/OS Connect serves web-facing payment applications.
Requirement 7 restricts access to CHD on a need-to-know basis. On z/OS, three products handle this: RACF, ACF2, and Top Secret. Use them to set least-privilege access on datasets, CICS transactions, Db2 tables, and MQ queues that hold CHD. Each product works differently, as shown below. For a full review, see the mainframe security solutions guide.
Requirement 8 mandates unique user identification and authentication. No shared accounts. Password complexity rules must be enforced in the security system. MFA is now required for all CDE access under PCI DSS 4.0 — IBM Z Multi-Factor Authentication provides TOTP, certificate-based, and RADIUS/LDAP options.
Requirement 9 covers physical access controls: card readers, surveillance, visitor logs, restricted console access, secured Hardware Management Console (HMC), and locked tape libraries. These are standard data centre controls that apply equally to mainframe and distributed environments.
Requirement 10 is where mainframe environments have a distinct advantage — and a distinct challenge. SMF (System Management Facility) records are the z/OS native audit trail. Types 30 (job activity), 80 (RACF events), 83 (RACF data access), and 119 (TCP/IP) are critical for PCI DSS compliance requirements around logging and monitoring.
The challenge is to forward these records to an enterprise SIEM such as Splunk or QRadar. Broadcom's Compliance Event Manager (CEM 7.0, released March 2026) provides real-time alerting on z/OS with turnkey policy workflows for mainframe security monitoring.
CorreLog (now part of Fortra) converts SMF records to syslog format for SIEM integration. PCI DSS requirements mandate at least 12 months of log retention, with 3 months immediately accessible.
Requirement 11 mandates security testing. PCI DSS 4.0 requires internal authenticated vulnerability scans — not just network-level scans from outside the mainframe. Penetration testing must include mainframe-specific attack vectors: TN3270 session hijacking, FTP brute force, and MQ injection.
Requirement 11.6.1 requires change detection for payment pages at least every 7 days, which is relevant when mainframe-backed applications serve web content. For implementation guidance on these two requirements, see how QSAs assess 6.4.3 and 11.6.1.
Requirement 12 mandates an information security policy. Mainframe security must be explicitly covered in your organization's policy, including z/OS-specific incident response procedures, skills training for RACF and SMP/E administration, and mainframe security best practices for risk assessments.
What most mainframe teams miss about PCI DSS compliance is that the best way to simplify it is to shrink the CDE. Remove cardholder data from systems that do not need it.
Tokenization replaces PAN and other CHD with random tokens. These tokens have no link to the original value. Systems that handle only tokens fall outside the CDE. This can cut the number of in-scope systems by 70–90%.
On IBM Z, agentless tokenization intercepts data in-flight before it reaches the mainframe in a sensitive state, or tokenizes data within Db2 at the field level.
The PCI SSC released tokenization guidelines in 2011, confirming that properly implemented tokenization can reduce PCI DSS scope. The critical distinction is between vaulted and vaultless approaches, as summarised in the table below.
Vaulted tokenization severs the mathematical link between the token and the original data entirely. An attacker who obtains tokens has nothing — no key to break, no algorithm to reverse.
This also makes vaulted tokenization inherently quantum-resistant, because unlike encrypted data (which can be harvested today and decrypted later when quantum computing matures), tokens have no cryptographic relationship to crack. For a detailed comparison, see format-preserving encryption vs tokenization.
Agentless tokenization on IBM Z works at the network layer, without installing agents on z/OS, without COBOL application rewrites, and without additional MIPS consumption. However, "no code changes" deserves honest qualification.
Most agentless implementations involve operational changes — DNS routing adjustments, RACF profile updates, and testing.
The key distinction is that no legacy COBOL code is modified. The mainframe application logic remains untouched, but the operational environment around it changes. Enterprise buyers should expect some integration work even with an agentless approach.
Network segmentation is a foundational PCI DSS requirement, and on the mainframe, it starts with LPAR isolation. Dedicate LPARs to CHD-processing workloads and configure each with separate network interfaces. z/OS Communications Server packet filtering rules control traffic between LPARs.
HiperSockets can provide high-speed inter-LPAR communication within the Central Electronics Complex (CEC), but these connections must be monitored and logged.
Coupling Facility paths — shared memory between LPARs — also create compliance questions when one LPAR is in-scope and another is not. Consider how your mainframe security architecture handles these shared paths.
PCI DSS 4.0 emphasizes security as a continuous process, not a point-in-time audit. On z/OS, this means building a reliable SMF-to-SIEM pipeline. Forward Type 80, 83, and 119 records to Splunk, QRadar, or Sentinel.
Broadcom CEM 7.0 provides real-time alerting for security events on z/OS, while CorreLog (Fortra) handles SMF-to-syslog conversion. Log retention under PCI DSS requires 12 months of history, with 3 months immediately available for forensic review. Make sure your data security management practices cover mainframe log flows alongside distributed and cloud telemetry.
The average mainframe security professional is nearing retirement age, and z/OS expertise is harder to recruit than cloud security skills. RACF administration, SMP/E patch management, and SMF log analysis are niche competencies with shrinking talent pools.
This skills gap compounds PCI DSS compliance challenges — organizations that cannot staff mainframe security roles struggle to maintain the continuous compliance that PCI DSS 4.0 requires.
The response should be to automate wherever possible: automated compliance scanning, automated patching, automated SIEM forwarding, and agentless security platforms that reduce dependency on mainframe-specialist skills. The fewer manual processes in your mainframe PCI DSS compliance programme, the less vulnerable you are to attrition and hiring gaps.
PCI DSS 4.0 introduced a push toward cryptographic inventory — organizations must now document all cryptographic algorithms, key lengths, and key management practices in use.
For z/OS environments, this means cataloguing ICSF configurations and CP Assist for Cryptographic Functions (CPACF) usage. It also means documenting data encryption algorithms applied to Db2 and VSAM datasets, TLS cipher suites in AT-TLS policies, and any hardware security module (HSM) integrations.
This requirement matters because PCI DSS compliance auditors are increasingly asking for evidence that organizations have a clear picture of their cryptographic posture. On mainframes, the answer is often fragmented across ICSF key datasets, RACF CSFKEYS profiles, and Communications Server configuration files.
Building a centralized cryptographic inventory — ideally as part of your broader data security management strategy — streamlines audit preparation and helps identify weak algorithms before a QSA flags them.
The quantum computing dimension adds urgency. Adversaries are already collecting encrypted data today, planning to decrypt it later when quantum computers can break current algorithms. This is known as "harvest now, decrypt later."
Vaulted tokenization is immune to this threat because tokens are not linked to the original data. Organizations that combine mainframe encryption for data at rest with tokenization for data in motion achieve both current PCI DSS compliance and quantum-readiness.
PCI DSS compliance levels are determined by annual transaction volume. Understanding which level applies to your organization dictates the validation method you must follow.
Mainframe organizations that process CHD are almost always Level 1 merchants (over 6 million annual transactions). This requires an annual Report on Compliance (RoC) conducted by a Qualified Security Assessor (QSA) plus quarterly Approved Scanning Vendor (ASV) scans.
Levels 2–4 can use Self-Assessment Questionnaires (SAQs), but the volume thresholds make this rare for mainframe shops. Service providers have their own compliance levels — for example, DataStealth is a PCI DSS Level 1 service provider.
Non-compliance carries serious financial penalties. Card brands can impose fines of $5,000 to $100,000 per month, increase transaction fees, and terminate merchant processing agreements. A data breach while non-compliant escalates costs, including forensic investigation, legal fees, customer notification, and reputational damage.
The Attestation of Compliance (AOC) is the formal document that confirms PCI DSS compliance, issued after an RoC or SAQ. For mainframe environments, the AOC must specifically cover the z/OS systems, PII, PHI, and PCI data types in scope, as well as the mainframe security controls applied to protect them.
Pre-audit checklist for IBM Z environments:
The mainframe PCI DSS tooling ecosystem spans platform vendors, specialist security firms, and data security platforms. The table below maps key vendors to the PCI DSS requirements they address.
DataStealth's differentiation is its agentless architecture. It tokenizes Db2 databases and masks TN3270 sessions on IBM Z without installing agents, consuming MIPS, or modifying COBOL application code.
Protection extends from the mainframe through to the cloud, covering hybrid data flows under a single platform. For organizations evaluating different approaches to data-at-rest encryption alongside tokenization, the critical distinction is that encryption keeps sensitive data in the CDE while tokenization removes it.
Choosing the right combination of mainframe security solutions depends on your PCI DSS compliance requirements, CDE scope, and hybrid architecture. Most enterprises need a layered approach: RACF or ACF2 for access control, ICSF or Pervasive Encryption for mainframe data encryption, a SIEM connector for logging, and tokenization for scope reduction.
The Vanguard Integrity Professionals platform adds RACF compliance reporting and policy management to IBM's native mainframe security controls.
For mainframe teams managing PCI DSS compliance, the fastest path to scope reduction is removing cardholder data from systems that do not need it. DataStealth's agentless platform addresses the challenges discussed throughout this guide:
Bilal is the Content Strategist at DataStealth. He's a recognized defence and security analyst who's researching the growing importance of cybersecurity and data protection in enterprise-sized organizations.
