SAQ A Documentation Checklist — What Your Auditor Wants

Last updated: 29 May 2026

We've sat on both sides of an SAQ A review — the merchant signing the form and the assessor reading what merchants send in. The pattern's pretty consistent. The 22-question form gets filled in quickly, and then everything stalls because the documentation pack behind it is half-built. Auditors don't take the answers at face value; they want to see the evidence. That's where most of the back-and-forth happens, and that's what this checklist is about.

SAQ A documentation isn't one document. It's a small pack of artefacts that together prove your environment matches the answers on the form. If you can produce them on demand — version-controlled, dated, signed off — your QSA or acquirer's review runs short. If you can't, you'll spend three weeks scrambling, which is the worst possible time to be building paperwork from scratch.

This piece walks through what your documentation pack actually needs, where teams trip up, what the v4.0.1 changes added, and a practical evidence checklist you can work through this week. It's written from where we sit as a PCI DSS Level 1 service provider — we've supplied AoCs into hundreds of merchant SAQs, including the ones that helped Pinnacle Group cut their PCI scope by 95%. If you want the wider eligibility context first, our SAQ A guide covers the basics.

What SAQ A documentation actually means#

The phrase "SAQ A documentation" gets used loosely. People mean the 22-question form itself, the Attestation of Compliance that follows it, and the supporting evidence pack — three different things that get conflated. Worth separating them out before anything else.

The 22-question SAQ A form is what you fill in, signed by an authorised executive, certifying that your environment meets the eligibility criteria in v4.0.1. The Attestation of Compliance (AoC) is the formal declaration that gets attached to it — same signature, summary of what's covered, and the questionnaire result. Together those two go to your acquirer.

The evidence pack is what sits behind them. It's the scope diagrams, data-flow drawings, third-party AoCs, scan results, incident-response plan, and policies that make the "yes" answers credible. Your acquirer won't usually ask for the full pack up front — they trust the signed form. But if anything goes wrong later (a card-data exposure, a forensic investigation, a follow-up review), the pack is what shows you were doing the things you said you were doing. And a QSA reviewing your SAQ A position before you file will absolutely want the pack on a screen-share.

The non-negotiable artefacts in your SAQ A pack#

Six artefacts make up the minimum SAQ A documentation pack. Every assessor we've worked with asks for these first, in roughly this order. Build them in this order too — each one informs the next.

First, the scope diagram. Required annually under Requirement 12.5.2. It's a one-page visual of every system that could touch cardholder data, with a clear boundary line showing what's in your cardholder data environment (CDE) and what isn't. Date it. Sign it. Name the person who reviewed it. If you can't produce a scope diagram in an afternoon, you haven't actually done a scope review — you've done a wish list.

Second, data-flow diagrams. One per channel: phone, web, email, post, anything else where a customer can hand over card details. Each diagram traces the card data from the customer's first touch through to the acquirer, with every system and integration point labelled. The diagram is what proves your scope diagram is honest — if there's a flow on the data-flow drawing that crosses an in-scope boundary on the scope diagram, you've got a gap to close.

Third, the service provider AoCs. For every PCI-relevant third party you use — payment gateway, masking provider, telephony, hosting, anything that touches the card flow — you need their current AoC. "Current" means dated within the last twelve months. Get it once a year, file it, cross-reference it with your responsibility matrix. Our piece on what an AoC actually is walks through the specifics of how to read one.

Fourth, the responsibility matrix. This is the document teams skip most often, and it's the one assessors ask for hardest. It lists every PCI DSS requirement and assigns it to either you or each service provider — with the relevant clause of their AoC referenced. Without it, you can't answer the basic question "who is responsible for control X?" without phoning the vendor mid-audit. Build it once, update it when contracts change.

Fifth, the most recent quarterly Approved Scanning Vendor (ASV) scan report. SAQ A merchants whose remaining attack surface includes any externally-facing system (a CRM web tier, a remote-access portal) need quarterly external scans by an ASV. If you genuinely have no external surface — pure phone-only flow with no internet-facing infrastructure — confirm that exemption in writing with your acquirer.

Sixth, the incident response plan with a dated tabletop exercise on the front page. Requirement 12.10. The plan needs named roles, escalation paths, and a record of when it was last tested. "Tested" means a tabletop run with the named roles in the room, scenarios walked all the way through, findings written up. A plan on a shared drive that nobody's ever opened doesn't count.

The five documents we see go missing most often#

