Most organisations collect PCI DSS evidence the same way every year: a spreadsheet of three hundred requirements, a mailbox, six weeks of asking the same engineers for the same exports, and a folder nobody can navigate by the end. The process that replaces it is not complicated. It is built on one idea: ask once.
One file, many requirements
A firewall ruleset export is evidence for the requirement about restricting inbound traffic, the one about outbound traffic, the one about the rule review, and the one about documented business justification for each rule. Four requirements, one file, one request. A quarterly access review record serves the requirement about reviewing accounts, the one about removing leavers, and the one about privileged access. The organisations that struggle request the same export four times, from four people, into four folders.
Requested once
Requirements it supports
Firewall rulesets and their last review
1.2.7Network security controls reviewed every six months
1.3.1Inbound traffic to the CDE restricted
1.3.2Outbound traffic from the CDE restricted
System hardening standard
2.2.1Configuration standards maintained
2.2.2Vendor default accounts managed
2.2.4Only necessary services enabled
Signed-off access review
7.2.4User access reviewed every six months
8.2.6Inactive accounts disabled within 90 days
3 requests to your team. 8 requirements supported.
Build the list the other way round. For each piece of evidence, list every requirement it supports. Then the request to the engineer is “the ruleset export, annotated”, once, and the assessor finds it in four places.
What good looks like, written down
For every item, write what “good” looks like before anyone collects it. For the ruleset: every rule has a documented business justification, and the last review is dated within six months. For the access review: a dated list, a named reviewer, and a record of what was removed. That one sentence turns a request from “send me the firewall config” into something an engineer can satisfy first time, and an assessor can review in minutes.
An owner and a date
Each item has one named owner, the person who produces it, and a date by which it has to exist. Recurring items have a frequency: this export every quarter, this review every six months, this test every year. A control owned by “IT” is not owned. A control owned by Marie, due on the first of the quarter, happens.
Evidence of operation, not definition
The process has to produce records that a control operated, not documents that it exists. A policy is collected once. A log review happens every day and leaves a record every day. The evidence process is mostly about the second kind: dated, attributable records produced by the routine, kept where they can be found, so that when the assessment period is reviewed, twelve months of operation are there.
The process has to produce records that a control operated, not documents that it exists.
Where the software comes in
We built software for this, and we use it on every engagement. Each evidence request is asked once and linked to every requirement it serves. Each item carries its “what good looks like”, its owner and its date. Findings are tracked to closure against the evidence that closes them, and the report is drafted from the work itself rather than retyped from a folder. The point is not the software; any organised system does most of this. The point is that the structure exists before the assessment starts, so that the assessment is a confirmation of a year’s records rather than a six-week reconstruction of them.
What people get wrong
They organise evidence by requirement number and file the same export under four numbers, or under none. They collect at assessment time, so the only evidence that exists is from the last month. They let the assessor’s request list define the process, which means the process is reinvented each year by a different assessor.