Security Questionnaire Mapper

Clause text

PCI DSS v4.0.1: the clauses the register cites

The 12 PCI DSS v4.0.1 clauses that questions are placed on, each with the evidence an assessor asks for and where answers usually fall short.

The text of this standard is not held in full here, so it is not quoted: each requirement carries a one-line statement of what it asks for, with its code and title, and the standard itself holds the wording.

12 clauses

the families they anchor

PCI DSS 3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following

What it asks for, in one line (the standard's own text is not quoted here):

Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:; Coverage for all locations of stored account data.

Evidence an assessor expects: Retention schedule by data type; Secure deletion procedure and logs; Data discovery scan results; Quarterly purge job evidence; Legal hold exception register
Where answers usually fall short: Indefinite retention by default; No deletion proof
Source: PCI DSS v4.0.1

PCI DSS 3.5.1 PAN rendered unreadable wherever stored

What it asks for, in one line (the standard's own text is not quoted here):

PAN is rendered unreadable anywhere it is stored using one of: one-way hashes, truncation, index tokens with secure pads, or strong cryptography with key management.

Evidence an assessor expects: Inventory of PAN storage locations with method per location; Encryption configuration; Tokenisation vendor SAQ; Hash algorithm and salt documentation; Sample database extracts showing rendered output
Where answers usually fall short: Cleartext PAN in backups; Reversible hash without keyed function
Source: PCI DSS v4.0.1

PCI DSS 4.2.1 Strong cryptography and security protocols are implemented

What it asks for, in one line (the standard's own text is not quoted here):

Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:; Only trusted keys and certificates are accepted.; Certificates used to safeguard PAN during transmission

Evidence an assessor expects: Documented policies and procedures defining trusted keys and certificates, and the protocol and cipher suites accepted; System configurations for each PAN transmission endpoint showing the strong cryptography and protocols implemented; Evidence of certificate validity checking, including expiry and revocation status, at the point of transmission; Captured transmission samples or scan output confirming PAN is not sent in the clear on any open public network path; Inventory of trusted keys and certificates in use for safeguarding PAN
Where answers usually fall short: Revocation checking disabled or failing open, so a revoked certificate is still accepted; Strong configuration on the primary endpoint while legacy, failover or administrative endpoints accept weak protocols
Source: PCI DSS v4.0.1

PCI DSS 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates

What it asks for, in one line (the standard's own text is not quoted here):

All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:; Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one

Evidence an assessor expects: Risk appetite statement; Risk tolerance thresholds; Impact and likelihood scales
Where answers usually fall short: Criteria not approved by leadership; Impact and likelihood scales inconsistent
Source: PCI DSS v4.0.1

PCI DSS 7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed

What it asks for, in one line (the standard's own text is not quoted here):

All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:; At least once every six months.; To ensure user accounts and access remain appropriate based on job function.

Evidence an assessor expects: Auditable consent records with timestamp, version, and channel
Where answers usually fall short: Consent capture mechanism does not record purpose, time, and version of notice shown; Withdrawal of consent not as easy as giving consent
Source: PCI DSS v4.0.1

PCI DSS 8.4.2 MFA is implemented for all non-console access into the CDE

What it asks for, in one line (the standard's own text is not quoted here):

MFA is implemented for all non-console access into the CDE

Evidence an assessor expects: Network and system configurations showing multi-factor authentication is implemented for all non-console access into the cardholder data environment; Observation of a non-administrative user logging in with evidence multi-factor was required; Complete enumeration of non-console access paths into the environment, including application, remote desktop and API paths; Evidence covering user accounts as well as administrative ones; Handling of accounts or paths that cannot support multi-factor, with the compensating position documented
Where answers usually fall short: Multi-factor required for administrators under 8.4.1 while ordinary user access into the environment still relies on a single factor; Application to application and batch access paths into the environment excluded with no documented position on why
Source: PCI DSS v4.0.1

PCI DSS 10.4.1 Daily log review for critical systems

What it asks for, in one line (the standard's own text is not quoted here):

The following audit logs are reviewed at least daily: all security events, logs of all CDE system components, logs of critical systems, and logs of authentication, authorization, and accounting services.

Evidence an assessor expects: SIEM dashboard showing daily review sign-off; Documented use cases reviewed daily; Triage tickets from daily reviews; Reviewer assignment and rotation; Sample of recent daily review records
Where answers usually fall short: Reviews skipped on weekends; No sign-off
Source: PCI DSS v4.0.1

PCI DSS 11.3.1 Internal vulnerability scans quarterly

What it asks for, in one line (the standard's own text is not quoted here):

Internal vulnerability scans are performed at least once every three months, with high-risk and critical vulnerabilities resolved per the entity's risk ranking, and re-scans confirm resolution.

Evidence an assessor expects: Quarterly scan reports for past 12 months; Risk ranking documentation; Remediation tickets with closure; Re-scan reports confirming fix; Coverage matrix of scanned assets
Where answers usually fall short: Coverage incomplete; Critical findings open
Source: PCI DSS v4.0.1

PCI DSS 11.4.3 External penetration testing annually

What it asks for, in one line (the standard's own text is not quoted here):

External penetration testing is performed at least once every 12 months and after any significant infrastructure or application upgrade or change.

Evidence an assessor expects: Annual external pen test report by qualified third party; Engagement letter establishing independence; Findings tracker and remediation tickets; Re-test evidence; Statement of work
Where answers usually fall short: Internal team performed external test; Findings open
Source: PCI DSS v4.0.1

PCI DSS 12.5.2 PCI DSS scope documented and confirmed annually

What it asks for, in one line (the standard's own text is not quoted here):

PCI DSS scope is documented and confirmed at least once every 12 months by identifying all data flows, system components, and segmentation controls in use.

Evidence an assessor expects: Scope document with named components; Data flow diagrams covering all CHD flows; Network and segmentation diagrams; Annual scoping exercise minutes and sign-off; Inventory cross-references
Where answers usually fall short: Diagrams stale; Annual scoping skipped
Source: PCI DSS v4.0.1

PCI DSS 12.8.1 Third-party service provider inventory

What it asks for, in one line (the standard's own text is not quoted here):

A list of all third-party service providers (TPSPs) with which account data is shared, or that could affect the security of account data, is maintained, including a description of services provided.

Evidence an assessor expects: TPSP register with contact info and services; Description of data shared or processed per vendor; Internal owner assignment; Annual inventory review records; Onboarding and offboarding workflows
Where answers usually fall short: TPSP register incomplete; No internal owner
Source: PCI DSS v4.0.1

PCI DSS 12.10.1 Incident response plan

What it asks for, in one line (the standard's own text is not quoted here):

An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident, covering roles, responsibilities, communication, containment, and recovery.

Evidence an assessor expects: Incident response plan with named roles; Communication trees including legal, comms, law enforcement; Containment and recovery procedures; Approval and version control; Annual review records
Where answers usually fall short: IRP stale; Roles unassigned
Source: PCI DSS v4.0.1