PCI DSS v4.0 Quick Start: 90-Day Implementation Roadmap for Teams Starting Fresh

What goes in scope: any system that stores, processes, or transmits PAN, SAD (full magnetic stripe, CVV, PIN), or cardholder name with expiry. Scope reduction options include tokenization (replace PAN with a token at the point of capture), P2PE (encrypt at terminal so the PAN never hits your systems), and hosted payment pages (iFrame or redirect to payment processor).

Scope mapping deliverable: a network diagram showing CDE boundaries, all in-scope systems, all connected systems, and all third-party service providers with system access. This diagram is a required artifact for any assessment.

Data flow diagram: document exactly where PAN enters your environment, where it goes, where it is stored, and where it exits. Every unique flow is a potential scope expansion.

Segmentation validation: confirm the CDE is network-isolated from out-of-scope systems using firewall rules, VLANs, or equivalent controls. Segmentation must be tested -- an untested segmentation claim is not accepted by QSAs.

Requirement 1 covers firewall controls: firewalls between the CDE and the internet, between the CDE and the internal corporate network, and deny-all with explicit permit rules. Ruleset reviews are required every 6 months.

Requirement 2 covers system hardening: no vendor default passwords on any in-scope system, unnecessary services disabled, and current security configuration standards applied. CIS Benchmarks are the most practical implementation guides for each OS and platform type.

Key deliverables: network diagram showing all firewall placement and approved rulesets; documented system configuration standards for each system type in the CDE; evidence of ruleset review. These are the first documents a QSA will request.

Requirement 3: Do not store SAD after authorization. Full track data, CVV, and PIN must never be retained. PAN storage requires strong encryption at rest.

Encryption options for PAN at rest: AES-256 is the standard choice. Key management is covered under Requirement 3.7 and requires documented key custodians, key rotation procedures, and secure key storage.

Requirement 4: Encrypt PAN in transit using TLS 1.2 or higher only. SSL, TLS 1.0, and TLS 1.1 are explicitly prohibited.

TLS verification command:

openssl s_client -connect [host]:443 2>/dev/null | grep -E "Protocol|Cipher"

Quick check for accidentally stored SAD in logs:

grep -r "[0-9]\{16\}" /var/log/

This is a crude first sweep -- false positives are common, but true positives are urgent findings.

Requirement 7: Need-to-know access to cardholder data. Role-based access control with documented roles and access justification for each role that can reach CDE systems.

Requirement 8: Unique IDs for all users. MFA is now required for all access into the CDE -- this is a significant v4.0 expansion from v3.2.1, which required MFA only for remote access.

MFA requirement scope: any user account with the ability to access CDE systems must authenticate with a second factor. This includes administrators, support staff, and any automated accounts with interactive logon capability.

Service accounts: fully inventoried, unique passwords per account, interactive logon disabled where possible. Generic or shared service accounts are a common finding.

Password policy requirements: 12 characters minimum, complexity requirements, 90-day maximum rotation (or equivalent compensating control documented and approved by QSA).

Requirement 10: Centralized logging for all CDE systems. Log retention: 12 months total, with 3 months immediately available for analysis. Logs must cover all user access, administrative actions, and security events.

Requirement 11 testing cadence:

• Internal vulnerability scans: quarterly and after every significant change
• External ASV scans: quarterly (ASV must be an approved vendor from the PCI SSC list)
• Penetration test: annually and after significant network changes

New in v4.0: Requirement 11.6.1 -- monitor payment page HTTP headers and scripts for unauthorized changes. Implement a change detection mechanism for all scripts running on payment pages.

Requirement 11.3.1 scoping note: document your definition of "significant change" in a written policy. Undocumented change criteria are a common finding during assessments.

Required policy documents for PCI compliance: information security policy, acceptable use policy, incident response plan, vulnerability management policy, and access control policy. Each must be reviewed and approved at least annually.

Incident response plan must be tested at least once per year. A tabletop exercise qualifies -- it does not require a live drill.

Third-party service providers: maintain a documented list of all providers with access to CHD or who could impact CDE security. Confirm their PCI compliance annually (Requirement 12.8). Get written acknowledgment of their responsibility for applicable controls.

Days 1-14: Scoping and data flow mapping. Engage a QSA early for scoping guidance -- many QSAs offer free pre-assessment calls. The cost of a scope mistake discovered during the assessment is far higher than an early consulting call.

Days 15-30: Close critical Requirement 1-4 gaps. Network segmentation validation, TLS 1.2+ enforcement everywhere, confirm no SAD stored post-authorization.

Days 31-45: Access control and MFA rollout (Requirements 7-8). Build the inventory of all accounts with CDE access. Enforce MFA for all of them.

Days 46-60: Logging infrastructure (Requirement 10). SIEM integration for all CDE systems. Verify log retention meets the 12-month / 3-month-available requirement.

Days 61-75: Run internal vulnerability scan. Schedule ASV external scan (ASV scans take time to schedule -- book early). Engage a penetration testing firm.

Days 76-90: Policy documentation complete. Third-party service provider list compiled and compliance confirmations in progress. Complete the SAQ or prepare the ROC package for QSA review.