How to complete a PCI DSS SAQ: testing and AOC steps

How to complete a PCI DSS SAQ, step by step

When an acquirer or payment brand asks for a self-assessment, the entity completes the SAQ itself, performs the Expected Testing for every requirement, records one response per requirement, then signs the Attestation of Compliance (AOC), along with any ASV scans and submissions the acquirer requires. The organization owns both the controls and the signature. The effort depends on which SAQ applies, how many systems fall inside the cardholder data environment, and how much usable evidence already exists. A quality security assurance (QSA) or internal security assessor (ISA) may help prepare the work, but for an SAQ-based assessment neither issues the AOC. Confirm the sequence with the acquirer before starting, since PCI SSC FAQ 1134 sets out the self-assessment steps in order.

Start by confirming the SAQ choice and scope in writing. Ask the acquirer or brand which SAQ it expects, whether a subset of requirements or specific Prioritized Approach milestones applies, and which submissions it wants. Then map the systems, people and processes that store, process or transmit card data, and check each eligibility criterion for the chosen SAQ against that map. Record who performed each test, what they examined, and where the evidence sits. Expected Testing is the core of the work. The testing column in each SAQ is drawn from the PCI DSS testing procedures, so the person answering must actually examine configurations, logs, policies or interviews as the column describes, not simply confirm that a control exists on paper.

Responses need care. Not Applicable must be justified in an appendix and verified, for example by confirming that no wireless technology touches the cardholder data environment before marking the wireless requirements not applicable. Not Tested is reserved for requirements the acquirer has excluded entirely and must also be explained in an appendix. In Place with CCW needs a completed compensating controls worksheet in Appendix B. Where a local or regional law prevents a requirement, mark it Not in Place, complete the legal exception attestation, and report an overall result of Compliant but with legal exception. Contractual obligations and legal advice do not qualify. Before signing, ask your QSA or ISA to record any help in Part 3c or Part 3d as agreed, then have an executive officer sign the AOC.

What are the steps from choosing the SAQ to submitting it?

The sequence runs from confirming which SAQ applies to submitting the completed questionnaire, Attestation of Compliance and any scan reports, with each step producing a record that the next one depends on.

Confirm the applicable SAQ with your acquirer or brand
Start by identifying which SAQ type matches how you accept cards, then confirm that choice with your acquirer or payment brand before you invest effort in testing. The output is a confirmed SAQ type, recorded in writing, because the acquirer or brand may require a different questionnaire or specific milestones. If you accept payments through more than one channel, ask how multiple SAQs should be combined. Done means you hold written confirmation of the SAQ type from the party that receives your validation.
Define scope and confirm eligibility
Map every system, network segment, payment channel and location that stores, processes or transmits cardholder data or could affect that environment. Check each eligibility criterion of the confirmed SAQ against this map, because one unmet criterion usually means a different SAQ applies. The output is a written scope statement with a data-flow view and an eligibility checklist signed off by the person accountable for the payment environment. Done means every in-scope component is listed and every criterion is either met with evidence or the SAQ is changed.
Perform the Expected Testing for each requirement
For each requirement in the SAQ, perform the testing described in its Expected Testing column, whether your team, a QSA or an Internal Security Assessor does the work. Keep the evidence you collect, such as configuration exports, policy documents, scan outputs and access reviews, because it supports each response you record. Where you mark a requirement Not Applicable, verify the exclusion, for example by confirming that no wireless technology touches the cardholder data environment. The output is a dated evidence folder with one response for every requirement. Done means no requirement is left unanswered.
Record a response and appendix for each requirement
Assign each requirement one of the response options the SAQ allows: In Place, In Place with CCW, Not Applicable, Not Tested or Not in Place, and in the v4 SAQ D also In Place with Remediation where a fix was completed before the self-assessment ended. Attach the compensating controls worksheet for any CCW response and write the appendix explanation for every Not Applicable or Not Tested answer. The output is a complete response set with every required appendix. Done means a reviewer can follow each answer back to its evidence without asking the author for context.
Complete the SAQ and Attestation of Compliance
Fill in the SAQ's contact, scope and parts sections, record any QSA or ISA involvement in the designated parts, and check the overall result against the response set. If a legal restriction prevents meeting a requirement, complete the legal exception attestation, bearing in mind that contractual obligations do not qualify. An executive officer of the entity then signs the Attestation of Compliance. The output is a completed SAQ and signed AOC. Done means the officer has reviewed the responses, not only the summary page.
Obtain passing ASV scans where required
If your SAQ type or your acquirer requires external vulnerability scanning, engage an Approved Scanning Vendor to scan your external network and review the results. Remediate findings and rescan until the report is passing, then keep the scan reports with the SAQ evidence. The output is one or more passing ASV scan reports matching the scope you defined. Done means the scan covers the same external addresses listed in your scope statement.
Submit the documents to the acquirer or brand
Send the completed SAQ, the signed AOC, any ASV scan reports and any other documents your acquirer or payment brand requested, through the channel they specify. Keep a copy of the full submission and the confirmation of receipt in your compliance records. The output is a submission record that shows what was sent, to whom and when. Done means the receiving party has acknowledged the package, and you have a retained copy ready for the next assessment cycle.

