PCI DSS 4.0

All security policies and operational procedures identified in Requirement 10 are documented, kept up to date, in use, and known to all affected parties, so that logging and monitoring expectations and oversight are defined, repeatable and consistently applied.

• The logging and monitoring policies and operational procedures covering Requirement 10
• Version history or document control record showing they are kept up to date
• Evidence of review and approval within the defined cycle and after process or technology changes
• Distribution, acknowledgement or training records proving affected parties know them
• Interview notes confirming the documented procedures match what personnel actually do

• Policy exists but the operational procedures behind it were never written
• Documents last reviewed years ago and still naming retired tooling
• Procedures not disseminated beyond the security team that wrote them
• Documented process contradicts the observed practice

Roles and responsibilities for performing the activities in Requirement 10 are documented, assigned and understood, so day-to-day accountability for logging and monitoring is allocated and personnel are accountable for the continuous operation of those activities.

• Documented descriptions of roles and responsibilities for Requirement 10 activities
• Responsibility assignment matrix (RACI) or equivalent naming responsible and accountable parties
• Named assignment of each Requirement 10 activity to a role or individual
• Acknowledgement records where personnel accept their assigned responsibilities
• Interview notes confirming personnel understand what they are responsible for

• Responsibilities described generically as belonging to security with no named owner
• Log review assigned to a team that does not know it owns the task
• Matrix exists but was never communicated or acknowledged
• Assignments not updated after reorganisation or outsourcing

Audit logs are enabled and active for all system components and cardholder data.

• Coverage matrix of system components and logging status
• Configuration baselines mandating logging
• SIEM ingestion dashboard showing all sources
• Sample log entries per component
• Gap report for unmonitored systems

• Logging disabled on some components
• Cloud workloads excluded
• No coverage matrix

Audit logs capture all individual user access to cardholder data.

• Sample audit log entries showing user, timestamp, action, data accessed
• Database audit policy configuration
• Application-level audit configuration
• SIEM use case detecting CHD access
• Coverage of all CHD repositories

• DB-level audit missing
• Application logs lack user attribution
• Bulk exports unlogged

Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts.

• PAM session recordings or logs
• OS-level admin command auditing (auditd, sysmon)
• Sample admin event logs
• Coverage of all admin entry points
• Alert rules on admin actions

• sudo not logged
• Cloud console actions missed
• Application admin actions unlogged

Audit logs capture all access to audit logs.

• SIEM configuration logging log access events
• Alerts on unauthorized log access
• Sample log access audit entries
• Procedure for log integrity monitoring
• Coverage of log storage locations

• Log access not logged
• No alerts on log views
• Local log files unprotected

Audit logs capture all invalid logical access attempts.

• Authentication log samples with failed attempts
• SIEM use cases on brute force or credential stuffing
• Threshold-based alerts and tuning evidence
• Coverage across all auth systems
• Sample investigation tickets

• Failures logged but not alerted
• Cloud IAM excluded
• Thresholds too high

Audit logs capture all changes to identification and authentication credentials, including creation, elevation, and modification of accounts with admin access.

• Directory audit log samples for account create, modify, delete
• Alerts on admin group additions
• Sample of recent IAM changes correlated to tickets
• Coverage of IAM platforms
• Procedure for emergency change logging

• Group changes not alerted
• Cloud IAM under-monitored
• Tickets not correlated

Audit logs capture all initialization of new audit logs and all starting, stopping, or pausing of existing audit logs.

• Sample audit log entries showing service start/stop
• Alerts on logging service halt
• Coverage matrix of logging agents
• Procedure for log service maintenance
• Tamper detection on log files

• Service stops not alerted
• Local agent stops invisible
• No tamper detection

Audit logs capture all creation and deletion of system-level objects.

• File integrity monitoring configuration and alerts
• Database object change logs
• OS-level object auditing configuration
• Sample audit entries for object create/delete
• Coverage across cloud and on-prem

• FIM not deployed
• DB schema changes unlogged
• No alerts on critical objects

Audit logs record at least user identification, type of event, date and time, success or failure indication, origination of event, and identity or name of affected data, system component, resource, or service.

• Sample logs containing all six required fields
• Log schema documentation per source
• SIEM normalization mapping
• Coverage matrix verifying field completeness
• Gap remediation tickets

• Source or affected resource missing
• Cloud logs lack origination
• No normalization

Read access to audit log files is limited to those with a job-related need.

• SIEM RBAC configuration
• List of users with log read access and justification
• Quarterly access review evidence
• Audit log of log access permissions changes
• Procedure for granting log access

• Wide read access granted
• No review
• Justification missing

Audit log files are protected to prevent modifications by individuals.

• SIEM configuration with append-only or WORM storage
• Permissions export on local log files
• Procedure for log preservation
• Sample integrity check results
• Alerts on log modification attempts

• Local logs writable
• No WORM storage
• No integrity alerts

Audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal log server or other media that is difficult to modify.

• Architecture diagram of log forwarding
• SIEM ingestion dashboards by source
• Coverage matrix of external-facing systems
• Sample of recent log entries forwarded
• Backup retention configuration

• External systems not forwarding
• Forwarding gaps unnoticed
• No central log server

File integrity monitoring or change-detection mechanisms are used on audit logs to ensure that existing log data cannot be changed without generating alerts.

• FIM tool configuration covering log paths
• Sample FIM alerts on log modification tests
• Coverage list across systems
• Procedure for FIM alert triage
• Periodic FIM health check evidence

• FIM not deployed on logs
• Alerts disabled
• Coverage gaps

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.

• 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

• Reviews skipped on weekends
• No sign-off
• Use cases stale

Automated mechanisms are used to perform audit log reviews.

• SIEM correlation rules export
• UEBA or analytics tool configuration
• Sample alerts and triage
• Tuning records reducing false positives
• Coverage matrix of automated rules

• Manual-only review
• Rules untuned
• No UEBA

Logs of all other system components (those not specified in 10.4.1) are reviewed periodically.

• Review schedule for non-critical systems
• Sample of completed reviews
• Sign-off records by reviewer
• Inventory of systems in scope
• Findings remediation tickets

• Reviews not performed
• Scope unclear
• No remediation

The frequency of periodic reviews for all other system components is defined in the entity's targeted risk analysis.

• TRA document with risk inputs and chosen cadence
• Annual TRA review records
• Approval by senior leadership
• Mapping of cadence to system criticality
• Sample reviews aligned to cadence

• No TRA
• Cadence chosen without analysis
• TRA not updated

Exceptions and anomalies identified during the review process are addressed.

• Ticketing system records for log anomalies
• Escalation procedure
• Sample of recent triaged anomalies
• Metrics on mean time to address
• Lessons learned records

• Anomalies ignored
• No tracking
• Escalation paths unclear

Audit log history is retained for at least 12 months, with at least the most recent three months immediately available for analysis.

• SIEM retention policy configuration
• Hot storage configuration for last 3 months
• Cold storage location and accessibility evidence
• Sample log restoration test results
• Retention policy document

• Retention below 12 months
• Cold storage hard to access
• No restore tests

System clocks and time are synchronized using time-synchronization technology.

• NTP server architecture diagram
• Coverage matrix of systems syncing to authoritative source
• Configuration baselines mandating NTP
• Sample time-sync verification on hosts
• Monitoring of NTP drift

• Some hosts not synced
• No authoritative source
• Drift unmonitored

Systems are configured to the correct and consistent time, with central time servers receiving time from external industry-accepted sources.

• Documented external NTP sources (e.g., NIST, pool.ntp.org)
• Configuration showing stratum hierarchy
• Time drift monitoring dashboard
• Sample of corrected drift events
• Procedure for time source changes

• No external source
• Stratum hierarchy unclear
• No drift monitoring

Time synchronization settings and data are protected, with access to time data restricted and changes logged and monitored.

• RBAC on NTP configuration
• Audit log of NTP configuration changes
• Alerting on NTP source changes
• Procedure for approved time changes
• Sample monitoring records

• Anyone can change time
• Changes not logged
• No alerts

Additional requirement for service providers: failures of critical security control systems are detected, alerted, and addressed promptly, including responses documented.

• List of critical security controls and health monitoring
• Alerting configuration for control failures
• Incident records of past failures
• Response runbooks
• Time-to-detect and time-to-restore metrics

• No health monitoring
• Failures missed
• Response runbooks absent

Failures of critical security control systems are detected, alerted, and addressed promptly for all entities (not just service providers), with documented response procedures.

• Documented list of critical security controls
• Health monitoring configuration per control
• Alert routing to on-call
• Sample failure tickets with response evidence
• Lessons learned records

• List of critical controls missing
• Alerts to no one
• No documented response

Failures of critical security control systems are responded to promptly, including restoring functions, identifying causes, addressing issues, and modifying procedures to prevent recurrence.

• Incident tickets with response timelines
• Root cause analysis documents
• Procedure update records post-incident
• Metrics on MTTR
• Trend analysis of control failures

• No RCA performed
• Procedures not updated
• MTTR not measured

Security policies and operational procedures for Requirement 11 are documented, kept up to date, in use, and known to affected personnel.

• Security testing policy with annual review
• Procedures for scanning, pen testing, monitoring
• Distribution and acknowledgement records
• Training records for test team
• Change history of policy

• Procedures outdated
• Not communicated
• No annual review

Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.

• RACI for testing activities
• Vendor scope documents for pen tests and scans
• Acknowledgement of role assignments
• Job descriptions citing duties
• Training records

• Vendor scope unclear
• No internal owner
• Acknowledgements missing

Authorized and unauthorized wireless access points are managed, with testing for the presence of wireless APs at least once every three months.

• Wireless scan reports for each quarter
• Authorized AP inventory with MAC and location
• WIPS configuration if used
• Procedure for unauthorized AP response
• Sample remediation tickets

• Scans not quarterly
• Inventory stale
• No response procedure

An inventory of authorized wireless access points is maintained, including a documented business justification.

• AP inventory document with business justification
• Update procedure with change control
• Sample reconciliation with WIPS data
• Approval records for new APs
• Photos or location maps

• No justification
• Inventory not updated
• Reconciliation missing

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.

• Quarterly scan reports for past 12 months
• Risk ranking documentation
• Remediation tickets with closure
• Re-scan reports confirming fix
• Coverage matrix of scanned assets

• Coverage incomplete
• Critical findings open
• No re-scan

All other applicable vulnerabilities (not classified as high-risk or critical) are managed via the entity's targeted risk analysis.

• TRA defining handling of lower-severity vulnerabilities
• Classification scheme document
• Sample tickets for medium and low findings
• Remediation SLA tracking
• Annual TRA review

• No TRA
• Lower-severity findings ignored
• SLAs not tracked

Internal vulnerability scans are performed via authenticated scanning, with credentials, where supported.

• Scanner credential vault configuration
• Authenticated scan reports and credential validation
• Coverage list of authenticated vs unauthenticated assets
• Procedure for credential rotation
• Exception list with compensating controls

• Unauthenticated scans only
• Credentials hardcoded in scanner
• Coverage gaps

Internal vulnerability scans are performed after any significant change, with high-risk and critical vulnerabilities resolved.

• Defined criteria for significant change
• Change tickets linked to triggered scans
• Scan reports post-change
• Remediation tickets with closure
• Re-scan evidence

• Significant change undefined
• Scans not triggered
• Findings open

External vulnerability scans are performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV) with passing scans achieved.

• ASV scan reports for past 4 quarters (passing)
• ASV attestation of scan compliance
• Remediation tickets for failed scans
• Re-scan reports confirming pass
• Scope of external-facing IPs

• No passing scan
• Scope incomplete
• ASV not engaged