Beyond the core six, there's a second tier of documents that QSAs flag as missing on first review. None of them are exotic, but they're the ones that get forgotten because they sit between teams — security, ops, vendor management, finance.

The written confirmation from your service provider that they're responsible for the PCI DSS requirements covering the outsourced functions. This is the document that validates clause two of the SAQ A eligibility test. Your provider's AoC alone isn't enough; you need a signed statement (often a clause in the contract or a separate letter) that says "we accept responsibility for the following PCI DSS requirements on your behalf." Ask your provider for it specifically — they won't volunteer it.

The third-party service provider management procedure. Requirement 12.8 says you need a documented programme for managing PCI-relevant vendors, not just a list of who they are. The procedure covers how you onboard a new provider, how you collect AoCs, how you handle a provider whose AoC has lapsed, and how you respond when a provider notifies you of a security incident. Most teams have these activities running in practice — they just haven't written them down.

The annual scope review attestation. Separate from the scope diagram itself, this is the signed statement that confirms a scope review happened on a specific date, who participated, what changes were identified, and what's been done about them. It's the audit trail that proves Requirement 12.5.2 isn't a once-and-done activity.

The acceptable use and information security policies. SAQ A still asks about these even though most of your environment is outsourced. Your staff still need to know what's expected of them when they handle customer information, what they're not allowed to do, and where the boundaries are. A policy that references "the CDE" without ever defining it is a red flag — write it in plain English with named systems.

The annual penetration test report. Some SAQ A merchants are exempt depending on their architecture, but if you have any external-facing systems at all, your acquirer will expect to see one. The report needs to be by a qualified tester, dated within the last twelve months, with a remediation log showing what's been done about the findings.

What a scope diagram needs to show — and what kills one#

Scope diagrams are where the documentation pack starts, so they're where the most damage gets done. We've seen scope diagrams that show a single box labelled "CRM" and nothing else. We've seen them with no date, no version, no reviewer. We've seen them that show only the happy path and skip the integration to the backup recording archive on a different vendor. Any of those will get bounced.

A diagram that works covers four things. Every system that handles, stores, or transmits cardholder data — labelled with its real product name, not a generic category. Every connection between those systems, with the protocol noted (HTTPS, SFTP, SIP/SRTP). The boundary of the cardholder data environment, drawn as a clear line. And every third party in that boundary, with their AoC reference noted.

The kill list. If your diagram doesn't have a date or version number, it's not evidence — it's a sketch. If it doesn't include the call recording archive (or whatever your equivalent is), it's hiding a system that's almost certainly in scope. If it labels services generically ("telephony", "payment processor") rather than naming them, it can't be cross-referenced against your AoC pack. If a reviewer can't trace a card detail from the customer's phone to the acquirer using the diagram alone, the diagram isn't doing its job.

The simplest sanity check we use: pick one of your sibling controls — for example the SAQ A eligibility criteria or the SAQ A controls — and walk a real transaction through the diagram against that control. If you can't complete the walk-through without referencing something not on the page, the diagram needs another revision.

Data-flow diagrams: one per channel, not one for everything#

The mistake we see most often on data-flow diagrams is teams trying to draw every channel on one canvas and ending up with something nobody can read. Splitting by channel — phone, web checkout, email link, post — makes each diagram readable and makes the differences between channels visible.

A phone-payment data-flow diagram, for example, should show: customer's handset, telephony carrier, the IVR or routing layer, the agent's desktop softphone, the agent's CRM, the masking provider's capture endpoint, the payment gateway, the acquiring bank. Arrows show the direction of card data. Every arrow tagged with what's encrypted in transit (TLS 1.2+, SRTP), what's tokenised, what's plain text. The card data arrows should converge into the masking provider's environment and exit at the gateway — they should never cross the boundary into the merchant's CRM, recording archive, or agent screen.

Where flows differ for fallback paths (out-of-hours, accessibility access, dispute investigations), draw them as separate flows on the same diagram or as their own pages. The fallback paths are where SAQ A eligibility most often breaks — if 95% of calls go through masking but the disability-access fallback puts an agent on the keyboard, the merchant is back in SAQ D for the audit. Make those paths visible, then either fix them or document the compensating control honestly.

The responsibility matrix template that actually works#

Most responsibility matrices we see are spreadsheets with three columns: Requirement, Owner, Notes. That's a reasonable starting point and a terrible final product, because it doesn't carry the evidence chain through to the AoC.

