PCI DSS v4.0.1

Every form of non-console access into the CDE, not only administrative access, must be protected with MFA. Applicability: excludes system or application accounts that run automated functions, to point-of-sale terminal user accounts that are limited to a single card number per transaction, or to user accounts authenticated only with phishing-resistant factors. MFA is required separately for this access and for remote access under 8.4.3, so a user who connects remotely to the network and then into the CDE authenticates with MFA twice. It covers every kind of system component (cloud and hosted systems, on-premises applications, workstations, servers, endpoints and network security devices) and both direct network or system access and web-based access to applications. MFA may be applied at network or system/application level, not necessarily both. Objective under the customized approach: access into the CDE cannot be gained with a single authentication factor. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

evidence an assessor asks for Inventory of all non-console entry paths into the CDE, including web applications, with the MFA point for each; MFA or SSO conditional access policies scoped to CDE resources; Observation records of non-administrative users authenticating into the CDE; List of accounts exempted as automated or phishing-resistant, with justification

Personnel with administrative access who reach the CDE through any non-console connection must use MFA. The guidance defines that using the same factor twice, such as two passwords, does not count as MFA. Applicability: covers every person holding administrative or elevated privileges who reach the CDE over a non-console connection, meaning logical access across a network interface rather than a direct physical connection. Objective under the customized approach: nobody can obtain administrative access into the CDE using a single factor alone.

evidence an assessor asks for MFA configuration for jump hosts, bastions, PAM and admin consoles into the CDE; List of administrative access paths into the CDE with the MFA control on each; Observation record of an administrator logging in with MFA; MFA enrolment report for all administrative accounts

MFA must be implemented for all remote access that originates outside the entity's network and could access or affect the CDE. Applicability: covers all user accounts able to access the network remotely where that access leads, or could lead, into the CDE, including staff, both users and administrators, and third parties such as vendors, suppliers, service providers and customers. Remote access to a network segment properly isolated from the CDE does not need MFA, though MFA is recommended for every remote connection into the entity's networks. It covers every kind of system component (cloud and hosted systems, on-premises applications, workstations, servers, endpoints and network security devices) and both direct and web-based access. The guidance defines MFA as presenting at least two of the three factor types from 8.3.1. Customized approach objective: a single authentication factor is never enough to gain remote access into the entity's network.

evidence an assessor asks for VPN, VDI and remote access gateway MFA configuration; Inventory of remote access methods, including vendor tools, with MFA status; Segmentation evidence for any remote access path claimed to be isolated from the CDE; Observation records of employee and third-party remote connections

Offline media backups that contain cardholder data must be kept in a secure location. The guidance describes off-site storage, for instance at a commercial storage provider or an alternate or backup site, as good practice, and notes that backups in a non-secured facility could be lost, stolen or copied. Applicability: entities keeping offline backups with cardholder data. Customized approach objective: unauthorized personnel cannot reach offline backups by unauthorized personnel.

evidence an assessor asks for Backup media storage procedure naming the secure storage location; Contract and security description for any commercial off-site storage vendor; Tape or disk check-in and check-out logs at the storage site; Access list for the backup storage room or vault

All system components must be shielded from known vulnerabilities by applying relevant security patches or updates such that: patches or updates addressing critical vulnerabilities, as ranked under Requirement 6.3.1, must go in within one month of their release; and every other relevant security patch or update is installed within a suitable time frame set by the entity's own assessment of how critical the risk is to its environment, using the Requirement 6.3.1 ranking process. It applies to all entities and all system components. Customized approach objective: exploitation of a known vulnerability cannot be used to compromise system components.

The requirement's own words: within one month of their release

evidence an assessor asks for Patch management procedure stating the one-month deadline for critical patches and time frames for others; Patch compliance reports per system component showing install dates against vendor release dates; Risk-based rationale or targeted risk analysis for non-critical patch time frames; Exception register for patches that could not be applied, with compensating measures; Sample of critical advisories traced to installation evidence

All system components must be shielded from known vulnerabilities by applying relevant security patches or updates such that: patches or updates addressing critical vulnerabilities, as ranked under Requirement 6.3.1, must go in within one month of their release; and every other relevant security patch or update is installed within a suitable time frame set by the entity's own assessment of how critical the risk is to its environment, using the Requirement 6.3.1 ranking process. It applies to all entities and all system components. Customized approach objective: exploitation of a known vulnerability cannot be used to compromise system components.