External vulnerability scans are performed after any significant change, with vulnerabilities scored 4.0 or higher by CVSS resolved and re-scans confirm resolution.

• Change tickets linked to post-change scans
• ASV or internal scanner reports
• Remediation tickets for CVSS 4.0+ findings
• Re-scan reports
• Significant change criteria document

• No post-change scans
• CVSS 4.0+ findings open
• Re-scan missing

A penetration testing methodology is defined, documented, and implemented covering industry-accepted approaches, CDE perimeter coverage, application-layer and network-layer tests, and exploitation of vulnerabilities.

• Pen test methodology document referencing NIST 800-115 or OWASP
• Scope statement covering CDE perimeter and critical systems
• Test plan including app and network layer
• Tester qualifications and certifications
• Engagement letter

• No methodology
• Scope misses critical systems
• Tester qualifications absent

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

• Annual internal pen test report
• Post-change pen test reports
• Tester engagement letters
• Findings remediation tracker
• Re-test evidence

• Tests not annual
• Post-change tests skipped
• Findings open

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

• Annual external pen test report by qualified third party
• Engagement letter establishing independence
• Findings tracker and remediation tickets
• Re-test evidence
• Statement of work

• Internal team performed external test
• Findings open
• No re-test

Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected, with penetration testing repeated to verify corrections.

• Finding-by-finding remediation tracker
• Re-test reports confirming closure
• Sign-off from test owner
• Risk acceptance forms for any unfixed findings
• Lessons learned records

• Findings closed without verification
• No re-test
• Risk acceptances without justification

If segmentation is used to isolate the CDE, penetration testing is performed at least every 12 months and after changes to segmentation controls, to verify segmentation effectiveness.

• Segmentation test scope document
• Annual segmentation test report
• Post-change segmentation test reports
• Findings tracker and remediation
• Network diagrams confirming segmentation

• Segmentation not tested
• Scope misses some boundaries
• Findings unaddressed

Additional requirement for service providers: if segmentation is used, segmentation penetration testing is performed at least once every six months and after any changes to segmentation controls or methods.

• Semi-annual segmentation test reports
• Change-triggered test reports
• Engagement letters
• Remediation tickets
• Customer-facing attestation

• Annual instead of semi-annual
• Change-triggered tests missed
• Customer attestation absent

Additional requirement for multi-tenant service providers: support customer requests for external penetration testing of their hosted environments.

• Documented customer pen test request procedure
• Sample customer request approvals
• Coordination evidence (rules of engagement, scoping)
• Post-test debrief records
• Customer agreement clauses

• No process
• Requests denied without reason
• Coordination informal

Intrusion detection or intrusion prevention techniques are used to detect or prevent intrusions into the network, monitoring all traffic at the CDE perimeter and at critical points within the CDE.

• IDS/IPS architecture diagram with sensor placement
• Coverage matrix at CDE perimeter and critical points
• Signature update logs
• Sample alerts and triage tickets
• Tuning records

• Coverage gaps
• Signatures stale
• Alerts untriaged

Additional requirement for service providers: intrusion detection or prevention techniques detect, alert on, or prevent and address covert malware communication channels.

• DNS, HTTP, and HTTPS inspection configuration
• Threat intelligence feed subscription evidence
• Sample detections of covert channels
• Response runbooks
• Tuning records

• No covert channel detection
• Threat intel not used
• Encrypted traffic not inspected

A change-detection mechanism (e.g., file integrity monitoring) is deployed to alert personnel to unauthorized modification of critical files, with comparisons performed at least weekly.

• FIM tool configuration and critical file inventory
• Weekly comparison reports
• Sample alerts and triage tickets
• Coverage matrix across CDE
• Procedure for change validation

• FIM not deployed
• Scope misses critical files
• Weekly cadence not met

A change- and tamper-detection mechanism is deployed for payment pages to alert personnel to unauthorized modifications to HTTP headers and contents of payment pages as received by the consumer browser.

• Client-side monitoring tool deployment evidence
• HTTP header and script inventory for payment pages
• Sample tamper detection alerts
• Weekly or risk-based scan results
• Response runbooks

• No client-side monitoring
• Script inventory missing
• Alerts untriaged

An overall information security policy is: • Established. • Published. • Maintained. • Disseminated to all relevant personnel, as well as to relevant vendors and business partners

• The overall information security policy document, showing it is established and published
• Evidence of maintenance, such as version control and the record of the last update
• Dissemination records showing the policy reached all relevant personnel as well as relevant vendors and business partners
• Acknowledgement records from personnel and from third parties where applicable
• Evidence the policy states the strategic objectives and principles of information security

• Policy published on an internal site with no dissemination to the vendors and business partners the requirement names
• Acknowledgement captured at induction only, so long serving staff have never acknowledged the current version
• Document exists but reads as a control list rather than stating objectives and principles

The information security policy is: • Reviewed at least once every 12 months. • Updated as needed to reflect changes to business objectives or risks to the environment

• Review records showing the information security policy was reviewed at least once every 12 months, with the date and reviewer
• Evidence of updates made as a result of changes to business objectives or risks to the environment
• The change history linking a specific business or risk change to a specific policy revision
• Approval of the reviewed or updated policy by the appropriate authority
• Interview confirmation from responsible personnel about how the review is triggered and performed

• Review recorded as no change required, with nothing showing the business objectives and risk environment were actually considered
• Review date slips beyond 12 months because the trigger is a calendar reminder held by one person
• Policy updated informally without approval, so the reviewed version and the published version differ

The information security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities, so that they understand their role in protecting cardholder data.

• The information security policy sections defining roles and responsibilities for all personnel
• Signed or system-recorded acknowledgements of information security responsibilities
• Coverage report showing acknowledgement across the whole personnel population, including contractors
• Interview notes with personnel in various roles confirming they understand their responsibilities
• Onboarding process evidence that acknowledgement is captured for new starters

• Policy defines responsibilities for security staff only, not for all personnel
• Acknowledgement captured at hire and never refreshed
• Contractors and third-party personnel excluded from the acknowledgement population
• Acknowledgement recorded but personnel interviews show no understanding

Responsibility for information security is formally assigned to a Chief Information Security Officer or other knowledgeable member of executive management.

• Executive appointment letter or job description
• Org chart showing CISO reporting line
• Charter document outlining authority
• Board minutes referencing CISO updates
• Bio confirming knowledge and qualifications

• No executive owner
• CISO buried in IT
• No board visibility

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.

• Incident response plan with named roles
• Communication trees including legal, comms, law enforcement
• Containment and recovery procedures
• Approval and version control
• Annual review records

• IRP stale
• Roles unassigned
• No communication tree

The incident response plan is reviewed at least once every 12 months and updated as needed, and tested annually.

• Annual IRP review minutes
• Tabletop exercise reports
• Lessons learned and IRP updates
• Participant lists for exercises
• Sign-off by incident response lead

• No annual test
• Tabletop superficial
• Lessons learned not actioned

Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.

• 24/7 on-call schedule with named personnel
• Escalation matrix
• Contact info maintenance procedure
• Sample on-call activations
• Coverage during holidays

• Coverage gaps overnight
• Stale contact info
• No escalation matrix

Personnel responsible for responding to suspected or confirmed security incidents are appropriately and periodically trained on their incident response responsibilities.

• IR training curriculum
• Completion records per responder
• Annual refresher schedule
• Specialized training certifications (GCIH, etc.)
• Tabletop participation records

• No formal training
• Refreshers skipped
• Certifications stale

Frequency of periodic training for incident response personnel is defined in the entity's targeted risk analysis.

• TRA document supporting training cadence
• Annual TRA review
• Completion records aligned to cadence
• Skills assessment evidence
• Approval by IR lead

• No TRA
• Cadence not justified
• Skills assessments missing

The incident response plan includes monitoring and responding to alerts from security monitoring systems including IDS/IPS, network and host-based file integrity monitoring, change-detection mechanisms, anti-malware solutions, and unauthorized payment page change detection.

• IRP section listing alert sources and triage paths
• SIEM playbook integration evidence
• Sample triaged alerts with timeline
• Coverage matrix of alert sources to IRP
• Monitoring tool inventory

• Alert sources missing from IRP
• No playbooks
• Coverage gaps

The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments.

• Post-incident review documents with lessons
• Industry threat intel review records
• IRP change log linked to lessons
• Approval of updates
• Communication of changes to responders

• Lessons learned skipped
• No industry input
• IRP unchanged

Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, including processes to determine PAN was stored, remediation, and prevention.

• Procedure for handling PAN in unexpected locations
• DLP or discovery scan results and triage
• Sample incident records with remediation
• Root cause analysis records
• Prevention controls update evidence

• No discovery process
• Findings not investigated
• Preventive controls not updated

Acceptable use policies for end-user technologies are documented and implemented, addressing approval, authentication, inventory, acceptable use, and remote access controls.

• Acceptable Use Policy document covering required topics
• Personnel acknowledgement records
• Enforcement evidence (DLP, MDM)
• Remote access guidance
• Annual review records

• AUP missing required topics
• Enforcement weak
• Acknowledgements stale

For each PCI DSS requirement that specifies completion of a targeted risk analysis, that analysis is documented and identifies the assets being protected, the threats the requirement protects against, and the factors contributing to the likelihood or impact of a threat being realized. It justifies how the entity-defined frequency or process minimizes that likelihood or impact, is reviewed at least once every 12 months to confirm the results are still valid, and is updated when the review shows an update is needed. Best practice until 31 March 2025, required after that date.

• Documented policy and procedure defining how targeted risk analyses are performed
• Inventory of every PCI DSS requirement where the entity sets its own frequency, each with its targeted risk analysis
• Each analysis showing assets, threats, likelihood and impact factors, and the justification for the chosen frequency
• Evidence of review of each analysis within the last 12 months
• Records of updated analyses triggered by the annual review or by environment change

• A single enterprise-wide risk assessment offered in place of per-requirement targeted analyses
• Frequency chosen first and the analysis written afterwards to justify it
• Some flexible-frequency requirements have no targeted risk analysis at all
• Analyses documented once and never reviewed within 12 months

A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, including documented controls and ongoing monitoring.

• List of requirements met via customized approach
• Controls matrix mapping objective to controls
• Risk analysis per customized control
• Testing procedures for assessor
• Ongoing monitoring evidence

• No documented customized approach
• Monitoring weak
• Controls not mapped

Cryptographic cipher suites and protocols in use are documented and reviewed at least every 12 months, with a plan to address known weaknesses and respond to changes.

• Inventory of crypto algorithms, protocols, key sizes
• Annual review with NIST or industry alignment
• Migration plan for weak algorithms
• Vendor and product list using crypto
• Monitoring for deprecation

• No inventory
• Weak ciphers not flagged
• No migration plan

Hardware and software technologies in use are reviewed at least once every 12 months to confirm vendor support and address end-of-life or unsupported components.

• Inventory of hardware and software with vendor support status
• Annual review records
• EOL or unsupported component list with plan
• Sample replacement projects
• Vendor support contracts

• EOL components in CDE
• No annual review
• No remediation plan

Additional requirement for service providers only. Executive management establishes responsibility for the protection of cardholder data and for a PCI DSS compliance program, covering overall accountability for maintaining PCI DSS compliance and a defined charter for the compliance program communicated to executive management. Executive management may be C-level, the board, or equivalent, and responsibility may be assigned to individual roles or to business units.

• Documented assignment by executive management of responsibility for protecting cardholder data
• The PCI DSS compliance program charter and evidence it was communicated to executive management
• Named executive or role holding overall accountability for maintaining PCI DSS compliance
• Board or executive meeting minutes recording the assignment and the program reporting
• Organisation chart or role description tying the accountability to a real position

