Overview
PCI-DSS (Payment Card Industry Data Security Standard) v4.0 is the mandatory security framework for any organization that stores, processes, or transmits cardholder data (CHD). It is enforced by the card brands — Visa, Mastercard, Amex, Discover — and assessed by Qualified Security Assessors (QSAs). Failure to comply means fines, increased transaction fees, and ultimately loss of the ability to accept card payments.
As a network engineer, PCI-DSS is not abstract policy — it directly governs what you configure on firewalls, switches, routers, and wireless infrastructure. Requirements 1, 2, 4, 7, 8, 10, and 11 all have direct network configuration mandates. Getting these wrong is how organizations accumulate findings.
The 12 Requirements at a Glance
- Req 1 — Install and maintain network security controls (firewall rules, segmentation)
- Req 2 — Apply secure configurations to all system components (hardening, no defaults)
- Req 3 — Protect stored account data (encryption at rest — primarily application/DBA domain)
- Req 4 — Protect cardholder data with strong cryptography during transmission (TLS, IPsec)
- Req 5 — Protect all systems against malware (AV, EDR — primarily endpoint/server domain)
- Req 6 — Develop and maintain secure systems and software (patching, SDLC)
- Req 7 — Restrict access to system components by business need (least privilege, RBAC)
- Req 8 — Identify users and authenticate access (MFA, no shared accounts, password policy)
- Req 9 — Restrict physical access to cardholder data (badge access, camera — physical domain)
- Req 10 — Log and monitor all access to system components and cardholder data (SIEM, NTP)
- Req 11 — Test security of systems and networks regularly (pen test, vuln scans, segmentation test)
- Req 12 — Support information security with organizational policies (documented policies)
SAQ vs. ROC
Smaller merchants can self-assess using a Self-Assessment Questionnaire (SAQ). The SAQ type depends on how you handle card data — SAQ-D covers all requirements and is the most comprehensive. Larger merchants and service providers processing over defined thresholds require a full Report on Compliance (ROC) conducted by a QSA. Service providers (including managed service providers handling CHD for clients) have stricter requirements than merchants.
Scope Creep
Over-scoping is nearly as damaging as under-scoping. Every system you include in scope requires full PCI controls — more systems in scope means more audit work, more evidence, more cost. The goal of segmentation is to minimize scope to only those systems that genuinely touch cardholder data, while maintaining a defensible boundary that satisfies QSA scrutiny. Systems "connected to" in-scope systems but not handling CHD can potentially be descoped with proper segmentation — this is the central technical argument of every PCI network design.
Scoping the CDE
The Cardholder Data Environment (CDE) is the set of systems and network segments that store, process, or transmit Primary Account Numbers (PANs) and associated cardholder data. Every device in the CDE is in scope. Every device on the same network segment as a CDE device is also in scope — unless you can demonstrate that the network traffic is fully controlled and filtered at the boundary.
What Goes Into Scope
- Payment servers, point-of-sale (POS) systems, payment gateways
- Systems that receive, process, or forward card transaction data
- Database servers storing PANs (even if encrypted — encryption key management is still in scope)
- Any system that can initiate or receive connections to/from in-scope systems without a filtering control
Segmentation to Reduce Scope
Segmentation is the primary technical lever for scope reduction. A properly segmented CDE means the corporate LAN workstations, development servers, and management systems are explicitly out of scope. The segmentation must be enforced by a firewall or equivalent filtering device — a Layer 2 VLAN without an ACL is not sufficient per PCI-DSS v4.0. The QSA will test that the boundary device actually blocks the traffic, not just logically separates it.
Segmentation Test Requirements
Requirement 11.4.5 (v4.0) mandates that network segmentation is tested at least every six months and after any significant change to the segmentation controls. This is effectively a penetration test scoped to the CDE boundary — the tester attempts to reach CDE systems from out-of-scope segments and must be unable to do so. Document the test methodology, tester qualifications, and results. A segmentation test finding is a critical finding — it means your scope assumption is wrong.
Requirement 1 — Network Security Controls
Requirement 1 is the most technically demanding for network engineers. It governs every firewall, router ACL, and network security control that touches the CDE boundary.
Core Mandates
- All inbound and outbound traffic to and from the CDE must be restricted to only what is necessary for the cardholder data environment
- A default-deny (implicit deny all) rule must be the last rule in every ruleset touching the CDE
- Stateful inspection is required — packet filtering ACLs alone are not sufficient for CDE boundaries
- No "any/any" permit rules anywhere in the CDE rulebase, and no rules with source "any" to a CDE destination without documented justification
- All rules must have a documented business justification, an owner, and a last-reviewed date
- Quarterly rule reviews are mandatory — document each review with date and reviewer name
- A DMZ must exist between internet-facing systems and the CDE — direct internet-to-CDE connectivity is prohibited regardless of encryption
Firewall Rule Documentation Table
Every rule on a CDE-boundary firewall must be documented. This is the table format used during audits:
Cisco ASA CDE Ruleset
# ASA interface zones for PCI CDE environment
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 203.0.113.1 255.255.255.0
interface GigabitEthernet0/1
nameif dmz
security-level 50
ip address 192.168.10.1 255.255.255.0
interface GigabitEthernet0/2
nameif cde
security-level 100
ip address 10.20.0.1 255.255.255.0
# Internet to DMZ — HTTPS and HTTP redirect only
access-list OUTSIDE_IN extended permit tcp any host 192.168.10.10 eq 443
access-list OUTSIDE_IN extended permit tcp any host 192.168.10.10 eq 80
access-list OUTSIDE_IN extended deny ip any any log
# DMZ to CDE — web LB to payment API only (specific source)
access-list DMZ_TO_CDE extended permit tcp host 192.168.10.10 host 10.20.0.10 eq 8443
access-list DMZ_TO_CDE extended deny ip any any log
# CDE outbound — payment server to card network only
access-list CDE_OUT extended permit tcp host 10.20.0.10 any eq 443
access-list CDE_OUT extended deny ip any any log
# Management access — jump host only, SSH only
access-list MGMT_TO_CDE extended permit tcp host 10.99.1.10 10.20.0.0 255.255.255.0 eq 22
access-list MGMT_TO_CDE extended deny ip any any log
# Apply to interfaces
access-group OUTSIDE_IN in interface outside
access-group DMZ_TO_CDE in interface dmz
access-group CDE_OUT in interface cde
Palo Alto Security Policy (Zone-Based)
# Palo Alto zone-based security rules — PCI CDE environment
# Rule 1: Internet to DMZ — customer web traffic
set rulebase security rules Internet-to-DMZ from internet
set rulebase security rules Internet-to-DMZ to dmz
set rulebase security rules Internet-to-DMZ destination [ web-lb ]
set rulebase security rules Internet-to-DMZ application [ ssl web-browsing ]
set rulebase security rules Internet-to-DMZ service application-default
set rulebase security rules Internet-to-DMZ action allow
set rulebase security rules Internet-to-DMZ log-end yes
# Rule 2: DMZ to CDE — application-specific, named service
set rulebase security rules DMZ-to-CDE from dmz
set rulebase security rules DMZ-to-CDE to cde
set rulebase security rules DMZ-to-CDE source [ web-lb ]
set rulebase security rules DMZ-to-CDE destination [ payment-server ]
set rulebase security rules DMZ-to-CDE application [ ssl ]
set rulebase security rules DMZ-to-CDE service svc-tcp8443
set rulebase security rules DMZ-to-CDE action allow
set rulebase security rules DMZ-to-CDE log-start yes
set rulebase security rules DMZ-to-CDE log-end yes
# Rule 3: Explicit deny-all with logging (PCI requirement)
set rulebase security rules Deny-All from any
set rulebase security rules Deny-All to any
set rulebase security rules Deny-All application any
set rulebase security rules Deny-All action deny
set rulebase security rules Deny-All log-end yes
Requirement 2 — Secure Configurations
Requirement 2 mandates that every system component in or connected to the CDE has a hardened configuration baseline. For network engineers this means routers, switches, firewalls, and wireless infrastructure.
Key Network Hardening Requirements
- Change all vendor default passwords before placing a device in the CDE environment
- Disable all unnecessary services: Telnet, HTTP management interface, SNMP v1/v2c with default community strings ("public", "private")
- Enable SSHv2 only — disable SSHv1 and Telnet
- Enable HTTPS for web management interfaces — disable HTTP
- Document a configuration baseline (golden config) per device type and deviation-track against it
- Maintain a network inventory listing every in-scope device, its role, and its location
IOS/IOS-XE Hardening Baseline
# PCI-compliant IOS hardening — apply to all in-scope routers/switches
# Disable insecure access methods
no service telnet
no ip http server
ip http secure-server
# SSH version 2 only
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3
# Encrypt all passwords in config
service password-encryption
enable secret 9 $9$hashedpassword
# AAA with TACACS+ (no local fallback in CDE context)
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
# Disable unneeded services
no ip finger
no ip bootp server
no service config
no cdp run
no ip source-route
# Console and VTY hardening
banner login ^
AUTHORIZED ACCESS ONLY. All sessions are logged and monitored.
Unauthorized access is a criminal offense.
^
line con 0
exec-timeout 5 0
login authentication default
line vty 0 15
exec-timeout 5 0
transport input ssh
login authentication default
access-class MGMT-ACCESS in
# SNMP v3 only — disable v1/v2c
no snmp-server community public
no snmp-server community private
snmp-server group PCI-GROUP v3 priv
snmp-server user pci-monitor PCI-GROUP v3 auth sha AuthPass priv aes 128 PrivPass
Requirement 4 — Encryption in Transit
Any cardholder data traversing a public network (internet, cellular, satellite) must be protected with strong cryptography. This is a hard requirement with no exceptions.
TLS Requirements
- TLS 1.2 minimum — TLS 1.0 and TLS 1.1 are explicitly prohibited by PCI-DSS v4.0
- TLS 1.3 is strongly recommended for new deployments
- Disable weak cipher suites: RC4, DES, 3DES (for new connections), MD5 for HMAC
- Certificate management: valid certificates, proper chain of trust, monitored for expiry (30-day advance alerting minimum)
- HSTS (HTTP Strict Transport Security) headers required on customer-facing web applications
Wireless Requirements
Only WPA2 or WPA3 are permitted in PCI-scoped environments. WEP is prohibited. WPA (TKIP) is prohibited. If wireless is in the CDE or connected to the CDE, it must use WPA2-Enterprise (802.1X with RADIUS) — WPA2-PSK is not acceptable for CDE-connected wireless as it does not provide per-user authentication.
IPsec for Site-to-Site CHD Transit
# IKEv2 IPsec tunnel for CHD transit between sites (PCI Req 4)
# Use AES-256 and SHA-256 minimum — no 3DES, no MD5
crypto ikev2 proposal PCI-IKEv2-PROP
encryption aes-cbc-256
integrity sha256
group 14
crypto ikev2 policy PCI-IKEv2-POL
proposal PCI-IKEv2-PROP
crypto ikev2 keyring PCI-KEYRING
peer SITE-B
address 203.0.113.50
pre-shared-key local PCI-SecureKey-2026!
pre-shared-key remote PCI-SecureKey-2026!
crypto ikev2 profile PCI-IKEv2-PROF
match identity remote address 203.0.113.50 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local PCI-KEYRING
crypto ipsec transform-set PCI-TS esp-aes 256 esp-sha256-hmac
mode tunnel
crypto ipsec profile PCI-IPSEC-PROF
set transform-set PCI-TS
set ikev2-profile PCI-IKEv2-PROF
# Apply to tunnel interface
interface Tunnel100
ip address 172.16.100.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.50
tunnel mode ipsec ipv4
tunnel protection ipsec profile PCI-IPSEC-PROF
Certificate Expiry Monitoring
# Check TLS certificate expiry on payment gateway (OpenSSL)
$ echo | openssl s_client -connect payment.example.com:443 2>/dev/null \
| openssl x509 -noout -dates
notBefore=Jan 1 00:00:00 2026 GMT
notAfter=Dec 31 23:59:59 2026 GMT
# Script to alert 30 days before expiry (add to cron)
$ EXPIRY=$(echo | openssl s_client -connect payment.example.com:443 2>/dev/null \
| openssl x509 -noout -enddate | cut -d= -f2)
$ DAYS=$(( ( $(date -d "$EXPIRY" +%s) - $(date +%s) ) / 86400 ))
$ [ $DAYS -lt 30 ] && echo "ALERT: Certificate expires in $DAYS days"
Requirements 7 and 8 — Access Control
Requirements 7 and 8 govern who can access CDE systems and how they must authenticate. For network engineers this means jump host architecture, TACACS+ privilege separation, and MFA enforcement.
Requirement 7 — Least Privilege
Every individual, system, and service account must have only the access required for their specific job function. On network devices this means:
- Read-only accounts for monitoring systems (SNMP, NMS polling)
- Operator-level access (privilege 7 or custom) for NOC staff — no configuration commands
- Admin-level access (privilege 15) only for senior engineers — audited via TACACS+ accounting
- No shared accounts — every login must be individually attributable to a person
- Service accounts for automation must have minimal privilege (no enable) and rotate passwords quarterly
Requirement 8 — Authentication
- MFA is mandatory for all non-console access to CDE systems and network devices in or connected to the CDE. A password alone does not satisfy Req 8 for remote access.
- Password complexity: minimum 12 characters, upper, lower, digit, special character
- Account lockout after 6 failed attempts, lockout duration minimum 30 minutes
- No account sharing — individual accounts for every user
- All access via jump host or bastion — no direct SSH from corporate workstations to CDE devices
TACACS+ Privilege Separation Configuration
# TACACS+ server configuration — Cisco ISE or TACACS+ daemon
tacacs server PCI-TACACS-PRIMARY
address ipv4 10.99.1.50
key 7 CiscoPCITacacsKey!
timeout 5
tacacs server PCI-TACACS-SECONDARY
address ipv4 10.99.1.51
key 7 CiscoPCITacacsKey!
timeout 5
aaa group server tacacs+ TACACS-SERVERS
server name PCI-TACACS-PRIMARY
server name PCI-TACACS-SECONDARY
# Authentication — TACACS+ with local fallback (console only)
aaa authentication login default group TACACS-SERVERS enable
aaa authentication login CONSOLE local
aaa authorization exec default group TACACS-SERVERS if-authenticated
aaa authorization commands 1 default group TACACS-SERVERS if-authenticated
aaa authorization commands 15 default group TACACS-SERVERS if-authenticated
aaa accounting exec default start-stop group TACACS-SERVERS
aaa accounting commands 1 default start-stop group TACACS-SERVERS
aaa accounting commands 15 default start-stop group TACACS-SERVERS
# Restrict VTY access to jump host only (Req 7 — least privilege)
ip access-list standard MGMT-ACCESS
permit host 10.99.1.10
deny any log
line vty 0 15
access-class MGMT-ACCESS in
transport input ssh
login authentication default
Privilege Level Separation on IOS
# Custom privilege levels for NOC (read-only) vs Admin (full)
privilege exec level 7 show running-config
privilege exec level 7 show interfaces
privilege exec level 7 show ip route
privilege exec level 7 show log
privilege exec level 7 ping
# NOC user — privilege 7 (show commands only)
username noc-user privilege 7 secret 9 $9$nochashedpassword
# Admin user — privilege 15 (full access, must use TACACS+)
# No local admin users on CDE devices except break-glass
username break-glass privilege 15 secret 9 $9$breakglasshash
Requirement 10 — Logging and Monitoring
Requirement 10 mandates comprehensive logging of all access to CDE systems and network infrastructure. Every login, every configuration change, every connection through a CDE firewall must be logged, timestamped, and retained.
Core Logging Requirements
- Log all user access to CDE systems and network devices
- Log all administrative actions (configuration changes, account creation, privilege escalation)
- Log all invalid logical access attempts (failed logins)
- Log all use of and changes to identification and authentication mechanisms
- Timestamps must be accurate — all devices synchronized to a trusted NTP source (stratum 2 or better)
- Log retention: 12 months total — the most recent 3 months must be immediately available online; months 4–12 can be archived but must be retrievable within 24 hours
- SIEM integration required for automated alerting and correlation
NTP Synchronization (Req 10.6)
# NTP configuration — synchronized to internal stratum 2 server
# Do not use public NTP (pool.ntp.org) for PCI devices — use internal
ntp authenticate
ntp authentication-key 1 md5 NTPAuthKey2026!
ntp trusted-key 1
ntp server 10.99.1.100 key 1 prefer
ntp server 10.99.1.101 key 1
ntp update-calendar
clock timezone UTC 0 0
# Verify NTP synchronization
Router# show ntp status
Clock is synchronized, stratum 3, reference is 10.99.1.100
nominal freq is 250.0000 Hz, actual freq is 250.0002 Hz, precision is 2**10
ntp uptime is 432000 (1/100 of seconds), resolution is 4000
reference time is EA2F5C00.00000000 (12:00:00.000 UTC Mar 13 2026)
# Verify NTP peers
Router# show ntp associations
address ref clock st when poll reach delay offset disp
*~10.99.1.100 192.168.1.1 2 22 64 377 0.824 0.073 0.110
+~10.99.1.101 192.168.1.1 2 18 64 377 0.931 0.089 0.118
Syslog Configuration
# Syslog to SIEM collector — all severity levels for CDE devices
logging host 10.99.2.100 transport udp port 514
logging host 10.99.2.101 transport tcp port 1468
logging trap informational
logging facility local6
logging source-interface Loopback0
logging buffered 65536 informational
logging on
# ASA syslog (more granular — log all firewall events)
logging enable
logging timestamp
logging host dmz 10.99.2.100
logging trap informational
logging class conn trap informational
logging class auth trap informational
logging class config trap informational
# Verify logging is active
Router# show logging
Syslog logging: enabled (11 messages dropped, 0 flushes, 0 overruns)
Console logging: level warnings, 42 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level informational, 1847 messages logged
Trap logging: level informational, 1849 message lines logged
Logging to 10.99.2.100 (udp port 514), 1849 messages logged
Requirement 11 — Security Testing
Requirement 11 mandates regular, structured security testing of the CDE environment. This is not optional or aspirational — it has specific timing requirements that QSAs verify with evidence.
Vulnerability Scanning
- External vulnerability scans must be performed quarterly by an Approved Scanning Vendor (ASV) — you cannot run these yourself. The ASV scan covers all internet-facing CDE systems. Passing scan results (no high or critical findings) must be retained.
- Internal vulnerability scans must be performed quarterly and after any significant change. These can be run by qualified internal staff using an approved tool (Nessus, Qualys, Rapid7). All medium and above findings must be remediated and rescanned to passing status.
- Change-triggered scans: any new CDE component, significant change to CDE topology, or new public-facing system requires a scan before going live.
Penetration Testing
An annual internal and external penetration test is required. The test must be performed by a qualified internal resource or qualified third party. The methodology must cover network layer and application layer. Findings must be remediated and the remediation must be verified.
Segmentation Testing (Req 11.4.5)
This is the test most network engineers need to understand deeply. The segmentation test must:
- Be performed at least every six months
- Be performed after any significant change to segmentation controls
- Verify that the CDE cannot be reached from out-of-scope systems
- Use methods sufficient to confirm isolation (attempting connections, not just checking firewall rules)
- Be documented with methodology, date, tester name, and results
Practically: the tester attempts nmap scans, port connections, and traceroutes from out-of-scope segments (corporate LAN, guest wireless, internet) toward CDE IP ranges. Every attempt must fail. If any attempt succeeds — even to an unexpected port — that is a finding.
Wireless Scanning
If wireless is present anywhere on the network — even if not intentionally in scope — quarterly wireless scans are required to detect rogue access points. Use a wireless IDS or periodic manual scanning with tools like Kismet or a similar protocol analyzer.
Zero Finding Strategy
Over three years of PCI-DSS compliance work as PCI-DSS Compliance Lead at Tech Mahindra, and continued enforcement for financial clients at Conduent, the pattern for zero audit findings is not complicated — it is consistent, documented execution of fundamentals. Here is what actually works.
1. Living Firewall Rule Justification Document
Every rule on every CDE-boundary device must have a row in a living document: rule ID, source, destination, port, action, business justification, rule owner (a person's name, not a team), and last-reviewed date. This document is not a one-time exercise — it is updated every time a rule changes and reviewed quarterly. When the QSA asks "why does this rule exist?" you hand them a document, not a verbal explanation. Verbal explanations produce follow-up questions. Documentation produces check marks.
2. Quarterly Rule Review Calendar
Block the quarterly reviews on the calendar at the start of the year. Q1 review in January, Q2 in April, Q3 in July, Q4 in October. Assign a reviewer and a reviewer backup. The review is a walk through the living rule document — confirm each rule still has a valid business need, confirm the owner is still the correct owner, confirm no out-of-date rules have accumulated. Export a dated screenshot of the firewall rulebase on the review date. This is your evidence.
3. Change Management Integration
All changes to CDE systems and network infrastructure must pass through a compliance review gate before implementation. The change request template includes: "Does this change affect the CDE? Does this change require a new firewall rule? Does this change require a new vulnerability scan?" If yes to any, the change is reviewed by the compliance lead before approval. Changes that bypass this gate create findings — without exception.
4. Configuration Baseline Templating
Create a golden configuration for each device type in scope: CDE access switch, CDE firewall, border router, jump host. The golden config contains all required hardening. New devices are provisioned from the golden config. Existing devices are compared against the golden config quarterly using a diff tool or configuration management system (Ansible, Oxidized). Any deviation from the golden config is a potential finding — catch and remediate deviations before the QSA does.
5. Pre-Audit Self-Assessment
Sixty days before the scheduled QSA visit, run an internal mock audit. Assign each PCI requirement to an internal team member. They must produce the same evidence the QSA will ask for. Where evidence is missing, incomplete, or undated — fix it before the QSA arrives. A finding discovered during the mock audit is an internal task. The same finding discovered by the QSA is an official finding that generates a remediation plan, a follow-up assessment, and potentially questions from leadership.
6. Evidence Collection System
Do not wait until audit time to collect evidence. Maintain a shared drive organized by PCI requirement number. For each control, maintain a dated screenshot or export. Examples: screenshot of NTP sync status exported monthly, firewall rule review sign-off form saved after each quarterly review, vulnerability scan reports saved immediately upon completion, TACACS+ accounting log exports saved monthly. When the QSA asks for evidence, the response is a folder path, not a scramble.
Audit Preparation Checklist
The differentiator between organizations with findings and organizations without is not technical complexity — it is operational discipline. The controls are not secret. The evidence requirements are published. The gap is always execution: rule reviews that slip past the quarter, log retention that was configured but never verified, NTP that drifted because someone changed the server IP without updating the device config. Build the calendar, assign the owners, and verify the evidence before the auditor does. That is how you achieve zero findings, not once, but consistently.