PCI DSS v4.0.1 (Payment Card Industry Data Security Standard)

Network security controls (firewalls and equivalents) are configured from defined standards, every allowed service, protocol and port is documented with a business justification, and NSC rule sets are reviewed at least once every six months.

Inbound and outbound traffic to and from the cardholder data environment is restricted to only what is necessary, all other traffic is denied, and the CDE is segmented from other networks.

Network connections between trusted and untrusted networks (including the internet) are controlled: a DMZ or equivalent limits inbound traffic to authorised system components, anti-spoofing is in place, and system components storing cardholder data are not directly reachable from untrusted networks.

System components are configured and managed securely: configuration standards address known vulnerabilities and are consistent with industry hardening standards, vendor default accounts are removed or have their passwords changed, and only necessary services are enabled.

Account data storage is kept to a minimum through retention and disposal policies that limit storage to what is required for legal, regulatory or business needs, and a process at least every three months securely deletes stored account data that exceeds the defined retention period.

Sensitive authentication data — full track data, card verification codes (CVV2/CVC2/CID) and PINs/PIN blocks — is not retained after authorisation, even if encrypted, and is rendered unrecoverable once authorisation completes.

PAN is masked when displayed so that only personnel with a legitimate business need can see more than the BIN and last four digits, and technical controls prevent copying or relocating PAN via remote-access technologies except with explicit authorisation.

PAN is rendered unreadable anywhere it is stored using one-way hashes of the entire PAN, truncation, index tokens, or strong cryptography with associated key management. Disk-level encryption alone is only acceptable for removable media.

Cryptographic keys used to protect stored account data are managed securely: access is restricted to the fewest custodians, keys are stored securely, key-management procedures cover generation, distribution, storage, cryptoperiod-based rotation, retirement and split knowledge/dual control where applicable, and custodians formally acknowledge their responsibilities.

PAN is protected with strong cryptography whenever it is transmitted over open, public networks: only trusted keys and certificates are accepted, certificates are valid and not expired, and PAN is never sent unprotected through end-user messaging technologies such as email or chat.

An anti-malware solution is deployed on all system components except those evaluated as not at risk, is kept current, performs periodic scans and active or real-time scanning, cannot be disabled by users without authorisation, and evaluations of not-at-risk systems are repeated periodically.

Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks — for example email link scanning, attachment sandboxing, and anti-spoofing controls such as SPF, DKIM and DMARC.

Bespoke and custom software is developed securely in line with industry standards; developers are trained at least annually in secure coding relevant to their language and role; and code is reviewed before release to identify and correct vulnerabilities, including attacks such as injection and XSS.

All system components are protected from known vulnerabilities by installing applicable security patches and updates; patches for critical vulnerabilities are installed within one month of release, and others within timeframes set by the entity's risk ranking.

Public-facing web applications are protected against known attacks — for those in scope, by an automated technical solution such as a web application firewall that continually detects and prevents web-based attacks, is kept up to date, and generates alerts.

Every script loaded and executed in the consumer's browser on payment pages is authorised, has its integrity assured (for example by SRI or a CSP), and is listed in an inventory with a written business or technical justification.

Changes to system components are made through documented change procedures including impact assessment, approval, testing and back-out; pre-production environments are separated from production with access controls; and live PANs are not used in pre-production environments.

Access to system components and cardholder data is defined and assigned by job classification and function, on least privilege; privileged access is limited to what is required; and all user accounts and their access privileges are reviewed at least once every six months.

Every user is assigned a unique ID; group, shared or generic accounts are used only when necessary on an exception basis; access for terminated users is revoked immediately; and inactive accounts are removed or disabled within 90 days.

User authentication factors are strong: passwords are at least 12 characters (or 8 where the system does not support 12) with numeric and alphabetic characters, accounts lock out after no more than 10 invalid attempts, and where passwords are the only factor they are changed at least every 90 days or access is analysed dynamically.