How does Expected Testing work in each SAQ?

Whoever completes the SAQ must perform the testing in its Expected Testing column before recording a response, whether the merchant, a service provider or a Qualified Security Assessor fills in the form. The column summarizes testing drawn from the PCI DSS testing procedures, so each row describes what an assessor would look at to confirm the requirement is met. The Council's guidance on SAQ testing (see PCI SSC FAQ 1316) makes clear that a response is a statement about tested facts, not a statement of intent. A useful habit is to read the Expected Testing text for each requirement first, then list the systems, people and documents it names before you open any console or file.

Turning each expected test into evidence means matching the verb in the test to an artifact. A test that asks you to examine configurations usually calls for an export of the firewall rule set, a hardening baseline or a screenshot with the date and hostname visible. A test that asks you to observe a process or interview personnel calls for a dated record of who was asked, what they said and what you saw, which is often stored as a short signed memo. Policies, network diagrams and logs support tests that ask you to review documentation or sample activity. Keep a simple evidence index that maps each requirement to the file names, sample dates and owners, because the same record will be needed again at the next annual cycle and when the acquirer asks questions.

Two cautions apply across every SAQ. A response of Not Applicable or Not Tested must be justified by testing too, so verify the claim (for example, by confirming that no wireless technology touches the cardholder data environment) and write down how you checked. Where a QSA or Internal Security Assessor helps, agree in advance who performs each test and who records the result, because Part 3c and Part 3d of the SAQ depend on that split. Confirm with your acquirer or payment brand whether they want the evidence submitted or only retained for their review.

Which response should you record for each requirement?

Every requirement in the SAQ needs one response, and each response carries its own evidence burden and appendix. Choosing the wrong one is a common way for an otherwise sound self-assessment to fail review, so check each option against the facts before you mark it.

In Place

Use In Place when the requirement is met as written, through the defined approach, and you can show it working at the time of the self-assessment. Expected Testing must be performed for that requirement, and the result recorded in the SAQ should match what you observed. The common misuse is marking a control In Place because a policy exists, when the configuration or process it describes has not been checked. Confirm with a sample of systems or records, not the policy alone.

In Place with CCW

Use In Place with CCW only when a compensating control meets the stated objective of a requirement that cannot be met as written, and the compensating controls worksheet in Appendix B is completed for it. The worksheet must document the constraint, the objective, the risk and the controls that address it. The common misuse is treating CCW as a general exception route for controls that are simply inconvenient or late, which the worksheet does not support.

Not Applicable

