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

2. Third‑Party Compliance Documentation

3. Operational & Policy Evidence

4. Website Security Proof

5. Attestation Support Files

6. Maintenance & Annual Validation Records

🗂️ 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.

This is where many first‑time PCI DSS filers stumble.

Even though SAQ‑A looks simple (just a few pages), it’s still a legal attestation of compliance, and a small mistake can cause delays, compliance holds, or even liability issues.

Here’s a breakdown of the most common SAQ‑A mistakes beginners make — and, more importantly, how to avoid them.

🧩 1. Using the wrong SAQ version

Mistake: Completing SAQ‑A when your setup doesn’t qualify — for example, when your website uses embedded payment fields or JavaScript libraries that interact with card data.

Why it’s a problem:
Your site is actually handling cardholder data indirectly, so you need SAQ‑A‑EP, which has stricter requirements. Filing the wrong SAQ form is considered non‑compliance.

How to avoid it:

• Read the “Eligibility” criteria in the first pages of each SAQ (A vs. A‑EP vs. D).
• Ask your payment gateway which SAQ applies to your integration type.
• If your web server ever sees or modifies card data (even transiently), SAQ‑A is not appropriate.

🔌 2. Not verifying service provider PCI compliance

Mistake: Assuming your payment processor or hosting provider is compliant without proof.

Why it’s a problem:
PCI DSS requires you to verify and document that every service provider with access to cardholder data (including cloud hosting and outsourcing partners) is PCI DSS validated.

How to avoid it:

• Ask for the provider’s Attestation of Compliance (AOC) or check Visa/Mastercard’s list of validated service providers.
• Keep a copy with your SAQ evidence package.
• Re‑verify annually — their certificate has an expiration date.

📁 3. Leaving documentation gaps

Mistake: Submitting only the SAQ form without backing policies or evidence.

Why it’s a problem:
Your acquirer might ask to see proof that you operate securely — patch management logs, access control, website architecture, etc.

How to avoid it:
Prepare a small “PCI evidence folder” including:

• Payment flow diagram showing where card data is handled externally.
• Proof of third‑party compliance (AOCs, contracts).
• Internal security policies (passwords, updates, incident response).
• Screenshots/logs showing no card data stored in your systems.

🧠 4. Marking “N/A” too liberally

Mistake: Using “Not Applicable” to skip requirements that do apply slightly (e.g., password controls for admin portals).

Why it’s a problem:
SAQ‑A only allows “N/A” for controls that are truly out of scope, meaning the entire requirement cannot apply. An acquirer may reject your submission for misuse of N/A.

How to avoid it:

• Only use “N/A” if the PCI DSS form explicitly allows it for SAQ‑A merchants.
• When unsure, answer “Yes” and maintain evidence supporting the control.

🔐 5. Forgetting about your own website security

Mistake: Thinking that outsourcing payments means you can ignore website security altogether.

Why it’s a problem:
Attackers compromise merchant websites to redirect payment pages or inject malicious scripts. Even though you don’t store card data, your site could still be the weak link.

How to avoid it:

• Keep your CMS and plugins patched.
• Use HTTPS everywhere.
• Restrict admin access with strong passwords and MFA.
• Regularly scan for vulnerabilities (many acquirers require quarterly external scans).

🧾 6. Treating SAQ‑A as a one‑time task

Mistake: Filing once and forgetting about it for years.

Why it’s a problem:
PCI DSS compliance is ongoing. You must re‑validate annually and keep controls in place all year.

How to avoid it:

• Establish a recurring “PCI compliance review” every 12 months.
• Monitor for changes in your payment setup — new integrations can change SAQ type.

🧰 7. Misunderstanding “no card data stored”

Mistake: Keeping order data with partial card info (like first six/last four) without verifying that storage is PCI‑compliant.

Why it’s a problem:
Even partial card data is regulated if combined with other sensitive fields.

How to avoid it:

• Ensure your eCommerce platform only stores non‑sensitive tokens or payment references.
• Validate that no logs, backups, or analytics capture card numbers accidentally.

✅ Summary — Avoiding SAQ‑A Pitfalls

By treating the SAQ‑A as a mini‑audit rather than a checkbox exercise, you’ll not only pass compliance smoothly but also strengthen your overall website security posture.