bmad-plus 0.7.4 → 0.8.0

package/src/bmad-plus/packs/pack-shield/references/pci-compliance/pci-dss-requirements.md

@@ -1,366 +1,366 @@
-# PCI DSS v4.0.1 — All 12 Requirements
-
-Source: PCI DSS v4.0.1 (PCI Security Standards Council, June 2024)
-https://www.pcisecuritystandards.org/document_library/
-
----
-
-## GOAL 1: Build and Maintain a Secure Network and Systems
-
-### Requirement 1 — Install and Maintain Network Security Controls
-
-Network security controls (NSCs) — firewalls, routers, cloud security groups — prevent unauthorised network access to and from the CDE.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 1.1 | NSC policies and procedures are defined, implemented, and maintained | Policy docs, network diagrams, change records |
-| 1.2 | NSC configurations restrict traffic to only what is necessary | Firewall/router ruleset review, deny-all default |
-| 1.2.1 | Configuration standards for NSCs are defined | Documented baseline standards |
-| 1.2.2 | NSC configuration changes are managed via change control | Change tickets, approval records |
-| 1.2.3 | Network diagrams are current and accurate | Dated network diagram showing CDE boundaries |
-| 1.2.4 | Data-flow diagrams for all account data flows are current | Data flow diagrams (DFDs) |
-| 1.2.5 | All allowed services/ports are documented with business justification | Firewall rule documentation |
-| 1.2.6 | Security features for each service are documented and implemented | Config baselines per service |
-| 1.2.7 | NSC configurations are reviewed at least every 6 months | Review records with dates and approvers |
-| 1.3 | Inbound and outbound network traffic is restricted to only that necessary | Egress filtering, deny-all-else rules |
-| 1.3.1 | Inbound traffic to CDE restricted to authorised sources and services | Firewall rules reviewed |
-| 1.3.2 | Outbound traffic from CDE restricted to authorised destinations | Egress rules documented |
-| 1.3.3 | NSCs installed between wireless networks and CDE | Wireless-to-CDE firewall rules |
-| 1.4 | Network connections between trusted and untrusted networks controlled | DMZ architecture, traffic inspection |
-| 1.4.1 | NSCs between trusted/untrusted networks inspect and filter traffic | Stateful inspection, IDS/IPS |
-| 1.4.2 | Inbound traffic from untrusted networks: no direct routes to CDE | No direct routing; proxy/DMZ required |
-| 1.4.3 | Anti-spoofing measures to detect and block forged source IP addresses | Anti-spoofing ACLs, RFC 3704 filtering |
-| 1.4.4 | Unauthorised traffic (cardholder data) blocked from entering untrusted networks | DLP rules or network controls |
-| 1.4.5 | Internal IP addresses not disclosed to unauthorised parties | NAT, private RFC 1918 space |
-| 1.5 | Risks from device connectivity to untrusted networks are managed | Endpoint security controls |
-| 1.5.1 | Security controls for devices connecting to both untrusted and trusted networks | MDM/endpoint policy, split tunnelling controls |
-
-**Common gaps**: Stale firewall rules never reviewed; no egress filtering; flat network (no CDE isolation); wireless networks not separated from CDE.
-
----
-
-### Requirement 2 — Apply Secure Configurations to All System Components
-
-Default credentials and unnecessary services must be eliminated before deployment.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 2.1 | Processes for managing vendor defaults and other security parameters | Hardening policy, config standards |
-| 2.2 | System configuration standards are developed and implemented | CIS Benchmark or equivalent; per platform standard |
-| 2.2.1 | System configuration standards address all known security vulnerabilities | Vuln scan results mapped to standards |
-| 2.2.2 | Vendor default accounts managed before deploying systems | Default creds disabled/renamed; evidence of removal |
-| 2.2.3 | Primary functions needing different security levels are on separate components | Server isolation, role separation |
-| 2.2.4 | Only necessary functions, ports, protocols, and services are enabled | Port scan results; services audit |
-| 2.2.5 | If insecure protocols are used, business justification and additional controls documented | Protocol exception log |
-| 2.2.6 | System security parameters are configured to prevent misuse | Config hardening evidence |
-| 2.2.7 | All non-console administrative access is encrypted | SSH, HTTPS, TLS for all admin access |
-| 2.3 | Wireless environments are configured and managed securely | Wi-Fi config review, WPA3 or WPA2-Enterprise |
-| 2.3.1 | Default wireless vendor defaults changed at installation | AP config records |
-| 2.3.2 | Wireless encryption keys changed when anyone with key knowledge leaves | Key rotation procedure and evidence |
-
-**Common gaps**: Vendor default passwords left unchanged; unnecessary services (Telnet, FTP) still enabled; no documented hardening standards.
-
----
-
-## GOAL 2: Protect Account Data
-
-### Requirement 3 — Protect Stored Account Data
-
-Minimise storage of account data; never store SAD post-authorisation; protect PAN wherever stored.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 3.1 | Processes for protecting stored account data are defined and implemented | Data retention policy |
-| 3.2 | Account data storage minimised | Data retention schedules; deletion procedures |
-| 3.2.1 | SAD not retained after authorisation | Scan results proving no SAD in storage; code review |
-| 3.3 | SAD is not retained after authorisation | Confirmed by system scans and application review |
-| 3.3.1 | SAD not stored (full magnetic stripe, CAV2/CVV2/CVC2/CID, PIN/PIN block) | Application code review; database scans |
-| 3.3.2 | SAD stored prior to authorisation is encrypted | Encryption evidence for pre-auth data |
-| 3.3.3 | Encryption keys for pre-auth SAD are managed securely | Key management docs |
-| 3.4 | PAN is protected wherever it is stored | Encryption, masking, or tokenisation evidence |
-| 3.4.1 | PAN is unreadable anywhere it is stored | AES-256 encryption; tokenisation proof; masking |
-| 3.4.2 | Copies of PAN only on authorised removable media | Media inventory and controls |
-| 3.5 | PAN is secured with strong cryptography | Encryption algorithm and key management review |
-| 3.5.1 | Primary account numbers protected with strong cryptography | AES-256 or equivalent; no DES/RC4 |
-| 3.6 | Cryptographic keys used for PAN encryption are secured | Key management policy and procedures |
-| 3.6.1 | Key management procedures and processes for cryptographic keys | Key custodian assignments; split knowledge |
-| 3.7 | Key management procedures and processes are implemented | Key rotation, key-encrypting keys, key retirement |
-| 3.7.1 | Key management policies cover the full key lifecycle | Generated, distributed, stored, retired |
-| 3.7.2 | Key storage is secure | HSM, encrypted key store |
-| 3.7.3 | Key access restricted to fewest custodians necessary | Dual control; split knowledge |
-| 3.7.4 | Key retirement/replacement policy documented and followed | Rotation records |
-| 3.7.5 | Key compromises managed per documented procedure | Incident response for key compromise |
-| 3.7.6 | Manual keys use split knowledge and dual control | Evidence of two-person key operations |
-| 3.7.7 | Informal key substitution prevented | Formal key management only |
-| 3.7.8 | Key custodians acknowledge their responsibilities | Signed custodian agreements |
-| 3.7.9 | Where key management services are used, they meet Req 3.6–3.7 | CSP KMS compliance evidence |
-
-**Common gaps**: CVV stored in database; PAN in log files; no key rotation; encryption with weak algorithms (MD5, SHA-1 for integrity); keys stored alongside encrypted data.
-
----
-
-### Requirement 4 — Protect Cardholder Data with Strong Cryptography During Transmission
-
-PAN transmitted over open, public networks must be encrypted using strong cryptography.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 4.1 | Processes for protecting PAN in transit are defined and implemented | Cryptography policy |
-| 4.2 | PAN protected during transmission over open, public networks | TLS 1.2+ config; certificate review |
-| 4.2.1 | Strong cryptography used to safeguard PAN in transit | TLS 1.2 or 1.3; no SSL, TLS 1.0, 1.1 |
-| 4.2.1.1 | Certificate inventory maintained | Certificate management tool or inventory |
-| 4.2.1.2 | Wireless networks transmitting PAN use strong cryptography | Wi-Fi encryption: WPA2-Enterprise or WPA3 |
-| 4.2.2 | PAN not sent by unprotected end-user messaging (email, chat) | DLP policy; email encryption controls |
-
-**Common gaps**: Legacy TLS 1.0/1.1 still enabled; expired SSL certificates; PAN sent via plain email; no certificate inventory.
-
----
-
-## GOAL 3: Maintain a Vulnerability Management Program
-
-### Requirement 5 — Protect All Systems and Networks from Malicious Software
-
-Anti-malware controls protect against viruses, ransomware, spyware, and other threats.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 5.1 | Processes for malware protection are defined | Anti-malware policy |
-| 5.2 | Anti-malware solution(s) deployed on all applicable components | AV deployment inventory; management console |
-| 5.2.1 | Anti-malware solution deployed on all components subject to malware | Coverage report; exceptions documented |
-| 5.2.2 | Anti-malware solution detects all known types of malware | Vendor capability matrix |
-| 5.2.3 | Systems not commonly affected by malware are evaluated periodically | Periodic risk analysis; documented exceptions |
-| 5.3 | Anti-malware solution maintained and monitored | Definition update logs; scan results |
-| 5.3.1 | Anti-malware solution kept current | Auto-update policy; current definition proof |
-| 5.3.2 | Anti-malware performs periodic scans and active/real-time scanning | Scan schedule; real-time protection enabled |
-| 5.3.3 | Anti-malware solution for removable media | USB scanning policy; endpoint config |
-| 5.3.4 | Anti-malware solution logs maintained and monitored | Log retention; SIEM integration |
-| 5.3.5 | Anti-malware mechanisms cannot be disabled by users | Admin-only uninstall; tamper protection enabled |
-| 5.4 | Anti-phishing mechanisms protect users (**NEW in v4.0**) | Anti-phishing filter; email gateway config |
-| 5.4.1 | Automated technical solution detects and protects against phishing | Email security gateway; URL filtering; DMARC/DKIM/SPF |
-
-**Common gaps**: AV not covering Linux/Unix systems; definitions not auto-updated; users can disable AV; no phishing protections (new v4.0 requirement).
-
----
-
-### Requirement 6 — Develop and Maintain Secure Systems and Software
-
-Vulnerabilities must be identified and addressed through patching and secure development practices.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 6.1 | Security vulnerability identification and management processes defined | Vuln management policy |
-| 6.2 | Bespoke and custom software is developed securely | SDLC policy; code review process |
-| 6.2.1 | Bespoke software developed based on secure coding guidelines | Coding standards; training records |
-| 6.2.2 | Software development personnel trained on secure coding techniques | Annual training records |
-| 6.2.3 | Code review performed before production release | Code review records; SAST scan results |
-| 6.2.4 | Software engineering techniques to prevent common vulnerabilities | OWASP Top 10 addressed; DAST results |
-| 6.3 | Security vulnerabilities identified and addressed | Patch management policy |
-| 6.3.1 | Security vulnerabilities managed using ranking | CVSS or internal risk ranking; patch SLAs |
-| 6.3.2 | Inventory of bespoke and custom software maintained | Software inventory/SBOM |
-| 6.3.3 | All system components protected from known vulnerabilities | Patch management; current patch evidence |
-| 6.4 | Public-facing web applications protected from attacks | WAF or application review |
-| 6.4.1 | Public-facing web apps protected against web-based attacks | WAF in blocking mode; annual app testing |
-| 6.4.2 | Automated technical solution deployed for public-facing web apps | WAF config; active monitoring |
-| 6.4.3 | All payment page scripts managed and authorised (**NEW v4.0**) | Script inventory; integrity controls |
-| 6.5 | Changes to system components managed securely | Change management policy |
-| 6.5.1 | Changes to system components via formal change control | Change tickets; approval evidence |
-| 6.5.2 | Post-change security verification | Test results; UAT sign-off |
-| 6.5.3 | Pre-production environments are separate from production | Environment separation proof |
-| 6.5.4 | Roles and functions are separated between production and pre-production | Access control evidence |
-| 6.5.5 | Live PANs not used in pre-production/testing | Anonymised test data confirmation |
-| 6.5.6 | Test data/accounts removed before production | Pre-prod cleanup checklist |
-
-**Common gaps**: No SDLC/secure coding policy; live PANs in test environments; WAF in detection-only mode; payment page scripts not inventoried (v4.0 new).
-
----
-
-## GOAL 4: Implement Strong Access Control Measures
-
-### Requirement 7 — Restrict Access to System Components and Cardholder Data by Business Need to Know
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 7.1 | Access control processes and procedures defined | Access control policy |
-| 7.2 | Access to system components and cardholder data is restricted | Role-based access matrix; IAM configuration |
-| 7.2.1 | All users have access based on least privilege and need-to-know | Access review results |
-| 7.2.2 | Access assigned based on job classification and function | Role definitions; access request records |
-| 7.2.3 | Privilege access approved by authorised personnel | Approval workflow records |
-| 7.2.4 | User accounts and access privileges reviewed at least every 6 months | Access review logs with dates |
-| 7.2.5 | Application/system accounts managed by policy | Service account inventory; access controls |
-| 7.2.6 | Query access to CHD repositories restricted to defined applications | DB access controls; application-level auth |
-| 7.3 | Access to system components and data is managed | IAM system; access control enforcement |
-| 7.3.1 | Access control system in place to restrict access to CDE | IAM/PAM tool deployment evidence |
-| 7.3.2 | Access control system configured to enforce least privilege | ACL review; deny-by-default configuration |
-| 7.3.3 | Access control system is kept current | Review and update cycle evidence |
-
-**Common gaps**: Shared accounts; no access recertification; over-privileged service accounts; no need-to-know principle enforced for database access.
-
----
-
-### Requirement 8 — Identify Users and Authenticate Access to System Components
-
-Every user must have a unique ID; strong authentication required for CDE access.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 8.1 | User identification and authentication processes defined | Authentication policy |
-| 8.2 | User IDs and authentication credentials managed | IAM system; unique account verification |
-| 8.2.1 | All users have a unique ID | Account audit; no shared accounts |
-| 8.2.2 | Group, shared, or generic accounts managed only in exceptional circumstances | Exceptions with justification documented |
-| 8.2.3 | Additional authentication for accounts used by third parties/vendors | MFA for vendor access |
-| 8.2.4 | User accounts added/modified/deleted only through formal process | Identity lifecycle management records |
-| 8.2.5 | Access for terminated users is immediately revoked | Offboarding checklist; IAM de-provisioning evidence |
-| 8.2.6 | Inactive accounts disabled within 90 days | Account review; automated disable policy |
-| 8.2.7 | Accounts used for system/application functions managed appropriately | Service account policy compliance |
-| 8.2.8 | Sessions inactive more than 15 minutes require re-authentication | Session timeout config |
-| 8.3 | Strong authentication established and managed | MFA configuration evidence |
-| 8.3.1 | All user access into CDE uses MFA (**Extended in v4.0**) | MFA deployment proof for ALL CDE access |
-| 8.3.2 | MFA for all access into the CDE from outside | Remote access MFA (VPN, RDP, etc.) |
-| 8.3.4 | Invalid authentication attempts limited | Account lockout policy (max 10 attempts) |
-| 8.3.5 | Passwords/passphrases set to meet minimum requirements | Password policy config: min 12 chars, complexity |
-| 8.3.6 | Passwords changed every 90 days (or with compensating control/risk analysis) | Password policy; expiry settings |
-| 8.3.7 | Individuals not allowed to submit new password same as any of last 4 | Password history settings |
-| 8.3.8 | Authentication policies communicated to users | Training records; policy acknowledgements |
-| 8.3.9 | Passwords for users not using MFA changed at least every 90 days | Password expiry config |
-| 8.3.10 | Guidance for changing passwords provided to users at specified intervals | Comms records |
-| 8.4 | MFA implemented for all access into the CDE | MFA for all privileged and standard user access |
-| 8.4.1 | MFA for all non-console admin access to CDE | Admin MFA config |
-| 8.4.2 | MFA for all access into the CDE (**Key new v4.0 change**) | MFA required for everyone accessing CDE |
-| 8.5 | MFA systems configured to prevent misuse | Anti-MFA-bypass controls |
-| 8.6 | Use of application/system accounts managed | Automated or manual interactive use controls |
-
-**Common gaps**: Shared admin accounts; weak passwords (< 12 chars); no MFA for all CDE access (key v4.0 gap); accounts not disabled within 90 days of inactivity; no session timeout.
-
----
-
-### Requirement 9 — Restrict Physical Access to Cardholder Data
-
-Physical controls prevent unauthorised access to systems, media, and facilities in the CDE.
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 9.1 | Processes for restricting physical access defined | Physical security policy |
-| 9.2 | Physical access controls for appropriate facility entry | Badge access logs; visitor records |
-| 9.2.1 | Individual physical access controls to sensitive areas | Badge reader logs; CCTV |
-| 9.2.2 | Visitor management procedure implemented | Visitor log; escort policy |
-| 9.2.3 | Physical access to wireless access points, gateways, and handheld devices controlled | Device location inventory; lock-down evidence |
-| 9.2.4 | Physical access to CDE systems via publicly accessible network jacks controlled | Port lock-out; network access control |
-| 9.3 | Physical access for personnel and visitors authorised and managed | Access management records |
-| 9.3.1 | Physical access controls for personnel with physical access | Access list; revocation process |
-| 9.3.2 | Physical access for visitors authorised and revoked | Visitor badge records |
-| 9.4 | Media with cardholder data is securely stored, accessed, distributed, and destroyed | Media inventory; destruction records |
-| 9.4.1 | Physical media containing CHD secured | Locked storage; media inventory |
-| 9.4.2 | Physical media containing CHD classified | Classification labels on media |
-| 9.4.3 | Physical media distributed externally via tracked courier or secure methods | Courier receipts; chain of custody |
-| 9.4.4 | Management approval for all media moved outside facility | Approval records |
-| 9.4.5 | External media inventory controlled and audited | Media audit logs |
-| 9.4.6 | Hard-copy materials with CHD destroyed cross-cut or confetti-shred | Destruction vendor certificates |
-| 9.4.7 | Electronic media destroyed or rendered unrecoverable when no longer needed | Secure wipe / degauss / physical destroy records |
-| 9.5 | Point-of-interaction (POI) devices protected from tampering and skimming | POI device inspection programme |
-| 9.5.1 | POI device surface inspected to detect tampering or substitution | Inspection schedule; checklist records |
-
-**Common gaps**: No visitor log; POI devices not regularly inspected; media not tracked or destroyed per policy; physical access not revoked for terminated staff.
-
----
-
-## GOAL 5: Regularly Monitor and Test Networks
-
-### Requirement 10 — Log and Monitor All Access to System Components and Cardholder Data
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 10.1 | Audit log processes defined | Log management policy |
-| 10.2 | Audit logs implemented to support detection of anomalies | SIEM or log management platform |
-| 10.2.1 | Audit logs capture all individual user access to CHD | Log samples showing user activity |
-| 10.2.2 | Audit logs capture all actions by root or admin | Privileged access logs |
-| 10.2.3 | Audit logs capture all access to audit logs | Audit-of-audit trail |
-| 10.2.4 | Audit logs capture invalid logical access attempts | Failed login logs |
-| 10.2.5 | Audit logs capture use of identification and authentication mechanisms | Auth logs; MFA event logs |
-| 10.2.6 | Audit logs capture initialisation, stopping, or pausing of logs | Log service event logs |
-| 10.2.7 | Audit logs capture creation/deletion of system-level objects | System event logs |
-| 10.3 | Audit logs are protected from destruction and modification | Log integrity controls; write-once storage |
-| 10.3.1 | Log files protected to prevent modifications | Immutable log storage; SIEM ingestion |
-| 10.3.2 | Audit log files protected from unauthorised access | Access controls on log infrastructure |
-| 10.3.3 | Audit logs are promptly backed up to a central log server | Syslog/SIEM centralisation evidence |
-| 10.3.4 | File integrity monitoring or change detection on audit logs | FIM solution monitoring log files |
-| 10.4 | Audit logs reviewed to identify anomalies or suspicious activity | Log review process |
-| 10.4.1 | Automated log review mechanisms used (**NEW in v4.0**) | SIEM alert rules; automated review evidence |
-| 10.4.2 | Logs for all system components reviewed daily | Review schedules; SIEM alert evidence |
-| 10.4.3 | Exceptions and anomalies addressed promptly | Ticket records tied to log alerts |
-| 10.5 | Audit log history retained for at least 12 months with last 3 months immediately available | Retention policy; log storage capacity |
-| 10.6 | Time synchronisation technology in use | NTP configuration; stratum 1/2 sync |
-| 10.7 | Failures of critical security controls detected and addressed (**NEW in v4.0**) | Monitoring for AV, FW, IDS failures |
-| 10.7.2 | Failures detected and responded to promptly | Alert/ticketing evidence |
-
-**Common gaps**: Logs not centralised to SIEM; retention under 12 months; no automated review (v4.0 new); time not synchronised across all CDE components; critical security control failures not monitored.
-
----
-
-### Requirement 11 — Test Security of Systems and Networks Regularly
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 11.1 | Security testing processes defined | Testing policy |
-| 11.2 | Wireless access points managed | Wireless AP inventory; rogue AP detection |
-| 11.2.1 | Authorised and unauthorised wireless access points managed | Quarterly wireless scans; rogue detection alerts |
-| 11.2.2 | Wireless scan inventory reconciled quarterly | Scan results vs inventory |
-| 11.3 | External and internal vulnerabilities assessed | Vulnerability scanning programme |
-| 11.3.1 | Internal vulnerability scans run at least every 3 months | Scan reports showing quarterly cadence |
-| 11.3.2 | External vulnerability scans run at least every 3 months by an ASV | ASV scan reports; passing results |
-| 11.3.3 | All exploitable vulnerabilities remediated and re-scanned | Remediation evidence; re-scan passing results |
-| 11.4 | External and internal penetration testing is performed | Penetration test reports |
-| 11.4.1 | Penetration testing methodology defined | Pen test scope document |
-| 11.4.2 | Internal penetration testing at least annually and after changes | Annual pen test report |
-| 11.4.3 | External penetration testing at least annually and after changes | External pen test report |
-| 11.4.4 | Exploitable vulnerabilities from pen testing remediated and re-tested | Remediation tracking; re-test confirmation |
-| 11.4.5 | Network segmentation verified by penetration testing at least every 6 months | Segmentation pen test report |
-| 11.5 | Network intrusion detection/prevention techniques used | IDS/IPS deployment evidence |
-| 11.5.1 | Intrusion detection/prevention used to detect and/or prevent intrusions | IDS/IPS alert logs; tuning records |
-| 11.5.2 | Change detection mechanism deployed on CDE | FIM solution alerts; change records |
-| 11.6 | Unauthorised changes on payment pages detected and responded to (**NEW v4.0**) | Script integrity monitoring |
-| 11.6.1 | Change and tamper detection mechanism for payment pages deployed | HTTP header monitoring; script hash verification |
-
-**Common gaps**: ASV scans failing (not "clean"); penetration testing not truly internal + external; segmentation not tested; no FIM; payment page integrity not monitored (v4.0 new).
-
----
-
-## GOAL 6: Maintain an Information Security Policy
-
-### Requirement 12 — Support Information Security with Organizational Policies and Programs
-
-| Sub-Req | Description | Evidence for QSA |
-|---------|-------------|-----------------|
-| 12.1 | Comprehensive information security policy defined, published, and maintained | Security policy doc; annual review |
-| 12.2 | Targeted risk analysis process defined for flexible requirements | TRA template; completed TRAs |
-| 12.3 | Risks to CHD and cardholder data environment managed | Risk management programme |
-| 12.3.1 | Targeted risk analysis for each PCI DSS requirement with customised approach | TRA documentation per requirement |
-| 12.3.2 | TRA performed for flexible-frequency requirements | Documented TRAs for each flexible req |
-| 12.3.3 | Cryptographic cipher suites and protocols reviewed and documented at least once every 12 months | Crypto inventory; annual review records |
-| 12.3.4 | Hardware and software technologies reviewed at least once every 12 months | Tech lifecycle review records |
-| 12.4 | PCI DSS compliance managed throughout the year | Compliance programme; quarterly review |
-| 12.4.2 | Reviews confirming personnel follow security policies performed at least quarterly | Quarterly compliance review records |
-| 12.5 | PCI DSS scope documented and validated | Scope documentation; annual review |
-| 12.5.1 | Inventory of system components in scope for PCI DSS maintained | CDE system inventory |
-| 12.5.2 | PCI DSS scope verified at least every 12 months and after major changes | Annual scope review; post-change assessment |
-| 12.6 | Security awareness education implemented | Security awareness programme; training records |
-| 12.6.1 | Security awareness programme in place | Programme documentation |
-| 12.6.2 | Security awareness programme reviewed at least every 12 months | Review records |
-| 12.6.3 | Personnel acknowledge at least annually they have read and understood security policy | Signed acknowledgements |
-| 12.7 | Personnel are screened before granting access to CDE | Background check policy; records |
-| 12.8 | Third-party service providers (TPSPs) with CHD access are managed | TPSP inventory; compliance monitoring |
-| 12.8.1 | List of all TPSPs maintained | TPSP register |
-| 12.8.2 | Written agreements with TPSPs acknowledging PCI DSS responsibility | Signed agreements |
-| 12.8.3 | Established process for engaging TPSPs | TPSP due diligence process |
-| 12.8.4 | TPSP PCI DSS compliance status monitored at least annually | Annual TPSP compliance confirmation; AOC |
-| 12.8.5 | Information about which PCI DSS requirements managed by each TPSP | Responsibility matrix |
-| 12.9 | TPSPs support customers' PCI DSS compliance | TPSP acknowledgement of responsibility |
-| 12.10 | Suspected and confirmed security incidents responded to immediately | Incident response plan; test records |
-| 12.10.1 | Incident response plan created and ready | Documented IR plan |
-| 12.10.2 | IR plan reviewed and tested at least annually | Annual tabletop or drill evidence |
-| 12.10.3 | Specific personnel designated for 24/7 incident response | On-call roster; contact list |
-| 12.10.4 | IR personnel trained appropriately | Annual training records |
-| 12.10.5 | Alerts from security monitoring systems included in IR plan | IR plan references monitoring alerts |
-| 12.10.6 | IR plan updated when new threats or lessons learned | Version history; update records |
-| 12.10.7 | Incident response procedures for discovery of stored PAN in unexpected location | PAN discovery procedure |
-
-**Common gaps**: Security policy not reviewed annually; no TPSP register or compliance monitoring; incident response plan never tested; personnel not acknowledging policy; no TRA process.
+# PCI DSS v4.0.1 — All 12 Requirements
+
+Source: PCI DSS v4.0.1 (PCI Security Standards Council, June 2024)
+https://www.pcisecuritystandards.org/document_library/
+
+---
+
+## GOAL 1: Build and Maintain a Secure Network and Systems
+
+### Requirement 1 — Install and Maintain Network Security Controls
+
+Network security controls (NSCs) — firewalls, routers, cloud security groups — prevent unauthorised network access to and from the CDE.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 1.1 | NSC policies and procedures are defined, implemented, and maintained | Policy docs, network diagrams, change records |
+| 1.2 | NSC configurations restrict traffic to only what is necessary | Firewall/router ruleset review, deny-all default |
+| 1.2.1 | Configuration standards for NSCs are defined | Documented baseline standards |
+| 1.2.2 | NSC configuration changes are managed via change control | Change tickets, approval records |
+| 1.2.3 | Network diagrams are current and accurate | Dated network diagram showing CDE boundaries |
+| 1.2.4 | Data-flow diagrams for all account data flows are current | Data flow diagrams (DFDs) |
+| 1.2.5 | All allowed services/ports are documented with business justification | Firewall rule documentation |
+| 1.2.6 | Security features for each service are documented and implemented | Config baselines per service |
+| 1.2.7 | NSC configurations are reviewed at least every 6 months | Review records with dates and approvers |
+| 1.3 | Inbound and outbound network traffic is restricted to only that necessary | Egress filtering, deny-all-else rules |
+| 1.3.1 | Inbound traffic to CDE restricted to authorised sources and services | Firewall rules reviewed |
+| 1.3.2 | Outbound traffic from CDE restricted to authorised destinations | Egress rules documented |
+| 1.3.3 | NSCs installed between wireless networks and CDE | Wireless-to-CDE firewall rules |
+| 1.4 | Network connections between trusted and untrusted networks controlled | DMZ architecture, traffic inspection |
+| 1.4.1 | NSCs between trusted/untrusted networks inspect and filter traffic | Stateful inspection, IDS/IPS |
+| 1.4.2 | Inbound traffic from untrusted networks: no direct routes to CDE | No direct routing; proxy/DMZ required |
+| 1.4.3 | Anti-spoofing measures to detect and block forged source IP addresses | Anti-spoofing ACLs, RFC 3704 filtering |
+| 1.4.4 | Unauthorised traffic (cardholder data) blocked from entering untrusted networks | DLP rules or network controls |
+| 1.4.5 | Internal IP addresses not disclosed to unauthorised parties | NAT, private RFC 1918 space |
+| 1.5 | Risks from device connectivity to untrusted networks are managed | Endpoint security controls |
+| 1.5.1 | Security controls for devices connecting to both untrusted and trusted networks | MDM/endpoint policy, split tunnelling controls |
+
+**Common gaps**: Stale firewall rules never reviewed; no egress filtering; flat network (no CDE isolation); wireless networks not separated from CDE.
+
+---
+
+### Requirement 2 — Apply Secure Configurations to All System Components
+
+Default credentials and unnecessary services must be eliminated before deployment.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 2.1 | Processes for managing vendor defaults and other security parameters | Hardening policy, config standards |
+| 2.2 | System configuration standards are developed and implemented | CIS Benchmark or equivalent; per platform standard |
+| 2.2.1 | System configuration standards address all known security vulnerabilities | Vuln scan results mapped to standards |
+| 2.2.2 | Vendor default accounts managed before deploying systems | Default creds disabled/renamed; evidence of removal |
+| 2.2.3 | Primary functions needing different security levels are on separate components | Server isolation, role separation |
+| 2.2.4 | Only necessary functions, ports, protocols, and services are enabled | Port scan results; services audit |
+| 2.2.5 | If insecure protocols are used, business justification and additional controls documented | Protocol exception log |
+| 2.2.6 | System security parameters are configured to prevent misuse | Config hardening evidence |
+| 2.2.7 | All non-console administrative access is encrypted | SSH, HTTPS, TLS for all admin access |
+| 2.3 | Wireless environments are configured and managed securely | Wi-Fi config review, WPA3 or WPA2-Enterprise |
+| 2.3.1 | Default wireless vendor defaults changed at installation | AP config records |
+| 2.3.2 | Wireless encryption keys changed when anyone with key knowledge leaves | Key rotation procedure and evidence |
+
+**Common gaps**: Vendor default passwords left unchanged; unnecessary services (Telnet, FTP) still enabled; no documented hardening standards.
+
+---
+
+## GOAL 2: Protect Account Data
+
+### Requirement 3 — Protect Stored Account Data
+
+Minimise storage of account data; never store SAD post-authorisation; protect PAN wherever stored.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 3.1 | Processes for protecting stored account data are defined and implemented | Data retention policy |
+| 3.2 | Account data storage minimised | Data retention schedules; deletion procedures |
+| 3.2.1 | SAD not retained after authorisation | Scan results proving no SAD in storage; code review |
+| 3.3 | SAD is not retained after authorisation | Confirmed by system scans and application review |
+| 3.3.1 | SAD not stored (full magnetic stripe, CAV2/CVV2/CVC2/CID, PIN/PIN block) | Application code review; database scans |
+| 3.3.2 | SAD stored prior to authorisation is encrypted | Encryption evidence for pre-auth data |
+| 3.3.3 | Encryption keys for pre-auth SAD are managed securely | Key management docs |
+| 3.4 | PAN is protected wherever it is stored | Encryption, masking, or tokenisation evidence |
+| 3.4.1 | PAN is unreadable anywhere it is stored | AES-256 encryption; tokenisation proof; masking |
+| 3.4.2 | Copies of PAN only on authorised removable media | Media inventory and controls |
+| 3.5 | PAN is secured with strong cryptography | Encryption algorithm and key management review |
+| 3.5.1 | Primary account numbers protected with strong cryptography | AES-256 or equivalent; no DES/RC4 |
+| 3.6 | Cryptographic keys used for PAN encryption are secured | Key management policy and procedures |
+| 3.6.1 | Key management procedures and processes for cryptographic keys | Key custodian assignments; split knowledge |
+| 3.7 | Key management procedures and processes are implemented | Key rotation, key-encrypting keys, key retirement |
+| 3.7.1 | Key management policies cover the full key lifecycle | Generated, distributed, stored, retired |
+| 3.7.2 | Key storage is secure | HSM, encrypted key store |
+| 3.7.3 | Key access restricted to fewest custodians necessary | Dual control; split knowledge |
+| 3.7.4 | Key retirement/replacement policy documented and followed | Rotation records |
+| 3.7.5 | Key compromises managed per documented procedure | Incident response for key compromise |
+| 3.7.6 | Manual keys use split knowledge and dual control | Evidence of two-person key operations |
+| 3.7.7 | Informal key substitution prevented | Formal key management only |
+| 3.7.8 | Key custodians acknowledge their responsibilities | Signed custodian agreements |
+| 3.7.9 | Where key management services are used, they meet Req 3.6–3.7 | CSP KMS compliance evidence |
+
+**Common gaps**: CVV stored in database; PAN in log files; no key rotation; encryption with weak algorithms (MD5, SHA-1 for integrity); keys stored alongside encrypted data.
+
+---
+
+### Requirement 4 — Protect Cardholder Data with Strong Cryptography During Transmission
+
+PAN transmitted over open, public networks must be encrypted using strong cryptography.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 4.1 | Processes for protecting PAN in transit are defined and implemented | Cryptography policy |
+| 4.2 | PAN protected during transmission over open, public networks | TLS 1.2+ config; certificate review |
+| 4.2.1 | Strong cryptography used to safeguard PAN in transit | TLS 1.2 or 1.3; no SSL, TLS 1.0, 1.1 |
+| 4.2.1.1 | Certificate inventory maintained | Certificate management tool or inventory |
+| 4.2.1.2 | Wireless networks transmitting PAN use strong cryptography | Wi-Fi encryption: WPA2-Enterprise or WPA3 |
+| 4.2.2 | PAN not sent by unprotected end-user messaging (email, chat) | DLP policy; email encryption controls |
+
+**Common gaps**: Legacy TLS 1.0/1.1 still enabled; expired SSL certificates; PAN sent via plain email; no certificate inventory.
+
+---
+
+## GOAL 3: Maintain a Vulnerability Management Program
+
+### Requirement 5 — Protect All Systems and Networks from Malicious Software
+
+Anti-malware controls protect against viruses, ransomware, spyware, and other threats.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 5.1 | Processes for malware protection are defined | Anti-malware policy |
+| 5.2 | Anti-malware solution(s) deployed on all applicable components | AV deployment inventory; management console |
+| 5.2.1 | Anti-malware solution deployed on all components subject to malware | Coverage report; exceptions documented |
+| 5.2.2 | Anti-malware solution detects all known types of malware | Vendor capability matrix |
+| 5.2.3 | Systems not commonly affected by malware are evaluated periodically | Periodic risk analysis; documented exceptions |
+| 5.3 | Anti-malware solution maintained and monitored | Definition update logs; scan results |
+| 5.3.1 | Anti-malware solution kept current | Auto-update policy; current definition proof |
+| 5.3.2 | Anti-malware performs periodic scans and active/real-time scanning | Scan schedule; real-time protection enabled |
+| 5.3.3 | Anti-malware solution for removable media | USB scanning policy; endpoint config |
+| 5.3.4 | Anti-malware solution logs maintained and monitored | Log retention; SIEM integration |
+| 5.3.5 | Anti-malware mechanisms cannot be disabled by users | Admin-only uninstall; tamper protection enabled |
+| 5.4 | Anti-phishing mechanisms protect users (**NEW in v4.0**) | Anti-phishing filter; email gateway config |
+| 5.4.1 | Automated technical solution detects and protects against phishing | Email security gateway; URL filtering; DMARC/DKIM/SPF |
+
+**Common gaps**: AV not covering Linux/Unix systems; definitions not auto-updated; users can disable AV; no phishing protections (new v4.0 requirement).
+
+---
+
+### Requirement 6 — Develop and Maintain Secure Systems and Software
+
+Vulnerabilities must be identified and addressed through patching and secure development practices.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 6.1 | Security vulnerability identification and management processes defined | Vuln management policy |
+| 6.2 | Bespoke and custom software is developed securely | SDLC policy; code review process |
+| 6.2.1 | Bespoke software developed based on secure coding guidelines | Coding standards; training records |
+| 6.2.2 | Software development personnel trained on secure coding techniques | Annual training records |
+| 6.2.3 | Code review performed before production release | Code review records; SAST scan results |
+| 6.2.4 | Software engineering techniques to prevent common vulnerabilities | OWASP Top 10 addressed; DAST results |
+| 6.3 | Security vulnerabilities identified and addressed | Patch management policy |
+| 6.3.1 | Security vulnerabilities managed using ranking | CVSS or internal risk ranking; patch SLAs |
+| 6.3.2 | Inventory of bespoke and custom software maintained | Software inventory/SBOM |
+| 6.3.3 | All system components protected from known vulnerabilities | Patch management; current patch evidence |
+| 6.4 | Public-facing web applications protected from attacks | WAF or application review |
+| 6.4.1 | Public-facing web apps protected against web-based attacks | WAF in blocking mode; annual app testing |
+| 6.4.2 | Automated technical solution deployed for public-facing web apps | WAF config; active monitoring |
+| 6.4.3 | All payment page scripts managed and authorised (**NEW v4.0**) | Script inventory; integrity controls |
+| 6.5 | Changes to system components managed securely | Change management policy |
+| 6.5.1 | Changes to system components via formal change control | Change tickets; approval evidence |
+| 6.5.2 | Post-change security verification | Test results; UAT sign-off |
+| 6.5.3 | Pre-production environments are separate from production | Environment separation proof |
+| 6.5.4 | Roles and functions are separated between production and pre-production | Access control evidence |
+| 6.5.5 | Live PANs not used in pre-production/testing | Anonymised test data confirmation |
+| 6.5.6 | Test data/accounts removed before production | Pre-prod cleanup checklist |
+
+**Common gaps**: No SDLC/secure coding policy; live PANs in test environments; WAF in detection-only mode; payment page scripts not inventoried (v4.0 new).
+
+---
+
+## GOAL 4: Implement Strong Access Control Measures
+
+### Requirement 7 — Restrict Access to System Components and Cardholder Data by Business Need to Know
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 7.1 | Access control processes and procedures defined | Access control policy |
+| 7.2 | Access to system components and cardholder data is restricted | Role-based access matrix; IAM configuration |
+| 7.2.1 | All users have access based on least privilege and need-to-know | Access review results |
+| 7.2.2 | Access assigned based on job classification and function | Role definitions; access request records |
+| 7.2.3 | Privilege access approved by authorised personnel | Approval workflow records |
+| 7.2.4 | User accounts and access privileges reviewed at least every 6 months | Access review logs with dates |
+| 7.2.5 | Application/system accounts managed by policy | Service account inventory; access controls |
+| 7.2.6 | Query access to CHD repositories restricted to defined applications | DB access controls; application-level auth |
+| 7.3 | Access to system components and data is managed | IAM system; access control enforcement |
+| 7.3.1 | Access control system in place to restrict access to CDE | IAM/PAM tool deployment evidence |
+| 7.3.2 | Access control system configured to enforce least privilege | ACL review; deny-by-default configuration |
+| 7.3.3 | Access control system is kept current | Review and update cycle evidence |
+
+**Common gaps**: Shared accounts; no access recertification; over-privileged service accounts; no need-to-know principle enforced for database access.
+
+---
+
+### Requirement 8 — Identify Users and Authenticate Access to System Components
+
+Every user must have a unique ID; strong authentication required for CDE access.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 8.1 | User identification and authentication processes defined | Authentication policy |
+| 8.2 | User IDs and authentication credentials managed | IAM system; unique account verification |
+| 8.2.1 | All users have a unique ID | Account audit; no shared accounts |
+| 8.2.2 | Group, shared, or generic accounts managed only in exceptional circumstances | Exceptions with justification documented |
+| 8.2.3 | Additional authentication for accounts used by third parties/vendors | MFA for vendor access |
+| 8.2.4 | User accounts added/modified/deleted only through formal process | Identity lifecycle management records |
+| 8.2.5 | Access for terminated users is immediately revoked | Offboarding checklist; IAM de-provisioning evidence |
+| 8.2.6 | Inactive accounts disabled within 90 days | Account review; automated disable policy |
+| 8.2.7 | Accounts used for system/application functions managed appropriately | Service account policy compliance |
+| 8.2.8 | Sessions inactive more than 15 minutes require re-authentication | Session timeout config |
+| 8.3 | Strong authentication established and managed | MFA configuration evidence |
+| 8.3.1 | All user access into CDE uses MFA (**Extended in v4.0**) | MFA deployment proof for ALL CDE access |
+| 8.3.2 | MFA for all access into the CDE from outside | Remote access MFA (VPN, RDP, etc.) |
+| 8.3.4 | Invalid authentication attempts limited | Account lockout policy (max 10 attempts) |
+| 8.3.5 | Passwords/passphrases set to meet minimum requirements | Password policy config: min 12 chars, complexity |
+| 8.3.6 | Passwords changed every 90 days (or with compensating control/risk analysis) | Password policy; expiry settings |
+| 8.3.7 | Individuals not allowed to submit new password same as any of last 4 | Password history settings |
+| 8.3.8 | Authentication policies communicated to users | Training records; policy acknowledgements |
+| 8.3.9 | Passwords for users not using MFA changed at least every 90 days | Password expiry config |
+| 8.3.10 | Guidance for changing passwords provided to users at specified intervals | Comms records |
+| 8.4 | MFA implemented for all access into the CDE | MFA for all privileged and standard user access |
+| 8.4.1 | MFA for all non-console admin access to CDE | Admin MFA config |
+| 8.4.2 | MFA for all access into the CDE (**Key new v4.0 change**) | MFA required for everyone accessing CDE |
+| 8.5 | MFA systems configured to prevent misuse | Anti-MFA-bypass controls |
+| 8.6 | Use of application/system accounts managed | Automated or manual interactive use controls |
+
+**Common gaps**: Shared admin accounts; weak passwords (< 12 chars); no MFA for all CDE access (key v4.0 gap); accounts not disabled within 90 days of inactivity; no session timeout.
+
+---
+
+### Requirement 9 — Restrict Physical Access to Cardholder Data
+
+Physical controls prevent unauthorised access to systems, media, and facilities in the CDE.
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 9.1 | Processes for restricting physical access defined | Physical security policy |
+| 9.2 | Physical access controls for appropriate facility entry | Badge access logs; visitor records |
+| 9.2.1 | Individual physical access controls to sensitive areas | Badge reader logs; CCTV |
+| 9.2.2 | Visitor management procedure implemented | Visitor log; escort policy |
+| 9.2.3 | Physical access to wireless access points, gateways, and handheld devices controlled | Device location inventory; lock-down evidence |
+| 9.2.4 | Physical access to CDE systems via publicly accessible network jacks controlled | Port lock-out; network access control |
+| 9.3 | Physical access for personnel and visitors authorised and managed | Access management records |
+| 9.3.1 | Physical access controls for personnel with physical access | Access list; revocation process |
+| 9.3.2 | Physical access for visitors authorised and revoked | Visitor badge records |
+| 9.4 | Media with cardholder data is securely stored, accessed, distributed, and destroyed | Media inventory; destruction records |
+| 9.4.1 | Physical media containing CHD secured | Locked storage; media inventory |
+| 9.4.2 | Physical media containing CHD classified | Classification labels on media |
+| 9.4.3 | Physical media distributed externally via tracked courier or secure methods | Courier receipts; chain of custody |
+| 9.4.4 | Management approval for all media moved outside facility | Approval records |
+| 9.4.5 | External media inventory controlled and audited | Media audit logs |
+| 9.4.6 | Hard-copy materials with CHD destroyed cross-cut or confetti-shred | Destruction vendor certificates |
+| 9.4.7 | Electronic media destroyed or rendered unrecoverable when no longer needed | Secure wipe / degauss / physical destroy records |
+| 9.5 | Point-of-interaction (POI) devices protected from tampering and skimming | POI device inspection programme |
+| 9.5.1 | POI device surface inspected to detect tampering or substitution | Inspection schedule; checklist records |
+
+**Common gaps**: No visitor log; POI devices not regularly inspected; media not tracked or destroyed per policy; physical access not revoked for terminated staff.
+
+---
+
+## GOAL 5: Regularly Monitor and Test Networks
+
+### Requirement 10 — Log and Monitor All Access to System Components and Cardholder Data
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 10.1 | Audit log processes defined | Log management policy |
+| 10.2 | Audit logs implemented to support detection of anomalies | SIEM or log management platform |
+| 10.2.1 | Audit logs capture all individual user access to CHD | Log samples showing user activity |
+| 10.2.2 | Audit logs capture all actions by root or admin | Privileged access logs |
+| 10.2.3 | Audit logs capture all access to audit logs | Audit-of-audit trail |
+| 10.2.4 | Audit logs capture invalid logical access attempts | Failed login logs |
+| 10.2.5 | Audit logs capture use of identification and authentication mechanisms | Auth logs; MFA event logs |
+| 10.2.6 | Audit logs capture initialisation, stopping, or pausing of logs | Log service event logs |
+| 10.2.7 | Audit logs capture creation/deletion of system-level objects | System event logs |
+| 10.3 | Audit logs are protected from destruction and modification | Log integrity controls; write-once storage |
+| 10.3.1 | Log files protected to prevent modifications | Immutable log storage; SIEM ingestion |
+| 10.3.2 | Audit log files protected from unauthorised access | Access controls on log infrastructure |
+| 10.3.3 | Audit logs are promptly backed up to a central log server | Syslog/SIEM centralisation evidence |
+| 10.3.4 | File integrity monitoring or change detection on audit logs | FIM solution monitoring log files |
+| 10.4 | Audit logs reviewed to identify anomalies or suspicious activity | Log review process |
+| 10.4.1 | Automated log review mechanisms used (**NEW in v4.0**) | SIEM alert rules; automated review evidence |
+| 10.4.2 | Logs for all system components reviewed daily | Review schedules; SIEM alert evidence |
+| 10.4.3 | Exceptions and anomalies addressed promptly | Ticket records tied to log alerts |
+| 10.5 | Audit log history retained for at least 12 months with last 3 months immediately available | Retention policy; log storage capacity |
+| 10.6 | Time synchronisation technology in use | NTP configuration; stratum 1/2 sync |
+| 10.7 | Failures of critical security controls detected and addressed (**NEW in v4.0**) | Monitoring for AV, FW, IDS failures |
+| 10.7.2 | Failures detected and responded to promptly | Alert/ticketing evidence |
+
+**Common gaps**: Logs not centralised to SIEM; retention under 12 months; no automated review (v4.0 new); time not synchronised across all CDE components; critical security control failures not monitored.
+
+---
+
+### Requirement 11 — Test Security of Systems and Networks Regularly
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 11.1 | Security testing processes defined | Testing policy |
+| 11.2 | Wireless access points managed | Wireless AP inventory; rogue AP detection |
+| 11.2.1 | Authorised and unauthorised wireless access points managed | Quarterly wireless scans; rogue detection alerts |
+| 11.2.2 | Wireless scan inventory reconciled quarterly | Scan results vs inventory |
+| 11.3 | External and internal vulnerabilities assessed | Vulnerability scanning programme |
+| 11.3.1 | Internal vulnerability scans run at least every 3 months | Scan reports showing quarterly cadence |
+| 11.3.2 | External vulnerability scans run at least every 3 months by an ASV | ASV scan reports; passing results |
+| 11.3.3 | All exploitable vulnerabilities remediated and re-scanned | Remediation evidence; re-scan passing results |
+| 11.4 | External and internal penetration testing is performed | Penetration test reports |
+| 11.4.1 | Penetration testing methodology defined | Pen test scope document |
+| 11.4.2 | Internal penetration testing at least annually and after changes | Annual pen test report |
+| 11.4.3 | External penetration testing at least annually and after changes | External pen test report |
+| 11.4.4 | Exploitable vulnerabilities from pen testing remediated and re-tested | Remediation tracking; re-test confirmation |
+| 11.4.5 | Network segmentation verified by penetration testing at least every 6 months | Segmentation pen test report |
+| 11.5 | Network intrusion detection/prevention techniques used | IDS/IPS deployment evidence |
+| 11.5.1 | Intrusion detection/prevention used to detect and/or prevent intrusions | IDS/IPS alert logs; tuning records |
+| 11.5.2 | Change detection mechanism deployed on CDE | FIM solution alerts; change records |
+| 11.6 | Unauthorised changes on payment pages detected and responded to (**NEW v4.0**) | Script integrity monitoring |
+| 11.6.1 | Change and tamper detection mechanism for payment pages deployed | HTTP header monitoring; script hash verification |
+
+**Common gaps**: ASV scans failing (not "clean"); penetration testing not truly internal + external; segmentation not tested; no FIM; payment page integrity not monitored (v4.0 new).
+
+---
+
+## GOAL 6: Maintain an Information Security Policy
+
+### Requirement 12 — Support Information Security with Organizational Policies and Programs
+
+| Sub-Req | Description | Evidence for QSA |
+|---------|-------------|-----------------|
+| 12.1 | Comprehensive information security policy defined, published, and maintained | Security policy doc; annual review |
+| 12.2 | Targeted risk analysis process defined for flexible requirements | TRA template; completed TRAs |
+| 12.3 | Risks to CHD and cardholder data environment managed | Risk management programme |
+| 12.3.1 | Targeted risk analysis for each PCI DSS requirement with customised approach | TRA documentation per requirement |
+| 12.3.2 | TRA performed for flexible-frequency requirements | Documented TRAs for each flexible req |
+| 12.3.3 | Cryptographic cipher suites and protocols reviewed and documented at least once every 12 months | Crypto inventory; annual review records |
+| 12.3.4 | Hardware and software technologies reviewed at least once every 12 months | Tech lifecycle review records |
+| 12.4 | PCI DSS compliance managed throughout the year | Compliance programme; quarterly review |
+| 12.4.2 | Reviews confirming personnel follow security policies performed at least quarterly | Quarterly compliance review records |
+| 12.5 | PCI DSS scope documented and validated | Scope documentation; annual review |
+| 12.5.1 | Inventory of system components in scope for PCI DSS maintained | CDE system inventory |
+| 12.5.2 | PCI DSS scope verified at least every 12 months and after major changes | Annual scope review; post-change assessment |
+| 12.6 | Security awareness education implemented | Security awareness programme; training records |
+| 12.6.1 | Security awareness programme in place | Programme documentation |
+| 12.6.2 | Security awareness programme reviewed at least every 12 months | Review records |
+| 12.6.3 | Personnel acknowledge at least annually they have read and understood security policy | Signed acknowledgements |
+| 12.7 | Personnel are screened before granting access to CDE | Background check policy; records |
+| 12.8 | Third-party service providers (TPSPs) with CHD access are managed | TPSP inventory; compliance monitoring |
+| 12.8.1 | List of all TPSPs maintained | TPSP register |
+| 12.8.2 | Written agreements with TPSPs acknowledging PCI DSS responsibility | Signed agreements |
+| 12.8.3 | Established process for engaging TPSPs | TPSP due diligence process |
+| 12.8.4 | TPSP PCI DSS compliance status monitored at least annually | Annual TPSP compliance confirmation; AOC |
+| 12.8.5 | Information about which PCI DSS requirements managed by each TPSP | Responsibility matrix |
+| 12.9 | TPSPs support customers' PCI DSS compliance | TPSP acknowledgement of responsibility |
+| 12.10 | Suspected and confirmed security incidents responded to immediately | Incident response plan; test records |
+| 12.10.1 | Incident response plan created and ready | Documented IR plan |
+| 12.10.2 | IR plan reviewed and tested at least annually | Annual tabletop or drill evidence |
+| 12.10.3 | Specific personnel designated for 24/7 incident response | On-call roster; contact list |
+| 12.10.4 | IR personnel trained appropriately | Annual training records |
+| 12.10.5 | Alerts from security monitoring systems included in IR plan | IR plan references monitoring alerts |
+| 12.10.6 | IR plan updated when new threats or lessons learned | Version history; update records |
+| 12.10.7 | Incident response procedures for discovery of stored PAN in unexpected location | PAN discovery procedure |
+
+**Common gaps**: Security policy not reviewed annually; no TPSP register or compliance monitoring; incident response plan never tested; personnel not acknowledging policy; no TRA process.