The complete PCI DSS SAQ walkthrough: a step-by-step guide

By Sam Rivera, Founder, SentinelPanda · June 3, 2026 · 11 min read · PCI DSS

Most SAQ guides stop at "pick the right type." This one walks the entire cycle end-to-end — what to gather before you start, how to read each requirement, what evidence actually satisfies it, and what happens after you submit.

Phase 0 — before you start

A clean SAQ takes 4–12 weeks of focused work the first time and 2–4 weeks for each annual revalidation. Most of that time is collecting evidence and getting answers from people, not filling in the form itself. The cheapest way to compress that schedule is to do the prerequisite work properly before you open the SAQ workbook.

Pre-flight checklist: a current network diagram covering everything that stores, processes, or transmits cardholder data; an up-to-date asset inventory; a list of all third parties handling cardholder data with their PCI DSS validation status; a copy of last year's SAQ (if any) and the AOC you signed; a clean folder structure for evidence (one per requirement). Without these, every requirement will turn into a fishing expedition.

Phase 1 — confirm you can use an SAQ at all

The Self-Assessment Questionnaire is the validation route for merchants and most service providers below the Level 1 threshold. Level 1 merchants and most Level 1 service providers require a Qualified Security Assessor (QSA) and a Report on Compliance (ROC). The thresholds vary by card brand, but broadly: Visa Level 1 merchant = more than 6 million Visa transactions a year; Level 1 service provider = stores, processes, or transmits more than 300,000 transactions a year.

You must use a QSA if any card brand has notified you that you need one (typically after a suspected breach), or if your acquirer has required QSA-led validation. If none of that applies and your transaction volumes are below the Level 1 thresholds, you can self-assess via SAQ.

Plenty of self-assessors still want a QSA's eyes on the work — for advisory, for a customer who asked for QSA-issued evidence even though SAQ would suffice, or to de-risk a borderline scope decision. In SentinelPanda the QSA joins your workspace as an auditor-layer seat: read access to the evidence, approval rights on the workflow, every action on the HMAC-signed audit log. You don't re-key anything into their toolchain; they don't see anything outside the engagement.

Phase 2 — identify your level and route

For each card brand you accept, look up your validation route. Visa, Mastercard, Discover, and JCB publish level tables; Amex has its own. The level is determined per brand by transaction volume (Mastercard counts MasterCard + Maestro transactions; Visa counts Visa + Visa Electron + Vpay; etc.). You can be Level 2 with one brand and Level 4 with another.

Document the level per brand in writing. The Attestation of Compliance asks for it, and your acquirer's portal will fail validation if the level is wrong or missing.

Phase 3 — pick the right SAQ type

There are nine SAQ types for merchants and service providers. Picking the wrong one is the most common expensive mistake — either you over-report (waste) or under-scope (audit failure, potentially fines).

The high-level decision tree: do you accept cards online? If yes, is it fully outsourced (SAQ A) or partially handled by your site (SAQ A-EP)? Do you take card-not-present transactions by keying into a virtual terminal on an isolated computer (SAQ C-VT) or via a payment application connected to the internet (SAQ C)? Do you only use a standalone PTS-listed terminal — dial-out (SAQ B) or IP-connected (SAQ B-IP)? Are you using a PCI-validated point-to-point encryption solution (SAQ P2PE)? If none of the above fits — or if you store cardholder data on your own systems — you need SAQ D-Merchant (or SAQ D-Service Provider for service providers).

Read the eligibility criteria at the front of each SAQ before committing. Many merchants discover that what looked like SAQ A actually requires SAQ A-EP because their site iframes or proxies the payment page; many "we don't store cardholder data" service providers discover that handling it in memory counts.

Phase 4 — scope the cardholder data environment

The cardholder data environment (CDE) is every system that stores, processes, or transmits cardholder data, plus every system connected to or impacting the security of those systems. The latter clause is what most teams miss: a jump server that has no card data on it but provides administrative access to a payment system is in scope; a monitoring tool that ingests logs from CDE systems is in scope.

Walk your network diagram and tag each system: in CDE, connected-to (provides services to CDE), out-of-scope (no card data, no connection, segmented). The boundary between connected-to and out-of-scope is where segmentation lives. If you claim segmentation, you must demonstrate it with technical controls — VLANs, firewall rules, separate authentication realms — and re-test it annually (Req 11.4.5).

Produce a Scope Statement: a versioned document that lists every system in scope, every segmentation boundary, every data flow, and the reasoning for each in/out decision. Req 12.5.2 makes this an explicit annual requirement. Without a Scope Statement an assessor cannot evaluate your assertions, and acquirer reviews will ask for it during incidents.

Phase 5 — read the SAQ before filling in answers

Skim the entire SAQ before you start completing it. The structure is consistent — each requirement has a question (or several), and you answer Yes / Yes with CCW (Compensating Control Worksheet) / No / N/A / Not Tested. The SAQ also embeds the relevant defined approach test procedures so you can see what an assessor would test.

Pay attention to the front matter. Each SAQ states its eligibility criteria — confirm you meet them. Many SAQ types have a short list of additional requirements that are typically out of scope but become in scope under specific conditions; read those carefully.

Phase 6 — walk each requirement and gather evidence

For each question, the workflow is the same: read the question and the test procedure; identify the system or process the question is about; collect evidence that you do what it asks; record the evidence reference; answer the question.

