The PCI DSS Self-Assessment Questionnaire (SAQ) is a required validation tool used by merchants and service providers to self-evaluate and attest to their PCI compliance with the Payment Card Industry Data Security Standard (PCI DSS). It allows eligible small-to-medium-sized entities to demonstrate a secure payment environment without undergoing a full external audit.

While the self assessment questionnaire simplifies validation, it does not reduce compliance obligations. All applicable PCI DSS requirements must still be met, and the organization remains fully accountable for accuracy and completeness.

Preparing for a PCI DSS SAQ Assessment

Completing an SAQ successfully depends heavily on preparation. Organizations that begin filling out an SAQ without first understanding their environment often encounter scope errors, incomplete evidence, or incorrect SAQ selection.

Before selecting an SAQ or validating controls, organizations should take the following preparatory steps.

1. Define Scope and the Cardholder Data Environment (CDE)

Preparation begins with clearly identifying the Cardholder Data Environment (CDE). This includes all systems, people, and processes that store, process, or transmit cardholder data, as well as any systems that can impact its security.

This PCI DSS assessment should account for:

• Payment systems and applications
• Supporting infrastructure (networks, firewalls, authentication systems)
• Personnel with access to payment systems or cardholder data

2. Map Cardholder Data Flows

Organizations should document how cardholder data enters, moves through, and exits their environment. Data-flow diagrams are not only a PCI DSS requirement, but also a practical tool for identifying in-scope systems and confirming whether scope-reduction techniques are effective.

Clear data-flow mapping supports:

• Correct SAQ selection
• Identification of unnecessary exposure point
• Validation of segmentation, encryption, and outsourcing models

3. Evaluate Scope Reduction Opportunities

PCI DSS allows organizations to reduce scope through architectural and technical controls. Common scope-reduction techniques include:

• Network segmentation
• Tokenization
• End-to-end encryption
• Validated Point-to-Point Encryption (P2PE) solutions

When implemented correctly, these controls can significantly reduce the number of systems subject to SAQ requirements and simplify ongoing PCI compliance.

Applicability by Merchant Level

Although all entities handling payment card data must remain PCI DSS compliant, the validation path is determined by merchant level. Level 1 merchants are always required to complete an external audit resulting in a Report on Compliance (RoC).

Merchant Level	Transaction Volume (Per Year)	Validation Requirement
Level 1	Over 6 million	External Audit (RoC) by a QSA
Level 2	1 million to 6 million	Eligible for SAQ (unless brand-mandated RoC)
Level 3	Under 1 million	Eligible for SAQ
Level 4	Under 1 million	Eligible for SAQ

SAQ Types Overview

There are nine SAQ types, each designed for a specific payment channel or technical architecture.

SAQ Type	Best For	Description
SAQ A	E-commerce / Mail Order	Merchants who outsource all cardholder data functions to PCI-compliant third parties. The merchant does not directly access card data; the website redirects customers or embeds a processor-hosted form (e.g., iFrame).
SAQ A-EP	E-commerce	Merchants who outsource processing but operate a website that influences transaction security. If the payment page is hosted by the merchant site, SAQ A-EP typically applies.
SAQ B	Face-to-Face (Dial-out)	Standalone, dial-out terminals with no internet connectivity. No electronic storage is permitted.
SAQ B-IP	Face-to-Face (IP Terminals)	Standalone, IP-connected, PTS-approved terminals isolated from other systems. No electronic data storage allowed.
SAQ C-VT	Virtual Terminals	Manual, one-at-a-time transaction entry into a web-based virtual terminal. Keyboard entry only.
SAQ C	Payment Applications	Internet-connected payment applications that do not store electronic cardholder data.
SAQ P2PE	Hardware Terminals	Merchants using PCI-listed Point-to-Point Encryption (P2PE) solutions significantly reduce assessment scope.
SAQ SPoC	Mobile Solutions	Merchants using commercial off-the-shelf devices with secure card readers as part of a PCI-listed SPoC solution.
SAQ D	All Others	The full PCI DSS requirements for merchants or service providers that do not meet other SAQ eligibility criteria.

E-Commerce Environments: SAQ A vs. SAQ A-EP

SAQ A: Complete Outsourcing

SAQ A applies to card-not-present merchants who have fully outsourced all cardholder data functions to PCI DSS–validated third parties.

