Skip to main content
All CollectionsFrameworksPCI DSS v4.0
Example Evidence for Not Monitored Controls (PCI DSS v4.0.1 )

Example Evidence for Not Monitored Controls (PCI DSS v4.0.1 )

Updated this week

PCI DSS v4.0.1 is a detailed framework with specific guidelines on how organizations should protect cardholder data. The updated version includes enhancements and clarifications that address emerging security risks and technologies, ensuring that organizations stay ahead of evolving threats.

To understand the changes, we’ve reviewed the PCI DSS v4.0.1 Report on Compliance (ROC) reporting template that PCI Qualified Security Assessors (QSAs) use when assessing cardholder data environments. This helps us identify the new and updated testing requirements for compliance with PCI DSS v4.0.1.

We’ve compiled each piece of evidence from the ROC and aligned it with the relevant controls in Drata to provide clarity on what should be submitted when preparing for a PCI QSA audit under the new version of PCI DSS.

NOTE: This article was written for PCI DSS v4.0.1

Please note: An auditor may request additional evidence for each control.

DCF Code

PCI Requirement

Name

Example Evidence

DCF-11

7.2.4, A3.4.1

Periodic Access Review

Upload documentation of the most recent user access and permissions review.

Example: Screenshots of the user lists and permissions reviewed, evidence of sign-offs or approvals by at least two individuals (SOD), documentation of changes requested if any, and evidence that the changes requested were implemented.

The scope of the review should be discussed with your auditor as different auditors may have different expectations (based on the scope of the assessment, relevant framework(s), etc.)

Auditors will generally require to see the following:

- Evidence of the review inputs (what artifacts were reviewed?) such as screenshots of user lists with permissions.

- Evidence that segregation of duties was maintained (e.g., two individuals sign-off the review so that no reviewer is approving their own access).

- Changes identified were implemented (e.g., tickets documenting removal of accounts, updated user lists showing modifications in permissions, etc.)

Auditors would generally expect to see these review activities done at least annually, with quarterly frequency being the most common.

Auditors may also expect that the user access review includes a review of physical access rights, if applicable (e.g., reviews of active personnel in the badge system, etc.)

DCF-22

1.2.3

Network Diagram

Upload evidence of your current network diagram(s) and evidence of updates/reviews within the past year for accuracy (e.g., emails from responsible personnel confirming the accuracy and completeness of the network diagram(s), etc.)

DCF-30

12.10.6, A3.5.1

Incident response Lessons Learned

For an example security event deemed an incident, upload the incident documentation including evidence of internal tracking (e.g., internal ticket), root-cause analysis (RCA)/post-mortem, lessons learned, etc.

DCF-56

12.8.1, 12.8.2

Vendor Register & Agreements

Upload evidence of an example executed agreement with a vendor or service provider.

DCF-57

12.8.4

Vendor Compliance Monitoring

Screenshots from the vendor directory showing that vendors are categorized based on impact/risk.

or

Review documents showing that vendors’ SOC2 reports were reviewed (Drata can provide a review template for this).

DCF-61

1.1.3

Customer Data Segregation

Upload evidence showing customer data is segregated.

Example: screenshots from the database showing that unique identifiers are used to associate data to a specific customer, screenshots showing that separate databases/storage buckets are used for individual customers, etc.

DCF-62

8.2.9

Session Termination

Upload evidence of automated logoff for relevant systems/applications.

For example:

1. Screenshots of users being logged out of the application when browser/tab is closed and being forced to re-authenticate upon next login.

2. Screenshots showing that a user is logged out after pre-defined activity timeout and being forced to authenticate upon next login (including application messages, parameters in the application code defining the inactivity period, etc.)

Relevant systems may include company-developed web applications and any system or application in use that allows for configuration of automated logoffs. If applicable, discuss scope with your chosen auditor.

DCF-69

7.2.3, 7.2.2, 9.3.1.1, 9.3.1, 7.3.2, 7.2.1

Access Provisioning

Upload an example record of access request and approval for a user to be granted permission to a system.

Example: Access request ticket with documented approval from system owner or manager, etc.

A process to request and approve user accounts and permissions must be in place. Auditors may request evidence of new hire access requests as well as request for changes in permissions to existing users (e.g., transfers, new administrative users, additional permissions to specific resources such as databases or repositories).

DCF-106

9.4.1

Clean Desk and Clear Screen Policies and Procedures

1. Acceptable Use Policy

-and-

2. (If applicable) Acknowledgement of the Acceptable Use Policy

DCF-107

9.4.6

Disposal of Sensitive Data on Paper

Observation of hard copy materials being disposed of. Note: This can be performed by auditors on-site or via virtual meeting.

DCF-108

9.4.6, 9.4.1

Secure Storage Mechanisms

Pictures of secure storage bins from office locations.

DCF-150

A3.2.6

Data Loss Prevention (DLP) Mechanism

Upload evidence of the data leakage prevention (DLP) measures implemented in the organization (e.g., screenshots of DLP rules implemented in corporate email service, configurations from DLP tools in place, etc.)