A matrix that holds up under audit has five columns. The PCI DSS requirement number (1.1.1, 1.2.1, etc., spelled out). The brief plain-English description of the requirement. The owner — your team, your service provider, or shared. The control reference — which document, system, or vendor process satisfies the requirement. And the AoC reference — for outsourced requirements, the specific clause or service line in the provider's AoC that covers it.

The matrix should cover every PCI DSS v4.0.1 requirement, including the ones you've outsourced. "Not applicable" needs a written justification, not a blank cell. "Service provider responsibility" needs the AoC reference. Your own responsibilities need a pointer to the policy, procedure, or evidence file that satisfies them. The matrix becomes the navigation map for your entire documentation pack — an assessor can pick any requirement, read across the row, and find every piece of evidence behind it.

If you're at the start of this and need a template, we've supplied them to dozens of customers using our DTMF masking service — it tends to be the document Curtis's team and the customer's compliance lead spend the first onboarding hour on. The matrix template isn't the secret sauce; the discipline of completing it row by row is.

What changed under v4.0.1 for SAQ A documentation#

PCI DSS v4.0.1 became mandatory in March 2025 and is the version every audit and self-assessment in 2026 is judged against. For SAQ A documentation specifically, three changes catch teams out.

First, the scope review under Requirement 12.5.2 is now an explicit annual obligation with documented sign-off, not a soft expectation. The diagram-plus-attestation pair we covered above is the v4.0.1 standard. A scope review buried in a security committee minute from 2024 doesn't satisfy the new wording.

Second, the third-party management requirement under 12.8 got more specific. You need a written agreement with each PCI-relevant provider that explicitly acknowledges their responsibility for the cardholder data they handle. "PCI-compliant vendor" on a marketing page isn't acknowledgement. The contract clause is. If your provider's standard contract doesn't include one, ask for a side-letter — they'll have one ready for SAQ A merchants who push.

Third, the customised approach — the ability to meet a requirement through a non-prescriptive equivalent control — now requires a targeted risk analysis, a defined customised control description, and QSA validation. SAQ A merchants don't usually use the customised approach because they've outsourced the relevant controls anyway. But if your environment includes any element that meets a requirement through a custom mechanism, the documentation burden is heavier than the old "defined approach" route. Our PCI DSS 4.0 phone payments checklist covers the customised approach for phone-payment flows specifically.

Common SAQ A documentation mistakes that get bounced#

From the assessor side, the same handful of mistakes come up in nearly every first-pass review. None of them are catastrophic; they're just the difference between a fast attestation and a three-week negotiation.

The first is stale third-party AoCs. A provider whose AoC expired four months ago doesn't satisfy the eligibility test until they renew it and you've got the new one on file. Build a calendar reminder for every AoC you depend on, set to ping you 60 days before expiry. We send our AoC out automatically to every customer on renewal, but not every provider does — for some you'll need to chase them down.

The second is mismatch between the SAQ form and the scope diagram. The form says "all cardholder data functions are outsourced" and the diagram shows a CRM that displays full PAN on an authorisation screen. You can't have both. The diagram is the truth — fix the underlying environment, not the form answer.

The third is the missing services-covered review on the provider's AoC. "PCI DSS Level 1 service provider" is broad. The provider's AoC will have a "Services Covered" or "Scope of Validation" section that lists exactly which services the attestation applies to. If your provider's AoC covers DTMF masking but not tokenisation, and your flow uses both, you've got an uncovered gap. Read the AoC every year, highlight the services that match your flow, file it with the highlights visible.

The fourth is the incident response plan with no tabletop record. A plan written in 2023 with no test record since is treated as a paper exercise. Run a tabletop every year, take photos of the room with the plan on screen, write up the findings. Cost: an afternoon. Saves: the painful conversation when an assessor asks when it was last tested.

The fifth is the "my CRM only stores the last four digits" position without a documented truncation control. Last-four truncation is allowed under PCI DSS — but you need to show what truncates the PAN before it reaches the CRM, and where the truncation happens. If the CRM displays the masked PAN but the database row stores the full number, you've got storage in scope. Run the data-flow check, find where the full PAN actually lives, fix it if it's anywhere it shouldn't be. Our piece on what "descoped" actually means walks through this kind of edge case in more depth.

Sample documentation pack for a phone-only merchant#

To make this concrete, here's the documentation pack a phone-only insurance broker we worked with last year submitted to their QSA for an SAQ A position review. The flow was straightforward — inbound renewals, agent-assisted, DTMF masking by Paytia. The pack ran to twelve documents, all on a single shared drive, all version-controlled, all dated within the last twelve months.

