Build the Evidence Package Your QSA Needs

Firewall rule change logs for Requirement 1.3 regularly go missing. Every QSA engagement begins with a request list, and it often arrives sooner than expected in a format that does not match how your team tracks work. The difference between what you track internally and what the QSA needs to review creates much of the pre-audit scramble.

The QSA request list is not arbitrary. It follows the Report on Compliance template published by the PCI Security Standards Council. Learn that structure before the engagement, then collect evidence against it instead of retrofitting documentation later.

ROC Template Is Your Outline

The Report on Compliance (ROC) is the formal output for a Level 1 merchant or service provider assessment. It follows the DSS requirement hierarchy: each requirement has testing procedures, and each procedure has a finding field where the QSA records observations and examined evidence.

The ROC therefore acts as an indirect evidence index. Before the engagement, download the current ROC Reporting Template from the PCI SSC document library. Review each requirement and ask what a QSA would need to complete its finding field. That answer, for every testing procedure, becomes your evidence checklist.

The ROC template changed with DSS 4.0 to reflect new requirement numbering. A checklist based on DSS 3.2.1 will not align with its testing procedures. The changes between 3.2.1 and 4.0 include moved sub-requirements and additions, not just cosmetic renumbering. Check your list against the current template before collecting evidence for the wrong specification.

Artifacts Most Likely to Go Missing

Across merchant evidence packages at different DSS stages, the same incomplete or missing artifact types recur. They are generally not difficult to produce, but they were not collected continuously, making later back-filling difficult or impossible.

Firewall rule change logs (Requirement 1.3). DSS 4.0 Requirement 1.3.2 requires documented business need for all allowed traffic between zones. Firewall rules therefore need written justification, and rule changes must be traceable through change management. Often the rules and an exported configuration exist, but the past 12 months of change history, including who approved each change and why, is missing or remains in an unexported ticket system. Requirement 1.3 needs both the current configuration and historical change trail.

Access review records (Requirement 7). Under DSS 4.0, Requirement 7.2.4 requires reviewing user access to CDE system components at least once every six months. The review may have occurred, but evidence must identify the reviewer, date, accounts examined, and disposition of removed or flagged access. An email thread is insufficient, and a spreadsheet without version history is marginal. Use a dated sign-off attached to a formal access review process.

Penetration test scope documentation (Requirement 11.4). Requirement 11.4.1 requires an annual penetration test covering the CDE external perimeter and internal network. The testing firm's report is usually available. More often absent is the scope document showing how the boundary was set, why systems were included, and that the scope matches the actual CDE boundary. QSAs must confirm the right surface was tested, not merely that testing occurred.

Targeted risk analysis documentation (new in 4.0). DSS 4.0 added targeted risk analysis (TRA) for certain requirements that once used fixed annual schedules. When 4.0 permits a customized approach or a frequency other than the default, a documented TRA must support that choice. Many merchants do not realize TRA documentation is required until the QSA requests it.

Arrange Evidence by Requirement Number

The most useful evidence structure mirrors the ROC: create one folder or evidence set for each requirement family, and label artifacts with the requirement number and testing procedure reference. If the QSA requests evidence for Requirement 8.3.6, minimum password length for CDE accounts, they should go straight to "Req 8.3" and find it without back-and-forth.

The difficulty is that one requirement's evidence often sits across several systems. Access reviews may be in a ticketing system, firewall rules in network management, and patch records in endpoint management. Bringing them together and labeling them by requirement is manual work that commonly takes three to six weeks before an audit.

This is the core problem PCIOasis is built to address: continuous collection organized by DSS requirement from the moment your CDE is connected, leaving evidence pre-labeled and pre-organized for the QSA. It does not remove every task, but it removes the back-filling sprint.

Evidence Freshness and the 12-Month Window

PCI DSS assessments cover 12 months, rather than only the current snapshot. QSAs generally request evidence for the full period since the prior assessment. Evidence not collected when created is hard to rebuild: logs may be purged, access reviews may not be retained, and firewall approvals may be buried in email.

Evidence collection should begin the day after the last assessment, not 60 days before the next. For periodic controls such as quarterly vulnerability scans or semi-annual access reviews, retain a documented schedule and results for every cycle in the assessment window. Missing a quarterly scan is not automatically a finding when a documented exception and compensating control exist, but that situation needs its own evidence trail.

What Continuous Evidence Collection Changes

Continuous monitoring does not remove the evidence package. It builds that package incrementally instead of under deadline pressure. Hourly firewall configuration samples create a 12-month history. Access review logs saved as reviews occur avoid back-filling, and vulnerability scan results retained at scan time provide a complete assessment record.

Continuous collection cannot replace artifacts that occur only periodically, such as penetration test reports. Annual risk assessments, targeted risk analysis documents, and policy reviews are similar. These require documentation when the activity occurs, not automation. Your package will contain both ongoing operational data and point-in-time records; the aim is to reduce what needs back-filling.

Automated evidence collection does not replace an experienced QSA relationship or a careful pre-assessment review. It changes your starting point: when the assessor sends the first request list, you should open an organized archive instead of scheduling four weeks of ticket pulls and screen captures.

Review Evidence One Week Before the QSA Arrives

One week before the assessment, compare the package with the ROC testing procedures. Check whether the 12-month CDE firewall change log is complete and includes approvals. Confirm quarterly vulnerability scan results are present, with passing status or documented remediation for each cycle. Confirm both scheduled access review cycles in the assessment window are present, dated, and tied to identified reviewers.

A gap found now can be remediated if addressed immediately. The same gap found by the QSA on day one of fieldwork becomes a finding requiring a remediation plan and possible re-test. The pre-assessment review is your last opportunity to control the outcome, and its return is significant for the time spent.