DCF-156

6.5.4, 6.2.3.1

Change Releases Approved

For an example change release, upload evidence showing that the release was approved by authorized personnel prior to deployment to production (e.g., screenshot of a pull request/ticket showing approval for a release candidate by authorized personnel).

DCF-171

1.1.1, 12.10.2, 2.1.1, 3.1.1, 4.1.1, 5.1.1, 6.1.1, 7.1.1, 8.1.1, 9.1.1, 10.1.1, 11.1.1

Documented Operating Procedures

Upload examples of your documented operating procedures for information security activities/controls.

Documented procedures should be prepared for the organization’s operational activities associated with information security, for example:

- when the activity needs to be performed in the same way by many people;

- when the activity is performed rarely and when next performed the procedure is likely to have been forgotten;

- when the activity is new and presents a risk if not performed correctly; and,

- prior to handing over the activity to new personnel.

DCF-188

6.3.1

Communication with Advisor and Special Interest Group

Upload evidence showing that the organization and members of management maintain contact with special interest groups (e.g., security groups, privacy groups, etc.).

For example, screenshots or exports showing members of management receive newsletters and updates from professional association groups, email alerts from security advisories such as CISA, participation in conferences, threat advisories, etc.

DCF-522

5.3.3

Anti-Malware Scans of Media

Upload evidence showing that the implemented anti-malware solution is configured to perform automatic scans or continuous behavioral analysis of systems or processes when removable electronic media is inserted, connected, or logically mounted within the environment.

Example: Screenshots showing configuration settings from the anti-malware system showing settings for anti-malware scans of media.

DCF-523

4.2.1.1

Inventory of Trusted Keys and Certificates to Protect PAN During Transmission

Upload evidence showing the inventory of trusted keys and certificates used to protect PANs during transmission. This should include details such as issuing authority, expiration date, and usage.

Example:

  1. Inventory Document of Trusted Keys and Certificates: A document (e.g., spreadsheet or PDF) listing all keys and certificates, including issuer, expiration dates, and relevant metadata like serial numbers or algorithms

  2. Key and Certificate Management System Logs: Screenshots or reports from your key management system showing key and certificate lifecycles, including issuance, renewal, revocation, and updates with metadata (e.g., status, timestamp).

DCF-524

7.2.5.1

Period Review of Application and System Accounts

Upload documentation showing records of periodic reviews of application and system accounts, including dates and details of each review. This should outline the accounts reviewed, associated privileges, and any changes made, such as access modifications or account removals.

Example:

  1. Review Logs: Logs documenting the accounts reviewed, their privileges, and any changes made.

  2. Meeting Minutes or Reports: Minutes or reports from meetings or system administrators confirming review details.

  3. Change Request Forms/Approval Records: Forms or records showing how changes were approved and implemented.

DCF-525

3.4.2

Technical Controls to Prevent Copy/Relocation of PAN

Upload documentation such as policies, procedures, and configuration settings detailing technical controls to prevent the copy or relocation of Primary Account Numbers (PAN) on local hard drives or removable storage media during remote access.

Example:

  1. Policies and Procedures: Documentation outlining controls to prevent the transfer of PAN data.

  2. System Configuration Records: Configuration settings that show restrictions on PAN data transfer.

  3. Access Control Lists (ACLs): ACLs showing restrictions or permissions for accessing PAN data.

  4. Logs: Logs demonstrating the enforcement of these restrictions.

  5. Exception Records: Documentation of any authorized exceptions for legitimate business needs.

DCF-557

8.2.2

Shared Account Management

For any highly privileged shared accounts, upload evidence of the business justification and evidence of how these shared accounts are securely managed.

Example: Documentation of the business purpose of the shared account(s) with management approval and screenshots showing how the shared accounts are securely managed (e.g., through password vaults restricted to specific personnel, etc.).

DCF-562

5.3.5

Management of Utility Programs

Upload screenshots or exports of user lists (with a screenshot of parameters used for exporting) showing the users with administrative or privileged access to the systems (e.g., super users, administrators, power users, etc.) for relevant systems.

Relevant systems may include cloud infrastructure provider, code repositories, identity provider, password vault systems, VPN clients, systems with stored customer data (e.g., database as a service), utility programs (e.g., antivirus consoles) and others based on the scope of the engagement. Discuss system scope with your chosen auditor.

DCF-637

6.2.1

Secure Development Process

Upload documentation of your organization's secure development processes.

Example: Internal wikis or other documentation that includes references to industry standards and/or best practices for secure development, security requirement considerations (for example, secure authentication and logging, etc.), and consideration of information security issues during each stage of the software development life cycle.

DCF-681

12.6.3, 5.4.1

Phishing Simulations

Upload evidence showing phishing simulations are conducted as part of the company's security awareness initiatives.

Example: Screenshots from phishing simulation campaign configurations, screenshots of dashboards showing results of the campaign, screenshot showing example simulated phishing email, etc.

DCF-682

