PCI DSS v4.0.1 Self-Assessment Questionnaire (SAQ A-EP)

Why does it matter?

SAQ A-EP exists because a website can compromise a payment even when card data never touches it. The Council introduced the questionnaire in February 2014, with PCI DSS v3.0, for e-commerce merchants whose site does not receive cardholder data but affects the security of the transaction or the integrity of the page that collects it (Document Changes table). The v4.0 text adds that, for this SAQ, every PCI DSS reference to the cardholder data environment applies to the merchant website, because the site directly impacts how account data is transmitted. Choosing correctly between SAQ A and SAQ A-EP decides whether a merchant answers a short questionnaire or one that spans all twelve requirements.

Key benefits include:

• Eligibility stated in eight criteria

Part 2h of the AOC repeats the criteria the merchant certifies: e-commerce only, processing outsourced except the payment page, a site that controls the redirect, a compliant hosting TPSP, page elements from the merchant or a compliant TPSP, no electronic account data, reviewed TPSP Attestations of Compliance, and paper-only retention.

• Payment-page scripts governed

Requirement 6.4.3 asks for a method to confirm each script is authorized, a method to assure its integrity, and an inventory with written business or technical justification; for SAQ A-EP it applies to the payment pages the merchant site delivers to the browser.

• Tampering detected

Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts on unauthorized modification of the security-impacting HTTP headers and script contents of payment pages as received by the consumer browser, run at least weekly or at a frequency set by a targeted risk analysis under 12.3.1.

• Third parties kept accountable

Requirements 12.8.1 to 12.8.5 ask for a list of TPSPs, written agreements, due diligence, monitoring of their PCI DSS status at least once every 12 months and a record of which requirements each party manages; Part 2f of the AOC lists them.

• Scan evidence on a fixed cadence

Requirement 11.3.2 requires external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor, with rescans until a passing result; the ASV reports accompany the SAQ when it is submitted.

How does it work?

The document has three sections plus appendices. Section 1, Assessment Information, is Parts 1 and 2 of the AOC: contact details for the assessed merchant and any assessor (Parts 1a and 1b), then an executive summary covering payment channels (2a), the role of the business with payment cards (2b), the environment (2c), in-scope locations (2d), PCI SSC validated products in use (2e), third-party service providers (2f), a summary of responses per requirement (2g) and the eligibility certification (2h). Section 2 is the questionnaire itself, which mirrors the wording of PCI DSS and adds an Expected Testing column telling the merchant what to examine, observe or interview for each requirement.

Section 2 runs through Requirements 1 to 12 with notes that narrow some of them to the SAQ A-EP environment: Requirement 6.4.3 applies to the payment pages provided from the merchant website, Requirement 11.6.1 to the web servers hosting them, and the media requirements at 9.4 only to merchants holding paper records with account data. Each requirement takes one response. Not Tested is not available: the Council states that all requirements in this SAQ must be tested. Not Applicable answers need an explanation in the appendix provided for them, and compensating controls need the Compensating Controls Worksheet in Appendix B. No SAQ can document the customized approach; that route needs a Report on Compliance.

The five completion steps are: confirm from the eligibility criteria and the SAQ Instructions and Guidelines that this is the correct SAQ; confirm the environment is properly scoped; assess it against the requirements; complete Sections 1, 2 and 3; and submit the SAQ and AOC with any other requested documentation, such as ASV scan reports, to the organization that manages the compliance program, usually the acquirer or a payment brand. Section 3 holds Parts 3 and 4 of the AOC: the compliance status, the merchant acknowledgement and executive officer signature (3a and 3b), QSA and ISA involvement (3c and 3d) and, only on request after a Non-Compliant result, the Part 4 action plan.

Key Elements

• Merchant Eligibility Criteria

The front-matter test for using SAQ A-EP: e-commerce only, partial outsourcing with the payment page retained, no electronic account data on merchant systems, and reviewed TPSP Attestations of Compliance for the services used.

