PCI DSS preparation
Build a working evidence file before anyone asks for it
A PCI DSS review becomes painful when the controls exist but nobody can prove when they were checked, who approved them or what changed. A usable PCI DSS evidence checklist fixes that problem. It gives a Sydney business one place to connect each requirement with an owner, a current record and a clear review date.
The PCI Security Standards Council document library lists PCI DSS v4.0.1 as the current standard. The Council described v4.0.1 as a limited revision that added clarifications and corrections without adding or removing requirements. The standard applies to organisations that store, process or transmit payment account data, as well as systems that can affect the security of that data. These points are set out in the official PCI DSS Quick Reference Guide.
This article is a working guide for business owners and internal IT teams. It does not determine your validation level or certify compliance. Your acquiring bank or payment brand determines which validation method applies, and a Qualified Security Assessor may be required for formal assessment work. Milnsbridge can support the technical control work through its PCI DSS compliance service, including gap analysis, remediation planning and implementation.
Evidence foundations
The four records that make evidence usable
A scope record
Start with a dated list of payment channels, locations, applications, networks and service providers. Record how cardholder data enters the business, where it travels and whether it is stored. Include systems that can affect the security of the cardholder data environment, even when those systems do not handle card data directly.
A control record
For every applicable control, name the control owner and link to the current evidence. The evidence may be a configuration export, access review, scan report, policy approval or ticket. Record the period covered. A screenshot with no system name, date or context is hard to assess and easy to misfile.
An exception record
Document failed checks and overdue tasks in the same evidence file. Give each item an owner, target date and remediation reference. Quietly deleting a failed result breaks the audit trail. A closed ticket that links the original finding to the fix is much more useful.
A review record
Add the date, reviewer and outcome for every recurring activity. Quarterly scans, access reviews and log checks should leave a sequence of records rather than one current file that gets overwritten. The history shows whether the control operates throughout the year.
Evidence quality
Policy files are different from operating evidence
A policy says what the business intends to do. Operating evidence shows that people and systems followed it. Both matter, but one cannot stand in for the other. Keep the connection visible. Give the policy an owner, version and approval date. Then link each recurring activity to the policy section it supports.
Generic record
A password policy sets authentication rules. A vulnerability policy sets a scanning timetable. Those documents describe the intended process, but they do not prove that the settings were applied or the scan took place.
Usable evidence
Keep identity configuration exports, access reviews and exception tickets with the policy. For vulnerability work, retain the dated scan, remediation ticket and successful re-scan. The chain should show what happened and when.
Requirement mapping
Map evidence to the twelve PCI DSS requirements
The PCI DSS Quick Reference Guide groups the standard into twelve principal requirements. A practical evidence register should follow the same numbering so a reviewer can move between the standard and your records without translating an internal naming system.
Network and account data
Requirements 1 to 4 cover network controls, secure configurations, stored account data and encryption during transmission. Keep dated diagrams, data flows, firewall rules, rule reviews, retention records, disposal evidence and encryption settings. Managed FortiGate can support managed firewall configuration and monitoring.
Secure systems and software
Requirements 5 and 6 cover protection from malicious software and secure systems and software. Evidence can include endpoint status, detection alerts, patch reports, vulnerability findings, remediation tickets and change approvals. Milnsbridge's endpoint protection service supports this control work.
Access control
Requirements 7 to 9 cover business need, user identification, authentication and physical access. Keep role definitions, approved access requests, account inventories, privileged access reviews, termination records and authentication settings. Add storage and destruction records for paper receipts or physical media.
Logging, testing and governance
Requirements 10 to 12 cover logging, monitoring, security testing and organisational policy. Keep log source inventories, alert reviews, incident tickets, scan results, risk assessments, training records and service provider reviews. Link findings to fixes and re-tests.
Official framework
The numbers behind the evidence plan
12
principal PCI DSS requirements (PCI DSS Quick Reference Guide, January 2025)
4
ongoing steps covering assessment, remediation, reporting and maintenance (PCI DSS Quick Reference Guide, January 2025)
3 months
minimum interval for required external vulnerability scans (PCI DSS Quick Reference Guide, January 2025)
6
risk-based milestones in the Prioritized Approach (PCI SSC Prioritized Approach for PCI DSS v4.0.1, January 2025)
Common gaps
Four control areas that need a clear evidence trail
Scope and segmentation
A payment terminal may be simple, while the network around it is not. Record the connection path, relevant network segments and systems that can reach the payment environment. Keep the rule set and the review record together. If segmentation reduces scope, retain the test evidence used to support that conclusion.
Identity and access
Access evidence should show the approved request, the account created and later reviews of continued need. Include privileged and service accounts. When a staff member leaves or changes roles, keep the ticket that shows when access was removed or changed.
Vulnerability management
A scan report is the beginning of the record. Add the owner, due date, remediation ticket and re-scan result. The PCI guidance says an approved scan result has no detected component with a CVSS score of 4.0 or higher and no automatic failure condition. Keep both failed and passing reports so the remediation path is visible.
Service providers
Using a payment provider does not automatically remove the merchant's PCI DSS responsibility. Keep the provider agreement, responsibility matrix, current compliance documentation and your review record. Write down which controls the provider performs and which remain with your business.
Working rhythm
Use a monthly evidence routine
Waiting for an annual review creates rushed screenshots and missing dates. A short monthly routine is easier to sustain. Review new systems and payment process changes first. Check whether the scope record or data flow diagram needs an update. Then collect recurring evidence due that month, close old findings and confirm that links in the register still open. Finish with an owner review of overdue items.
Use filenames that carry meaning. Include the control number, system, evidence type and date. Keep original exports where possible. If a screenshot is necessary, capture enough context to identify the system and setting. Add a short note explaining what the image proves.
Do not treat the PCI Security Standards Council's Prioritized Approach as a shortcut. It groups work into six risk-based milestones, but the Council states that it is not a substitute for PCI DSS and does not create a one-size-fits-all order. It can help organise remediation while formal obligations remain tied to the applicable standard and validation method.
Submission control
Prepare the right submission set
The reporting method depends on the business, payment channels and instructions from the receiving entity. PCI guidance identifies the Self-Assessment Questionnaire or Report on Compliance together with an Attestation of Compliance as common validation documents. Some environments also require quarterly external scan reports from an Approved Scanning Vendor.
Confirm the right Self-Assessment Questionnaire before filling it in. The PCI Security Standards Council says merchants must meet all eligibility criteria for the selected questionnaire and should confirm eligibility and reporting instructions with the acquiring bank or payment brand. The Council's SAQ bulletin for PCI DSS v4.0.1 explains this point.
Create a final index that lists every submitted document, its period, owner and approval status. Keep working papers separate from approved submissions. This prevents an old draft or superseded scan from entering the final pack.
Practical answers
PCI DSS evidence checklist questions
Who decides which PCI DSS validation method applies
The acquiring bank or payment brand determines the applicable validation and reporting requirements. A QSA can help assess scope and validate technical information, but the receiving entity sets the submission instructions.
Does outsourcing card processing remove PCI DSS responsibility
No. PCI guidance states that outsourcing payment processing does not remove the organisation's responsibility for PCI DSS. The business still needs to manage provider relationships and confirm how responsibilities are divided.
How often should external vulnerability scans run
Where external scans are required, PCI guidance says they are performed at least once every three months by an Approved Scanning Vendor. Scans are also required after significant changes to the cardholder data environment.
What belongs in a PCI DSS evidence register
Record the requirement, system, evidence description, owner, review period, file location, status and remediation reference. Keep failed checks and re-test results so the file shows how an issue was resolved.
Can Milnsbridge certify PCI DSS compliance
Milnsbridge supports practical technical control work, including gap analysis, remediation planning and implementation. Formal validation and certification decisions sit with the relevant acquiring bank, payment brand and assessor arrangements for the business.
Related services
Explore more
PCI DSS compliance support
Plan and implement the technical controls that support PCI DSS readiness. View PCI DSS support.
Managed FortiGate
Managed firewall configuration and monitoring for business networks. View Managed FortiGate.
Financial services IT support
IT support for Sydney financial advisers and accounting teams. View financial services IT support.
Incident response
Prepare the technical response path before a security incident. View incident response services.
Practical PCI DSS support
Build the evidence file around real control work
A clean evidence register makes gaps visible while there is still time to fix them. It also gives management a usable view of ownership instead of a folder full of disconnected exports.
Milnsbridge supports Sydney businesses with PCI DSS technical controls and ongoing IT support. Our support team has a 20-second average answer time and 87% first-call resolution.
Discuss your PCI DSS evidence planAbout the Author
Adrian Weir
Adrian Weir is the Managing Director and founder of Milnsbridge Managed IT Services, with over 30 years of global IT experience spanning Telstra, Citibank, Unilever, and hundreds of Sydney SMBs. A Microsoft Partner since 2002, Adrian leads a team of IT specialists delivering responsive, business-focused managed IT support across Greater Sydney.
Meet the Milnsbridge Team