1.1.2, 2.1.2, 3.1.2, 4.1.2, 5.1.2, 6.1.2, 7.1.2, 8.1.2, 9.1.2, 10.1.2, 11.1.2

Roles and Responsibilities for PCI DSS Compliance

Upload evidence to demonstrate that roles and responsibilities for PCI DSS compliance activities are documented, assigned, and reviewed at least annually, with acknowledgment from relevant personnel.

Example:

  1. RACI Matrix: A document outlining the roles and responsibilities for PCI DSS compliance.

  2. Signed Policy Document: A policy that clearly defines roles and responsibilities for PCI DSS controls.

  3. Annual Review Meeting Minutes: Minutes from the annual review meeting with management sign-off.

  4. Signed Acknowledgment Forms: Forms signed by department heads confirming their understanding of their roles.

  5. Review Confirmation Email: An email confirming the annual review sent to relevant personnel.

  6. Training Attendance Logs: Logs showing attendance at PCI DSS compliance training sessions.

DCF-683

8.3.10.1

Password Expiration Periods for Customer User Access

Upload evidence to demonstrate compliance with the PCI DSS requirement for either enforcing a 90-day password change policy or implementing dynamic access controls based on real-time security posture.

Example:

  1. Formal Password Policy or Access Control Procedure: A document clearly stating the requirement for passwords to be changed every 90 days.

  2. Screenshots of Technical Configurations: Screenshots of system settings or configurations that enforce the 90-day password expiration policy.

  3. Automated Enforcement Evidence: Evidence of automated measures (e.g., account lockout, alerts, or automatic password expiration) implemented to enforce the 90-day password change policy.

DCF-685

12.6.2

Review of Security Awareness Program

Upload evidence demonstrating that your organization has a process in place to review and update the security awareness program annually, and that the program addresses new threats and vulnerabilities impacting the security of your environment and the protection of sensitive data.

Examples:

  1. Documented Review Record or Meeting Minutes: A record or minutes confirming the security awareness program was reviewed at least annually.

  2. Signed Acknowledgment Forms: Forms signed by management or personnel confirming they reviewed and approved the updated program.

  3. Meeting Minutes or Review Documentation: Documentation showing the annual review process and discussion of updates made to the program.

DCF-686

12.3.1, 12.10.4.1, 9.5.1.2.1, 10.4.2.1, 5.2.3.1, 5.3.2.1, 11.3.1.1

PCI Targeted Frequency Risk Analysis

Upload the Risk analysis report that includes identification of assets, threats, factors contributing to likelihood and impact, and frequency justification for PCI DSS activities.

DCF-687

5.4.1

Email Protection Mechanisms

Upload evidence showing that phishing and spam detection mechanisms have been implemented in your organization.

Example: Screenshots showing SPF, DMARC, DKIM configurations enabled for email authentication.

DCF-688

9.3.1.1, 9.3.1

Return of Assets

For one recently terminated personnel, upload evidence showing that assets were returned to the company.

Example: Screenshots of offboarding checklists or internal tickets showing tracking of return of devices, badges, tokens, etc., upon termination, evidence of pre-paid labels sent to remote personnel for asset return and tracking, etc.

DCF-689

12.10.3

On-Call Team

Upload evidence of on-call rotation schedule.

Example: Screenshots from tools like PagerDuty or equivalent tool showing on-call schedule and teams assigned.

DCF-690

12.3.2

PCI Targeted Customed Approach Risk Analysis

Upload Targeted Risk Analysis document.

DCF-698

10.4.1.1, A3.5.1

Automated Mechanism for Audit Log Reviews

Upload evidence to demonstrate that your organization has implemented automated mechanisms for audit record reduction and log analysis.

Examples:

  1. System Configuration Documentation: Documentation for your SIEM or log management platform showing how automated log reduction and correlation are configured.

  2. Log Management System Reports: Reports from your log management system demonstrating automated log reduction and correlated event analysis.

DCF-699

11.3.1.2

Authenticated Scanning for Internal Vulnerability Scans

Upload vulnerability scan reports showing authenticated scans with credentials that have sufficient privileges, along with the company's credential management policies.

Examples:

  1. Vulnerability Scan Reports: Reports from authenticated scans with credentials having sufficient privileges.

  2. Credential Management Policies: Document outlining how credentials are managed securely in accordance with company policies.

  3. Systems List: A list of systems that cannot accept authenticated scans, with compensating controls in place.

  4. Access Control Logs: Logs showing access control details for systems with restricted scan capabilities.

DCF-700

A3.3.2, 12.3.4

Review of PCI Hardware and Software

Provide documentation of the annual review of hardware and software technologies, including a list of technologies evaluated and the findings of the review.

Examples:

  1. Annual Review Documentation: A report or document listing all technologies evaluated, including findings from the review.

  2. Remediation Plan: A plan detailing steps for addressing or replacing technologies that no longer meet PCI DSS requirements.

  3. Approval Records: Documentation showing approval from relevant personnel, such as signed approval forms or meeting minutes.