One scope diagram, single page, last reviewed two months before submission, signed by the IT director. One data-flow diagram for the phone-payment channel, plus a single page covering the email-and-post fallback for customers who couldn't use the phone keypad (the fallback used a payment link, not agent-keyed entry — which kept SAQ A eligible). Three third-party AoCs: Paytia for masking, their payment gateway, and their CRM hosting provider, each highlighted to show the services covered. One responsibility matrix, five-column format, every PCI requirement covered.

Two scan reports: the quarterly ASV scan covering the CRM web tier (the only external surface) and the most recent annual penetration test. One incident response plan with a tabletop test record from three months earlier on the front page. One acceptable use and information security policy, three pages, plain English. One signed letter from Paytia confirming our responsibility for the PCI DSS requirements covering DTMF masking, tokenisation, and gateway transmission. And one annual scope review attestation, signed by the IT director and the compliance lead, dated the day they finished the review.

Twelve documents, no surprises, attestation signed off in three working days. That's what a clean SAQ A documentation pack looks like. The Pinnacle Group team — who we worked with on a 95% scope reduction — followed the same template, just with more documents because they were running a multi-site contact centre rather than a single broker. The principle scales; the document count grows.

Evidence collection rhythm — what to do monthly, quarterly, annually#

The hardest part of SAQ A documentation isn't building the pack the first time. It's keeping it current so the next year's attestation is a refresh rather than a rebuild. The teams that get this right have a documented evidence-collection rhythm.

Monthly. Pull the security event log review attestation from your SIEM. Pull the access-control review showing who has admin access to the systems in scope. Pull the change-management log showing what changed in the CDE that month. Drop each into the evidence folder under the month's date.

Quarterly. Run the ASV scan. File the report. Triage findings, document remediations, close them out within the timeline specified by the requirement. Review the third-party AoC list — anything expiring in the next 90 days needs a chase email to the provider.

Annually. Refresh the scope diagram and data-flow diagrams. Run the scope review with named participants. Sign and date the attestation. Refresh the responsibility matrix against the new AoCs. Run the incident response tabletop. Commission the penetration test. Refresh policies if anything has changed.

That rhythm — monthly, quarterly, annual — is what turns SAQ A documentation from a panic project into a regular operational task. The teams using our masking service typically run this rhythm against a shared compliance drive with calendar reminders. The first year is the build; every year after is maintenance.

How to package the pack for an acquirer or QSA#

How you deliver the documentation matters almost as much as what's in it. Email attachments don't scale, get lost, and don't preserve version history. The packaging that works is a shared drive folder with a clear structure, read-only links sent to the reviewer, and a single "index" document that maps SAQ A questions to the supporting evidence.

Folder structure we recommend. Top level: scope. Subfolder: data-flows. Subfolder: aocs (one document per provider). Subfolder: policies. Subfolder: scans (subfoldered by quarter). Subfolder: incident-response. Subfolder: scope-reviews (one document per annual review). The matrix and the SAQ A form sit at the top level alongside the index. An assessor opening that structure can find anything in three clicks.

The index document is the navigation aid. It lists each SAQ A question number, the answer (yes/no/not applicable), the supporting evidence (the relative file path), and the date the evidence was last refreshed. It's two pages. It saves hours of back-and-forth on the review call.

Where to take this next#

If your next SAQ A is on the horizon, work through the six non-negotiable artefacts first. Build the scope diagram, the data-flow diagrams, collect the AoCs, fill in the responsibility matrix, attach the ASV scan, attach the incident response plan with a recent tabletop. Then pick up the second tier — written confirmations, scope-review attestation, policies, penetration test. Then layer on the monthly-quarterly-annual rhythm so the pack stays current.

If you'd like to walk a real environment through the checklist with someone who's supplied AoCs into hundreds of merchant SAQs, we're a PCI DSS Level 1 service provider with the documentation and templates ready to go. Have a look at our phone payments solution for the architecture, our contact centres practice for similar customer stories, or get in touch and we'll talk through your pack. If you want the wider eligibility view first, the SAQ A pillar guide is the place to start, and our sibling pieces on SAQ A vs SAQ A-EP and SAQ A controls fill in the rest of the cluster.

Frequently asked questions#

What documents do I need for SAQ A?

Six non-negotiables: a scope diagram, data-flow diagrams for every channel, a current AoC for every PCI-relevant service provider, a responsibility matrix, the most recent quarterly ASV scan report, and an incident response plan with a dated tabletop record. Beyond those, you need written confirmation from each provider acknowledging their responsibility, a third-party management procedure, an annual scope review attestation, security policies, and (for most merchants) an annual penetration test report.

