Completing a PCI DSS Self-Assessment Questionnaire, step by step
By Sam Rivera, Founder, SentinelPanda · January 16, 2026 · 4 min read · PCI DSS
The SAQ is short next to a full Report on Compliance, but it is still an annual evidentiary document with real legal weight. Treating it like a form-filling exercise is how programs end up missing things.
1. Confirm you can use an SAQ at all
PCI DSS validation comes in two shapes: a Self-Assessment Questionnaire (SAQ) that you complete and attest to yourself, and a Report on Compliance (ROC) issued by a Qualified Security Assessor. Which one you owe depends on your transaction volume and on how the card brands and your acquirer have classified you. Level 1 merchants and most Level 1 service providers do not have the SAQ option; everyone else typically does.
Confirm the validation path with your acquirer before you spend a quarter completing the SAQ. Getting halfway through and discovering the acquirer expects a ROC is a common, expensive surprise.
2. Pick the right SAQ type
There are nine SAQ types — A, A-EP, B, B-IP, C, C-VT, P2PE, D-Merchant, and D-Service Provider — and choosing the right one is the most consequential decision in the whole process. The applicability is driven by how you handle card data, not by what you would like the answer to be.
SAQ A is the shortest (fully outsourced e-commerce, no card data touches your systems). SAQ D is the longest (all PCI requirements; a catch-all for anything that does not fit a shorter SAQ). The middle SAQs (A-EP, B, B-IP, C, C-VT, P2PE) cover narrow specific scenarios — picking one when you do not actually qualify produces an attestation that will not survive any subsequent review.
3. Define and document your cardholder data environment
Every SAQ question is answered against a defined cardholder data environment (CDE). Before you answer anything, draw the boundary: which systems store, process, or transmit cardholder data, which systems are connected to those, and what is segmented out. Capture the result as a Scope Statement under change control. Requirement 12.5.2 expects this to be reviewed at least annually and after significant change.
A scope statement that drifts from reality is the single most common reason an SAQ falls apart during an acquirer review or a follow-up forensic investigation.
4. Walk the SAQ requirements and gather evidence
Take each in-scope requirement and answer it with evidence that would still hold up if a forensic investigator asked the same question after a breach. "In place" is not a checkbox; it is a claim that you can substantiate with logs, screenshots, policy excerpts, scan reports, or system configuration exports.
Where a requirement is "not applicable" because of how you have scoped the environment, document the justification clearly. Where a requirement is met by a third party (your payment processor, your hosting provider), keep a copy of their AOC and document the boundary of their responsibility.
5. Quarterly ASV scans (where required)
Most SAQ types that touch internet-facing infrastructure require quarterly external vulnerability scans by an Approved Scanning Vendor. The ASV scan produces a "Compliant" or "Non-Compliant" attestation; you owe four passing attestations over the year alongside the SAQ.
A failed ASV scan is fixable: remediate the high-severity findings, request a rescan within the same quarter, and use the latest passing scan as the quarterly evidence. Plan the first scan early in the quarter so you have remediation runway.
6. Complete the Attestation of Compliance
The AOC is the legal cover sheet for the SAQ — a signed statement from a named executive confirming that the assessment is accurate and that the listed requirements are met. The AOC, not the SAQ workbook, is what your acquirer files. Sign it after every other step is complete, not at the start.
For service providers, the AOC is also a customer-facing artifact: your customers will ask for it as part of their own SAQ evidence. Keep a current, redacted version available for distribution under NDA.
7. Submit and schedule revalidation
Send the AOC (and, where requested, the SAQ workbook) to your acquirer through whatever portal or contact they specify. Most acquirers expect annual submission on the anniversary of the previous attestation; some expect calendar-year alignment. Confirm the cadence.
Put the next revalidation date on the calendar with a 90-day lead time. SAQs that look easy in year one routinely slip in year two because the scope changed, the team changed, or the acquirer started asking different questions.
Common mistakes
- Choosing SAQ A when the payment page is iframed or direct-post (you actually need A-EP).
- Treating "not applicable" as "no answer needed" — every NA must have a written justification.
- No documented scope statement, or a scope statement that pre-dates the last major architecture change.
- Missing ASV scans for a quarter (or two), then trying to catch up at year-end.
- AOC signed by someone without the authority the standard requires.