DCF-701

A3.2.3, 12.5.3

Review of PCI Requirements Upon Organizational Structure Changes

Upload documentation of the formal internal review process for assessing the impact of organizational changes on PCI DSS scope and controls.

Examples:

  1. Review Process Documentation: A policy or procedure document outlining the internal review process for organizational changes impacting PCI DSS scope.

  2. Records of Reviews: Documentation of reviews conducted after changes, such as mergers, acquisitions, or changes in personnel responsible for security controls.

  3. Executive Communication: Evidence showing the results of the review communicated to executive management, such as emails or meeting minutes.

DCF-702

12.5.2

PCI Scope Validation (Annual)

Upload documentation of the formal review of the PCI DSS scope conducted at least annually or following significant environmental changes.

Examples:

  1. Review Process Documentation: A policy or procedure document outlining the annual or event-triggered review process of PCI DSS scope.

  2. Review Records: Documentation showing the results of the review, including any scope changes, and confirmation that these changes were retained.

  3. Approval Records: Evidence of sign-off or approval from responsible personnel regarding the review and any changes made.

DCF-703

12.5.2.1

PCI Scope Validation for Service Providers (Semi-Annual)

Provide documentation of the formal review of the PCI DSS scope conducted at least every six months or following significant changes to the environment. Results of the review, including any changes, must be documented and retained.

Examples:

  1. Review Process Documentation: A policy or procedure outlining the semi-annual review of PCI DSS scope and the process followed after significant changes.

  2. Review Records: Documentation showing the results of the review, including any changes to the scope and justification for these changes.

  3. Approval Records: Evidence of sign-off or approval from responsible personnel confirming the review and any changes made.

DCF-704

A3.1.4

PCI Compliance Training

Provide documentation showing that PCI DSS or specialized information security training is provided to all personnel with PCI DSS responsibilities at least once every 12 months. Include records of training attendance and the content covered.

Examples:

  1. Training Policy or Procedure: Documentation outlining the requirements for PCI DSS or information security training, including the frequency and topics covered.

  2. Training Attendance Logs: Records showing personnel attendance at the training sessions, such as signed attendance sheets or digital attendance reports.

  3. Training Materials: Evidence of the content covered in the training, such as course slides, handouts, or training outlines that detail PCI DSS responsibilities and related security topics.

  4. Certification or Acknowledgment Forms: Signed forms or certificates from personnel confirming they completed the training.

DCF-705

A3.2.1

PCI Scope Validation for Designated Entities (Quarterly)

Upload formal review documentation showing that the PCI DSS scope is performed at least once every three months and after significant environmental changes. Include records of the review and any changes, along with documentation of the results.

Examples:

  1. Review Logs or Reports: Documentation showing that the PCI DSS scope was reviewed at least every three months, including details of the review process and any changes made.

  2. Meeting Minutes or Approval Records: Signed minutes from review meetings or approval records from responsible personnel confirming the review and any scope adjustments.

  3. Change Documentation: Evidence of any changes made to the PCI DSS scope, such as updated scope documents or revised network diagrams.

  4. Email Communications: Copies of emails or communications that confirm the results of the review were shared with relevant stakeholders.

DCF-706

A1.1.1

Multi-Tenant Segregation Between Provider and Customer

Provide documentation showing that logical separation is implemented for multi-tenant service providers.

Examples:

  1. Network Diagrams: Diagrams illustrating the logical separation of networks and systems for each tenant, showing isolated environments.

  2. Access Control Policies: Policies or access control lists (ACLs) that detail how tenants are restricted from accessing each other’s environments, including role-based access controls (RBAC).

  3. Configuration Settings: System or network configuration files that demonstrate technical controls (e.g., VLAN configurations, firewall rules) enforcing logical separation between tenants.

DCF-707

8..6.2

Credentials for System Accounts Not Hard-Coded

Upload evidence showing that the organization has implemented mechanisms to validate that authentication credentials for any application and system accounts are not hard coded in scripts, configuration/property files, or bespoke and custom source code.

Example: Screenshots from source code repositories showing secret scanning is conducted as part of the CI/CD pipeline.

DCF-708

6.3.2

Software and Third Party Libraries Inventory

Upload evidence of your organization's software and third party libraries Inventory (i.e., software bill of materials).

Example: Screenshots from software composition analysis tools showing software bill of materials (SBOM).

DCF-709

11/5/1/1

IDS/IPS Addresses Covert Malware

Provide evidence of intrusion-detection and/or intrusion-prevention mechanisms that detect and alert on covert malware communication channels, such as DNS tunneling.

Examples:

  1. Configuration Settings: Documentation of system settings that enable detection of covert malware communication channels, including IDS/IPS configurations for DNS tunneling detection.

  2. Monitoring Procedures: Procedures that outline how intrusion-detection systems monitor for suspicious activity, including DNS tunneling.

  3. Response Protocols: Documentation of established protocols for responding to detected threats, including steps for isolating affected systems and remediating vulnerabilities.

  4. Alert Logs: Example logs showing triggered alerts for DNS tunneling or other covert channels.

  5. Incident Response Reports: Reports detailing how detected threats were addressed, including actions taken and outcomes.

  6. Automated Systems or Personnel Response: Evidence of automated responses or personnel actions taken when alerts are triggered, such as system isolation or notifications.

