PCI DSS v4.0 Compliance for Engineers — What Actually Changed and How to Implement It

The v4.0 Transition Timeline

If you're confused about the timeline, you're not alone. PCI SSC rolled this out in phases, and the dates matter because some requirements are already enforced while others have a grace period.

The key date most teams missed: March 31, 2025 was when the "future-dated" requirements became mandatory. These are the new requirements that PCI SSC gave everyone extra time to implement. If you haven't addressed them yet, you're technically non-compliant right now.

What v4.0 Actually Changed (The Engineer's Version)

The PCI SSC published a 360-page document with hundreds of changes. Most are clarifications or rewording. Here are the changes that actually require engineering work:

Area	v3.2.1	v4.0 Change
Authentication	MFA for admin access to CDE	MFA for ALL access to CDE, not just admin. Minimum 12-char passwords (was 7).
Encryption	TLS 1.1+ acceptable	TLS 1.2+ minimum. Inventory all cipher suites. No more "strong cryptography" hand-waving.
Vulnerability Scanning	Quarterly ASV scans	Authenticated internal scans required. Must manage all vulns, not just "high" and "critical."
Log Monitoring	Review logs daily	Automated log review mechanisms required. Manual-only review no longer sufficient.
Script Management	Not explicitly covered	New Req 6.4.3: Inventory and integrity-check all payment page scripts (anti-Magecart).
Risk Assessment	Annual risk assessment	Targeted risk analysis for each requirement where "periodically" is mentioned. You define the frequency and justify it.
Customized Approach	Compensating controls only	New "customized approach" — meet the security objective your own way, with documented evidence.

Network Segmentation That Actually Works

Network segmentation isn't a v4.0 requirement per se — it's been "strongly recommended" since forever. But in practice, every QSA I've worked with treats it as mandatory because without it, your entire network is in scope. And "entire network in scope" means every server, every workstation, every printer gets audited.

Here's the segmentation architecture that passed our last audit:

The critical rule: traffic between zones must pass through a firewall with explicit allow rules. No "allow all from corporate to CDE." Every connection needs a documented business justification. In practice, this means:

• Your payment API servers in the CDE only accept connections from the API gateway in the DMZ, on specific ports
• Your CI/CD pipeline can deploy to the CDE, but only from a hardened deployment server with MFA and audit logging
• Developer workstations never touch the CDE directly — all access goes through a jump box with session recording
• The CDE has no outbound internet access except to specific whitelisted endpoints (card network APIs, HSM vendors)

# Example: iptables rules for CDE ingress (simplified)
# Only allow API gateway to reach payment service
-A INPUT -s 10.1.0.0/24 -p tcp --dport 8443 -j ACCEPT
# Only allow deploy server for deployments
-A INPUT -s 10.2.0.50/32 -p tcp --dport 22 -j ACCEPT
# Only allow monitoring agent
-A INPUT -s 10.2.0.100/32 -p tcp --dport 9090 -j ACCEPT
# Drop everything else
-A INPUT -j DROP

Log Monitoring — Requirement 10 in Practice

Requirement 10 is where most engineering teams underestimate the work. v4.0 made it explicit: you need automated mechanisms to detect anomalies and suspicious activity. "We review logs manually every morning" doesn't cut it anymore.

What you need to log (at minimum):

• All access to cardholder data — reads, writes, deletes
• All authentication attempts — successful and failed
• All actions by privileged users (root, admin, DBA)
• All changes to audit log settings
• Creation and deletion of system-level objects
• All access to audit trails

Each log entry needs: user ID, event type, date/time, success/failure, origination (IP/hostname), and the identity or name of affected data/resource.

// Structured log entry for PCI compliance (Go)
type AuditEntry struct {
    Timestamp   time.Time `json:"ts"`
    UserID      string    `json:"user_id"`
    Action      string    `json:"action"`     // "read", "write", "delete", "auth_attempt"
    Resource    string    `json:"resource"`    // "card_token", "pan_lookup", "settlement_report"
    Result      string    `json:"result"`      // "success", "failure", "denied"
    SourceIP    string    `json:"source_ip"`
    SessionID   string    `json:"session_id"`
    Details     string    `json:"details"`     // additional context
}

For the automated detection piece, I've used two approaches that QSAs accepted:

1. ELK + ElastAlert: Ship logs to Elasticsearch, define alert rules in ElastAlert for patterns like "5+ failed auth attempts in 60 seconds" or "bulk data access outside business hours." Works well, but you own the infrastructure.
2. Cloud SIEM (Datadog Security, Splunk Cloud): More expensive, but the built-in PCI compliance dashboards save weeks of setup. Datadog's PCI compliance pack has pre-built detection rules mapped to specific PCI requirements.

The SAQ Decision — Which One Applies to You

Self-Assessment Questionnaires are how most companies validate PCI compliance. The right SAQ depends entirely on how card data flows through your system:

• SAQ A (~30 questions) — All card processing is fully outsourced. You use a hosted payment page (Stripe Checkout, Adyen Drop-in). Card data never touches your systems. This is the goal.
• SAQ A-EP (~190 questions) — You use client-side tokenization (Stripe Elements, Braintree Hosted Fields). Card data hits the user's browser on your domain but never your server. More work than SAQ A because your website can still be compromised to intercept card data.
• SAQ D (~330 requirements) — Card data touches your servers. Full audit scope. You need this if you store, process, or transmit cardholder data directly. Avoid if at all possible.

Five Things That Fail Audits

After going through two QSA audits and helping a third team prepare for theirs, these are the issues I see repeatedly:

1. Stale firewall rules. You added a temporary rule six months ago for a migration and forgot to remove it. QSAs check every rule against your documentation. Run a quarterly firewall rule review — put it in your calendar.
2. Missing evidence of log review. You have logs, you have alerts, but you can't prove anyone looked at them. The QSA wants timestamped evidence that a human acknowledged and investigated alerts. Automate this with ticket creation.
3. Default credentials on internal tools. That Grafana instance running on default admin/admin in your monitoring subnet? It's in scope if it can reach the CDE. Scan for default credentials quarterly.
4. Incomplete asset inventory. v4.0 requires a complete inventory of all system components in scope. That test server someone spun up and forgot about? If it's in the CDE network, it needs to be inventoried, patched, and hardened.
5. No documented change management for payment pages. Requirement 6.4.3 means every change to your payment page — including updating a JavaScript dependency — needs to go through a documented approval process with integrity verification.

Getting Started

If you're starting from scratch, here's the order I'd tackle things:

1. Determine your SAQ type — this defines your scope
2. Draw your network diagram and identify your CDE boundary
3. Implement network segmentation if you haven't already
4. Set up centralized logging with automated alerting
5. Inventory all payment page scripts (Req 6.4.3)
6. Upgrade all authentication to MFA with 12+ char passwords
7. Document everything — policies, procedures, evidence

PCI compliance is tedious, but it's not mysterious. The standard is prescriptive — it tells you exactly what to do. The engineering challenge is implementing it without slowing down your development velocity. Automate the evidence collection, bake security checks into your CI/CD pipeline, and treat compliance requirements like any other engineering requirement: write tests for them.

References

• PCI Security Standards Council — Document Library (PCI DSS v4.0)
• PCI SSC Blog — PCI DSS v4.0 Resource Hub
• PCI DSS v4.0 Standard (PDF)
• PCI SSC — Approved Scanning Vendors (ASV) List
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls

Disclaimer: This article reflects the author's personal experience and opinions. It is not legal or compliance advice. PCI DSS requirements vary by merchant level, acquirer, and card brand. Always consult with a Qualified Security Assessor (QSA) and your acquiring bank for definitive compliance guidance. Product names and brands are property of their respective owners.