• Accountability implied by an org chart but never formally established
• Charter drafted by the security team and never taken to executive management
• Assignment made to a departed individual and not reassigned
• Entity is a service provider but treats this requirement as not applicable

Additional requirement for service providers: reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures.

• Quarterly review reports with sign-off
• Sampling methodology and coverage
• Findings and remediation tickets
• Review meeting minutes
• Trend analysis across quarters

• Reviews not quarterly
• Sampling too narrow
• Findings not tracked

Additional requirement for service providers: reviews per 12.4.2 are documented and include results, remediation actions, and review by personnel assigned responsibility for the PCI DSS compliance program.

• Standardized review template completed each quarter
• Remediation tracker with closure
• Sign-off by PCI program owner
• Escalation records for unresolved items
• Archive of past 12 months of reviews

• Reviews undocumented
• No remediation tracking
• No program owner sign-off

An inventory of system components in scope for PCI DSS is maintained and kept current, including a description of function or use.

• CMDB or asset inventory export covering CDE
• Function or use field per asset
• Update procedure and change control
• Sample reconciliation with discovery scans
• Inventory owner assignment

• Inventory stale
• Function field empty
• No reconciliation

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.

• 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

• Diagrams stale
• Annual scoping skipped
• Flows incomplete

Additional requirement for service providers: PCI DSS scope is documented and confirmed at least once every six months and upon significant change.

• Semi-annual scoping records with sign-off
• Change-triggered scoping reviews
• Updated diagrams per cycle
• Inventory reconciliation
• Customer notification of scope changes if applicable

• Annual only
• Change-triggered reviews missed
• No customer notification

Additional requirement for service providers: significant changes to organizational structure result in a documented review of the impact on PCI DSS scope and applicability of controls.

• Procedure for triggering scope review on org changes
• Sample impact analyses from past M&A or reorg
• Sign-off by PCI program owner
• Updated scope documentation post-change
• Communication records

• No procedure
• Org changes not flagged
• No impact analyses on file

A formal security awareness program is implemented to make all personnel aware of the entity's information security policy and procedures and of their own role in protecting cardholder data, so personnel understand the threat landscape and their responsibility for operating relevant security controls.

• The documented security awareness program and its curriculum
• Program content showing coverage of the information security policy and procedures and of personnel's role in protecting cardholder data
• Completion and attendance records covering all personnel
• Coverage report reconciling completions against the full personnel roster including contractors
• Evidence the program is formally owned and approved

• Awareness delivered as an informal email rather than a formal program
• Content covers generic phishing only and never mentions cardholder data
• Contractors, temporary staff and third parties excluded from the roster
• Completion tracked but non-completers never chased

The security awareness program is reviewed at least once every 12 months and updated as needed to address emerging threats and vulnerabilities relevant to the cardholder data environment.

• Annual review minutes with attendees
• Threat landscape input documentation
• Curriculum change log
• Approval signatures
• Communication of updates

• No annual review
• Curriculum unchanged for years
• Threats not incorporated

Personnel receive security awareness training upon hire and at least once every 12 months, covering threats and vulnerabilities including phishing, social engineering, and acceptable use.

• LMS completion reports per employee
• Training content covering phishing and social engineering
• Phishing simulation results
• Acknowledgement records
• Make-up training for missed sessions

• Training missed at hire
• Phishing not covered
• Completion below 100%

Security awareness training includes threats and vulnerabilities that could impact the security of cardholder data including phishing and related attacks, and social engineering.

• Training module specifically on phishing and social engineering
• Phishing simulation campaign reports
• Click rates and remediation training records
• Curriculum reviewed against current threats
• Sample assessments

• Phishing simulations not run
• No remediation for clickers
• Content generic

Security awareness training includes acceptable use of end-user technologies in accordance with the entity's policies.

• Training module on acceptable use
• Acknowledgement combined with AUP
• Coverage list of relevant personnel
• Annual refresher records
• Sample quiz or assessment

• AUP not in training
• Coverage gaps for remote staff
• No acknowledgements

Potential personnel who will have access to the CDE are screened, within the constraints of local laws, to minimize the risk of attacks from internal sources.

• Background check policy
• Vendor reports for past hires
• Coverage list including contractors with CDE access
• Local law alignment documentation per jurisdiction
• Periodic re-screening procedure if applicable

• Contractors not screened
• Screening shallow
• No jurisdictional alignment

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.

• 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

• TPSP register incomplete
• No internal owner
• Stale entries

Written agreements with TPSPs are maintained, including acknowledgement by the TPSP that they are responsible for the security of cardholder data they possess, store, process, or transmit on behalf of the customer.

• Master agreements with PCI clauses
• DPA or addenda referencing PCI DSS
• Sample agreements per TPSP
• Procurement review checklist
• Legal sign-off records

• No PCI clause
• Acknowledgement language weak
• Old contracts unrenewed

An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.

• TPSP due diligence procedure
• Sample due diligence packs (security questionnaires, SOC 2 reviews)
• Risk assessment outputs per vendor
• Approval records before engagement
• Risk tiering criteria

• Due diligence informal
• No risk tiering
• Engagement without approval

A program is implemented to monitor TPSPs' PCI DSS compliance status at least once every 12 months.

• Annual TPSP compliance review records
• Collected AOCs or compliance reports
• Tracker of TPSP compliance status
• Escalation procedure for non-compliant TPSPs
• Sample evidence requests and responses

• AOCs not collected
• Monitoring annual only in name
• No tracker

Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.

• Responsibility matrix per TPSP mapping each requirement
• Shared controls documentation
• Annual or change-driven update records
• Approval by both parties
• Reconciliation with AOC

• No matrix
• Shared controls ambiguous
• Updates not synced

Additional requirement for service providers: TPSPs acknowledge in writing to customers that they are responsible for the security of account data they possess or otherwise store, process, or transmit on behalf of the customer.

• Standard customer acknowledgement letter or contract clause
• Distribution log to customers
• Acknowledgement renewal schedule
• Legal sign-off records
• Customer queries log

• Acknowledgement not distributed
• Language too narrow
• No renewal cycle

Additional requirement for service providers: TPSPs support their customers' requests for information to meet Requirements 12.8.4 and 12.8.5 by providing PCI DSS compliance status and information about which requirements are the responsibility of the TPSP and which are the responsibility of the customer.

• Customer trust portal or AOC distribution process
• Standard responsibility matrix shared with customers
• SLA for compliance info requests
• Sample customer responses
• Annual update cycle

• No portal
• Slow responses
• Matrix not standardized

All security policies and operational procedures for Requirement 1 are documented, kept current, in use, and known to affected parties.

• Network security control policy document with version history
• Annual review attestation signed by control owner
• Distribution list and acknowledgement records
• Procedures for firewall and router management
• Training material referencing the policy

• Policies older than 12 months
• No evidence of distribution
• Procedures missing operational detail

Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.

• RACI matrix for NSC activities
• Job descriptions referencing NSC duties
• Signed acknowledgements from assigned personnel
• Org chart showing reporting lines
• Interview notes confirming understanding

• Roles assigned only verbally
• No acknowledgement records
• Outdated job descriptions

Configuration standards for network security controls are defined, implemented, and maintained.

• Firewall configuration standard document
• Sample running configurations matching standard
• Change tickets approving deviations
• Baseline comparison reports
• Version-controlled config repository

• Standard exists but devices drift
• No evidence of approval workflow
• Standards do not cover all device types

All changes to network connections and configurations of NSCs are approved and managed via the formal change control process.

• Sample of change tickets for NSC modifications
• Approver signatures or workflow logs
• Pre and post change configuration diffs
• Rollback evidence for failed changes
• Change advisory board minutes

• Emergency changes lack retrospective approval
• Tickets missing business justification
• No technical review evidence

An accurate network diagram is maintained showing all connections between the CDE and other networks.

• Current network diagram with version date
• Annual review sign-off
• Mapping of all ingress and egress points
• Wireless network locations marked
• Third-party connections labelled

• Diagrams not updated after changes
• Missing wireless or cloud segments
• No CDE boundary indicated

A current data flow diagram is maintained showing all account data flows across systems and networks.

• Account data flow diagram with version date
• Inventory of systems handling PAN
• Annual review attestation
• Mapping of storage, processing, transmission points
• Linkage to network diagram

• Flow diagrams missing third-party paths
• No annual refresh
• Tokenisation flows not represented

All services, protocols, and ports allowed are identified, approved, and have a documented business need.

• Inventory of allowed ports, protocols, services
• Business justification document per entry
• Risk acceptance for insecure protocols
• Compensating controls documentation
• Last review date and reviewer

• No justification for legacy protocols
• Insecure protocols allowed without controls
• Inventory not reviewed annually

Security features are defined and implemented for all services, protocols, and ports in use that are considered to be insecure.

• Register of insecure protocols with control mapping
• Configuration showing compensating controls applied
• Risk assessment document
• Approval by senior management
• Quarterly review records

• Controls documented but not implemented
• No senior approval
• Missing review cadence

Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.

• Last two semi-annual review reports
• Reviewer sign-off with date
• List of rules removed or modified
• Stale rule report from firewall tool
• Remediation ticket trail

• Reviews skipped or backdated
• Stale rules left in place
• No reviewer independent of operations

Configuration files for NSCs are secured from unauthorized access and kept consistent with active configurations.

• ACLs on configuration repositories
• Backup vs running config comparison reports
• Access logs to config store
• Encryption at rest evidence
• Version control history

• Running and startup configs diverge
• Backup repository over-permissioned
• No drift detection

Inbound traffic to the CDE is restricted to only that which is necessary; all other traffic is denied.

• Firewall rule export with business justification per rule
• Default deny rule at end of ACL
• Penetration test confirming filter effectiveness
• Sample packet captures
• Rule review report

• Any-any rules present
• Missing explicit deny
• No justification per rule

Outbound traffic from the CDE is restricted to only that which is necessary; all other traffic is denied.

• Egress firewall rules with justification
• Default deny rule evidence
• Monitoring logs of blocked outbound attempts
• Approved destination whitelist
• Periodic review records

• Wide-open egress for convenience
• DNS or NTP allowed to any
• No monitoring of denied traffic

NSCs are installed between all wireless networks and the CDE, denying all wireless traffic except authorized flows.

• Network diagram showing wireless segregation
• Firewall configuration between wireless and CDE
• Authorised wireless device list
• Wireless scan results
• Test of segmentation

• Guest wireless reaches CDE indirectly
• No firewall between corporate wireless and CDE
• Missing wireless inventory

NSCs are implemented between trusted and untrusted networks.

• Definition of trusted versus untrusted zones
• Perimeter device configurations
• Network diagram with trust boundaries
• Asset inventory tagged by zone
• Architecture review document

• Trust zones not defined
• Missing NSC at one perimeter
• Inconsistent enforcement across sites

Inbound traffic from untrusted networks to trusted networks is restricted to communications with authorized publicly accessible system components.

• DMZ architecture diagram
• List of publicly accessible components
• Firewall rules restricting inbound to DMZ only
• Penetration test report
• External port scan results

• Internal hosts reachable from internet
• DMZ used as transit to internal
• Unapproved public services

Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

• uRPF or equivalent configuration on edge devices
• Sample logs of dropped spoofed packets
• Test results from spoofing simulation
• Bogon and martian ACLs
• Annual validation report

• Anti-spoofing disabled for performance
• No logging of drops
• Not configured on all ingress points

System components that store cardholder data are not directly accessible from untrusted networks.

• Database server network placement evidence
• Firewall rules between DMZ and data tier
• Architecture diagram of three-tier design
• Penetration test confirming non-accessibility
• Internal scan results