Multi-factor authentication is implemented for all non-console access into the cardholder data environment (including administrators), and for all remote network access originating from outside the entity's network.

System and application accounts that can be used interactively are managed, their use is exception-based and attributable, and their passwords or secrets are not hard-coded in scripts, configuration files or source code and are changed periodically.

All media containing cardholder data — paper and electronic — is physically secured, classified by sensitivity, tracked when moved, and destroyed when no longer needed so that the data cannot be reconstructed (cross-cut shredding, pulping, secure wiping or physical destruction).

Point-of-interaction devices that capture card data by direct physical interaction are listed, periodically inspected for tampering or substitution, and personnel are trained to recognise attempted tampering and to verify the identity of anyone claiming to service the devices.

Audit logs are enabled and active for all system components and cardholder data, capturing individual user access to cardholder data, all actions by administrators, access to audit logs, invalid access attempts, changes to identification and authentication credentials, and creation or deletion of system-level objects, with sufficient detail for each event.

Security events and logs of critical components and those that store, process or transmit cardholder data are reviewed at least once daily, using automated mechanisms such as a SIEM, and exceptions and anomalies are identified and addressed.

Audit log history is retained for at least 12 months, with at least the most recent three months immediately available for analysis, and logs are protected from destruction and unauthorised modification.

System clocks and time are synchronised using time-synchronisation technology, from designated time servers receiving time from industry-accepted sources, with time data protected and changes logged.

Failures of critical security control systems — such as network security controls, IDS/IPS, anti-malware, change-detection, audit logging and access controls — are detected, alerted and addressed promptly, including restoring the control, identifying the cause and documenting remediation.

Internal vulnerability scans are performed at least once every three months (authenticated) and after significant changes, with high-risk and critical findings resolved and rescanned; external scans are performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV) with passing results.

A penetration-testing methodology is defined; internal and external penetration tests are performed at least once every 12 months and after any significant infrastructure or application change by a qualified, organisationally independent tester; exploitable vulnerabilities are corrected and retested; and segmentation controls are tested (every 12 months, or every six months for service providers).

Intrusion-detection and/or intrusion-prevention techniques detect or prevent intrusions into the network at the CDE perimeter and critical points, and a change-detection mechanism (such as file-integrity monitoring) alerts on unauthorised modification of critical files, with comparisons at least weekly.

A change- and tamper-detection mechanism alerts personnel to unauthorised modification of the security-impacting HTTP headers and script contents of payment pages as received by the consumer's browser, evaluated at least once every seven days or at a frequency set by targeted risk analysis.

An overall information security policy is established, published, maintained, disseminated to all relevant personnel and reviewed at least once every 12 months and updated as needed; roles and responsibilities for information security are defined, and a member of executive management is formally assigned responsibility.

For each PCI DSS requirement that lets the entity set its own frequency, a targeted risk analysis identifies the assets and threats, the factors affecting likelihood and impact, and justifies the chosen frequency; each analysis is reviewed at least once every 12 months.

PCI DSS scope is documented and confirmed at least once every 12 months and upon significant change — identifying all data flows, locations where account data is stored, processed and transmitted, connected systems, and segmentation controls — together with an inventory of in-scope system components.

A formal security awareness programme makes all personnel aware of the security policy and their role in protecting cardholder data; personnel receive awareness training on hire and at least every 12 months, including phishing and related social-engineering attacks, and acknowledge the policies at least annually.

Risk to account data from third-party service providers is managed: a list of TPSPs is maintained with a description of services; written agreements include the TPSP's acknowledgement of responsibility for the account data it handles; due diligence precedes engagement; each TPSP's PCI DSS compliance status is monitored at least once every 12 months; and responsibilities are allocated between the entity and the TPSP.

An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident, covering roles, communication and contact strategies including notifying payment brands and acquirers, containment and mitigation, business recovery, and legal requirements; it is reviewed and tested at least once every 12 months, and it is initiated when stored PAN is found where it is not expected.