Use Not Applicable only after you verify that the requirement truly does not apply to your environment, and explain it in the appendix the SAQ provides. For example, confirm that no wireless technology touches the cardholder data environment before marking wireless requirements N/A. The common misuse is marking N/A from an assumption, such as a store with no wireless network that has not checked whether a payment terminal uses Bluetooth or Wi-Fi.

Not Tested

Use Not Tested only when a requirement is excluded from consideration entirely, such as when an acquirer or payment brand asks for only certain Prioritized Approach milestones. The SAQ requires an appendix explaining the exclusion. The common misuse is using Not Tested for requirements that are simply hard to test or that you have not yet reviewed, which is different from an exclusion agreed with the acquirer. Confirm the scope of any exclusion in writing before you record it.

Not in Place

Use Not in Place when a requirement is not met and no compensating control or remediation applies, and the SAQ result will reflect that gap. Recording it honestly is required, and a completed self-assessment with Not in Place responses is not automatically a failed one, but the entity will need to address the gaps before it can attest to full compliance. The common misuse is avoiding this response by marking In Place with optimistic evidence, which tends to surface later during acquirer review.

In Place with Remediation

The SAQ D offers In Place with Remediation for controls fixed before the self-assessment was completed, so the requirement is In Place at completion. Record it only when the fix is finished and verified, with the date and evidence retained. The common misuse is using it for controls still in progress, which should be recorded as Not in Place. Confirm with your acquirer whether this response is accepted for the SAQ type you are completing.

How do the appendices and legal exceptions change the result?

Mark a requirement Not Applicable only when it genuinely does not apply to your environment, and explain why in the appendix the SAQ provides for that purpose. The SAQ D instructions treat this as a claim you must verify, not a convenience. For example, a merchant that confirms no wireless technology touches the cardholder data environment can mark the wireless requirements not applicable, but the verification has to be real and documented. Assessors and acquirers will ask how you confirmed the claim, so the explanation should name the evidence you reviewed.

Verify before marking: Confirm the absence of the technology or process through inventory, configuration review or network checks, not assumption.
Explain in the appendix: Record the reason for each Not Applicable response in the appendix the SAQ provides, specific to your environment.
Avoid blanket use: Marking whole groups of requirements not applicable across a changing environment invites challenge at the next review.
Recheck after change: Re-verify the claim when systems, payment channels or vendors change.
Distinguish from exclusion: Not Applicable means the requirement does not touch your environment, which is different from Not Tested.

Before submitting, confirm with your acquirer whether they accept your Not Applicable reasoning, since they may ask for the supporting evidence.

Who signs the Attestation of Compliance, and when is it final?

An executive officer of the entity signs the Attestation of Compliance (AOC), and the signature is the entity's formal statement that its validation is accurate. Both a Self-Assessment Questionnaire and a Report on Compliance end with an AOC, and a ROC AOC also carries the signature of a duly authorized officer of the QSA company. The AOC is the document the acquirer or payment brand reads, not the questionnaire itself, so the signer should be someone with the authority to commit the organization and the accountability to stand behind the answers. A PCI DSS certificate is not accepted as validation, so a certificate cannot replace the signed AOC when a customer or acquirer asks for proof.

By signing, the officer attests that the answers in the SAQ match the actual environment and that the Expected Testing behind each response was performed and the evidence reviewed. The signature should therefore come last, after every response is recorded, every Not Applicable and Not Tested justification is written and checked, and any compensating controls worksheets are complete. Signing before the evidence review is finished is the most common way an AOC overstates the position. Where a QSA or Internal Security Assessor helped, the signer should confirm that the roles recorded in Part 3c or Part 3d match what actually happened.

Once signed, the AOC is not a final verdict on the organization's compliance. The acquirer or payment brand decides what to do with the submission, including whether it is accepted, what additional documents it requests and whether any follow-up applies. Before signing, confirm with your acquirer the exact signature requirements, whether a particular title or signatory is needed, the submission route and format, and the deadline. Ask also whether a legal exception or a passing ASV scan must accompany the AOC, since those change what the signer is attesting to.