The requirement's own words: within one month of their release

evidence an assessor asks for Patch management procedure stating the one-month deadline for critical patches and time frames for others; Patch compliance reports per system component showing install dates against vendor release dates; Risk-based rationale or targeted risk analysis for non-critical patch time frames; Exception register for patches that could not be applied, with compensating measures; Sample of critical advisories traced to installation evidence

Internal vulnerability scans must be run at least every three months. All vulnerabilities ranked high-risk or critical under the entity's risk rankings from Requirement 6.3.1 must be resolved, and rescans must be run to confirm that every such high-risk and critical finding is fixed. The scanning tool must be kept current with the latest vulnerability information, and the people running scans must be qualified and organizationally independent of what they scan. Guidance (good practice): several scan reports may be combined to show full coverage within the three-month cycle, and scanning more often than quarterly is recommended where the environment warrants it. Applicability: a QSA or ASV is not needed for internal scans; qualified internal staff reasonably independent of the scanned components (for example, not the administrator of that network) may run them, or a specialist scanning firm may be used. Objective under the customized approach: automated tools that detect vulnerabilities inside the network periodically verify the security state of every system component, and findings are assessed and fixed using a formal risk assessment framework.

The requirement's own words: every three months

evidence an assessor asks for Four quarters of internal scan reports covering all in-scope system components; Rescan reports showing high-risk and critical findings closed; Scan tool plugin or signature update logs; Vulnerability risk ranking criteria from Requirement 6.3.1; Scanner qualifications and evidence of independence from the scanned systems

Access for every user, including privileged users, must be assigned on the basis of the user's job classification and function, and restricted to the least privileges needed to perform that person's responsibilities. The guidance explains that once role needs are defined under 7.2.1, individuals can be granted access by placing them in the matching roles, gives the example that a database or backup administrator should not hold the full privileges of a systems administrator, and suggests entities may consider privileged access management that grants elevated rights only when needed and removes them afterwards. Objective under the customized approach: access to systems and data is confined to what each job function needs, as set out in the related access roles.

evidence an assessor asks for User access provisioning procedure referencing job classification and least privilege; Export of user-to-role and user-to-group assignments, including privileged groups; Sample of privileged user records compared with their job descriptions; PAM tool configuration or just-in-time elevation logs where used

All user accounts and their related access privileges, including third-party and vendor accounts, must be reviewed at least every six months. The review must confirm that accounts and access remain appropriate for each person's job function, any inappropriate access must be dealt with, and management must acknowledge that the remaining access is appropriate. The guidance notes the review is also a chance to catch terminated users and third parties whose access was missed. Applicability: covers every user account and related privilege, including accounts of personnel, of vendors and of other third parties and accounts used to reach third-party cloud services; application and system accounts are handled instead by Requirement 7.2.5 (and its sub-requirement) and by 8.6.1 to 8.6.3. Objective under the customized approach: management periodically verifies that account privilege assignments are correct and remediates nonconformities. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

The requirement's own words: every six months

evidence an assessor asks for Semi-annual user access review records for each in-scope system, with review dates; Evidence that inappropriate access found was removed or corrected, such as closed tickets; Management sign-off acknowledging access remains appropriate; Inventory of third-party, vendor and cloud-service accounts included in the review scope

Where a system or application account is capable of interactive login, it must be managed so that: interactive use is prevented unless an exceptional circumstance requires it; interactive use lasts no longer than the exceptional circumstance requires; the business justification is documented; management explicitly approves interactive use; the individual's identity is verified before the account is made available; and each action performed is attributable to one individual user. The guidance advises that, where possible, such accounts be configured to disallow interactive login and limited to specific machines and devices. Objective under the customized approach: whenever system or application accounts are used interactively, each action is authorized and traceable to one person. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

evidence an assessor asks for List of application and system accounts with interactive logon capability flagged; Configuration denying interactive logon for service accounts (for example logon rights policies); Approval and justification records for each interactive use; Vault or PAM session logs tying interactive use to a named individual