• Database server reachable through DMZ pivot
• Storage in same VLAN as web
• Missing internal segmentation

The disclosure of internal IP addresses and routing information is limited to authorized parties.

• NAT configuration on perimeter devices
• Split DNS configuration
• External scan showing no internal IPs leaked
• Header sanitisation evidence
• Documented exceptions with approval

• Internal IPs in email headers
• Verbose error pages leak hostnames
• No NAT in cloud egress

Security controls are implemented on any computing devices that connect to both untrusted networks and the CDE to prevent threats entering via these devices.

• Endpoint policy defining required controls
• EDR or host firewall deployment report
• Sample device inspection records
• MDM configuration export
• User attestation of policy

• BYOD devices outside MDM scope
• Personal firewall disabled by user
• No alteration prevention controls

All security policies and operational procedures that are identified in Requirement 2 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• Secure configuration policy with version control
• Annual review attestation
• Distribution and acknowledgement records
• Linked configuration standards
• Training material

• Outdated policy
• No acknowledgement
• Missing operational detail

Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood

• RACI for configuration management
• Job descriptions referencing config duties
• Signed acknowledgements
• Org chart
• Interview confirmations

• Roles not assigned in writing
• Missing acknowledgements
• Stale job descriptions

Configuration standards are developed, implemented, and maintained to: • Cover all system components. • Address all known security vulnerabilities. • Be consistent with industry-accepted system hardening standards or vendor hardening recommendations. • Be updated

• Hardening standards per OS, database, network device
• Mapping to CIS or NIST benchmarks
• Configuration compliance scan reports
• Standard update history
• Coverage matrix versus asset inventory

• No standard for one platform
• Standards not aligned to industry benchmark
• No drift scanning

Vendor default accounts are managed as follows: • If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. • If the vendor default account(s) will not be used,

• Build checklist requiring default cred change
• Sample evidence on deployed systems
• Account inventory showing disabled defaults
• Scanner results confirming no default creds
• Exceptions register with controls

• Defaults left on appliances
• No pre-deployment review
• Service accounts skipped

Primary functions requiring different security levels are managed so that only one primary function exists per component, or different security levels are isolated, or all are secured to the highest level.

• System role inventory
• Architecture diagram showing function separation
• Container or VM isolation evidence
• Configuration review
• Approved exceptions with controls

• Mixed roles on single host
• No isolation between dev and prod functions
• No documented rationale

Only necessary services, protocols, daemons, and functions are enabled. All unnecessary functionality is removed or disabled.

• Per-platform allowed service list
• Configuration audit output
• Removal scripts and logs
• Vulnerability scan reports
• Build review checklist

• Sample systems with unused daemons running
• No baseline scan
• Bloated default images

If any insecure services, protocols, or daemons are present, business justification is documented and additional security features are documented and implemented.

• Register of insecure services with justification
• Senior approval records
• Compensating control configuration
• Risk assessment
• Periodic review records

• Insecure services without controls
• No senior approval
• No periodic re-review

System security parameters are configured to prevent misuse.

• Hardening checklists per platform
• Configuration scan reports
• Sample system inspections
• Parameter standards document
• Drift remediation tickets

• Default parameters unchanged
• No periodic verification
• Inconsistent application across estate

All non-console administrative access is encrypted using strong cryptography.

• SSH and TLS configuration on admin interfaces
• Disabled telnet and HTTP admin evidence
• Cipher suite review
• Network scan confirming encrypted admin only
• Jump host configuration

• Legacy management interfaces use HTTP
• Weak cipher suites enabled
• Admin via cleartext on internal networks

For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or confirmed secure.

• Wireless build checklist
• Sample AP configuration
• SSID and key change records
• WPA2 or WPA3 enterprise configuration
• Wireless audit reports

• Default SNMP strings on APs
• WEP or WPA still in use
• Default admin credentials

For wireless environments connected to the CDE, encryption keys are changed when personnel with knowledge of the key leave or when keys are suspected of being compromised.

• Wireless key rotation log
• Leaver process linked to key rotation
• Incident records triggering rotation
• Approved key management procedure
• Distribution records

• No rotation on leavers
• PSKs never changed
• No documented process

The full contents of any track are not retained after authorization.

• Data discovery scan for magstripe patterns
• Application code search results
• Database column audit
• Sample QA test
• Vendor confirmation letter

• Track data captured in debug logs
• Lab environments retain track
• Backups contain track data

The card verification code is not retained after authorization.

• Log search for three- or four-digit CVV patterns
• Database column inventory
• Application code review
• Vendor attestations
• QA test cases

• CVV in app debug logs
• Saved in fraud screening systems
• Found in support tickets

Personal identification number (PIN) and the encrypted PIN block are not retained after authorization.

• HSM transaction logs showing PIN destruction
• Application code review
• Data discovery scan
• Vendor attestation
• Penetration test confirming no PIN at rest

• PIN block in transaction archive
• Encrypted PIN retained for analytics
• HSM not used for PIN handling

SAD stored electronically prior to completion of authorization is encrypted using strong cryptography.

• Encryption configuration for SAD storage
• Key strength documentation
• Test of stored SAD format
• Cryptographic library version evidence
• Code review records

• Cleartext SAD on disk pre-auth
• Weak ciphers used
• No verification testing

For issuers and entities supporting issuing services that store SAD, SAD storage is limited to that needed for legitimate business need and is secured.

• Business justification document
• Encrypted storage configuration
• Access logs to SAD stores
• HSM integration evidence
• Annual review of need

• No documented business need
• Over-broad access
• Indefinite retention

When using remote-access technologies, technical controls prevent copy and relocation of PAN for all personnel except those with documented, explicit authorization.

• DLP policy blocking PAN egress
• VDI or jump host configuration disabling clipboard and storage
• Authorisation register
• Sample test of copy prevention
• Quarterly review of permitted users

• Clipboard not disabled on remote sessions
• DLP not tuned for PAN
• No authorisation register

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.

• 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

• Cleartext PAN in backups
• Reversible hash without keyed function
• Mixed methods inconsistent

Hashes used to render PAN unreadable are keyed cryptographic hashes of the entire PAN with associated key management processes.

• HMAC or equivalent configuration
• Key custodian records
• Algorithm and key length documentation
• Code review showing entire PAN hashed
• Key rotation evidence

• Plain SHA without key
• Truncated PAN hashed
• No key rotation

If disk-level or partition-level encryption is used to render PAN unreadable, it is implemented only on removable media or together with another mechanism that meets 3.5.1, with logical access separate from native OS authentication.

• Disk encryption configuration
• Documentation showing additional layer
• Logical access design separate from OS
• Key custody records
• Architecture review

• Disk encryption alone on non-removable media
• Same credential for OS and encryption
• No layered control

If disk-level or partition-level encryption is used, cryptographic keys are managed in accordance with Requirements 3.6 and 3.7.

• Key custodian assignments
• Key storage and rotation procedures
• HSM or KMS evidence
• Access control to keys
• Audit log review

• Keys stored alongside data
• No documented custody
• Missing rotation evidence

A documented description of the cryptographic architecture is maintained, including algorithms, protocols, keys, key strengths, expiry dates, and locations of cryptographic devices.

• Cryptographic architecture document with version
• Key inventory with strength and expiry
• HSM and KMS inventory
• Algorithm justification
• Annual review attestation

• No architecture document
• Inventory missing legacy keys
• Strength below 112 bits accepted

Secret and private keys used to protect stored account data are stored in encrypted form, within a secure cryptographic device, or as key components, with access restricted to the fewest custodians necessary.

• Custodian list and access logs
• HSM access logs
• Key encryption key documentation
• Split knowledge configuration
• Periodic access review

• Wide custodian access
• Keys stored without wrapping
• No access review

Access to cleartext cryptographic key components is restricted to the fewest custodians necessary.

• Approved custodian register
• Access control on KMS or HSM
• Quarterly access review
• Logs of key access events
• Job description references

• Shared admin accounts with key access
• No access logging
• No review cadence

Cryptographic keys are stored in the fewest possible locations.

• Key storage location inventory
• Architecture diagram
• Justification for each location
• HSM consolidation evidence
• Annual review

• Keys copied across hosts
• No inventory
• Legacy copies not retired

Key management policies and procedures address secure distribution of cryptographic keys.

• Key distribution procedure
• Wrapped key transport logs
• Out-of-band channel documentation
• Custodian receipts
• Test of mechanism

• Keys emailed in cleartext
• No wrapping
• No record of distribution

Key management policies and procedures address secure storage of cryptographic keys.

• Storage method documentation per key
• HSM or vault configuration
• Wrapping key inventory
• Access control records
• Audit logs

• Keys in config files
• Plain text in repositories
• No HSM where required

Key management policies and procedures address cryptographic key changes for keys that have reached the end of their cryptoperiod.

• Cryptoperiod documented per key
• Rotation log with dates
• Automated rotation configuration
• Re-encryption evidence
• Post-rotation validation

• No cryptoperiod defined
• Keys never rotated
• Rotation evidence missing

Key management policies and procedures address retirement, replacement, or destruction of keys when integrity has been weakened or keys are suspected of compromise.

• Retirement procedure document
• Destruction logs from HSM
• Replacement evidence
• Compromise event response records
• Custodian sign-off

• Retired keys not destroyed
• No procedure for compromise
• Old keys still accepted

Where manual cleartext key management operations are performed, they use split knowledge and dual control.

• Key ceremony script and recordings
• Two-custodian sign-off forms
• Split component custody records
• Procedure document
• Video or witness logs

• Single custodian handles key
• No ceremony documentation
• Split components stored together

Key management policies prevent unauthorized substitution of cryptographic keys.

• Approval workflow for key changes
• Integrity verification mechanism
• Logs of key replacement events
• Dual approval evidence
• Reconciliation reports

• Single admin can swap keys
• No integrity check
• No approval trail

Key custodians formally acknowledge in writing that they understand and accept their key custodian responsibilities.

• Signed custodian acknowledgement forms
• Responsibility document
• Training completion records
• Annual refresh evidence
• Custodian inventory

• No signed forms
• Forms outdated
• Custodians unaware of duties

Additional requirement for service providers: cryptographic keys used to protect stored customer account data are managed under a documented agreement with the customer or based on service provider responsibilities.

• Customer responsibility matrix per contract
• Master agreement clauses
• Annual confirmation to customers
• Internal procedure document
• Customer onboarding evidence

• No matrix shared with customers
• Inconsistent responsibilities across customers
• No annual confirmation

All security policies and operational procedures that are identified in Requirement 3 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• Authorized user roster
• Device authorization records
• Access request workflow output
• Examine identification process
• Test unauthorized access denial

• Service accounts not enumerated
• BYOD authorization unclear
• Contractor devices missing from inventory
• No periodic review of authorization list

Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood

• Role to function matrix
• Application authorization configuration
• Sample access reviews
• Examine RBAC implementation
• Test for unauthorized function execution

• Application level controls absent
• ERP transaction restrictions undocumented
• API authorization not tested
• Sample size too small

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.

• Retention schedule by data type
• Secure deletion procedure and logs
• Data discovery scan results
• Quarterly purge job evidence
• Legal hold exception register

• Indefinite retention by default
• No deletion proof
• Discovery scans miss locations

SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process

• Logging policy with retention period
• Sample audit records
• SIEM ingest list
• Examine log content fields
• Test log creation across systems

• Cloud audit logs not retained
• Retention period inconsistent across systems
• Audit log integrity not assessed
• Gaps in log generation for critical events

PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can

• Approved baselines per OS and platform
• Asset inventory export
• Baseline change records
• Examine baseline currency
• Test inventory completeness

• Shadow IT not in inventory
• Firmware versions not tracked
• Baseline for network devices missing
• Documentation not version controlled

Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: • Access to keys is restricted to the fewest number of custodians necessary.