How often do I need to refresh SAQ A documentation?

The scope review and scope diagram refresh annually under Requirement 12.5.2. ASV scans run quarterly. Penetration tests run annually. Third-party AoCs are valid for twelve months and need refreshing as each expires — don't wait for an annual sweep, set calendar reminders 60 days ahead of each provider's expiry date. Policies refresh as changes happen, with an annual review even if nothing has changed.

Is the SAQ A form the same as SAQ A documentation?

No. The form is the 22-question questionnaire you sign and submit to your acquirer. The documentation pack is the evidence behind every "yes" answer — scope diagram, data flows, AoCs, matrices, scan reports, policies. The acquirer doesn't usually ask for the full pack up front, but a QSA reviewing your position will, and any follow-up after a security incident definitely will.

What's a responsibility matrix and why does the auditor care?

It's a document that lists every PCI DSS requirement and assigns it to either you or a specific service provider, with a reference to where the evidence sits. The auditor cares because without it, they can't answer the most basic question — "who is responsible for control X?" — without phoning your vendor. The matrix becomes the navigation map for your whole documentation pack.

Do I need a scope diagram if my flow is fully outsourced?

Yes. Even if you're 100% outsourced, you still need a scope diagram showing your own systems, your provider's systems, the boundary between them, and the data flows that cross the boundary. Requirement 12.5.2 doesn't have an exemption for outsourced flows. The diagram is short, but it has to exist.

What goes wrong with third-party AoCs in SAQ A reviews?

Three things, in order. Stale AoCs (expired in the last twelve months and not renewed). Mismatched services covered (the AoC validates one service but your flow uses two). And missing written acknowledgement (the AoC exists but the provider hasn't signed a statement explicitly accepting responsibility for the PCI DSS requirements that cover your flow). All three are common, all three are fixable, all three need chasing the provider rather than waiting.

How do I document a scope review?

The scope review is a meeting (or series of meetings) where named people walk through the cardholder data environment, identify any changes since the last review, and confirm the scope diagram is still accurate. Document it with a written attestation showing the date, the participants, the changes identified, the actions taken, and the signed sign-off. That attestation, plus the refreshed scope diagram, is what evidences Requirement 12.5.2 compliance.

What evidence do auditors actually look at?

In a QSA-led review, all of it. In an acquirer review, usually the form and AoC, with the pack pulled in if anything looks unusual. In a forensic investigation after an incident, the pack is the primary evidence base — your scope diagram, data flows, and access logs become the working documents for the investigation. Build the pack assuming the worst-case reviewer will read it line by line.

Can I file SAQ A without an annual penetration test?

It depends on your remaining attack surface. If you genuinely have no external-facing systems — phone-only, no internet-exposed infrastructure — confirm the exemption with your acquirer in writing. If you have any external surface at all (a CRM web tier, a remote access portal, a marketing site that takes form submissions), the penetration test is part of the expected evidence base. Most SAQ A merchants do commission one, even where the technical requirement is borderline, because the report is useful well beyond the audit.

What happens if my documentation pack is incomplete at audit time?

You don't get a clean attestation. The QSA or acquirer flags the gaps, you build the missing artefacts, you resubmit. That takes weeks at best. At worst, if a critical artefact is missing (a current AoC for an in-scope provider, a scope diagram), you can be moved to a fuller SAQ tier until the gap is closed. The work to build the pack ahead of time is always smaller than the work to fix it under audit pressure.

Next steps#

If your environment looks like the architecture this checklist describes — a phone-payment flow with masking, a small remaining attack surface, a few key service providers — the documentation pack is well within reach. Most teams can build a complete pack in two weeks of focused work, refreshable each year in days rather than weeks. The first build is the steep part; everything after is calendar discipline and a shared drive with the right folder structure.

If you're earlier in the journey — still working out whether SAQ A is even on the table for your business — start with the eligibility test and the controls write-up before you worry about the documentation pack. The sibling pieces on SAQ A eligibility and SAQ A controls in this cluster cover that ground. The pack we've walked through here is what you build once you've confirmed SAQ A applies to you.

Get in touch and we'll talk through your environment and what your pack needs to look like, or book a 15-minute demo and we'll show you the masking architecture that makes the documentation work in the first place. Either route, you'll come away with a clearer picture of what's in your pack today and what's missing.