Configuration standards must be developed, implemented and maintained so that they: (a) cover every system component; (b) address all known security vulnerabilities; (c) are consistent with vendor hardening recommendations or hardening standards the industry accepts; (d) are revised whenever new vulnerability issues come to light, following Requirement 6.3.1; and (e) are used whenever new systems are set up, and are confirmed to be in place before, or right after, a component goes live in a production environment. Applicability: no special notes; applies to every assessed entity. Objective under the customized approach: every system component is set up securely and consistently consistent with vendor guidance or hardening standards the industry accepts.

evidence an assessor asks for Configuration standards for each component type (operating systems, databases, network devices, containers, cloud services) referencing CIS or vendor baselines; Change history of standards showing updates triggered by newly identified vulnerabilities; Build checklists or pipeline logs showing standards applied to new systems; Configuration compliance scan reports taken at or shortly after production deployment

Audit logging must be switched on and actively recording for every system component and for cardholder data. Applies to all entities. The guidance explains that logs feed alerts and other monitoring tools such as IDS and SIEM and give a history trail for investigating incidents, and it advises storing only essential information in logs because log content is itself sensitive. Customized approach objective: every activity affecting system components and cardholder data leaves a record.

evidence an assessor asks for Inventory of in-scope system components reconciled against log sources reporting to the SIEM; Audit policy or syslog configuration exports for sampled servers, network devices and databases; SIEM source health report showing last event received per device; Cloud provider logging configuration (for example trail or activity log settings) for in-scope accounts

Every day, at a minimum, the entity must review: all security events; the logs of each critical system component; the logs of each system component that stores, processes or transmits CHD and/or SAD; and the logs of each server and system component with a security function (such as authentication servers, IDS/IPS and network security controls). Applies to all entities. Objective under the customized approach: activity that may be suspicious or anomalous is found fast, keeping its impact low.

evidence an assessor asks for Daily log review procedure naming the four log categories; SIEM dashboards or review tickets showing a review for every calendar day, including weekends and holidays; List of critical system components and security function systems covered by review; Reports or sign-offs from an outsourced SOC, if used; Interview records with analysts performing the review

An incident response plan must exist and be ready to activate if a security incident is suspected or confirmed. At minimum it covers: roles and duties, plus approaches for communication and for contacting parties, including at least notifying payment brands and acquirers; response procedures giving specific containment and mitigation steps per incident type; procedures for business recovery and continuity; processes for backing up data; an analysis of the legal duties to report compromises; coverage of, and responses covering, every critical system component; and reference to, or inclusion of, the payment brands' incident response procedures. Objective under the customized approach: a thorough incident response plan meeting card brand expectations is kept.

evidence an assessor asks for Incident response plan with role and contact tables; Payment brand and acquirer notification procedures; Incident-type playbooks with containment and mitigation steps; Legal reporting requirements analysis; Records of prior incidents showing plan use

An anti-malware solution (one or more) must be installed on every system component, with the only exception being components that the periodic evaluations under Requirement 5.2.3 have concluded are not at risk from malware. A component counts as affected by malware when real-world active exploits exist for it, not merely theoretical ones. Applicability: applies to every entity in scope, with no special notes. Customized approach objective: automated mechanisms stop systems from turning into a route for malware attacks.

evidence an assessor asks for System component inventory reconciled against the anti-malware console's list of protected hosts; Deployment status report showing agent installed and healthy per system component; List of excluded components with a reference to the 5.2.3 evaluation for each; Sample screenshots or agent queries from selected servers and workstations showing the solution running

The anti-malware solution or solutions must be kept up to date by means of automatic updates, covering signatures, security updates, threat analysis engines and any other protections the solution relies on. Updates should come from a trusted source as soon as they are available; they may be pulled first to a central location, for example for testing, before rollout to individual components. Applicability: applies to every entity in scope, with no special notes. Objective under the customized approach: anti-malware mechanisms are able to detect and deal with the newest malware threats.

evidence an assessor asks for Management console or master installation policy showing automatic update settings; Report of signature and engine versions across endpoints and servers; Update logs showing timely distribution after vendor releases; Sample of individual hosts with current definition dates