• Incident response plan
• Playbook library
• Tabletop after action reports
• Examine team roster
• Test detection to recovery flow

• CUI specific incidents not exercised
• External notification timelines unclear
• Lessons learned not implemented
• Forensic capability not validated

Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data

• Documented key generation procedure
• HSM key generation logs
• Entropy source documentation
• Key strength approval
• Sample generation evidence

• Keys generated on commodity hosts
• Insufficient entropy
• No procedure document

All security policies and operational procedures that are identified in Requirement 4 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• The documented policies and operational procedures covering transmission of cardholder data over open public networks, including the protocols and key strengths permitted
• Version history or review record showing the transmission security procedures are kept up to date
• Evidence the procedures are in use, such as change records citing them when a certificate or protocol was updated
• Distribution and acknowledgement records for the network, application and vendor management staff affected by them

• Procedures name TLS versions and cipher suites that were current when written and were never revised as protocols were deprecated
• Documented centrally and unknown to the teams terminating TLS at load balancers, gateways and third party endpoints
• Procedures exist for internal transmissions but omit the customer facing and partner channels that carry PAN

Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood

• Documented descriptions of the roles responsible for Requirement 4 activities, covering certificate management, protocol configuration and inventory of PAN transmissions
• Assignment records naming the individuals or teams holding each role
• Interview confirmation that the assigned personnel understand their day to day transmission security responsibilities
• Evidence of continuity arrangements, such as a named deputy for certificate expiry response

• Certificate ownership assigned to whoever created the certificate, so it lapses when they change roles
• Responsibility documented at team level with no named accountable individual, so expiries fall between teams
• Cloud and third party terminated transmissions have no assigned owner at all

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

• 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

• 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
• Certificate inventory absent, so expiry is discovered by outage rather than by management

An inventory of trusted keys and certificates used to protect PAN during transmission is maintained.

• Certificate and key inventory with expiry dates
• Automated discovery scan output
• Renewal calendar
• Revocation check evidence
• Trust store review

• No central inventory
• Expired certs in use
• Forgotten internal CAs

Wireless networks transmitting PAN or connected to the CDE use industry best practices for strong cryptography for authentication and transmission.

• Wireless configuration showing WPA2 Enterprise or WPA3
• Disabled WEP and WPA evidence
• Authentication mechanism documentation
• Wireless audit scan
• Penetration test results

• WPA PSK in use for CDE traffic
• WEP enabled on legacy AP
• No EAP authentication

PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies

• Documented policies and procedures prohibiting cleartext PAN over end-user messaging technologies such as email, chat and SMS
• System configurations and vendor documentation showing the mechanism that secures or blocks PAN in those channels
• Evidence of detection or blocking in practice, such as data loss prevention rule output for PAN patterns in messaging
• The defined process for handling a customer or third party who sends PAN in the clear, including secure alternatives offered
• Awareness material showing personnel know they must not transmit PAN this way

• Policy forbids the practice with no technical detection, so the only evidence is that nobody has reported it
• Email covered while chat, ticketing systems and SMS carry the same data unmonitored
• Inbound PAN from customers accepted and left sitting in mailboxes and ticket histories in the clear

All security policies and operational procedures that are identified in Requirement 5 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• Documented policies and operational procedures for anti-malware protection, covering which system components are in scope and the evaluation for those deemed not at risk
• Review record showing the anti-malware procedures are kept up to date
• Evidence of use, such as the periodic evaluation records the procedures require
• Distribution and awareness evidence for the endpoint, server and operations personnel affected

• Procedures cover workstations and servers while the periodic evaluation for components deemed not at risk is undefined
• Written once and not updated when the organisation moved to container and serverless workloads
• Kept by the security team and unknown to the platform teams who build the images

Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood

• Documented descriptions of roles for Requirement 5 activities, covering deployment, signature currency, alert triage and the periodic evaluation of components not at risk
• Assignment records naming who holds each role
• Interview confirmation that assigned personnel understand their day to day anti-malware duties
• Escalation path for malware detections, showing who acts outside business hours

• Alert triage assigned to a shared mailbox with no individual accountable for response
• Signature and engine currency assumed to be the vendor's responsibility with nobody checking it
• No owner for the periodic evaluation of components deemed not at risk, so it never happens

The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity's targeted risk analysis.

• Targeted risk analysis document for 5.2.3
• Defined frequency with rationale
• Approval by management
• Evidence of evaluations at chosen cadence
• Linkage to 12.3.1 process

• No targeted risk analysis
• Frequency undefined
• Frequency not justified

If periodic scans are used to meet 5.3.2, the frequency is defined in the entity's targeted risk analysis.

• Targeted risk analysis document
• Frequency with rationale
• Management approval
• Evidence of scans at defined cadence
• Linkage to 12.3.1

• Frequency not justified
• No analysis document
• Cadence not followed

Audit logs for the anti-malware solution are enabled and retained in accordance with Requirement 10.5.1.

• Log configuration on AV console
• SIEM ingestion evidence
• Log retention policy
• Sample log extracts
• Tamper protection evidence

• Logs local-only, not forwarded
• Retention shorter than 12 months
• No tamper protection

Anti-malware mechanisms cannot be disabled or altered by users unless specifically documented and authorized by management on a case-by-case basis for a limited time period.

• Policy configuration preventing disablement
• Exception register with approvals and expiry
• Sample test of user-attempted disable
• Logs of authorised disablement
• Re-enablement verification

• Local admin can disable AV freely
• Exceptions open-ended
• No re-enablement verification

Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks

• Documentation of the automated mechanisms deployed to detect and protect against phishing, such as mail authentication enforcement, link and attachment inspection and impersonation controls
• Configuration evidence for each mechanism, showing the action taken on detection
• Processes complementing the mechanisms, such as reporting routes and response to a reported phish
• Records of phishing detections and the outcome of each during the period
• Evidence coverage extends to all personnel with access to system components, including contractors and privileged administrators

• Awareness training presented as the control, where the requirement calls for automated mechanisms as well as processes
• Mail authentication published in monitor mode rather than enforcing, so spoofed senders still arrive
• Protection applied to corporate mail while collaboration platforms and personal device access are uncovered

An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware

• Approved PIMS scope statement
• Stakeholder map showing data subjects, regulators, and third parties

• No documented identification of internal and external privacy-relevant issues
• PII processing roles (controller/processor) not formally determined
• Jurisdictional privacy obligations not catalogued against operating context
• No periodic review of context changes affecting the PIMS

The deployed anti-malware solution(s): • Detects all known types of malware. • Removes, blocks, or contains all known types of malware

• Mapping of legal, regulatory, and contractual privacy obligations to PIMS controls

• Interested parties relevant to PII processing not enumerated
• Requirements of PII principals, regulators, and customers not captured in a single register
• No mapping from stakeholder expectations to specific PIMS controls
• Updates to legal and contractual privacy requirements not tracked

Any system components that are not at risk for malware are evaluated periodically to include the following: • A documented list of all system components not at risk for malware. • Identification and evaluation

• Scope diagram showing PII flows, processing locations, and system boundaries

• PIMS scope statement does not list PII categories, processing activities, and locations
• Boundaries between controller and processor activities unclear
• Excluded systems or business units not justified in writing
• Scope not reconciled with the ISMS scope statement

The anti-malware solution(s) is kept current via automatic updates

• Management review minutes addressing PIMS
• Board or executive sign-off on privacy policy

• No top-management statement of accountability for PII protection
• Privacy objectives not integrated with strategic business objectives
• Resources for the PIMS not formally approved or tracked
• Leadership review of privacy performance not on a fixed cadence

The anti-malware solution(s): • Performs periodic scans and active or real-time scans. OR • Performs continuous behavioral analysis of systems or processes

• Policy version history
• Publication evidence (intranet, website)

• Privacy policy does not differentiate controller and processor commitments
• Policy not approved by a named accountable executive
• No defined cadence for privacy policy review and reissue
• Policy not communicated to staff, processors, and PII principals in a verifiable way

For removable electronic media, the anti- malware solution(s): • Performs automatic scans of when the media is inserted, connected, or logically mounted, OR • Performs continuous behavioral analysis of systems or processes when the

• Org chart showing privacy function
• Contact details published where required by law

• No documented role responsible for PIMS operation (DPO or equivalent)
• Privacy responsibilities not embedded in job descriptions
• Authority to approve privacy risk treatment not assigned
• Segregation of duties for PII processing decisions not defined

All security policies and operational procedures that are identified in Requirement 6 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• Documented policies and operational procedures for secure software development, vulnerability identification and change management
• Review record showing the development security procedures are kept up to date against current languages and platforms
• Evidence of use, such as change tickets and code review records citing the procedures
• Distribution and acknowledgement evidence for development, quality assurance and release personnel

• Procedures written for the previous technology stack and never revised for current frameworks and pipelines
• Formal change procedure documented while emergency and pipeline driven changes proceed under no procedure at all
• Third party and outsourced developers not covered by the documented procedures

Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood

• Documented descriptions of roles for Requirement 6 activities, covering secure coding, vulnerability ranking, patching and change approval
• Assignment records naming who holds each role
• Interview confirmation that development personnel understand their day to day security responsibilities
• Evidence that responsibility for public facing web application protection is explicitly assigned

• Vulnerability ranking assigned to nobody, so severity is taken from the scanner default
• Security responsibilities described for the security team rather than for the developers who perform the activities
• Release approval authority undocumented, so changes ship on informal sign off

Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for example, secure authentication and logging). • Incorporating

• Documented software development procedures showing development is based on named industry standards or practices for secure development
• Evidence the procedures require PCI DSS aligned outcomes such as secure authentication and logging in bespoke and custom software
• Evidence information security is considered at each stage of the development life cycle, not only at test
• Design or requirements artefacts from a real project showing security considered during design
• Records of review or approval confirming software was developed under these procedures

• Secure development claimed from a scanning step in the pipeline, with no security consideration during requirements and design
• Standard named in the procedure with no mapping to what developers actually do
• Bespoke software from third parties developed outside the organisation's procedures with no equivalent imposed

Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: • On software security relevant to their job function and development languages. • Including secure

• Software development procedures defining the training required, its content and its at least annual frequency
• Training content showing coverage of software security relevant to job function and development languages, secure design and secure coding techniques
• Training content covering the use of tools for detecting vulnerabilities in software where such tools are used
• Training records and attendance evidence for each developer working on bespoke and custom software, with dates
• Evidence the training is refreshed within 12 months for each individual

• Generic security awareness recorded as developer training, missing the language and job function specificity required
• Training completed at induction only, so the annual cycle lapses for existing staff
• Contract developers excluded from the training records despite working on bespoke software

Bespoke and custom software is reviewed prior to release into production or to customers to identify and correct potential coding vulnerabilities, by knowledgeable individuals other than the originating developer using both manual and automated methods.

• Pull request review evidence with reviewer name
• SAST scan results per release
• Code review checklist
• Issue tracker showing remediation
• Approval gate before deployment

• Self-approval of pull requests
• SAST not blocking on findings
• No manual review evidence

If manual code reviews are performed, code changes are reviewed by individuals other than the originating author who are knowledgeable about code review techniques and secure coding, code reviews ensure code is developed per secure coding guidelines, appropriate corrections are implemented prior to release, and code review results are reviewed and approved by management prior to release.

• Reviewer competency records
• Code review checklists completed
• Corrections evidence in version control
• Management approval before release
• Release sign-off

• Reviewers without secure-coding training
• Findings closed without fix
• Management approval missing

Software engineering techniques or other methods are defined and used by software development personnel to prevent or mitigate common software attacks and related vulnerabilities (e.g., injection, broken auth, XSS).

