When does PCI DSS SAQ D for merchants apply?
SAQ D for Merchants applies to SAQ-eligible merchants that meet the criteria for no other SAQ type. It is not for service providers, who have their own SAQ D. Typical triggers include an e-commerce site that receives card data on the merchant's own web pages, any electronic storage of cardholder data, and an environment that carries PCI DSS requirements beyond what another SAQ covers. An acquirer or card brand asking for a self-assessment often lands here because the merchant's setup does not fit a narrower questionnaire.
The answer depends on three facts you need to pin down before choosing a form. First, how cardholder data flows, from the customer's browser or terminal through your systems to your processor. Second, whether any electronic storage exists, including storage of encrypted cardholder data. Encrypted data still counts as cardholder data for SAQ eligibility, and every SAQ except SAQ D asks you to attest that no cardholder data is stored electronically, so encrypted storage usually pushes a merchant to SAQ D. Third, which payment brand or acquirer sets your validation requirement, because the SSC does not decide who must validate and the acquirer confirms the questionnaire type.
Your organization owns its controls and the evidence behind every answer. Before you submit, ask your acquirer in writing which SAQ it expects, and record the data flow diagram and storage inventory that justify that choice. An implementation partner can help you prepare systems and documentation, but only the acquirer or payment brand accepts the questionnaire, and a QSA or ISA is needed only where your acquirer or brand requires one for the submission.
Which merchants fall into SAQ D?
SAQ D for Merchants is the fallback for SAQ-eligible merchants whose card acceptance does not fit any narrower questionnaire. The cards below describe the most common triggers, and each one names the facts a merchant should confirm in its own environment before choosing SAQ D.
E-commerce sites that take card data
A merchant that collects the PAN and other cardholder data on its own website, rather than redirecting shoppers to a provider's hosted page or iframe, usually falls outside the narrower e-commerce SAQ. Confirm which payment page script or form receives the card number, whether that page is served from the merchant's own servers, and whether any code path writes the entered data to a database, log or file. If the answer is yes, SAQ D is the likely fit.
Any electronic storage of account data
Storing cardholder data electronically, even in a single database table, a support ticket attachment or a spreadsheet, moves a merchant out of the questionnaires built for merchants that do not store it. Search file shares, backups, email archives, logging platforms and analytics exports for card numbers before deciding. Stray data found during this search can change the answer, so the search should be documented.
Environments beyond another SAQ's scope
Some merchants combine channels, such as a web store plus a point-of-sale system on the same network, or several locations linked by a shared back office. When the environment includes systems or requirements that the narrower SAQ does not cover, SAQ D is the questionnaire that addresses the full set. Map every system that receives, processes or could affect card data and compare that list with the scope each candidate SAQ describes.
Encrypted storage only
Encrypted cardholder data still counts as cardholder data for SAQ eligibility. Every SAQ except SAQ D asks the merchant to attest that it does not store cardholder data electronically, so a merchant that stores only encrypted data cannot attest to that statement and generally moves to SAQ D. Confirm who holds the keys, where they are stored and whether the merchant or a provider can decrypt the data, because those answers shape the requirements that apply.
Requirements marked not applicable
Being on SAQ D does not mean every requirement applies. The SAQ D instructions give examples such as wireless requirements where no wireless technology touches the cardholder data environment, or secure coding requirements where the merchant has no bespoke or custom software. Before marking any requirement not applicable, confirm the condition in writing, such as a network diagram showing no wireless access or a software inventory showing only off-the-shelf products.
Why encrypted storage can still mean SAQ D
Encrypted cardholder data still counts as cardholder data when you decide which self-assessment questionnaire fits. Every SAQ except SAQ D includes an attestation that the merchant does not store cardholder data electronically. A merchant that keeps encrypted card numbers anywhere, even if it holds only ciphertext and no readable account data, cannot truthfully make that attestation, so SAQ D usually becomes the only questionnaire that fits. The encryption still matters for the controls you must meet under SAQ D, but it does not change which questionnaire you complete. Many merchants discover this late, after assuming that encryption alone keeps them on a shorter form, so the storage question should be answered before you pick an SAQ.
The answer depends on facts you must confirm rather than assume. Ask your acquirer which SAQ it expects and whether it has recorded any storage in its own file. Then trace every location where a primary account number could land, including databases, file shares, exported reports, support tickets, email, application logs, error traces, analytics tools and backups. Backups and disaster recovery copies deserve particular attention because they are often created automatically and retained longer than teams expect. Keep in mind that encrypted data in a backup is still stored data for this purpose.
Use your current data-flow diagram as the starting point and mark every store and every path that carries card data into a store. Where the diagram does not show a store, a log or a backup, treat that as a gap to close before you sign the questionnaire. Ask your engineering and hosting teams to confirm the results in writing, and record who checked each location and when. If you find stored data you did not intend to keep, remove it or stop the process that writes it, then document the change. Your Attestation of Compliance depends on that record being accurate, so an incomplete inventory is a risk to plan for, not a detail to tidy up later.
How to answer each requirement in SAQ D
Use In Place when the requirement is met as written by the defined approach, and the evidence you hold shows it. This is the response most merchants use for the majority of requirements. The assessor-style question is simple: can you show that the control operates today, in the systems in scope? In Place does not require an appendix, but it does require that the answer rests on evidence you could produce on request, such as configuration exports, policy documents, scan reports or access review records.
- Test the control, not the policy: A written policy alone does not make a requirement In Place. Confirm the control runs in your cardholder data environment.
- Match the answer to the Expected Testing: The Expected Testing steps describe what must be observed or examined. Your evidence should cover that scope.
- Keep the evidence current: Records from a previous year do not show the control operates now.
- Cover every system in scope: One system outside the control can turn an In Place answer into a false one.
- Retain artifacts for the assessment: Store screenshots, exports and approval records in a location your acquirer or QSA can access.
Before you mark In Place, confirm that each supporting artifact still reflects your current environment, not the environment from last quarter.
Use In Place with CCW when a requirement is not met exactly as written but a compensating control addresses the same risk. The compensating controls worksheet in Appendix B records the constraint, the objective, the risk, the controls you put in place and how you verified them. Compensating controls are rare in practice and are normally needed only where a legacy system or a technical limit makes the defined approach impossible. Because the worksheet is a formal record, it invites scrutiny.
- Document the constraint: Explain the technical or business reason the requirement cannot be met as written.
- Map the objective: The compensating control must meet the intent of the requirement, not only reduce a related risk.
- Show the added protection: Describe how the control reduces risk beyond the baseline and how you verified it.
- Plan for review: Record who approves the control and when it is reviewed, and retire it when the constraint is removed.
- Consider the customized approach: SAQs cannot document a customized approach, so a complex case may need a ROC instead.
Before you select this response, confirm with your acquirer that it accepts compensating controls for the requirement in question.
Use In Place with Remediation for a control that was not in place when you began the self-assessment but was fixed before you completed it. The response records that the gap existed and was closed. It is not a way to defer work. If a control is still being built when you submit, the correct response is Not in Place, with a remediation plan agreed with your acquirer.
- Fix before completing: The control must be operating by the time you complete the questionnaire.
- Record what changed: Keep the date of the fix, the change ticket and the verification result.
- Verify the fix: Test the corrected control against the same Expected Testing steps as any In Place answer.
- Do not use it for planned work: Work scheduled for a later date belongs under Not in Place.
- Reflect it in the summary: Your Attestation of Compliance and any acquirer communication should match the remediation record.
Before you choose this response, confirm with your acquirer how it handles requirements that were remediated during the assessment period.
Use Not Applicable when a requirement does not apply to your environment because of how you operate. The SAQ D instructions give examples such as wireless requirements where no wireless technology is used, stored-data protection where no account data is stored electronically, and secure coding requirements where you have no bespoke or custom software. Not Applicable is a claim you must verify, and an unverified N/A is one of the most common errors in self-assessments. Each N/A answer needs an explanation in the appendix that the questionnaire provides.
- Verify before you mark it: For wireless requirements, confirm that no wireless technology touches the cardholder data environment, through a walkdown or network inventory.
- Check the stored-data claim: If you hold encrypted cardholder data, it still counts as cardholder data, so Requirement 3 may still apply.
- Explain in the appendix: Describe what you checked and why the requirement cannot apply.
- Revisit when things change: A new point-of-sale device, a new payment page or a bespoke script can make an N/A answer false.
- Do not use it to avoid cost: A requirement that applies but is expensive to meet is not Not Applicable.
Before submitting, reconfirm each N/A answer against your current inventory of systems and data flows.
Use Not Tested only when a requirement is excluded from the assessment entirely, typically because your acquirer has asked for only certain Prioritized Approach milestones. It is not a way to skip a requirement that applies to you. Not in Place means a requirement applies and is not met, which must be disclosed with a remediation plan and a target date. The difference matters because an incomplete assessment is not a compliant one, and acquirers treat the two responses differently.
- Not Tested is an acquirer decision: Confirm in writing which requirements the acquirer has excluded before you use this response.
- Explain the exclusion: The appendix must state the reason the requirement is outside this assessment.
- Not in Place needs a plan: Record the gap, the owner, the remediation steps and the target date.
- Affects the attestation: A Not in Place answer generally prevents a compliant Attestation of Compliance until the gap is closed.
- Check the difference: Not Applicable is a verified fact about your environment, while Not Tested is an exclusion set by someone else.
Before you use either response, ask your acquirer to confirm in writing how it will treat each one.
Which requirements can a merchant mark not applicable?
SAQ D lets a merchant mark a requirement Not Applicable only when the environment truly lacks the technology or data that the requirement governs. Each card below covers one common case, the verification to document first, and why an unverified N/A fails the self-assessment.
Wireless requirements
Wireless requirements apply only when wireless technology connects to or could affect the cardholder data environment. Before marking them N/A, confirm in writing that no wireless device, access point or wireless payment terminal touches the CDE, and retain the scan or asset inventory that supports the claim. Walk the premises and check network diagrams, because a forgotten guest access point or a Bluetooth-enabled reader can invalidate the answer. An N/A that the merchant cannot back up fails the self-assessment.
Stored account data protection
Requirement 3.5.1 governs how stored primary account numbers are rendered unreadable. It can be marked N/A only where no account data is stored electronically, which is different from storing it encrypted. Document data discovery results, confirm that logs, backups, spreadsheets and support tickets hold no card numbers, and keep the evidence with the SAQ. If encrypted cardholder data is stored anywhere, this N/A is not available and SAQ D applies.
Secure coding requirements
Requirements 6.2.1 to 6.2.4 cover bespoke and custom software development. They are N/A only where the merchant has no bespoke or custom software, meaning the business runs entirely on off-the-shelf products it does not modify. Verify that no in-house scripts, custom plugins, theme changes or integration code are written or maintained by the merchant or its contractors. Store the application inventory and the contractor confirmation. A site with custom checkout code cannot claim this N/A.
Not applicable versus not tested
Not Applicable means the requirement does not apply to the environment, and it must be justified in an appendix. Not Tested means the requirement was excluded from consideration altogether, such as when an acquirer asks for only certain Prioritized Approach milestones. Mixing the two is a common error. Confirm with your acquirer whether any exclusion is permitted before using Not Tested, and never use it to avoid a requirement that the environment actually triggers.
Documenting each N/A claim
Every N/A answer needs a written explanation in the SAQ appendix that states why the requirement does not apply. Assessors and acquirers look for a specific fact, such as a sworn asset list or a data discovery report dated close to the submission. Vague statements like 'not relevant to our business' do not meet the bar. Review each N/A claim whenever the environment changes, because a new integration or payment channel can make a previously inapplicable requirement apply again.
Why the customized approach cannot be documented in SAQ D
SAQs cannot record customized approach objectives. The self-assessment questionnaire is built around the defined approach, where each requirement is met the way the standard describes. The customized approach lets an entity meet a stated objective in a different way, but the SAQ template has no place to describe that alternative design, the evidence behind it or the risk analysis that supports it. A merchant that completes SAQ D cannot use it to validate a customized control. If an acquirer or payment brand expects validation with the customized approach, the merchant should confirm early whether it needs the ROC template instead, which requires a Qualified Security Assessor to test the objectives and write the findings.
In plain terms, the *defined approach* means the merchant implements the control as written and tests it against the Expected Testing steps. The *customized approach* means the merchant designs a control that achieves the same security objective through a different mechanism, documents the objective, defines how it is monitored, and shows the assessor why it works. The customized approach is available only to entities with robust security and risk management, so a merchant with a thin risk program or a patchy inventory should not plan around it. The PCI SSC's blog on compensating controls versus customized approach explains how the two differ and why compensating controls are a separate route.
Practically, the decision comes before the self-assessment starts. Ask whether any requirement in scope would be met by a customized control, and if so, budget for a ROC and a QSA rather than assuming the SAQ will cover it. Confirm the choice with the acquirer, since the payment brands set validation requirements. Where a merchant intends to rely on a customized control, the objective, the testing evidence and the review cycle should be documented before the assessor arrives. Costs for a QSA-led ROC are set by the assessor's written scope, so ask for the scope and the expected evidence list in writing.
How to complete SAQ D and its Attestation of Compliance
The sequence runs from confirming the SAQ type with your acquirer to signing the Attestation of Compliance yourself. Each step leaves a specific record: a confirmed SAQ type, a data-flow and CDE map, a scope statement, a response for every requirement with its evidence, completed appendices, and a signed AOC. No third party issues the validation.
Confirm the SAQ type with your acquirer
Before you start, confirm with your acquirer or payment brand that SAQ D for Merchants is the correct questionnaire and which version and reporting requirements apply to your business. Ask them whether they expect any Prioritized Approach milestones, since that affects how you mark excluded requirements. The output is a written note from the acquirer, or a dated record of the conversation, that names the SAQ type and any reporting expectations. Keep it with your validation file so the choice can be explained later.
Map cardholder data flows and the CDE
Trace every path that card data takes through your business, from the point of capture to storage, processing, transmission and disposal. Include your website, payment forms, POS or back-office systems, email, paper records, and any third party that touches the data. Identify the cardholder data environment (CDE) and the connected or security-impacting systems around it. The output is a current data-flow diagram and a system list that a reviewer can follow without asking you questions.
Document scope and electronic storage
Using the data-flow map, state which systems are in scope and confirm whether any cardholder data is stored electronically, including encrypted data. Record where storage occurs, what is retained and for how long, and which controls limit it. Note any third party whose service affects your scope and how you confirm its own compliance status. The output is a written scope statement with storage findings. This statement drives which requirements can be marked Not Applicable later, so it must be specific and dated.
Answer each requirement with evidence
Work through every requirement in the SAQ D for Merchants and select one response: In Place, In Place with CCW, In Place with Remediation, Not Applicable, Not Tested or Not in Place. For each response, perform the Expected Testing described in the SAQ, then store the evidence that supports the answer, such as configuration exports, policies, logs or screenshots. For Not Applicable answers, verify the reason against your environment, for example confirming that no wireless technology touches the CDE before marking the wireless requirements N/A. The output is a response and evidence reference for every requirement.
Complete the appendices
Complete the appendices the SAQ requires for your responses. Appendix B documents each compensating control, including its constraints, objective and how it was validated. Appendices that explain Not Applicable or Not Tested answers must state the specific reason in your own words, tied to your scope statement. Where you used remediation, record what was fixed and when it was verified. The output is a set of appendices that a second reviewer can read against the evidence file without contacting you.
Sign the Attestation of Compliance
Complete the Attestation of Compliance (AOC) that accompanies SAQ D and confirm each statement against your evidence. A senior officer of your organization signs it, and that person is accountable for the accuracy of the answers. If an independent party helped you prepare the evidence, that does not change who attests. No third party issues a certificate for SAQ D, and PCI SSC does not accept certificates as validation. The output is a signed AOC, dated and stored with the completed questionnaire.
Submit the questionnaire to your acquirer
Submit the completed SAQ D and signed AOC to your acquirer or payment brand through the channel they specify, and confirm they have received it. Keep a copy of the submission, the acknowledgement, and the evidence file together so that the answers can be reproduced if questioned. Note the date each renewal falls due, based on the reporting schedule your acquirer confirmed in the first step. The output is an acknowledged submission and an archived validation file ready for the next cycle.
What causes SAQ D projects to stall or fail
SAQ D projects rarely fail on the questionnaire itself. They stall on storage nobody mapped, answers nobody verified, and evidence that went stale between scoping and signing. The cards below name the control to check first for each problem.
Unmapped storage in logs and backups
Card data often lands in application logs, debug output, database backups, support ticket attachments and screenshots that no one listed in the data flow diagram. Because SAQ D applies when any electronic storage exists, one forgotten location changes the answer to the eligibility question. Check first: search log pipelines, backup targets, helpdesk tools and shared drives for primary account numbers, and confirm that each location is recorded in the data discovery results and the inventory.
Not Applicable answers without verification
Marking a requirement Not Applicable is only valid when the condition behind it is true and the reason is documented in the appendix. Teams often mark wireless or custom software requirements N/A from memory, then add a wireless access point or a small internal script later. Check first: confirm that no wireless technology touches the cardholder data environment and that no bespoke or custom software exists, then record the verification steps and the date they were performed.
Scope creep from connected systems
A self-assessment covers the cardholder data environment and any connected or security-impacting system, so a new reporting server, identity directory or monitoring agent can enlarge the assessed scope after the questionnaire is drafted. Shared administrative accounts and flat networks make this worse. Check first: review network diagrams and firewall rules for paths from the payment systems to corporate networks, and rerun the scope confirmation after every significant change.
Undocumented compensating controls
An In Place with CCW response needs a completed compensating controls worksheet in Appendix B that explains the constraint, the objective, the risk and the controls that address it. Teams that use a compensating control informally, without the worksheet and its review, cannot show how the control meets the objective. Check first: confirm that every CCW has a written constraint, a risk analysis, testing evidence and a named owner, and that the worksheet is attached before the AOC is signed.
Merchant SAQ used for a service provider duty
A merchant who hosts payment pages or manages systems for other businesses may have service provider duties that a merchant questionnaire does not cover. Using SAQ D for Merchants to answer for a customer's environment, or sending a merchant AOC as proof of service provider compliance, leaves a gap that the customer's assessor will find. Check first: determine whether any part of the business stores, processes or transmits card data on behalf of others, and if so, confirm the correct SAQ with the acquirer before submitting.
Evidence that is stale at signing
The attestation is a statement about the environment on the date it is signed, but many evidence items are gathered months earlier. Firewall rule reviews, vulnerability scan results, access reviews and policy approvals can all fall out of date before signature. Check first: list every piece of evidence with its collection date and confirm that the scan, review and approval cycles were completed within the periods the expected testing describes, and re-collect anything that is older than that.
Who owns the SAQ D work and where a partner fits
The merchant owns the SAQ D work from start to finish. Your organization decides which requirements apply, documents how each one is met, runs the Expected Testing against its own environment, and signs the Attestation of Compliance. No outside party can make those decisions for you or sign on your behalf. Before any work starts, name one accountable person, usually in payments, security or finance, who can answer for every response in the questionnaire, and confirm with your acquirer which SAQ and which validation milestones they expect you to submit.
An implementation partner such as DeployOpen can prepare the systems and evidence the questionnaire asks for. In a written, fixed-scope engagement that might include mapping where card data flows, confirming which systems sit in the cardholder data environment, hardening and documenting configurations, collecting logs and access reviews, and organizing the policies and inventories behind each answer. Those deliverables are owned by your team once handed over. Ask any partner to show, in writing, exactly which artifacts they will produce and which of your staff must review and approve them.
Validation sits outside the partner's role. DeployOpen does not issue reports, attestations or certificates, and nothing it delivers should be presented as a PCI DSS validation. Your acquirer or the relevant payment brand process decides whether your submitted SAQ is accepted. Where a QSA or ISA is engaged for review or validation, that assessor forms its own opinion from its own testing. Confirm early whether your acquirer requires an independent assessor for your situation, and keep any consulting role separate from the assessor's role so the review stays independent.
Questions merchants ask about SAQ D
Can we use SAQ D if we only store encrypted card data?
Yes, SAQ D can apply when the only cardholder data you keep is encrypted. The PCI SSC treats encrypted cardholder data as cardholder data for SAQ eligibility, and every SAQ except SAQ D includes an attestation that the merchant does not store cardholder data electronically. Storing encrypted data therefore removes you from the narrower SAQs. Confirm the exact eligibility reasoning with your acquirer, because they decide which validation type your business must file. Also check whether you truly need to keep the data at all, since a smaller data footprint can reduce the systems in scope.
Can we complete SAQ D ourselves without an outside assessor?
Often yes, if you have staff who understand your network, payment flows and the requirements, because a self-assessment is completed by the merchant. The questionnaire does not require a Qualified Security Assessor, but your acquirer may ask for specific evidence or an independent review, so confirm that first. Outside help is commonly used for technical testing, such as scanning and penetration testing, or for reviewing answers before signing the Attestation of Compliance. Only the merchant signs the AOC, and an outside party's help does not transfer responsibility for the answers.
How much effort does SAQ D take and what drives it?
Effort depends mainly on how many systems fall in scope and how many requirements apply to your environment. The main drivers are the number of systems that touch card data, whether you store any cardholder data electronically, whether you build or customize software, how many third parties handle payment data, and how much evidence your team already keeps. Each requirement requires you to perform the Expected Testing and record evidence, so a documented network diagram and data-flow map usually shorten the work. Ask any provider for a written scope and an estimate of the hours your own staff must contribute, since no supplied figure sets a standard duration.
Who decides which SAQ our business must use?
Your acquirer, or the payment brand programs that apply to you, decides which validation type and SAQ you must file. The PCI SSC sets the standard and the SAQ templates but does not enforce compliance or impose penalties, and the individual payment brands determine who must validate. Ask your acquirer in writing which SAQ, which AOC and which deadline apply to each sales channel. Share your payment flows and any encrypted storage with them up front, because a wrong choice is often discovered only after a breach or during a review.
Can we mark wireless requirements as not applicable?
Yes, but only after you verify that no wireless technology is connected to, or could affect, the cardholder data environment. The SAQ D instructions give wireless requirements as an example of items that may be Not Applicable where no wireless technology is used. Verification means documenting the check, such as a survey of the premises and network inventory, and explaining the conclusion in the appendix. Revisit the answer whenever you add a Wi-Fi access point, a mobile payment device or a wireless terminal, because a change in the environment can make the requirement applicable again.
What is the difference between Not Applicable and Not Tested?
Not Applicable means a requirement does not apply to your environment, and you must verify that with evidence. Not Tested means the requirement was excluded from the assessment entirely, usually because your acquirer has asked for only a subset of requirements, such as certain Prioritized Approach milestones. Both answers must be explained in an appendix. Using Not Tested to avoid a requirement that does apply is a serious error, so confirm with your acquirer before selecting it and never choose it simply to shorten the questionnaire.
Does SAQ D replace a ROC for our business?
No, SAQ D is a self-assessment, while a Report on Compliance is written by a Qualified Security Assessor on the PCI SSC template. Whether you must file a ROC or an SAQ depends on your validation level and what your acquirer or payment brand requires. A SAQ D merchant does not need a ROC unless the acquirer specifically asks for one. SAQs also cannot document use of the customized approach, so if you plan to use that approach, check whether the ROC template is the right path. Certificates are not recognized as validation, so the AOC is the document to keep and submit.
How DeployOpen prepares SAQ D evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems behind your SAQ D answers are built and recorded in a form you can present. We prepare systems, controls and evidence; the self-assessment, its responses and the Attestation of Compliance remain your organization's responsibility.
How we scope
- Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
- We map where cardholder data enters, is stored and leaves your environment, so the SAQ D scope is defined before any build.
- We identify which requirements may be marked Not Applicable and list the verification each one needs.
How we build
- We implement and harden the self-hosted platforms in your cloud accounts, data centers or air-gapped networks.
- We configure controls such as logging, access management and encryption so they produce the records an assessor will ask to see.
- We test controls against the expected testing for each requirement and record gaps for remediation before the self-assessment.
How we hand over
- We deliver configuration records, network and data-flow documentation and control evidence mapped to each SAQ D requirement.
- We document each Not Applicable and Not Tested justification with the verification performed, ready for your reviewers.
- Your team owns the controls, the responses and the signed Attestation of Compliance, and an independent assessor reviews it where required.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can update evidence when systems change, such as a new payment page, a new platform or a change in data flows.
- We confirm with you which acquirer or payment brand requirements apply, since those parties decide validation obligations.