Evidence types that satisfy most requirements: configuration export (firewall rules, IAM policy, server config), screenshot (only for things that aren't exportable), policy document with version and approval, ticket showing a process ran (e.g. quarterly review completed on date X by person Y), penetration test report, vulnerability scan attestation, training completion records, signed agreements with third parties.

Anchor each evidence item to the requirement it satisfies and date-stamp it. Evidence from 18 months ago does not satisfy an annual control. Evidence with no date does not satisfy anything. SentinelPanda tracks the requirement-to-evidence link and the evidence age; if you are using spreadsheets, build that tracking yourself.

Phase 7 — Compensating Controls and the Customized Approach

Some controls cannot be met as the defined approach states (legacy system, technical constraint, business reason). You have two paths. The Compensating Control Worksheet (CCW) is for one-off cases where you cannot fully meet a requirement but can demonstrate equivalent risk reduction through alternative controls. CCWs need: the constraint, the objective, the risk analysis, the validation, the maintenance.

The Customized Approach (introduced in PCI DSS 4.0) is broader — you meet the Customized Approach Objective of a requirement using controls of your choosing, with the assessor agreeing. The Customized Approach requires a documented Targeted Risk Analysis and a controls matrix, and is meaningful work; reserve it for the small number of requirements where a modern control genuinely fits better than the prescriptive text.

Phase 8 — Targeted Risk Analyses (Req 12.3.1)

PCI DSS 4.0.1 lets you set your own frequency for many activities (anti-malware reviews, log monitoring frequency, training, and others). Each entity-defined frequency requires a documented Targeted Risk Analysis: the asset, the threat, the likelihood, the impact, the justification for the frequency you chose.

List every requirement that uses an entity-defined frequency and produce one TRA per requirement. The TRA must be reviewed at least annually and when something material changes. They are short — typically one page each — but they must be written. "We do X every Y because we have always done it that way" is not a TRA.

Phase 9 — quarterly ASV scans

Almost all SAQs (the exceptions are SAQ A and SAQ P2PE) require quarterly Approved Scanning Vendor (ASV) external vulnerability scans. The requirement is four passing attestations a year — not four scans. If a scan finds something that prevents it from passing (CVSS 4.0+ or vendor-marked critical), you fix it and rescan within the quarter to get a passing attestation.

Schedule the four scans evenly across the year so you have time to remediate. Track scan dates, scan results, remediation tickets, and the passing attestation per quarter as separate items. At SAQ time the four passing attestations become supporting evidence — gather them across the year, not at signing.

Phase 10 — the Attestation of Compliance

The AOC is the signed document that says you completed the SAQ and are compliant. It is what your acquirer requires, not the full SAQ workbook (though they may ask for the workbook during an incident). The AOC includes your legal name, address, levels per card brand, the SAQ type completed, the assessment date, the signatures, and any in-progress remediations.

Sign the right thing. The AOC must be signed by an executive officer (typically CISO, CIO, or COO) who can attest to the validity of the assessment. If you signed a CCW or used the Customized Approach, the AOC has additional sections to complete. Re-read the AOC before signing; it is a legal attestation.

Phase 11 — submit and store

Submit the AOC to your acquirer through their portal. They will confirm receipt; keep that confirmation. Store the signed AOC and the underlying SAQ workbook plus all evidence in a location your team can find for the full annual cycle.

Customer-facing service providers: store a copy that your customers can request, and a redacted version safe for distribution. Bridge letters for the period between cycles are normal; have a template ready (see the SOC 2 bridge letter pattern — same concept).

Phase 12 — between revalidations

The SAQ is annual but compliance is continuous. Keep the evidence folder current: when a control changes (new firewall rule, new training cohort, updated policy), update the evidence. Track scope changes — new systems, new third parties, new payment flows — and re-classify them as they appear, rather than discovering them at next year's SAQ.

Run the controls that have an annual cadence on schedule (penetration testing, segmentation testing, policy review, training, incident-response testing) and capture the evidence as they happen. Next year's SAQ is the same workflow with a 90% smaller delta if you keep the record current.

Common mistakes — expanded

• Filling in answers before reading the SAQ's eligibility criteria — and discovering at AOC time you used the wrong SAQ.
• Treating "we use a PCI-compliant payment processor" as a complete SAQ A answer — without a Scope Statement that proves you don't touch cardholder data anywhere else.
• Letting connected-to systems get classified as out-of-scope because no card data lives on them — forgetting that "impacts the security of" includes admin access and monitoring.
• Forgetting Targeted Risk Analyses for entity-defined frequencies. Every "at a frequency defined in the entity's targeted risk analysis" wording in 4.0.1 owes you a TRA.
• Doing four ASV scans but having only three passing attestations because remediation slipped — the requirement is four passing, not four attempted.
• Signing the AOC at executive level without the executive having read it. The executive is the legal attestor; brief them.
• Storing evidence in screenshots only. Configuration exports and ticket records age better and survive assessor scrutiny.
• Treating SAQ as a one-week scramble at renewal. Twelve months of small updates beats one month of frantic gathering.

A realistic timeline

• Weeks 1–2: Pre-flight (Phase 0). Diagrams, asset inventory, third-party list, evidence folder structure.
• Week 3: Level confirmation and SAQ type selection (Phases 1–3).
• Weeks 4–5: Scope Statement (Phase 4). The most consequential single document.
• Weeks 6–9: Requirement walk and evidence gathering (Phase 6). This is the long stretch.
• Week 10: CCWs / Customized Approach / Targeted Risk Analyses (Phases 7–8).
• Week 11: ASV scan reconciliation and AOC drafting (Phases 9–10).
• Week 12: Executive review, signature, submission (Phases 10–11).
• Continuous: Phase 12 — keep the record current between revalidations.