• Secure coding guideline document
• Mapping to OWASP Top 10
• SAST and DAST configuration
• Sample remediated findings
• Library and framework standards

• Guideline exists but not enforced
• No DAST in pipeline
• Vulnerability classes ignored in scanner config

For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: • Reviewing public-facing web applications via manual or automated application

• Documented process defining which of the permitted methods is used for public-facing web applications
• Where assessment is used, records of reviews at least once every 12 months and after each change, by an entity specialising in application security
• Evidence that all vulnerabilities found were ranked, corrected and the application re-evaluated after correction
• Inventory of public-facing web applications, reconciled so none are outside the process
• Independence evidence for the assessing party

• Annual assessment performed while the after each change trigger is ignored, which is where most exposure appears
• Findings corrected without re-evaluation, so the fix is unverified
• Application inventory incomplete, missing marketing sites and APIs that reach the same environment

For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: • Is installed in front of public-facing web applications and is configured

• Evidence of the automated technical solution installed in front of public-facing web applications
• Configuration showing it is set to detect and prevent web-based attacks rather than to log only
• Evidence it is actively running and up to date, with the version or ruleset in use
• Audit logs generated by the solution, and evidence they are retained and reviewed
• Coverage evidence reconciling protected applications against the public-facing application inventory

• Solution deployed in detection mode indefinitely because blocking risks false positives, so it never prevents
• Applications reachable by a path that bypasses the solution, such as a direct origin address
• Rulesets left at deployment defaults with no update process, so new attack classes are unaddressed

Live PANs are not used in pre-production environments except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.

• Policy prohibiting live PAN in test
• Data masking or synthetic data process
• Sample scans of test databases
• Developer training on test data
• Exception register

• Live PAN copied for debugging
• Masking incomplete
• No test data governance

Test data and test accounts are removed from system components before the system goes into production.

• Release checklist requiring removal
• Sample pre-production review
• Scanner output confirming no test accounts
• Sign-off evidence
• Post-go-live verification

• Test accounts left active in production
• No release checklist item
• Test data in production tables

Security vulnerabilities are identified and managed as follows: • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). • Vulnerabilities

• Scope statements per assessment
• Objectives definition
• Boundaries and exclusions

• Risk assessment scope unbounded
• Excluded systems not justified
• Boundaries not updated after change
• Shadow IT not captured
• Cloud assets out of scope

An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management

• External and internal context analysis per assessment
• Stakeholder map
• Relevant objectives

• External factors not documented
• Internal culture and capability ignored
• Threat intel not integrated
• Regulatory updates not tracked
• Risk drivers not refreshed

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

• Risk appetite statement
• Risk tolerance thresholds
• Impact and likelihood scales

• Criteria not approved by leadership
• Impact and likelihood scales inconsistent
• Appetite and tolerance not stated
• Criteria not applied uniformly
• Privacy specific criteria missing

All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A method is implemented

• Risk analysis records
• Scenario analyses
• Control effectiveness ratings

• Analysis methods inconsistent
• No traceability from threats to risks
• Quantitative inputs unsupported
• Privacy risks treated as security only
• Analysis not peer reviewed

Changes to all system components in the production environment are made according to established procedures that include: • Reason for, and description of, the change. • Documentation of security impact. • Documented change approval

• Treatment plans
• Treatment options analysis
• Residual risk records

• Treatment options not evaluated
• No treatment plan template
• Risk owner approval missing
• Treatment not linked to register
• Costs and benefits not analyzed

Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable

• Cost benefit analyses
• Option appraisal records
• Legal and regulatory review

• Only mitigation considered
• No structured option appraisal
• Transfer via insurance not analyzed
• Acceptance lacks justification
• Privacy controls not mapped

Pre-production environments are separated from production environments and the separation is enforced with access controls

• Approved treatment plans
• Action owners and due dates
• Resource allocation

• Plans lack owners and dates
• No status tracking
• Dependencies not managed
• Resources not allocated
• Implementation evidence missing

Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed

• Residual risk acceptance records
• Escalation logs
• Further treatment plans

• Residual risk not calculated
• Acceptance not signed off
• No monitoring for residual triggers
• Re evaluation cycle missing
• Aggregate residual exposure unknown

All security policies and operational procedures that are identified in Requirement 7 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• Documented policies and operational procedures for restricting access to system components and cardholder data by business need to know
• Review record showing the access control procedures are kept up to date
• Evidence of use, such as access request records that follow the documented procedure
• Distribution evidence to system owners, managers who approve access and administrators who provision it

• Procedures describe the joiner process while movers and leavers, where access accumulates, are thin
• Documented for the primary application with cloud consoles, databases and administrative tooling uncovered
• Approvers unaware of the procedure, so approvals are given without applying need to know

Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood

• Documented descriptions of roles for Requirement 7 activities, covering definition of the access control model, approval of privileges and periodic review
• Assignment records naming who holds each role
• Interview confirmation that assigned personnel understand their day to day access control responsibilities
• Evidence that authority to approve privileged access is explicitly assigned and bounded

• Approval authority assumed by line managers with no documented assignment or limit
• Ownership of the access control model itself unassigned, so it ages without review
• Administrators provision access on request with nobody accountable for whether need to know was applied

An access control model is defined and includes granting access as follows: • Appropriate access depending on the entity's business and access needs. • Access to system components and data resources that is based

• The documented access control model showing access granted by business and access needs
• Evidence access is based on job classification and function, with the role to entitlement mapping
• Documentation of the least privileges required for each job classification
• Access control model settings examined against the documented model to confirm they agree
• Approval record for the model itself by authorised personnel

• Model documented in policy while entitlements in the system were built up historically and do not match it
• Job classifications defined so broadly that least privilege has no meaning
• Privileged and service accounts excluded from the model entirely

Access is assigned to users, including privileged users, based on: • Job classification and function. • Least privileges necessary to perform job responsibilities

• Policies and procedures covering assignment of access to users based on job classification and function
• User access settings extracted from system components, including for privileged users
• Comparison of assigned access against the job classification for a sample of users, showing least privilege applied
• Management confirmation that the access held by their staff is what the role requires
• Records showing access reduced when a user changed role

• Access cloned from an existing user at onboarding, which propagates accumulated privilege
• Privileged users assigned broad administrative rights because scoping them is harder than granting them
• Role changes add new access without removing the old, so entitlement only ever grows

Required privileges are approved by authorized personnel

• Policies and procedures defining the approval process for privileges and who is authorised to approve
• Documented approvals for a sample of user IDs, matched against the privileges actually assigned
• Evidence that the approval specifies the privileges granted, so assignment can be checked against it
• Evidence no privileges exist without a corresponding documented approval
• Records showing an approval was refused or reduced, demonstrating the process is real

• Approvals held as email threads that do not state which privileges were approved
• Privileges assigned first and approved retrospectively, or never
• Approver is the same person as the requester for administrative accounts

Application and system account access is reviewed at a frequency defined in the entity's targeted risk analysis (TRA).

• TRA document supporting chosen review frequency
• Review schedule and completed review reports
• Tickets remediating findings from reviews
• Sign-off from account owner per review
• Audit log of permission changes

• No TRA on file
• Review frequency too low for risk
• Findings open beyond SLA

The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function

• Vendor documentation and system settings for the access control system showing enforcement of permissions by job classification and function
• Evidence permissions apply to individuals, applications and systems, covering non-human identities
• Configuration showing individual rights are inherited from group membership rather than granted directly
• Sample extracts of effective permissions demonstrating what the system actually enforces
• Reconciliation between the enforced permissions and the documented access control model

• Direct individual grants layered on top of group membership, so effective access differs from the model
• Application and system accounts assigned permissions outside the access control system
• Enforcement verified from the configuration screen rather than from effective permission output

The access control system(s) is set to “deny all” by default

• Vendor documentation and system settings showing the access control system is set to deny all by default
• Configuration evidence for each in scope access control system, not only the primary one
• Test evidence that an identity with no assigned permission is refused
• Evidence that default or built-in permissive entries have been removed or restricted
• Change control preventing the default from being relaxed

• Default deny at the application while the database or file share underneath grants broad read
• Built-in groups such as everyone or authenticated users left with permissions, defeating the default
• Deny all asserted from product documentation with no test on the actual deployment

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.

• Auditable consent records with timestamp, version, and channel

• Consent capture mechanism does not record purpose, time, and version of notice shown
• Withdrawal of consent not as easy as giving consent
• Consent records not retained for the duration of processing
• Consent not refreshed when purposes materially change

All application and system accounts and related access privileges are assigned and managed as follows: • Based on the least privileges necessary for the operability of the system or application. • Access is limited

• Completed PIAs with sign-offs
• Regulator consultation records where required

• No defined trigger criteria for when a PIA is required
• PIA template does not cover necessity, proportionality, and principal rights
• PIAs not reviewed when processing changes materially
• PIA outcomes not linked to risk treatment and control implementation

All user access to query repositories of stored cardholder data is restricted as follows: • Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges. •

• Executed DPAs and due diligence records

• Processor contracts missing required instructions on purpose and duration
• Sub-processor flow-down obligations not enforced
• No documented process to assess processor compliance before onboarding
• Termination assistance and data return clauses missing

An access control system(s) is in place that restricts access based on a user's need to know and covers all system components

• Workflow diagrams for each right (access, rectification, erasure, portability, restriction, objection)

• No documented process for handling each principal right (access, rectification, erasure, portability, objection)
• Identity verification for rights requests not standardised
• Response timelines not tracked against statutory deadlines
• Rights request log and outcomes not retained as evidence

All users are assigned a unique ID before access to system components or cardholder data is allowed

• Evidence that every user is assigned a unique ID before access to system components or cardholder data is allowed
• User account lists from in scope components showing no shared or generic IDs outside approved exceptions
• Audit logs demonstrating actions can be traced back to an individual user
• Provisioning records showing ID assignment precedes access being granted
• Reconciliation of accounts against the current personnel list to identify orphans

• Unique IDs at the application while the database, operating system or appliance is accessed through a shared administrative account
• Contractors and third party support using a shared vendor account, so their actions are unattributable
• Service accounts used interactively by named people, breaking attribution

Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: • ID use is prevented unless needed for an exceptional

• User account lists and documentation identifying every group, shared or generic ID and other shared authentication credential in use
• The exceptional circumstance justifying each, with management approval
• Evidence use is prevented unless needed and limited to the time needed for that circumstance
• Records showing individual user identity is confirmed before use of a shared ID, and the actions taken are attributable
• Evidence shared credentials are changed when someone with knowledge of them leaves

• Shared administrative accounts used routinely rather than on an exception basis, with the exception rationale written once
• Credential not changed after a holder departs, so the account remains usable by them
• Use of the shared ID not linked back to an individual, so no attribution exists for the period of use

Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises

• Authentication policies and procedures for service provider remote access to customer premises
• Evidence a unique authentication factor is used for each customer premises, such as per customer credentials or certificates
• Inventory of customer environments accessed remotely and the distinct factor used for each
• Interview confirmation from support personnel about how they authenticate to each customer
• Records showing a factor compromised for one customer cannot be used at another

• One support tool account reused across the customer base, so a single compromise reaches every customer
• Unique accounts created per customer but sharing one password across them
• Per customer factors issued at onboarding and never rotated as support staff change

Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: • Authorized with the appropriate approval. • Implemented with only the privileges specified on the documented approval

• Documented authorisations covering additions, modifications and deletions of user IDs, authentication factors and identifier objects
• System settings and account records showing the privileges implemented match those on the documented approval
• Evidence lifecycle events are logged, so an unauthorised change would be visible
• A sample walk through comparing an approval to the resulting account state
• Records showing a modification request was refused or altered before implementation