• Section 1: Assessment Information (AOC Parts 1 and 2)

Contact information, executive summary and the Part 2h eligibility certification, with Part 2f naming every TPSP to which Requirement 12.8 applies.

• Section 2: Self-Assessment Questionnaire A-EP

Requirements 1 to 12 in the Council's six goal groups, from network security controls to organizational policies, each with Expected Testing and a single response.

• Requirement 6.4.3 and Requirement 11.6.1

The two payment-page requirements: script authorization, integrity and inventory; and weekly, or risk-analysis-based, detection of changes to headers and scripts as the browser receives them. Both were best practice until March 31, 2025 and are now required.

• Requirement 11.3.2: ASV scans

External scans at least once every three months by an Approved Scanning Vendor, with vulnerabilities resolved and rescans to a passing result under the ASV Program Guide.

• Appendices

Appendix A1 (multi-tenant service providers) is not used for merchant assessments, A2 is not used for SAQ A-EP, and A3 (Designated Entities Supplemental Validation) applies only to entities a payment brand or acquirer designates; Appendix B is the Compensating Controls Worksheet, and further appendices explain Not Applicable responses.

• Section 3: Validation and Attestation (AOC Parts 3 and 4)

Compliant, Non-Compliant or Compliant but with Legal exception; acknowledgement, signatures and, if requested, an action plan with target dates per requirement.

What does it cover?

SAQ A-EP applies to e-commerce merchants that partially outsource their payment channel to PCI DSS validated and compliant third parties, whose website does not receive account data but controls how customers or their data are redirected to the processor, or delivers elements of the payment page. It is for e-commerce channels only; a merchant with other channels validates them with a different SAQ or SAQ D. It is not applicable to service providers. The entity to which the SAQ is submitted, an acquirer or a payment brand, decides whether a merchant may self-assess at all and which SAQ it accepts; the Council's bulletin asks merchants to confirm this before starting.

What are its objectives?

The questionnaire is built so that a merchant with a payment page under its control can show that:

The payment page the site delivers carries only authorized scripts, each with an integrity method and a justified place in an inventory (Requirement 6.4.3).

Unauthorized changes to the headers and scripts of that page are detected and alerted (Requirement 11.6.1).

The web servers and supporting systems that deliver the page are configured, patched, access-controlled, logged and scanned under Requirements 1, 2, 5, 6, 7, 8, 10 and 11.

Every third party that handles account data or could affect its security is listed, contracted and monitored (Requirements 12.8.1 to 12.8.5), and an incident response plan is ready (12.10.1).

The result is attested by a merchant executive officer in Part 3b and submitted with ASV scan reports to the acquirer.

Framework in Context

SAQ A-EP sits between SAQ A, for merchants that fully outsource the payment page, and SAQ D for Merchants, for anyone who meets no shorter SAQ's criteria. The boundary moved in October 2024: the v4.0.1 SAQ A added a criterion that the merchant has confirmed its site is not susceptible to attacks from scripts that could affect its e-commerce systems, and FAQ 1588 (February 2025) says a merchant with an embedded iframe can meet it with techniques such as those in Requirements 6.4.3 and 11.6.1 or with confirmation from its PCI DSS compliant TPSP. A merchant that cannot meet that criterion asks its compliance-accepting entity which SAQ applies; the requirement text comes from PCI DSS v4.0.1 (June 2024).

Common Framework Mappings

Merchants that already run an information security program map the SAQ A-EP requirements to it so that the same controls, owners and evidence serve the annual PCI attestation and their other audits. The list below is indicative: it does not replace the requirement list in Section 2 of the SAQ, and the acquirer accepts only the completed SAQ and AOC themselves.

Mapped frameworks include:

CIS Controls v8.1

ISO 27001:2022

ISO 27002:2022

NIST CSF 2.0

NIST 800-53 Rev.5

SOC 2

SWIFT CSCF