DCF-710

11.4.7

Multi-Tenant Service Provider Supports Customer Pentest Requests

Provide documentation showing access granted to customers for conducting tests or providing evidence of comparable testing.

Examples:

  1. Penetration Test Reports: Detailed reports of penetration tests conducted, including the scope of testing, results, and any vulnerabilities identified.

  2. Test Results: Results of any other relevant security tests conducted that demonstrate the security posture of the system or service.

  3. Correspondence or Agreements: Emails, agreements, or contracts confirming that customers were granted access to conduct tests or provided with evidence of comparable testing (e.g., results, reports).

  4. Test Access Logs: Logs or records showing that customers were granted access to systems or tools for testing, along with any relevant permissions or approvals.

DCF-711

A1.2.2

Incident Procedures Support Customers Forensic Investigations

Provide evidence of documented processes or mechanisms that support a prompt forensic investigation of servers in the event of a suspected or confirmed security incident for any customer.

Examples:

  1. Incident Response Procedures: A documented policy or procedure outlining the steps for responding to and investigating security incidents, including identification, containment, and resolution.

  2. Investigation Protocols: Specific protocols that guide the forensic investigation process, including methodologies, tools, and timeline for investigations.

  3. Contact Information for Forensic Team: A list or directory of personnel responsible for conducting forensic investigations, including their roles and contact details.

  4. Past Incident Investigations: Any past examples of incident investigations, including investigation reports, findings, and actions taken, with sensitive details redacted if necessary.

DCF-712

6.2.3, 6.2.4

Static Application Security Testing

Upload evidence that static application security testing (SAST) is conducted for software development testing.

Example: Screenshots from the CI/CD pipeline for relevant code repositories showing a SAST scan automatically executes every time new code is committed, screenshots of configurations and dashboards from SAST tools such as SonarCloud, etc.

DCF-713

9.2.4

Consoles in Sensitive Areas Locked

Upload evidence that console login screens for physical consoles in sensitive areas are locked to prevent unauthorized use.

Examples:

  1. Screenshots: Provide screenshots showing that the lock screen feature is enabled for console login screens in sensitive areas.

  2. Configuration Settings: Include system configuration settings or access control configurations that enforce the lock screen requirement.

  3. Access Control Lists: Submit access control lists (ACLs) or other related documents showing how access to consoles in sensitive areas is restricted.

  4. Policies: Provide a documented policy or procedure that outlines how unauthorized access to consoles in sensitive areas is prevented and controlled

DCF-714

8.2.4

Lifecycle Events for Users IDs and Authentication Factors Authorized

Upload evidence that changes to user IDs, authentication factors, and other identifier objects are made only with documented management approval.

Examples:

  1. Signed Approval Forms: Provide signed forms from management that approve changes to user IDs, authentication factors, or other identifiers.

  2. Change Request Logs: Submit logs from the change management system showing that all changes to user IDs or authentication factors are documented, along with the associated approvals.

  3. Screenshots of Access Control Systems: Include screenshots from the access control system showing that changes are properly recorded and reflect the privileges specified in the management approval.

DCF-715

6.5.5

Live PANs Not Used Outside of CDE

Provide evidence that live PANs are not used in pre-production environments unless those environments are within the scope of the PCI compliance program.

Examples:

  1. Policy Documentation: Upload a policy document that restricts the use of live PANs in non-production environments, outlining exceptions and how they are handled.

  2. Approval or Exception Forms: Provide any approval or exception forms that were used for live PANs in pre-production environments, demonstrating that they were managed in accordance with PCI DSS requirements.

  3. System Configuration Settings: Include configuration settings from pre-production environments showing that live PANs are not stored, processed, or transmitted unless within the scope of the PCI DSS compliance program.

DCF-716

7.2.5

Application and System Accounts Authorized

Upload company’s access control policies, access request forms or approval tickets, access logs demonstrating privileges align with system needs, signed management approval for provisioning access, and periodic access review records.

Examples:

  1. Access Control Policies: Upload the company’s access control policies that define the rules and requirements for granting, managing, and reviewing access to systems.

  2. Access Request Forms or Approval Tickets: Provide sample access request forms or approval tickets showing how access is requested and approved.

  3. Access Logs: Include access logs that show how user privileges align with system needs, ensuring users only have the necessary access.

  4. Signed Management Approval: Upload signed management approval records for access provisioning to demonstrate that access was granted with appropriate oversight.

  5. Periodic Access Review Records: Provide documentation showing the periodic review of user access, confirming that access privileges are reassessed regularly.

DCF-717

8.3.11

Unique Authentication Factors