The entity must have processes and automated mechanisms that detect phishing attacks and protect personnel from them. A combination of approaches is encouraged, for example anti-spoofing controls (DMARC, SPF, DKIM), link scrubbing and server-side anti-malware that block phishing messages before delivery, and training personnel to spot and report phishing; applying the controls across the whole organisation is recommended but not required. Applicability: the emphasis is on protecting staff who can access in-scope PCI DSS system components. Technical anti-phishing controls under this requirement are separate from security awareness training under Requirement 12.6.3.1; meeting one does not satisfy the other. This was advisory only up to 31 March 2025 and is now required and fully assessed. Objective under the customized approach: mechanisms exist that protect against, and reduce the risk from, phishing attacks. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

evidence an assessor asks for DNS records and mail gateway settings showing DMARC, SPF and DKIM for the entity's domains; Secure e-mail gateway or filtering configuration with phishing detection, link rewriting or sandboxing enabled; Reports of blocked or quarantined phishing messages over the assessment period; Documented process for personnel reporting suspected phishing and how reports are triaged

A formal security awareness program must be in place so that all personnel know the entity's security policy and its procedures, and understand their own part in protecting cardholder data. The guidance notes that without such education, safeguards may be undermined by accidental mistakes or deliberate acts. Customized approach objective: personnel understand the threat landscape and their duties in operating relevant security controls, and can obtain help and guidance when they need it.

evidence an assessor asks for Security awareness program document with scope and owner; Training curriculum mapped to policy and procedures; Population coverage list showing all personnel groups; Help channel or contact point for security guidance

Security awareness training must address threats and vulnerabilities that could affect cardholder data or sensitive authentication data, covering at minimum phishing (and attacks related to it) plus social engineering. Applicability: technical and automated anti-phishing controls under Requirement 5.4.1 are a separate and distinct requirement; meeting one does not satisfy the other. Objective under the customized approach: personnel understand their own human weaknesses and how attackers try to exploit them, and can obtain help and guidance when needed. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

evidence an assessor asks for Training module content on phishing and social engineering; Phishing simulation campaign results; Reporting procedure for suspected phishing; Completion records for the module

The entity must keep a list of every TPSP that receives account data from it or that could influence how safe that data is, and must describe the services each one provides. Applicability: using a PCI DSS compliant TPSP neither makes the entity compliant nor removes its own responsibility for compliance. Customized approach objective: records of TPSPs and the services they supply are kept.

evidence an assessor asks for TPSP inventory with service descriptions; Procedure for maintaining the TPSP list; Procurement or contract register reconciled to the list; Records of additions and removals

The entity must hold written agreements with every TPSP that receives its account data or could influence CDE security, and each agreement must contain the TPSP's acknowledgment that it answers for protecting the account data it holds, stores, processes or transmits for the entity, or to whatever extent it could affect the entity's sensitive authentication data or cardholder data. Applicability: exact wording depends on the service and allocated responsibilities and need not match the requirement text. An AOC, website declaration, policy statement, responsibility matrix or other evidence outside a written agreement does not count as a written acknowledgment. Objective under the customized approach: records exist of every TPSP's acknowledgment of its duty to protect account data.

evidence an assessor asks for Executed contracts or addenda with each in-scope TPSP; Security responsibility acknowledgment clauses; Contract review procedure; Tracker linking each listed TPSP to its agreement

PAN must be made unreadable wherever it is stored, using one of these methods: (1) one-way hashes of the whole PAN based on strong cryptography; (2) truncation, where hashing may not substitute for the removed segment, and where hashed and truncated forms, or differing truncation formats, of the same PAN coexist in an environment, added controls must stop them being correlated to rebuild the original; (3) index tokens; (4) strong cryptography with supporting key-management processes and procedures. Applicability: covers PAN in primary storage (databases, flat files such as text files or spreadsheets) and non-primary storage (backups, audit, exception or troubleshooting logs); temporary files holding cleartext PAN during encryption and decryption are not prohibited. Customized approach objective: PAN held on any storage media is never readable in the clear.

evidence an assessor asks for Data storage inventory mapping each PAN location to its protection method; Encryption, hashing, truncation or tokenization design documentation including algorithms; Sample database and log extracts showing PAN unreadable; Backup and archive encryption evidence; Controls preventing correlation of hashed and truncated values (for example keyed hashing, segregation)