• Approval covers the addition while later modifications proceed on informal request
• Implemented privileges exceed the documented approval, and nothing compares the two
• Deletions performed without record, so it cannot be shown when access ended

Access for terminated users is immediately revoked

• Termination information source, such as the human resources leaver feed, and evidence it reaches the access administration process
• Current user access lists for both local and remote access, checked against recent terminations
• Evidence terminated user IDs are deactivated or removed immediately rather than at the next review
• Records of physical authentication factors returned or disabled, such as tokens and cards
• Timing evidence showing the interval between termination and revocation

• Revocation covers the directory while local accounts on servers, appliances and applications remain active
• Contractors and third party staff not on the leaver feed, so their access survives the engagement
• Revocation batched to a weekly job, which does not meet the immediate requirement

Inactive user accounts are removed or disabled within 90 days of inactivity

• User account listing with last logon information for all in scope system components
• Evidence accounts inactive for 90 days are removed or disabled, with the mechanism that enforces it
• The automated or scheduled process performing the check, and its execution records
• Handling of accounts where last logon is not recorded, so inactivity can still be determined
• Exception records where an account is retained despite inactivity, with justification

• Last logon not collected for some platforms, so inactivity cannot be measured and those accounts are skipped
• Service and application accounts exempted as a class rather than individually justified
• Check performed manually and missed during busy periods, so the 90 day limit slips

Accounts used by third parties to access, support, or maintain system components via remote access are managed and monitored.

• Inventory of third-party accounts and vendors
• Procedure to enable only when needed and disable after use
• Session monitoring logs and recordings
• Approval tickets for each session
• Quarterly review of third-party access

• Vendor accounts always enabled
• No session monitoring
• No approval per session

If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the session.

• System and application configuration showing 15 minute timeout
• Sample test logs demonstrating session lock
• Group policy or MDM settings export
• Configuration baseline document
• Exception inventory with compensating controls

• Timeout exceeds 15 minutes
• Workstations excluded
• Test evidence missing

All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: • Something you know, such as a password or passphrase. • Something you

• Documentation describing the authentication factors used for user and administrator access to system components
• For each type of authentication factor, observation or configuration evidence that access is authenticated using it
• Inventory of in scope system components and the authentication method for each
• Evidence no access path permits access without authentication
• Records for non-console and console access alike

• Authentication enforced on the main path while a management interface, API or legacy port allows unauthenticated access
• Certificates or keys used as the factor with no control over their distribution, weakening the something you have claim
• Component inventory incomplete, so a component authenticating differently is never assessed

Additional requirement for service providers: guidance is provided to customers on changing passwords periodically when used as a sole factor for access.

• Customer-facing guidance documents
• Customer portal notices and FAQs
• Sample communications to customers
• Customer acknowledgement records
• Updated guidance in service agreements

• No customer guidance issued
• Guidance buried in long docs
• No acknowledgement tracked

Additional requirement for service providers: customer passwords used as sole factor are changed at least every 90 days, or access is dynamically analyzed.

• Configuration enforcing 90 day rotation for customers
• Posture analysis platform evidence if used
• Coverage list per customer tenant
• Audit log of customer password rotations
• Customer notifications of upcoming changes

• Rotation not enforced per customer
• Posture analysis missing
• Inconsistent across tenants

When authentication factors such as physical or logical security tokens, smart cards, or certificates are used, the factor is assigned to an individual user and not shared.

• Token inventory linking each token to an individual
• Procedure prohibiting sharing
• Sample audit confirming one token per person
• Certificate issuance log per user
• Lost or stolen token replacement records

• Tokens shared in teams
• Inventory not maintained
• No anti-sharing policy

Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components

• Vendor documentation and system configuration showing authentication factors are rendered unreadable with strong cryptography in transmission and in storage
• Examination of authentication factor repositories confirming stored values are not readable
• Evidence the hashing or encryption method meets a strong cryptography definition, including the algorithm and parameters
• Capture or configuration evidence that authentication factors are not sent in the clear on any path
• Key or salt management evidence for the stored factors

• Application credentials protected while an underlying directory, database or legacy store keeps reversible or weakly hashed values
• Transmission protected to the front end and forwarded internally in the clear
• Legacy hash algorithms retained for old accounts because rehashing requires a reset

User identity is verified before modifying any authentication factor

• Procedures for modifying authentication factors, including the identity verification steps required
• Observation of security or service desk personnel performing a modification request, showing verification before the change
• The verification methods permitted and their strength, such as knowledge questions, callback or a second channel
• Records of modification requests showing the verification performed
• Evidence of a request refused because identity could not be verified

• Verification uses information an attacker can obtain, such as employee number or manager name
• Self service reset relies on a channel the attacker may already control, such as the same mailbox
• Procedure documented but not followed under pressure, with no monitoring that would show it

Invalid authentication attempts are limited by: • Locking out the user ID after not more than 10 attempts. • Setting the lockout duration to a minimum of 30 minutes or until the user's identity

• System configuration settings showing lockout after not more than 10 invalid authentication attempts
• System configuration showing lockout duration of at least 30 minutes, or lockout until identity is confirmed
• Evidence the settings apply across all in scope components, including those with their own local authentication
• Test or log evidence showing lockout actually occurs
• The process for confirming identity where lockout is released by an administrator

• Lockout configured in the directory while applications with local authentication have no limit
• Threshold or duration relaxed for administrative accounts to avoid operational disruption
• Lockout applied per component, so an attacker spreading attempts across systems never trips it

If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: • Set to a unique value for first-time use and upon reset. •

• Procedures for setting and resetting passwords or passphrases
• Evidence each initial and reset value is set to a unique value rather than a standard or predictable one
• Configuration forcing a change immediately after first use
• Observation of security personnel performing a reset, showing both elements applied
• Records or configuration showing the delivery method for the initial value

• A standard welcome password used for all new accounts, which fails the unique value element
• Forced change on first use not enforced technically, so the initial value can persist
• Initial value delivered in the same message as the user ID over an unprotected channel