Upload records showing how authentication factors (e.g., tokens, smart cards, certificates) are assigned to individual users. Include logs, spreadsheets, and related policies or procedures. Also, provide screenshots or records showing physical or technical controls (e.g., PINs, biometrics) to ensure only the intended user can access these factors.

Examples:

  1. Assignment Logs or Spreadsheets: Logs or spreadsheets with user details and assigned authentication factors.

  2. Authentication Policies: Documentation outlining the policies and procedures for assigning and managing authentication factors.

  3. Screenshots or Records of Controls: Screenshots or records showing how physical or technical controls (PINs, biometrics) are used to secure access.

  4. Evidence of Control Enforcement: Proof that controls are in place to ensure proper access to authentication factors.

DCF-718

A2.1.1

SSL and Early TLS Vulnerability Verification

Upload records or reports showing that the POS and POI terminals using SSL and/or early TLS have been inspected for known vulnerabilities.

This may include vendor documentation, system configuration details, or network configuration reports that confirm the devices are not susceptible to known exploits. Can also provide screenshots or logs from security scanning tools or vulnerability assessment reports that demonstrate the inspection process. Additionally, include any related policies or procedures that outline how these inspections are performed and how evidence of compliance is retained.

DCF-719

A2.1.3

SSL and Early TLS Secure Service Offering

Upload documentation showing the secure service offering provided to upgrade point-of-interaction (POI) terminals that use SSL and early TLS.

This could include upgrade plans, project timelines, or communications that outline how and when the POIs will be upgraded to eliminate vulnerabilities associated with these protocols.

Additionally, you may provide any vendor or third-party documentation that supports the upgrade process, as well as logs or records showing the completion of upgrades for affected terminals.

DCF-720

11.6.1

Unauthorized Changes on Payment Pages Detected

Upload screenshots of configuration settings showing the mechanism’s parameters, logs or reports that show alerts being triggered for unauthorized changes, and evidence of the periodic evaluation of the HTTP header and payment page, such as scan or review schedules based on the entity's targeted risk analysis.

Additionally, provide evidence such as system reports that demonstrate that the mechanism is evaluated at least weekly or as specified by the risk analysis.

DCF-721

6.4.3

Payment Page Scripts Inventory and Verification

Upload the inventory of all payment page scripts loaded in the consumer's browser, including a list of scripts and their business or technical justifications. Provide evidence of mechanisms confirming that the scripts are authorized, such as access control logs or approval workflows. To show script integrity, include reports or documentation demonstrating how integrity checks (e.g., hashes, digital signatures) are conducted and the tools or processes used to prevent tampering.

Examples:

  1. Inventory of Scripts: Documented list of payment page scripts with justifications for their use.

  2. Authorization Evidence: Access control logs or approval workflows confirming script authorization.

  3. Integrity Check Documentation: Reports or documentation showing how integrity checks (e.g., hashes, digital signatures) are performed.

  4. Tools/Processes for Tamper Prevention: Documentation or evidence of tools or processes used to maintain script integrity.

DCF-722

12.9.2

Service Provider Responds to PCI DSS Information Requests from Customers

Upload documentation such as a PCI DSS compliance status report that outlines your current compliance standing. Include a responsibility matrix (e.g., RACI) that clearly defines which PCI DSS requirements are your organization’s responsibility, the customer’s responsibility, and those that are shared.

Examples:

  1. PCI DSS Compliance Status Report: A report detailing the current status of your PCI DSS compliance.

  2. Responsibility Matrix (RACI): A document or matrix outlining which PCI DSS requirements are the responsibility of your organization, the customer, and shared responsibilities

DCF-723

A1.2.1

Multi-Tenant Customers Log Availability

Upload the Audit Logging Policy or Log Management Policy, which outlines how audit logs are enabled by default for each customer’s environment. Include access control logs or permission settings that demonstrate log access is restricted to the owning customer. Provide customer-facing documentation (e.g., emails or notices) confirming that log locations are communicated to customers.

Examples:

  1. Audit Logging Policy or Log Management Policy: A document detailing how audit logs are enabled and managed for each customer.

  2. Access Control Logs or Permission Settings: Logs or screenshots showing how access to logs is restricted to the owning customer.

  3. Customer-facing Documentation: Emails or notices sent to customers confirming log locations.

DCF-724

12.10.7, A3.2.5.2

Incident Response Procedures When Cleartext PAN Detected

Upload the Incident Response Policy or Incident Response Procedures document, which outlines the processes for responding to, analyzing, and addressing situations where cleartext PAN is detected in unexpected locations. Include records of past incidents or test scenarios demonstrating adherence to the documented procedures. Provide evidence of staff training or awareness regarding the detection and handling of cleartext PAN, if applicable.

Examples:

  1. Incident Response Policy or Procedures Document: A document outlining processes for handling cleartext PAN detection.

  2. Incident Records or Test Scenarios: Logs or reports of past incidents or simulated test cases showing compliance with procedures.

  3. Staff Training Evidence: Records or certificates confirming that staff has been trained on handling cleartext PAN detection.

DCF-725

8.5.1

MFA Configured to Prevent Misuse

