Having a ready‑to‑use evidence checklist will make your SAQ‑A submission clean and defensible if your acquirer or payment processor asks for supporting materials.
Below is a practical, SAQ‑A‑specific evidence checklist, tailored for merchants who fully outsource payment processing (e.g., redirect or hosted payment page).
✅ SAQ‑A Evidence Checklist
1. Scope & Environment Documentation
| Evidence Type | Description | Example Artifacts |
|---|---|---|
| Payment Flow Diagram | A simple diagram showing where and how payments occur — your site redirects the customer to a PCI‑validated payment gateway, so your environment never sees card data. | PDF or image showing: User browser → Your web app → Redirect → Payment Gateway (PCI DSS provider) |
| System Inventory / Data Flow Summary | A one‑page document listing which servers, databases, and services are in scope and confirming that none store, process, or transmit card data. | Word or PDF summary table |
| Network Diagram (if applicable) | Optional for SAQ‑A, but useful to illustrate that the eCommerce server has no connectivity to cardholder systems. | Network map or Visio diagram |
2. Third‑Party Compliance Documentation
| Evidence Type | Description | Example Artifacts |
|---|---|---|
| Payment Processor’s PCI DSS Attestation of Compliance (AOC) | Proof that your gateway (e.g., Stripe, PayPal, Adyen) is PCI DSS validated. | Provider’s standard AOC PDF or certification letter |
| Hosting Provider’s Security Compliance (if applicable) | If you host your site in the cloud, supply AWS, Google Cloud, or hosting company’s PCI or ISO 27001 evidence. | Provider security whitepaper, SOC 2 or PCI AOC |
| Third‑Party Service Agreements | Show that your contracts require each provider to maintain PCI DSS compliance. | Contract clause or service agreement snippet |
3. Operational & Policy Evidence
| Evidence Type | Description | Example Artifacts |
|---|---|---|
| Information Security Policy | High‑level policy establishing roles, responsibilities, and PCI compliance commitment. | PDF policy signed by management |
| Password & Access Control Policy | Policies enforcing strong passwords, least‑privilege access, and MFA for admin systems. | Short document or admin‑user guide |
| Software Update / Patch Record | Record of how your site or CMS is updated securely. | Change logs, screenshots from update dashboard |
| Incident Response Procedure | A short plan explaining how you’d respond if your site is breached or defaced. | PDF or internal wiki extract |
| Employee Awareness Evidence | Record that staff handling the website know data‑handling practices (no card data). | Training slide, sign‑off list, or email log |
4. Website Security Proof
| Evidence Type | Description | Example Artifacts |
|---|---|---|
| HTTPS / TLS Certificate Evidence | Confirm your site forces HTTPS and has a valid TLS cert. | Screenshot of padlock or certificate details |
| Admin Access Controls | Demonstrate MFA or restricted login. | Screenshot from CMS admin configuration panel |
| Vulnerability Scan Results | Even if you outsource card data, some acquirers require quarterly external scans. | Scan report summary (e.g., “no high vulnerabilities”) |
| File/Config Review Proof | Screenshots or notes showing no cardholder data stored in web configs, logs, or DBs. | Screenshots of empty payment fields in admin backend |
5. Attestation Support Files
| Evidence Type | Description | Example Artifacts |
|---|---|---|
| Completed SAQ‑A Form | Filled out “Self‑Assessment Questionnaire A.” | PDF of the official form |
| Attestation of Compliance (AOC) | The final signature page confirming compliance. | Signed PDF |
| Contact Info Sheet | List of your merchant’s PCI contact persons. | Internal contact form |
6. Maintenance & Annual Validation Records
| Evidence Type | Description | Example Artifacts |
|---|---|---|
| Annual Review Checklist | Record showing you re‑assessed PCI scope annually. | Dated checklist or meeting minutes |
| Provider PCI Renewals | Updated AOCs each year from gateways and hosts. | New PDF certificates |
| Change Management Log | Record of website or system changes that could affect card handling. | Internal change-log excerpt |
🗂️ How to Present It
- Keep all evidence in a single folder (e.g.,
/PCI_2024/SAQ-A_Evidence/). - Organize subfolders:
/Scope/,/3rdParty_AOCs/,/Policies/,/Screenshots/,/Scans/. - Include a README.txt summarizing what each file demonstrates.
- Date all documents and screenshots.
- Submit only the SAQ and Attestation to the acquirer unless they explicitly request supporting evidence — but keep your folder ready.
🧠 Quick Tips
- Only include live, relevant evidence — don’t dump logs or sensitive system data.
- Redact internal IPs or credentials in screenshots.
- Review that nothing contradicts SAQ‑A eligibility (e.g., no internal card data processing).
- Keep all docs digitally signed or on company letterhead for clarity.
This checklist, kept current, will get you through most PCI DSS SAQ‑A validations with minimal back‑and‑forth.
Here’s a ready‑to‑use folder template and example README you can drop into your compliance archive or share with your acquiring bank/processor if they request supporting materials. It’s designed specifically for PCI DSS SAQ‑A merchants (those fully outsourcing card processing).
📁 Folder Structure Template
PCI_DSS_SAQ-A_2024/
│
├── 00_README/
│ └── README_SAQ-A_COMPLIANCE.txt
│
├── 01_Scope_and_Network/
│ ├── Payment_Flow_Diagram.pdf
│ ├── Network_Topology.png
│ └── System_Inventory_Summary.pdf
│
├── 02_Third_Party_Compliance/
│ ├── Payment_Gateway_AOC_2024.pdf
│ ├── Hosting_Provider_Compliance_Certificate.pdf
│ ├── Cloud_Service_Provider_SOC2.pdf
│ └── ThirdParty_Contracts_PCI_Clauses.pdf
│
├── 03_Policies_and_Procedures/
│ ├── Information_Security_Policy.pdf
│ ├── Password_Access_Control_Policy.pdf
│ ├── Patch_Management_Procedure.pdf
│ ├── Incident_Response_Plan.pdf
│ └── Staff_Awareness_Training_Record.pdf
│
├── 04_Website_Security_Evidence/
│ ├── HTTPS_Certificate_Screenshot.png
│ ├── Web_Admin_MFA_Enabled.png
│ ├── External_Scan_Report_Summary.pdf
│ ├── No_Card_Data_Stored_Proof.png
│ └── CMS_Update_Log_2024.pdf
│
├── 05_Attestation_and_SAQ/
│ ├── SAQ-A_Completed_2024.pdf
│ ├── Attestation_of_Compliance_Signed.pdf
│ └── PCI_Contact_Info_Sheet.pdf
│
└── 06_Annual_Review_and_Change_Logs/
├── Annual_PCI_Review_Checklist_2024.pdf
├── Gateway_AOC_Updated_2025_Placeholder.txt
└── Website_Change_Log_2024.xlsx
🧾 Notes on Organization
- Clear folder names: Prefix each with a number so evidence stays in logical order.
- Version/year suffixes: Add the year (
_2024) to help auditing over time. - Readable filenames: Use plain English; avoid internal system paths.
- Sensitive file handling: Redact passwords, keys, or IP addresses in screenshots or logs.
🧰 Sample README File
README_SAQ-A_COMPLIANCE.txt
=====================================================================
PCI DSS SAQ‑A Compliance Evidence Repository
Merchant: [Your Company Name]
Scope Year: 2024
Prepared by: [Your Name, Title]
Date Prepared: [YYYY‑MM‑DD]
=====================================================================
1. PURPOSE
-----------
This folder contains documentation and evidence supporting [Company Name]’s
Self‑Assessment Questionnaire A (SAQ‑A) for PCI DSS compliance.
Our environment does not store, process, or transmit cardholder data;
all payment processing is outsourced to PCI DSS‑validated third parties.
2. STRUCTURE OVERVIEW
----------------------
01_Scope_and_Network/
→ Contains diagrams and scope summaries proving no in‑scope card data.
02_Third_Party_Compliance/
→ Attestations of Compliance (AOCs) and security certifications
from our payment gateway and hosting provider.
03_Policies_and_Procedures/
→ Core security and access control policies, patching, and
incident response procedures.
04_Website_Security_Evidence/
→ Screenshots and scan results demonstrating we maintain a secure
eCommerce site that never handles card data.
05_Attestation_and_SAQ/
→ Completed SAQ‑A form, signed Attestation of Compliance (AOC), and
PCI contact list.
06_Annual_Review_and_Change_Logs/
→ Record of PCI reviews, updated provider attestations, and
system change tracking.
3. CONTACT DETAILS
-------------------
PCI Compliance Lead: [Name, Title, Email, Phone]
Alternate Contact: [Name, Title, Email, Phone]
Acquirer / Processor: [Bank or Payment Processor Name]
4. REVISION HISTORY
--------------------
| Date | Updated By | Summary of Changes |
|-------------|------------|--------------------------------|
| YYYY‑MM‑DD | [Name] | Initial creation of evidence set |
| YYYY‑MM‑DD | [Name] | Updated provider AOC |
| YYYY‑MM‑DD | [Name] | Annual PCI review completed |
=====================================================================
End of README
=====================================================================
✅ Tips for Use
- Keep everything digital (PDF, PNG, DOCX → exported to PDF for integrity).
- Update folder contents annually or any time your integration model changes.
- Use a secure storage location (e.g., restricted cloud drive or encrypted archive).
- When submitting, your acquirer usually wants only the SAQ and Attestation — keep the rest on hand in case of an audit.
This structure mirrors what assessors and acquirers expect when reviewing self‑attested compliance evidence.
Leave a Reply