Eligibility criteria

• The merchant does not store, process, or transmit cardholder data
• Not applicable to face-to-face environments

Implementation examples

• URL redirection to a third-party processor
• Processor-hosted payment forms embedded via iFrame

SAQ A-EP: Partial Outsourcing

SAQ A-EP addresses e-commerce environments where the merchant website can affect transaction security, even if cardholder data is sent directly to the processor.

Eligibility criteria

• E-commerce only
• The merchant website controls the delivery of the payment page

Implementation examples

• Direct post payment forms
• Merchant-hosted JavaScript supporting payment functions

Comparison

Feature	SAQ A	SAQ A-EP
Functions outsourced	All processing and management	Processing outsourced; page delivery retained
Payment page origin	Third party only	Merchant or third party
Merchant system role	No influence on security	Influences transaction security
Typical requirement count	Low	High
Security focus	Third-party compliance	Web server and application security

Face-to-Face and Brick-and-Mortar: SAQ B, B-IP, and P2PE

SAQ B: Legacy and Isolated Systems

For imprint machines or standalone, dial-out terminals with no internet connectivity. Not applicable to e-commerce. Electronic storage is prohibited.

SAQ B-IP: IP-Connected Terminals

For standalone, IP-connected, PTS-approved payment terminals.

Key distinctions:

1. Devices must be network-segmented
2. Transmission is limited to device-to-processor traffic
3. Secure Card Readers (SCRs) are excluded

SAQ P2PE-HW: Validated Encryption

Uses PCI-listed P2PE hardware solutions, encrypting data at the point of interaction and providing the greatest scope reduction.

Feature	SAQ B	SAQ B-IP	SAQ P2PE-HW
Connection type	Dial-out	IP-based	Validated P2PE
PTS approval required	No	Yes	Yes
Data transmission	None	Device to processor	Encrypted end-to-end

Virtual Terminals and Connected Systems: SAQ C-VT and SAQ C

SAQ C-VT applies to non-e-commerce merchants manually entering transactions via keyboard into third-party virtual terminals.

SAQ C applies to internet-connected payment applications that do not store cardholder data, commonly used in networked POS environments.

Service Providers and Universal Compliance: SAQ D

SAQ D is the required SAQ for:

• Merchants that do not meet other SAQ eligibility criteria
• All service providers

Service provider documentation requirements

• Detailed descriptions of the reviewed environment
• Narrative explanations of testing evidence for every requirement

Commonly Tested Security Domains

Network Security Controls (Requirement 1)

Key activities include maintaining policies, network and data-flow diagrams, approved services and ports, and clearly defined roles.

System Configuration (Requirement 2)

Systems must be securely hardened and vendor-default credentials removed before deployment.

Vulnerability Management

External scans must be performed by an Approved Scanning Vendor (ASV). Ongoing compliance requires four passing quarterly scans within a 12-month period.

Validation Methodology and Response Reporting

PCI DSS v4.0 defines six response options:

Response	Definition
In Place	Requirement met and fully tested
In Place with CCW	Met using compensating controls
In Place with Remediation	Corrected before assessment completion
Not Applicable	The requirement does not apply
Not Tested	Requirement excluded (partial assessment)
Not in Place	Requirement not met

SAQs cannot be used to document the Customized Approach, which requires a full RoC and Targeted Risk Analysis.

Submission and Maintenance Procedures

Completion process

1. Confirm scope and CDE boundaries
2. Perform expected testing
3. Complete all SAQ sections
4. Sign the Attestation of Compliance
5. Submit documentation to the acquirer or payment brand

Scope management tips

• Maintain accurate data-flow maps
• Use encryption and tokenization strategically
• Collect AOCs from service provider
• Monitor for scope creep as environments change

Automation and Ongoing SAQ Readiness

PCI DSS SAQ Automation plays an increasingly important role in maintaining ongoing readiness and reducing operational risk.

Automated Evidence Collection and Control Monitoring

Many SAQ requirements rely on verifiable evidence, such as system configurations, access controls, patch status, and security monitoring activities. Automated GRC and compliance platforms can continuously collect, organize, and retain this evidence, reducing reliance on manual screenshots and ad hoc documentation.

Platforms such as Centraleyes support this process by centralizing control evidence across environments, mapping technical and procedural controls to PCI DSS requirements, and maintaining a continuous view of compliance status. This allows teams to validate that controls remain in place throughout the year, rather than recreating evidence during each assessment cycle.