Upload the MFA Policy or Configuration Procedure detailing how replay attacks are prevented, two-factor authentication is required, and MFA bypass is restricted. Include screenshots of system settings that show alignment with the policy. Also, provide documentation for any exceptions authorized by management, including justification and timeframes.

Examples:

  1. MFA Policy or Procedure: Document describing MFA configurations.

  2. System Settings Screenshots: Screenshots showing MFA settings.

  3. Exception Documentation: Approval forms or emails for any MFA exceptions.

DCF-726

8.6.1

Interactive Use of System and Application Accounts Managed

Include screenshots of system settings that restrict interactive login, along with signed approval forms or emails for exceptional access. Provide business justification documentation and audit logs showing individual user actions taken during those exceptions.

Examples:

  1. System Settings Screenshots: Configuration showing login restrictions.

  2. Signed Approval Forms/Emails: Documents authorizing exceptional access.

  3. Business Justification: Documentation explaining the need for exceptions.

  4. Audit Logs: Logs tracking user actions during the exception period.

DCF-727

8.6.3

Passwords for System and Application Accounts Changed Periodically

Provide the "Password Management Policy" or "Access Control Policy" that outlines password change procedures based on the entity's risk analysis and after a compromise.

Examples:

  1. Password Management Policy: Document outlining password change procedures.

  2. Screenshots of Password Complexity Settings: System settings showing password rules.

  3. Records of Password Changes: Logs showing when passwords were updated.

  4. Change Logs/Incident Reports: Documentation of actions taken after a compromise

DCF-728

A3.1.3

Roles and Responsibilities for PCI DSS Compliance for Designated Entities

Upload a "PCI DSS Compliance Responsibility Policy" or "Roles and Responsibilities Matrix" that documents and assigns roles for PCI DSS activities. This should include responsibilities for ongoing compliance activities, assessments, and business-impact analysis.

Example evidence:

  • Screenshots of the roles and responsibilities matrix.

  • Signed acknowledgment forms from responsible individuals.

  • Documentation of meetings or reviews confirming the assignments.

DCF-729

A.3.1.2

Formal PCI DSS Compliance Program in Place

Upload documentation of the compliance program, including detailed processes and examples of business-impact analysis reports. This should include meeting notes or discussions that address the PCI DSS impacts on business decisions.

DCF-730

1.5.1

Security Controls on Devices that Connect to the Internet

Evidence:

  • Security Control Inventory: Upload a document (e.g., a spreadsheet or list) showing all active security controls such as firewalls, endpoint protection software, and any other relevant security measures.

  • Configuration Settings: Provide screenshots or configuration files that demonstrate the security controls are configured and active on both company- and employee-owned devices.

  • Logs: Include logs that verify the application of these security controls across the devices, confirming they are being enforced properly.

DCF-731

A3.2.5

Documented PAN Discovery Methodology

Upload a document detailing the approach for identifying cleartext PAN within the environment, including both automated and manual mechanisms used.

Examples:

  • Data Discovery Methodology Document: Document outlining the approach for identifying cleartext PAN, including automated and manual methods.

  • Discovery Logs: Logs showing data discovery efforts conducted at least once every three months or after significant CDE changes.

  • Discovery Results: Reports or screenshots documenting findings and actions taken after the discovery process.

DCF-732

12.3.3

Review of Cryptographic Suites and Protocols

Upload an inventory document that lists all cipher suites and protocols in use, including their purpose and where they are used within the environment.

Examples:

  • Cipher Suites and Protocols Inventory: Document listing all cipher suites and protocols in use, their purpose, and locations within the environment.

  • Review Reports or Sign-off Documentation: Records showing that the inventory was reviewed at least once every 12 months.

  • Cryptographic Vulnerabilities Response Document: Document outlining responses to potential changes or vulnerabilities in cryptographic protocols and suites..

DCF-733

A3.3.3

Review of Business as Usual Activity

Upload documents such as the review records that show the reviews were performed every three months, including the names of personnel assigned to the PCI DSS compliance program.

Examples:

  • Review Records: Documentation showing that reviews were performed every three months, including names of assigned personnel.

  • Signed-off Documentation or Acknowledgment Forms: Signed confirmation from responsible personnel that reviews were conducted.

  • Retention Records: Records confirming that these documents are retained for at least 12 months.

DCF-734

A3.2.6.1

Incident Response Procedures for Cleartext PAN Removal

Upload the documented incident response procedures that outline the steps to take when cleartext PAN is detected being removed from the CDE via unauthorized methods.

Examples:

  • Incident Response Procedures: Document outlining the steps to take when cleartext PAN is detected being removed from the CDE via unauthorized methods.

  • Incident Logs or Alert Records: Logs showing investigations conducted by responsible personnel.

  • Corrective Action Plans: Documentation addressing any identified data leaks or process gaps with plans for remediation.

DCF-735

A2.1.2

Migration Plan in Place for SSL and Early TSL POS POI