What usually delays or invalidates a self-assessment?

Most delayed or rejected self-assessments trace back to a handful of avoidable errors made before the questionnaire is signed. The cards below cover the choice of SAQ, scope, Not Applicable answers, Expected Testing evidence, compensating controls and ASV scans, with a named owner for each check.

Choosing the wrong SAQ

An SAQ is only valid for the payment channel and data handling it describes, so picking one from the merchant's self-description often fails when the actual flow is different. Confirm the choice with the acquirer or payment brand before any testing starts, and recheck it whenever a new channel, store or storage location is added. The acquirer relationship owner should hold this check, since they receive the submission and decide whether it is accepted.

Scope not confirmed against data flow

Assessors and acquirers compare the questionnaire against how cardholder data actually moves, not against the network diagram someone drew years ago. Trace each payment path from entry to storage and transmission, and check for stray card data in logs, email or spreadsheets. Confirm the result with the payment operations lead and the security owner together, and record who signed off on the scope in writing.

Not Applicable marked without verification

Marking a requirement Not Applicable is a claim that must be proven, and an unverified claim is one of the most common reasons a submission is challenged. For example, a merchant that marks wireless requirements Not Applicable should be able to show that no wireless technology touches the cardholder data environment. Keep the verification record with the SAQ, and have the security lead confirm each N/A entry before signing.

Missing evidence for Expected Testing

Each response must rest on the Expected Testing column, which describes the observations and examinations the assessor would expect. Teams often answer In Place from memory or policy text alone, when the testing requires a configuration export, a sample of logs or a dated review record. Assign each requirement a named evidence owner, and store the artifacts in a folder that maps to the SAQ numbering so they can be produced on request.

Compensating controls without a worksheet

In Place with CCW is only valid when the Compensating Controls Worksheet in Appendix B is completed for that requirement. Teams sometimes describe a workaround in the response box, or treat a planned control as if it already compensates for a gap. Before using CCW, confirm with the security lead and the acquirer that the approach is acceptable, and keep one completed worksheet per affected requirement.

ASV scans not passing when required

Where the SAQ requires passing external vulnerability scans, a scan that fails or covers the wrong IP addresses will hold up the submission even when the questionnaire itself is complete. Confirm with the acquirer whether scans are required for the SAQ type, then schedule them after remediation rather than before. The infrastructure owner should verify that the scanned addresses match the scope, and the scan report should be kept with the AOC.

What do buyers ask before completing a PCI DSS SAQ?

How much effort does a PCI DSS SAQ take and what drives it?

The effort depends mainly on how many systems fall inside the cardholder data environment, how many requirements apply to your payment channel, and how mature your evidence is. A merchant with one standalone terminal has a short questionnaire to work through. A business that stores card data electronically, runs several systems in the payment flow, or keeps evidence scattered across tickets and spreadsheets will spend far more time on each Expected Testing step. Ask yourself three things before starting: is the scope written down and validated, is each in-scope system inventoried, and can you show current evidence for each requirement without rebuilding it. Where those answers are yes, the work is mostly verification. Where they are no, most of the effort goes into finding and documenting facts first.

Can our own team complete a PCI DSS SAQ without outside help?

Often yes, provided someone on the team can perform the testing summarized in the SAQ's Expected Testing column and record a response for each requirement. The PCI SSC expects the entity completing the SAQ to perform that testing, whether the work is done by staff, a service provider or a QSA. The practical limits are knowledge and independence: a team that has never reviewed firewall rules, log settings or access reviews may miss a gap that an acquirer later finds. Confirm with your acquirer or payment brand which SAQ applies before you begin, because an incorrect SAQ choice costs more time than any help you could buy. If your team lacks depth in a requirement area, you can bring in a provider to prepare evidence or test controls, while the attestation remains the organization's responsibility.

Do we need a QSA or an ISA to complete an SAQ?

