Evidence Guide
PCI DSS Evidence Collection — What Auditors Actually Expect
Even a perfectly secured environment will fail its PCI assessment without well-organised, complete evidence. This guide explains exactly what evidence your assessor needs for each of the 12 PCI DSS requirements, how to organise it, and how to avoid the gaps that derail audits.
What Is PCI DSS Evidence and Why It Matters
PCI DSS evidence is the documented proof that your organisation has implemented and is maintaining the security controls required by the standard. Evidence transforms your compliance from a claim into a verifiable fact. Without it, your assessor — whether that is a QSA conducting a Report on Compliance or you completing a Self-Assessment Questionnaire — cannot validate that controls are in place, operational, and effective.
The distinction between being compliant and demonstrating compliance is critical. Organisations routinely implement strong security controls but fail assessments because they cannot produce the documentation to prove it. A firewall with excellent rules is worthless to an assessor without a screenshot or export of those rules, a policy governing their management, and change records showing they are maintained through a formal process.
PCI DSS v4.0.1 has expanded evidence expectations significantly. The introduction of targeted risk analyses (Requirement 12.3.1), the customised approach, and 64 new requirements means there are more artefacts to collect than ever before. Organisations that treat evidence collection as a last-minute sprint before assessment day invariably discover gaps that cannot be filled retroactively — you cannot fabricate six months of quarterly scan history the week before your audit.
Evidence Types
PCI DSS evidence falls into eight distinct categories. Understanding these categories is the foundation for systematic, gap-free collection.
- Policies — Written information security policies approved by management, reviewed annually, and covering each of the 12 PCI DSS requirement domains. Your assessor verifies that policies exist, are current, and are distributed to relevant personnel.
- Procedures — Documented operational procedures for recurring security activities: user provisioning and deprovisioning, change management, key rotation, incident response, and vulnerability remediation. Procedures must match actual operational practices.
- Configurations — Screenshots, exports, or printouts of system configurations: firewall rulesets, access control lists, encryption settings, hardening baselines, password policies, and logging configurations. These prove that technical controls are correctly implemented.
- Logs and audit trails — Samples demonstrating that audit logging is active, capturing required events, and being reviewed. Assessors do not review every log entry but verify that logging infrastructure is functional and comprehensive.
- Diagrams — Network topology diagrams showing CDE boundaries and security control placement, and data flow diagrams showing how cardholder data enters, moves through, and exits your environment.
- Scan and test reports — Quarterly ASV scan results, quarterly internal vulnerability scan reports, annual penetration test reports, and wireless scanning reports. These must cover the full assessment period.
- Training records — Completion records for security awareness training, developer secure coding training, and role-specific training showing dates, topics, and personnel who completed each programme.
- Third-party documentation — Service provider Attestations of Compliance, contracts with required security clauses, and responsibility matrices defining which PCI requirements each party fulfils.
The Evidence Library contains sample artefacts for every requirement, showing exactly what well-prepared evidence looks like for each category.
Evidence by PCI DSS Goal and Requirement
PCI DSS organises its 12 requirements under six security goals. Below is a breakdown of the specific evidence your assessor expects for the most critical requirements within each goal. This is not exhaustive — consult the full requirements browser for every sub-requirement — but it covers the artefacts that assessors most commonly request and that organisations most commonly miss.
Goal 1: Build and Maintain a Secure Network and Systems
Requirement 1 — Network Security Controls. Your assessor will request: a current network diagram showing all CDE boundaries and security control placement; firewall or network security control rulesets with documented justification for each rule; evidence that rulesets are reviewed at least every six months (or per your targeted risk analysis frequency); configuration standards for routers, switches, and firewalls; and change management records for any ruleset modifications. For cloud environments, provide VPC configurations, security group rules, and network ACLs with the same level of documentation.
Requirement 2 — Secure Configurations. Provide system hardening standards (CIS Benchmarks, vendor guidelines, or your own documented baselines), configuration samples from representative systems showing compliance with those baselines, evidence that default passwords and accounts have been changed or disabled, and an inventory of all system components with their software versions. Assessors sample from your inventory, so every system must be hardened — not just the ones you think they will check.
Goal 2: Protect Account Data
Requirement 3 — Protect Stored Account Data. This is one of the most evidence-intensive requirements. Provide: your data retention and disposal policy, evidence of data discovery scans (showing you know where cardholder data exists), encryption configurations for data at rest (algorithm, key length, key management procedures), evidence that sensitive authentication data is not retained after authorisation, and key management documentation including key custodian assignments, key rotation schedules, and split-knowledge/dual-control procedures.
Requirement 4 — Protect Data in Transit. Provide TLS configuration screenshots showing minimum TLS 1.2 on all transmission channels, certificate inventories with expiry dates, and evidence that cardholder data is never sent via unencrypted channels (email, chat, FTP). For organisations using end-to-end encryption, provide architecture documentation and key management evidence.
Goal 3: Maintain a Vulnerability Management Programme
Requirement 5 — Anti-Malware. Provide anti-malware deployment evidence showing coverage across all CDE systems, configuration screenshots demonstrating real-time scanning and automatic updates, and logs confirming the solution is active and cannot be disabled by users. Under v4.0.1, you also need a documented targeted risk analysis for malware scan frequency (Req 5.3.2.1) and evidence of phishing protection mechanisms.
Requirement 6 — Secure Development. Provide your secure development lifecycle documentation, code review or application security testing records, change management logs for all CDE system changes (Req 6.5.1), and for e-commerce, evidence of payment page script management per Requirement 6.4.3 — including your script inventory, authorisation records, and integrity monitoring mechanism.
Goal 4: Implement Strong Access Control Measures
Requirement 7 — Restrict Access. Provide your role-based access control matrix, access approval records, evidence of least-privilege implementation, and periodic access review records showing that access rights are reviewed at least every six months.
Requirement 8 — Identify Users and Authenticate Access. This requirement expanded significantly under v4.0.1. Provide: MFA configuration evidence for all CDE access points (Req 8.4.2) — not just remote access; password policy configuration showing minimum 12 characters (Req 8.3.6); evidence that shared and group accounts are prohibited or controlled per Req 8.5; system and service account inventory with documented justification (Req 8.6.1–8.6.3); and user account lifecycle procedures covering provisioning, modification, and deprovisioning.
Requirement 9 — Physical Security. Provide physical access control evidence: badge reader logs, visitor logs, CCTV retention records, media destruction certificates, and point-of-interaction device inspection records. For organisations with no physical CDE (fully cloud-hosted), provide your cloud provider's SOC 2 report covering physical security controls and your responsibility matrix.
Goal 5: Regularly Monitor and Test Networks
Requirement 10 — Log and Monitor All Access. Provide audit log samples showing capture of all required event types: individual user access to cardholder data, all administrative actions, access to audit trails, invalid access attempts, authentication mechanism usage, and audit log initialisation. Under v4.0.1, also provide evidence of automated log review mechanisms (Req 10.4.1.1) and your targeted risk analysis defining review frequency. SIEM configuration screenshots and alerting rule documentation are typically requested.
Requirement 11 — Security Testing. Provide: four consecutive quarters of passing ASV scan reports, quarterly internal vulnerability scan reports with remediation evidence, annual external and internal penetration test reports, wireless access point detection results, and file integrity monitoring (FIM) configuration and alert samples. For organisations using network segmentation, penetration testing must validate that segmentation is effective (Req 11.4.5) — this is a frequently missed evidence item.
Goal 6: Maintain an Information Security Policy
Requirement 12 — Information Security Policy. Provide: your overarching information security policy with management approval and annual review dates; acceptable use policies; risk assessment documentation (Req 12.3); security awareness training records with completion dates and topics (Req 12.6); incident response plan and records of annual testing (Req 12.10); and all targeted risk analysis documents required by v4.0.1 (Req 12.3.1). Also provide service provider management documentation: contracts, AOCs, and responsibility matrices for every third party handling cardholder data (Req 12.8–12.9).
Evidence Naming Conventions and Organisation
How you organise your evidence is almost as important as collecting it. Assessors reviewing hundreds of evidence artefacts will quickly lose patience with disorganised file structures, ambiguous file names, or evidence scattered across multiple systems. A consistent, well-labelled evidence repository demonstrates operational maturity and accelerates the assessment process.
Recommended Naming Convention
Adopt a naming standard that encodes four pieces of information into every file name: the requirement number, the evidence type, the collection date, and the system or scope it covers. Use hyphens or underscores consistently. Examples:
Req-01.2.1_Config_2026-01-15_Palo-Alto-FW-Ruleset.pdfReq-03.5.1_Config_2026-01-20_AES256-Encryption-Settings.pngReq-08.4.2_Config_2026-02-01_Okta-MFA-CDE-Policy.pngReq-10.2.1_Log_2026-02-10_SIEM-User-Access-Sample.csvReq-11.3.1_Report_2026-Q1_ASV-Scan-External.pdf
Folder Structure
Organise your evidence repository with a top-level folder for each of the 12 PCI DSS requirements. Within each requirement folder, create sub-folders for each evidence type (policies, configurations, logs, reports). Maintain a master evidence index — a spreadsheet or tracker that maps each sub-requirement to its corresponding evidence artefact(s), collection date, and status (collected, pending, not applicable).
This structure allows your assessor to navigate directly to the evidence they need for any given requirement without asking you to locate it. GRCTrack's compliance platform automatically organises uploaded evidence by requirement and maintains the master index, eliminating manual file management.
Digital Evidence vs Physical Evidence
Most PCI DSS evidence today is digital: configuration exports, screenshots, scan reports, and electronic policy documents. However, some requirements — particularly Requirement 9 (physical security) — may involve physical evidence such as visitor logbooks, media destruction certificates, or photographs of physical access controls. For physical evidence, digitise it by scanning or photographing, and include it in your evidence repository with the same naming convention. Ensure photographs include enough context to identify the location and date.
For configuration screenshots, capture the full screen including the system name, timestamp, and the specific setting being demonstrated. Partial screenshots that crop out identifying information force the assessor to request additional evidence, slowing the assessment. If a configuration spans multiple screens, capture each screen and label them sequentially (e.g., Req-01.2.1_Config_Page-1-of-3.png).
Retention Periods and Evidence Freshness
PCI DSS Requirement 10.7 specifies that audit trail history must be retained for at least 12 months, with the most recent three months immediately available for analysis. While this requirement technically applies to audit logs, the principle extends to all compliance evidence: your assessor expects to see a full year of evidence demonstrating continuous compliance, not a single point-in-time snapshot.
Minimum Retention: One Year
At minimum, retain all evidence for one full year. This means you should have four consecutive quarters of ASV scan results, four quarters of internal vulnerability scan results, at least one annual penetration test report, 12 months of audit log archives, and a full year of change management records. If your assessment cycle is annual (as most are), retaining evidence for the full inter-assessment period ensures you can demonstrate compliance across the entire cycle without gaps.
Recommended Retention: Full Assessment Cycle Plus One Year
Best practice is to retain evidence for at least two full assessment cycles. This provides continuity if your assessment dates shift, allows your current assessor to reference prior-year evidence when evaluating trends, and protects you in the event of a forensic investigation or regulatory inquiry after a breach. Many organisations retain PCI evidence for three to five years, aligning with their broader data retention policies.
Evidence That Must Be Collected Continuously
Some evidence artefacts cannot be generated retroactively. These items require ongoing collection throughout the year:
- Quarterly ASV scans — Must show four consecutive quarters of passing results. You cannot backdate scan reports.
- Quarterly internal vulnerability scans — Same quarterly cadence requirement as ASV scans.
- Audit logs — Must be continuously captured. A gap in logging is a compliance gap that cannot be remediated after the fact.
- Change management records — Every change to CDE systems must be documented as it occurs. Reconstructing change history months later is unreliable and assessors will flag it.
- File integrity monitoring alerts — FIM must be running continuously. Historical gaps indicate periods where changes could have gone undetected.
- Log review records — Under Req 10.4.1.1, you must demonstrate that logs are reviewed through automated mechanisms at the frequency defined by your targeted risk analysis. Evidence of review must span the full assessment period.
Set up a recurring evidence collection calendar. The PCI Compliance Checklist includes a timeline view showing when each periodic evidence item is due throughout the year.
Common Evidence Gaps That Cause Audit Failures
Based on analysis of hundreds of PCI DSS assessments, these are the evidence gaps that most frequently lead to non-compliance findings. Each represents a situation where the organisation likely had the control in place but could not prove it to the assessor.
1. Missing Firewall Rule Justifications
Requirement 1.2.5 mandates that all services, protocols, and ports allowed through network security controls are authorised and documented with a business justification. Many organisations can produce their firewall rulesets but cannot produce the corresponding justification document explaining why each rule exists. A 500-rule firewall policy without a justification register is a finding. Maintain a living document that maps each rule to its business purpose, approval date, and approving authority.
2. Incomplete ASV Scan History
Assessors need four consecutive quarters of passing ASV scans. The most common gaps: the first quarter was a failing scan that was never re-scanned after remediation, one quarter was simply missed, or the organisation changed ASV vendors mid-year and did not ensure continuity. Track your ASV scan schedule rigorously — each quarter's window is approximately 90 days, and a missed quarter cannot be retrospectively filled.
3. No Evidence of Periodic Access Reviews
Requirement 7.2.5 requires that user access rights are reviewed at least every six months. Many organisations conduct these reviews informally — a manager glances at the user list and confirms it looks correct. Without a documented review record showing who reviewed access, when, what was reviewed, and what actions were taken (accounts removed, permissions adjusted), the assessor cannot validate this control. Formalise the review process and retain signed-off records.
4. Audit Logs Missing Required Event Types
Requirement 10.2 specifies the exact event types that must be logged: individual user access to cardholder data, all administrative actions, access to audit trails, invalid access attempts, authentication events, and more. Organisations frequently enable "default" logging on their systems without verifying that every required event type is captured. Perform a logging coverage audit against every Req 10.2 sub-requirement and retain the audit results as evidence.
5. Missing Targeted Risk Analyses
PCI DSS v4.0.1 introduced targeted risk analyses as a replacement for blanket timeframes in numerous requirements. Many organisations have not yet documented these analyses, even though the controls themselves are in place. Each targeted risk analysis must identify the asset or process, the threats and vulnerabilities, the likelihood and impact of compromise, and the resulting frequency determination. Requirement 12.3.1 is the meta-requirement governing all of them. See the requirements browser for every instance where a targeted risk analysis is required.
6. Service Provider AOCs on Older PCI DSS Versions
With PCI DSS v4.0.1 now fully mandatory, your service providers' Attestations of Compliance must also be assessed against v4.0.1. Organisations frequently retain AOCs from their service providers without verifying the assessment version. An AOC assessed against v3.2.1 or even v4.0 (without the mandatory future-dated requirements) is no longer sufficient evidence of your provider's compliance.
Tips for Working with Your QSA on Evidence Review
The relationship between your organisation and your assessor significantly impacts the efficiency and outcome of the evidence review process. Here are practical strategies for making the evidence exchange as smooth as possible.
Conduct a Pre-Assessment Walkthrough
Before the formal assessment begins, schedule a call with your QSA to walk through your evidence repository structure and discuss any areas where you are uncertain about the required evidence. This is not a pre-assessment — it is a logistics discussion. A good QSA will identify any structural gaps in your evidence organisation early, saving both parties time during the formal assessment. Find experienced QSAs through the QSA Directory.
Provide Context with Every Artefact
A configuration screenshot without context forces the assessor to ask follow-up questions. For every evidence artefact, include a brief description of what it demonstrates, which system or component it was collected from, and the date of collection. This metadata can be embedded in the file name, included as annotations on screenshots, or maintained in your evidence index.
Do Not Over-Collect
More evidence is not always better. An assessor who receives 500 documents when 100 would suffice must spend time sorting through irrelevant material, which slows the assessment and increases cost. Focus on providing exactly the evidence that demonstrates compliance with each specific sub-requirement. If your assessor requests additional detail, provide it promptly — but do not front-load your repository with tangentially related documents.
Respond to Evidence Requests Promptly
During the assessment, your QSA will issue evidence requests for items not in your initial submission or for clarification on existing items. The single greatest factor in assessment timeline is how quickly your team responds to these requests. Designate a single point of contact who can coordinate evidence gathering across departments and ensure responses within 24–48 hours. Delays in evidence response directly extend your assessment timeline and cost.
Be Transparent About Gaps
If you know a control has a gap, tell your assessor upfront. Assessors are trained to identify gaps; attempting to obscure one with incomplete evidence will be discovered and damages the trust relationship. Proactively disclosing a gap along with your remediation plan demonstrates maturity and allows the assessor to work with you on a resolution timeline rather than issuing a surprise finding.
For a complete walkthrough of the assessment process from start to finish, read the First PCI Assessment guide.
Automate Your Evidence Collection
GRCTrack maps every PCI DSS requirement to the exact evidence your assessor expects, tracks collection progress, and organises your evidence repository automatically.