Upload the documented risk mitigation and migration plan that outlines the steps for addressing existing connection points to POS/POI terminals using SSL and/or early TLS.

Examples:

  • Risk Mitigation and Migration Plan: Document outlining the steps to address existing connection points to POS/POI terminals using SSL and/or early TLS.

  • Meeting Minutes, Project Plans, or Progress Reports: Documentation demonstrating the implementation of the plan.

DCF-736

A3.2.5.1

PAN Discovery Mechanisms Assessed

Upload the documented process that outlines how the methods for data discovery are tested to ensure the effectiveness of identifying cleartext PAN.

Examples:

  • Data Discovery Testing Process: Document detailing how data discovery methods are tested for effectiveness in identifying cleartext PAN.

  • Test Results, Reports, or Logs: Evidence of the last test execution performed within the last 12 months, confirming the completeness and accuracy of the data discovery process.

DCF-737

3.6.1.2

Protected Storage of Secret and Private Keys for Account Data

Upload evidence related to secret and private keys stored in a secure cryptographic device (SCD).

Examples:

  • Key Management Policy: A screenshot of the relevant section of the policy document that describes the key management process, focusing on how secret and private keys are stored within the secure cryptographic device (SCD).

  • Configuration Documentation: A screenshot of the system configuration demonstrating how keys are stored as two full-length key components or key shares within the SCD. This could include system settings or encrypted key storage details.

  • System or Audit Logs: A screenshot of the audit logs showing key management activities, such as key storage, access events, or use, that confirm the use of the secure cryptographic device (SCD) for key management.

DCF-738

3.5.1.1

Keyed Cryptographic Hashes of PAN

Upload evidence related to the management of keyed cryptographic hashes for PAN.

Examples:

  • Documented Key Management Policy/Procedure: A screenshot or copy of the company's key management policy or procedure that outlines how hashing methods are implemented and how the resulting keyed cryptographic hashes of the entire PAN are managed in accordance with key management processes.

  • Hashing Method Documentation: A screenshot or document detailing the hashing methods used to render PAN unreadable, ensuring that they are keyed and meet industry standards.

  • Key Management System Logs or Configuration: A screenshot or document showing key management system logs or configurations that confirm the management of the cryptographic keys used in the hashing process. This could include screenshots of system settings, encryption modules, or key rotation processes that align with the company's procedures.

DCF-739

A3.2.2

PCI DSS Scope Impact Assessment

Upload evidence related to the PCI DSS scope impact assessment for system or network changes.

Examples:

  • Assessment Results Documentation: A sample of the impact assessment reports or records that document the results of the scope impact assessment, including any updates made to the PCI DSS scope based on system or network changes.

  • Sign-off Documentation: A copy of the sign-off documentation, such as emails, approval forms, or internal communication records, confirming that responsible personnel have reviewed and approved the results of the impact assessment.

DCF-740

1.1.1, 2.1.1, 3.1.1, 4.1.1, 5.1.1, 6.1.1, 7.1.1, 8.1.1, 9.1.1, 10.1.1, 11.1.1

PCI DSS Compliance Policy

Upload evidence of the documented policy outlining the company's requirements and activities related to PCI DSS compliance.

Example:

  • PCI DSS Compliance Policy: A copy of the documented policy that details the company's requirements and activities to support PCI DSS compliance.

DCF-741

10.2.1

Logging and Monitoring Policy

Upload Logging and Monitoring Policy.

DCF-784

6.3.2

Software Composition Analysis (SCA)

Upload evidence to show that your organization checks software components and libraries for policy and license compliance, security risks, and supported versions.

Example: Screenshots showing that software composition analysis tools are used as part of your CI/CD pipeline to check for vulnerabilities in third party libraries.

DCF-814

6.5.1, 1.2.2

Security Impact Assessment for Changes

Upload evidence of the documented process for evaluating the security impact of system changes and validating security requirements after implementation.

Examples:

  • Change Management Policy/Procedure: A copy of the documented policy or procedure that outlines the process for evaluating the security impact of system changes before implementation.

  • Change Impact Assessment Records: Evidence of completed security impact assessments for system changes, including any findings or recommendations related to vulnerabilities or security risks.

  • Post-Implementation Validation Records: Documentation that confirms security requirements were validated after system changes were implemented, such as validation reports, testing records, or sign-offs by responsible personnel.

DCF-832

12.8.3

Review of Agreements and Contracts

Upload evidence of the process for reviewing third-party agreements for PCI DSS compliance.

Examples:

  • Third-Party Agreement Review Policy: A documented policy or procedure outlining how third-party agreements are reviewed for PCI DSS compliance.

  • Review Records for New Agreements: Documentation (e.g., meeting notes or emails) showing that new third-party agreements are reviewed for PCI DSS requirements.

  • Ad-Hoc Review Records for Existing Agreements: Evidence of periodic reviews for existing agreements, such as review reports or emails confirming their ongoing appropriateness.

  • Sign-Off Forms: Signed documents or acknowledgment forms from personnel confirming the review of third-party agreements.

Did this answer your question?