Automated evidence collection supports:

• Faster and more accurate SAQ completion
• Improved consistency in testing results
• Reduced risk of missing or outdated documentation

Logging, Monitoring, and Requirement 10

PCI DSS Requirement 10 mandates comprehensive logging and monitoring across in-scope systems. Meeting this requirement manually is challenging, particularly in environments with multiple systems, cloud services, or third-party integrations.

Security monitoring tools, such as SIEM platforms, automate log collection, retention, and analysis. When integrated into a compliance workflow, these tools support both operational security monitoring and SAQ evidence requirements.

Centraleyes integrates with logging and security tooling to align monitoring outputs with PCI DSS control expectations. This helps organizations demonstrate not only that logs are collected, but that monitoring is active, reviewed, and documented in a way that supports SAQ validation.

Vulnerability Management and Continuous Assessment

For SAQs that require vulnerability scanning, automation enables organizations to schedule scans, track remediation efforts, and retain historical scan results. This is particularly important for demonstrating ongoing compliance across quarterly scan cycles.

Automated vulnerability management reduces the risk of missed scans, incomplete remediation tracking, or inconsistent reporting during Attestation of Compliance (AOC) submissions.

Centraleyes+ and Supported SAQ Readiness

For organizations that require additional guidance or external validation support, Centraleyes+ extends platform-based automation with expert services. Centraleyes+ connects organizations with qualified assessors and compliance professionals who support SAQ preparation, evidence review, and readiness validation.

This model allows organizations to combine automated compliance workflows with professional oversight, helping ensure that SAQs are completed accurately, eligibility criteria are met, and documentation aligns with acquirer expectations.

Automation does not replace assessment responsibility or accountability. However, when combined with structured workflows and expert support, it significantly improves consistency, audit readiness, and long-term compliance sustainability.

FAQs

Can I use the PCI DSS v4.0 “Customized Approach” in an SAQ?

No. While PCI DSS v4.0 introduced the Customized Approach to allow organizations to design alternative controls that meet defined security objectives, this approach is not supported in Self Assessment Questionnaires.

SAQs are limited to the Defined Approach, which requires implementation and testing of the specific controls and procedures outlined in the standard. Organizations that wish to use the Customized Approach must generally complete a full Report on Compliance (RoC), supported by a Targeted Risk Analysis, rather than an SAQ.

What does “In Place with Remediation” mean in an SAQ?

“In Place with Remediation” is a new response option introduced in PCI DSS v4.0. It is used when a requirement was not met during initial testing, but the issue was fully corrected before the assessment was completed.

To select this response, the organization must be able to demonstrate that it:

1. Identified the root cause of the control failure
2. Implemented the required control
3. Established processes to prevent recurrence

This response requires documentation in Appendix C of the SAQ to explain the remediation actions taken.

Do I need to perform external vulnerability scans?

It depends on the SAQ type and the specific eligibility criteria.

In general:

• SAQ A-EP, SAQ B-IP, SAQ C, and SAQ D require quarterly external vulnerability scans performed by an Approved Scanning Vendor (ASV).
• SAQ A, SAQ B (dial-out terminals), and SAQ P2PE typically do not require external scans as part of their SAQ validation, provided all eligibility conditions are met and no internet-connected systems are in scope.

Can I mark a requirement as “Not Applicable” (N/A)?

Yes, but only when the requirement genuinely does not apply to your environment. For example, if your environment does not use wireless technology, wireless-specific requirements may be marked as “Not Applicable.”

When using N/A, you must provide a justification in Appendix D of the SAQ explaining why the requirement does not apply.

Important distinction:

Do not confuse “Not Applicable” with “Not Tested.”

• “Not Applicable” means the requirement truly does not apply.
• “Not Tested” means the requirement applies but was excluded from assessment, resulting in a partial assessment, which may not be accepted by your acquirer.

For SAQ P2PE, the “Not Tested” option is not available.

The post Complete Guide to PCI DSS SAQ Preparation and Automation appeared first on Centraleyes.

*** This is a Security Bloggers Network syndicated blog from Centraleyes authored by Rebecca Kappel. Read the original post at: https://www.centraleyes.com/complete-guide-to-pci-dss-saq-preparation-and-automation/