If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: • A minimum length of 12 characters (or IF the system does not support 12

• System configuration settings showing minimum length of 12 characters, or eight where the system cannot support 12
• System configuration showing both numeric and alphabetic characters are required
• Evidence the parameters are enforced on every system where passwords are used as the authentication factor
• Documentation of any system limited to eight characters and the reason it cannot support 12
• Test evidence that a non-conforming password is rejected

• Complexity enforced at the directory while applications with local password stores accept weaker values
• The eight character allowance applied by default rather than only where the system genuinely cannot support 12
• Existing passwords never brought up to the standard because the policy applies only at next change

Individuals are not allowed to submit a new password or passphrase that is the same as any of the last four used.

• Directory policy setting password history to four or more
• Test attempting to reuse last four passwords (denied)
• Coverage list of systems enforcing history
• Sample audit log of password change rejections
• Policy document specifying history depth

• History depth below four
• Some apps exempt
• No reuse rejection logging

Authentication policies and procedures are documented and communicated to all users, including guidance on selecting strong factors and protecting them.

• User guidance document on creating strong passwords
• Acknowledgement records of policy receipt
• Training module covering authentication hygiene
• Sample communications (email, intranet) to users
• Annual reminder evidence

• No user-facing guidance
• Acknowledgements missing
• Training stale

If passwords are the only authentication factor, they are changed at least every 90 days, or access to resources is dynamically analyzed and access granted based on security posture.

• Password expiration policy set to 90 days where applicable
• Dynamic access posture tool configuration if used
• Coverage matrix of password-only systems
• Sample of forced password changes
• Risk analysis supporting posture-based approach

• Expiration disabled with no compensating control
• Posture analysis not deployed
• Inconsistent enforcement

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

• Network and system configurations showing multi-factor authentication is required for all non-console access into the cardholder data environment by personnel with administrative access
• Observation of an administrator logging in, demonstrating the second factor is demanded
• Inventory of administrative access paths into the environment, each mapped to its enforcement point
• Evidence the factors used are independent, so compromise of one does not yield the other
• Records of any bypass and its authorisation

• Multi-factor at the virtual private network boundary with unprotected administrative access once inside
• Jump host protected while direct database, hypervisor and appliance management paths are not
• Both factors delivered to the same device or derived from the same secret, so independence fails

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

• 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

• 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
• Access paths enumerated from the network diagram rather than from the live estate, so an undocumented path is never assessed

MFA is implemented for all remote access originating from outside the entity's network that could access or impact the CDE

• Network and system configurations for remote access servers and systems showing multi-factor is required for remote access originating outside the entity's network
• Observation of users and administrators connecting remotely, showing multi-factor demanded
• Evidence the requirement covers all remote access that could access or impact the cardholder data environment, including third party and vendor access
• Inventory of remote access mechanisms in use, reconciled against those protected
• Records of vendor remote access sessions showing multi-factor applied

• Employee remote access protected while vendor and support remote access tools are exempt
• Cloud management consoles reachable from the internet treated as not remote access, so multi-factor is not applied
• Alternative remote paths such as legacy dial-in or secondary gateways left outside the requirement

MFA systems are implemented as follows: • The MFA system is not susceptible to replay attacks. • MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by

• Vendor system documentation evidencing the multi-factor system is not susceptible to replay attacks
• Configuration of the multi-factor implementation showing bypass is not possible for any user, including administrators
• Documented and management authorised exceptions where bypass is permitted, limited in time and scope
• Evidence at least two different factor types are used, drawn from different categories
• Evidence access is granted only after all factors succeed, with logs showing failed factor attempts denying access

• Standing administrative bypass retained for support convenience, with no time limit or documented authorisation
• Two factors drawn from the same category, such as a password and a security question, which does not satisfy different types
• Fallback to a single factor when the second is unavailable, granting access before all factors succeed

All security policies and operational procedures that are identified in Requirement 8 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• Operational procedures and safe systems of work (SSOW)
• Permit to work systems for high risk activities
• Pre task briefings and last minute risk assessments
• Work adaptation evidence (ergonomic adjustments, schedule design)

• Permit systems applied inconsistently
• Work not adapted to workers (fatigue, ergonomics)

Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood

• Documented hierarchy of controls procedure
• Elimination and substitution case files (chemical removed, automation introduced)
• Engineering control commissioning records (guarding, LEV, interlocks)
• Administrative controls (rotation, signage, procedures)
• PPE program records (selection, fit, inspection, replacement)

• Default to PPE without justification
• Engineering controls not maintained

If accounts used by systems or applications can be used for interactive login, they are managed as follows: • Interactive use is prevented unless needed for an exceptional circumstance. • Interactive use is limited

• Ticket records
• Priority guide
• Resolution reports

• Priority not based on impact and urgency
• Major incidents handled ad-hoc

Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code

• Catalogue items
• Workflow configuration
• Performance reports

• Requests handled as incidents
• No targets per request type

Passwords/passphrases for any application and system accounts are protected against misuse as follows: • Passwords/passphrases are changed periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all

• Problem records
• RCA documents
• KEDB

• Reactive only
• KEDB not used by service desk

All security policies and operational procedures that are identified in Requirement 9 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

• Documented policies and operational procedures for physical access to the cardholder data environment, media handling and point of interaction device protection
• Review record showing the physical security procedures are kept up to date
• Evidence of use, such as visitor logs and media transport records completed under the procedures
• Distribution evidence to facilities, reception, operations and any third party providing physical security

• Procedures held by security with reception and facilities staff, who actually perform the activities, unaware of them
• Written for the primary data centre with branch sites, offices and storage locations uncovered
• Media handling and device inspection procedures thinner than the entry control procedures

Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood

• Documented descriptions of roles for Requirement 9 activities, covering entry authorisation, visitor management, media inventory and device inspection
• Assignment records naming who holds each role
• Interview confirmation that assigned personnel understand their day to day physical security responsibilities
• Evidence of coverage outside business hours and at each site

• Responsibilities assigned at head office with site level duties unowned
• Outsourced facilities staff performing the activities with no documented assignment or training
• Media inventory ownership unassigned, so the periodic inventory is never performed

Appropriate facility entry controls are in place to restrict physical access to systems in the CDE

• Observation records or photographs of the entry controls restricting physical access to systems in the cardholder data environment
• Documentation of the control mechanism, such as badge readers, locks or staffed reception, at each entry point
• Evidence all entry points are covered, including loading docks, fire doors and shared tenancy access
• Interview confirmation from responsible personnel about how access is restricted
• Records showing entry control failures such as propped or faulty doors are detected and fixed

• Main entrance controlled while secondary doors, service risers and roof access are not
• Shared building tenancy where landlord controlled areas provide an uncontrolled route
• Doors held open for convenience with no monitoring that would detect it

Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows: • Entry and exit points to/from sensitive areas within the

• Observation of the locations where individual physical access to sensitive areas within the cardholder data environment occurs, showing video cameras or physical access control mechanisms at entry and exit points
• Evidence both entry and exit points are monitored
• Evidence the monitoring devices or mechanisms are protected from tampering or disabling
• Retention evidence showing collected data is stored for at least three months unless otherwise restricted by law
• Review evidence showing collected data is correlated with other entries

• Entry monitored while exit is not, so tailgating out and the duration of a visit cannot be established
• Recording retention set below three months by the default configuration of the recorder
• Cameras and controllers physically accessible within the area they monitor, so they can be disabled by the person being monitored

Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility

• Observation of publicly accessible areas within the facility and the locations of network jacks in them
• Evidence of the physical or logical controls restricting use of those jacks, such as disabled ports, port security or network access control
• Configuration extract showing the ports in public areas are disabled or restricted
• Test evidence that an unauthorised device connected in a public area cannot reach the network
• Process for enabling a jack when legitimately required, and for disabling it afterwards

• Jacks disabled at one point in time with no process, so ports enabled for an event stay enabled
• Wireless access in public areas treated as out of scope of the same concern, providing the connection the jacks were meant to prevent
• Port security configured to log rather than block an unknown device

Physical access within the facility to wireless access points, gateways, networking and communications hardware, and telecommunication lines is restricted, so that networking equipment cannot be reached by unauthorized personnel.

• Floor plan or inventory locating wireless access points, gateways, switches, patch panels and telecom lines
• Evidence that wiring closets, comms rooms and network cabinets are locked (photos, lock or badge reader records)
• Badge system access list for comms rooms and wiring closets, with authorization approvals
• Walkthrough or inspection records confirming exposed network hardware is secured
• Procedure covering physical protection of wireless access points in public or visitor areas

• Wireless access points mounted in open ceilings or public areas with no tamper protection
• Wiring closets unlocked or propped open
• Comms room badge list never reviewed and full of leavers
• Network hardware inventory does not record physical location, so nothing can be verified

Access to consoles located in sensitive areas is restricted by locking them when not in use, so that physical consoles cannot be used by unauthorized personnel.

• Screen lock or session timeout configuration for consoles in sensitive areas
• Group policy or endpoint management export showing enforced lock settings
• Observation record of an administrator attempting console login and finding it locked
• Definition and list of sensitive areas and the consoles sited in each
• Procedure requiring consoles to be locked when unattended

• Console lock left to user discipline with no enforced timeout
• Sensitive areas never formally defined, so console population is unknown
• Jump hosts and KVM consoles excluded from the lock policy
• Shared operator consoles kept permanently logged in for convenience

Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including: • Identifying personnel. • Managing changes to an individual's physical access requirements. • Revoking or terminating personnel identification. •

• Documented procedures for authorising and managing physical access of personnel to the cardholder data environment
• Evidence of the identification mechanism in use, such as badges, and observation of it being applied
• Records of changes to individual physical access requirements, and of revocation or termination of identification
• Evidence access to the identification process itself, such as badge issuance, is limited to authorised personnel
• A sample reconciliation of badge holders with current authorised personnel

• Badge deactivation on termination handled by facilities on a separate timetable from logical access revocation
• Badge issuance available to reception staff with no authorisation check on who may request one
• Changes to a person's access on role change add new areas without removing the old

Physical access to sensitive areas within the CDE for personnel is revoked immediately upon termination, with all physical access mechanisms returned or disabled.

• Termination checklist with badge return step
• Badge disablement logs with timestamps
• Reconciliation between HR exits and badge system
• Sample termination tickets
• Lost badge incident records

• Badge return not tracked
• Disablement delayed
• No reconciliation

Procedures are implemented for authorizing and managing visitor access to the CDE, including: • Visitors are authorized before entering. • Visitors are escorted at all times. • Visitors are clearly identified and given a

• Documented procedures for authorising and managing visitor access to the cardholder data environment
• Observation of visitors being authorised before entry, escorted at all times and clearly identified
• The visitor badge or identification used, showing it expires and is visually distinguishable from personnel identification
• Visitor logs showing authorisation and escort for the period
• Interview confirmation from escorting personnel about their obligations

• Visitors signed in and then left unescorted in areas the procedure requires escort for
• Visitor badges identical in appearance to staff badges, so an unescorted visitor is not noticeable
• Regular contractors treated as personnel without going through either personnel authorisation or visitor management

Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration

• Observation of visitors leaving the facility showing badges surrendered or deactivated on departure
• Evidence of deactivation at the date of expiration for badges not returned
• Visitor log entries recording departure and badge return
• Badge stock reconciliation showing issued badges are accounted for
• Configuration of the access system showing visitor badge expiry

• Badges collected at reception but never deactivated in the access system, so a retained badge still opens doors
• No expiry configured, so a badge taken away remains valid indefinitely
• Departure not recorded, so unreturned badges are not identified

Visitor logs are retained for at least three months unless restricted by law, and include visitor name, firm, sponsor, date, and time in and out.

• Sample visitor logs containing required fields
• Retention policy specifying three months
• Secure storage location for logs
• Periodic log review evidence
• Procedure for legal hold scenarios

• Logs missing required fields
• Retention below three months
• Logs unsecured

All media holding cardholder data is physically secured, so that the data it carries cannot be accessed by unauthorized personnel. Sub-requirements extend this to offline media backups being stored in a secure location and the security of that location being reviewed.

• Documented procedures for protecting cardholder data that include controls for physically securing all media
• Evidence of secure storage for media (locked cabinets, safes, restricted rooms)
• Inventory of media holding cardholder data with storage location
• Offsite or offline backup storage arrangements and the facility's security description
• Records of the periodic review of the offline backup storage location's security

• Printed reports and receipts holding cardholder data left on desks or in unlocked drawers
• Backup tapes handed to a courier with no secure storage evidence at the far end
• Only electronic media considered, with paper media out of scope
• Offline backup location never assessed for security

Offline media backups containing cardholder data are stored in a secure location, with security reviewed at least once every 12 months.

• Offsite vendor agreement and SOC report
• Annual site security review evidence
• Inventory of backup media offsite
• Chain of custody records for media transfers
• Encryption verification for backup media

• Annual review skipped
• No SOC review of vendor
• Inventory drift

The security of the offline media backup location is reviewed at least once every 12 months.

• Annual offsite site visit report
• Review checklist completed and signed
• Remediation tickets for findings
• Vendor SOC 2 or equivalent report
• Approval to continue use post-review

• No site visits
• Findings not remediated
• Review checklist absent

All media with cardholder data is classified in accordance with the sensitivity of the data.

• Data classification policy with media handling rules
• Sample labelled media (photos)
• Inventory tagged with classification
• Training records on classification
• Audit of media labels

• No labels
• Classification scheme missing
• Inventory not classified

Media with cardholder data sent outside the facility is secured using a tracked secured courier or other delivery method that can be accurately tracked.

• Courier contracts with secure handling clauses
• Shipment tracking numbers and receipts
• Management approval for each shipment
• Chain of custody documentation
• Sample tracked deliveries

• No tracking
• Standard postal used
• No approvals

Management approves all movement of media holding cardholder data outside the facility, including when media is distributed to individuals, so media cannot leave a facility without the approval of accountable personnel. The approver needs appropriate management authority but is not required to hold manager as part of their job title.

• Documented procedure requiring management approval before media leaves the facility
• Offsite media tracking logs showing an approver against each movement
• Approval records or tickets for a sample of media movements, including media distributed to individuals
• Definition of who holds the authority to approve media movements
• Interview notes with personnel responsible for despatching media

• Courier collections logged after the fact with no prior approval
• Approval implied by the shipping record rather than captured as a decision
• Media handed directly to individuals treated as outside the process
• Approver authority undefined, so anyone in the team signs the log

Inventory logs of all electronic media with cardholder data are maintained, and inventories are conducted at least once every 12 months.

• Electronic media inventory log
• Annual physical inventory report with sign-off
• Reconciliation results between logbook and actual media
• Discrepancy investigation records
• Procedure for inventory updates

• Inventory stale
• No annual count
• Discrepancies unresolved

Inventories of electronic media with cardholder data are conducted at least once every 12 months

• Documented procedures defining the conduct of electronic media inventories at least once every 12 months
• Electronic media inventory logs for the period showing the inventory was performed
• Interview confirmation from personnel who performed the inventory
• Evidence the inventory covers all electronic media with cardholder data, including offsite and archived media
• Records of discrepancies found and how each was resolved

• Inventory covers onsite media while offsite storage held by a third party is taken on the provider's word
• Inventory recorded as complete with no evidence of physical verification against the log
• Discrepancies noted with no investigation, so missing media is normalised

Hard copy materials with cardholder data are destroyed when no longer needed for business or legal reasons via crosscut shredding, incineration, or pulping.

• Destruction policy specifying methods
• Certificate of Destruction from shredding vendor
• Secure bin locations and pickup logs
• Witness sign-off for on-site destruction
• Photos of destroyed material

• Standard recycling used
• No certificates
• Bins unlocked

Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons, rendering cardholder data unrecoverable.

• Media sanitization procedure aligned to NIST 800-88
• Certificates of Destruction for drives
• Disposal vendor SOC report
• Serialized destruction log per device
• Verification testing for sanitized media

• No NIST alignment
• Certificates missing
• No verification

Point-of-interaction (POI) devices that capture payment card data are protected from tampering and unauthorized substitution.

• POI device inventory with make, model, serial, location
• Inspection checklist and completed inspections
• Training records for POI staff
• Sample tamper-evident seals or photos
• Procedure for suspected tampering

• POI inventory incomplete
• Inspections skipped
• No staff training

An up-to-date list of POI devices is maintained, including make, model, location, serial number, and other device characteristics.

• POI inventory export with all required fields
• Inventory update procedure and change log
• Sample reconciliation between inventory and on-site devices
• Onboarding and offboarding records for devices
• Inventory ownership assignment

• Missing serial numbers
• Inventory not updated post-move
• No owner

POI device surfaces are periodically inspected to detect tampering and unauthorized substitution, with frequency defined in the entity's targeted risk analysis.

• TRA document supporting inspection frequency
• Completed inspection checklists with photos
• Findings remediation tickets
• Inspector training records
• Sample tamper-evident seal logs

• No TRA
• Inspections informal
• Findings unaddressed

Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of devices.

• Training curriculum covering POI risks
• Completion records per employee
• Annual refresher schedule
• Quiz or attestation results
• Procedure for reporting suspected tampering

• Training not annual
• No completion tracking
• Curriculum lacks tampering scenarios