No. The PCI SSC does not require a Qualified Security Assessor or an Internal Security Assessor to complete an SAQ. A QSA or ISA is useful when you want an independent view of your answers, help interpreting a requirement, or support for a scope or compensating control decision. The PCI SSC sets no specific reporting rules for QSAs who help merchants complete SAQs, so agree the QSA's role in writing before work starts. The QSA's involvement is recorded in Part 3c of the SAQ, and any ISA involvement is recorded in Part 3d. Ask whether your acquirer or brand requires a QSA for your merchant level, because that requirement, not the SAQ itself, decides whether outside assessment is mandatory.

Can we sign the SAQ and AOC with Not Applicable responses?

Yes, but only where the Not Applicable answer is true and you can verify it. The SAQ instructions require you to explain each Not Applicable response in an appendix. For example, before marking the wireless requirements Not Applicable, you must confirm that no wireless technology connects to the cardholder data environment. A Not Applicable answer based on assumption will not hold up if an acquirer or assessor later tests the environment. Do not confuse it with Not Tested, which excludes a requirement from consideration entirely, such as when an acquirer asks for only certain Prioritized Approach milestones. Keep the verification records with your evidence so you can show how each Not Applicable answer was reached.

What should we give an outside helper before they start?

Give the helper a written picture of your payment environment and the evidence that supports it. The most useful package usually includes a confirmed SAQ choice, a current network diagram and data-flow diagram, an inventory of systems and payment components in scope, the list of third parties that touch card data, and recent records for each requirement such as configuration standards, access reviews, log reviews and scan results. Also provide the scope validation you have already done and any compensating controls you plan to use. Agree in writing what the helper will test, what they will record in the SAQ, and who signs off on each response. Missing or contradictory documentation is the most common cause of delays, because the helper must stop and rebuild facts before testing can begin.

What changes when we renew an SAQ for the next assessment cycle?

Renewal is a fresh assessment, not a copy of last year's answers. Start by confirming that the SAQ type still matches how you accept cards, since a new payment channel, a new store, or electronic storage of card data can move you to a different SAQ. Check that the version of the standard you use is current: PCI DSS v4.0 was retired on 31 December 2024, leaving v4.0.1 as the only active version, so an SAQ built on the older version is out of date. Then re-run the Expected Testing for every requirement, because systems, staff and third parties change between cycles. Review any Not Applicable and compensating control entries, since their justifications may no longer be valid. Ask your acquirer whether they want the same documents or new ones this cycle.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, controls and evidence behind their SAQ, while the organization keeps ownership of its answers and the Attestation of Compliance. Work is agreed in a written scope before it starts, and any signed attestation comes from the entity's executive officer, not from DeployOpen.

How we scope

Confirm the applicable SAQ with your acquirer or payment brand before any technical work begins
Map which systems, networks and people fall inside the cardholder data environment for your chosen SAQ
Record which requirements you expect to mark Not Applicable and what verification each one needs
Agree in writing whether a QSA or ISA is involved and what role each party plays

How we build

Prepare the in-scope systems and configurations so each SAQ requirement has a testable state
Implement or harden the open-source platforms your team will run inside your own infrastructure
Set up logging, access controls and scanning so Expected Testing can be repeated and recorded
Document each control's configuration so responses match what the systems actually do

How we hand over

Deliver evidence packs aligned to each SAQ requirement, showing the Expected Testing performed and its results
Provide records for any compensating controls and their Appendix B worksheets, where your SAQ uses them
Hand over the Appendix C or Appendix D explanations for Not Applicable or Not Tested responses, with verification notes
Leave your team with runbooks and an accurate inventory so the next SAQ cycle starts from current evidence

How we support

Review draft responses against the evidence before your executive officer signs the AOC
Available as a retainer for ongoing upgrades, continuous testing and re-validation after system changes
Security testing of applications, infrastructure and APIs can be scoped separately to inform your answers
Confirm with your acquirer or the assessor which submission documents they expect and when they need them

How to complete a PCI DSS SAQ: responses, expected testing and the AOC