PCI DSS SAQ A-EPSupported in OneClickComply

Complete PCI DSS SAQ A-EP with evidence that collects itself

SAQ A-EP is the PCI DSS v4.0.1 Self-Assessment Questionnaire for e-commerce merchants that partially outsource their payment channel to a PCI DSS compliant provider, while their own website controls how customers or their card data reach that provider. Because the merchant website can affect the security of the payment transaction, SAQ A-EP covers 139 requirements across all 12 PCI DSS principal requirements, far more than SAQ A.

See the SAQ A-EP requirements

SAQ A-EP Aligned

Automated Evidence

OneClickFix Enabled

Continuous Monitoring

In-House Audit Team

Who needs SAQ A-EP

Is SAQ A-EP right for your organisation?

SAQ A-EP is used by e-commerce merchants that use a direct post form or a JavaScript-generated payment form, where card data goes straight to a compliant processor but the payment page or its elements are served from the merchant's own website. Merchants usually complete it each year when their acquiring bank or payment brand requires a self-assessment to validate PCI DSS compliance. It cannot be used by service providers or for card-present channels.

It is usually required by customers, partners or schemes rather than by law.

Issued by: PCI Security Standards Council (PCI SSC)
Latest version: SAQ A-EP for PCI DSS v4.0.1, published October 2024
Applies to: E-commerce merchants whose website affects payment page security but does not receive card data
Requirements: 139 requirements across all 12 PCI DSS principal requirements
Enforced by: Acquiring banks and payment card brands, through merchant contracts
Validation route: Self-assessment questionnaire with an Attestation of Compliance, plus quarterly external ASV scans
Not for: Service providers, card-present channels or merchants that store card data electronically
Type: Standard (contractual)
Region: Global
In OneClickComply: Supported today

How we help

OneClickComply makes it simple

SAQ A-EP is mapped in OneClickComply's control library and available on request, so your SAQ A-EP requirements can be tracked alongside the frameworks you already run. OneClickComply collects evidence for areas such as access control, MFA, logging, patching and vendor oversight from your connected tools, generates the policies the questionnaire asks for, and links each piece of evidence to the matching requirement. Our in-house audit team can help you confirm eligibility and prepare for the attestation.

Requirements covered

139 requirements drawn from all 12 PCI DSS principal requirements, including payment page script management (6.4.3), quarterly ASV scans (11.3.2) and payment page tamper detection (11.6.1).

Already working towards another framework?

ISO 2700117% of SAQ A-EP overlaps
SOC 287% of SAQ A-EP overlaps
NIST CSF70% of SAQ A-EP overlaps
GDPR14% of SAQ A-EP overlaps

Evidence you collect once counts towards every framework it applies to.

Manual SAQ A-EP vs. OneClickComply

Manual SAQ A-EP

Working through 139 questionnaire requirements in a spreadsheet, one row at a time
Chasing screenshots of MFA, password and logging settings from several admin consoles
Keeping payment page script inventories and tamper alerts tied to evidence by hand
Tracking quarterly ASV scans, annual pen tests and six-monthly reviews on a calendar
Collecting your payment provider's AOC and responsibility split by email each year

With OneClickComply

Each SAQ A-EP requirement linked to a control with its status and evidence in one place
Evidence pulled automatically from connected cloud, identity and device tools
Alerts when monitored controls drift, so gaps surface before your attestation
Recurring tasks for scans, tests and reviews with completed evidence attached
Third-party records and compliance documents held in the vendor risk register

Capabilities

Everything you need for SAQ A-EP

SAQ A-EP requirements mapped to controls you already run for other frameworks

Automated evidence for MFA, user access reviews and inactive account removal

Continuous monitoring of patching, logging and configuration drift on in-scope systems

AutoComplete policies for information security, incident response and change control

Vendor risk management to track your payment provider's AOC and responsibility matrix

Penetration testing and Ask an Auditor support ahead of your attestation

How it works

Three steps to SAQ A-EP compliance

Connect & scan

Connect your cloud, identity and SaaS tools. OneClickComply checks them against SAQ A-EP and shows you exactly where you stand.

Fix & generate

OneClickFix remediates technical gaps in one click, and AutoComplete generates SAQ A-EP-aligned policies from your real environment.

Monitor & evidence

Continuous monitoring keeps you compliant, and our in-house audit team is on hand when you need expert guidance.

Requirements

PCI DSS SAQ A-EP requirements

All 139 requirements in SAQ A-EP for PCI DSS v4.0.1, listed by PCI DSS requirement number with short descriptive titles.

Reference	Requirement
1.1.1	Requirement 1 security policies and procedures documented and in use
1.2.1	Configuration standards for network security control rulesets
1.2.2	Changes to network connections and NSC configurations follow change control
1.2.3	Accurate network diagram maintained
1.2.4	Accurate data-flow diagram maintained
1.2.5	Allowed services, protocols and ports identified and approved
1.2.6	Security features for insecure services, protocols and ports
1.2.7	NSC configurations reviewed at least every six months
1.2.8	NSC configuration files secured and consistent
1.3.1	Inbound traffic to the CDE restricted
1.3.2	Outbound traffic from the CDE restricted
1.3.3	NSCs installed between wireless networks and the CDE
1.4.1	NSCs implemented between trusted and untrusted networks
1.4.2	Inbound traffic from untrusted networks restricted
1.4.3	Anti-spoofing measures implemented
1.4.4	Systems storing cardholder data not directly accessible from untrusted networks
1.4.5	Disclosure of internal IP addresses and routing information limited
1.5.1	Security controls on devices connecting to untrusted networks and the CDE
2.1.1	Requirement 2 security policies and procedures documented and in use
2.2.1	System configuration standards developed and maintained
2.2.2	Vendor default accounts managed
2.2.3	Primary functions with different security levels managed
2.2.4	Only necessary services, protocols and functions enabled
2.2.5	Insecure services, protocols or daemons justified and secured
2.2.6	System security parameters configured to prevent misuse
2.2.7	Non-console administrative access encrypted
3.1.1	Requirement 3 security policies and procedures documented and in use
3.2.1	Account data storage kept to a minimum
3.3.1	Sensitive authentication data not retained after authorisation
3.3.1.2	Card verification code not retained after authorisation
3.3.1.3	PIN and PIN block not retained after authorisation
4.1.1	Requirement 4 security policies and procedures documented and in use
4.2.1	Strong cryptography protects PAN over open, public networks
4.2.2	PAN secured when sent via end-user messaging technologies
5.1.1	Requirement 5 security policies and procedures documented and in use
5.2.1	Anti-malware solution deployed on system components
5.2.2	Anti-malware detects, removes, blocks or contains malware
5.2.3	Components not at risk from malware periodically evaluated
5.2.3.1	Frequency of malware risk evaluations set by targeted risk analysis
5.3.1	Anti-malware kept current via automatic updates
5.3.2	Anti-malware performs periodic or real-time scans
5.3.2.1	Frequency of periodic malware scans set by targeted risk analysis
5.3.3	Anti-malware protection for removable electronic media
5.3.4	Anti-malware audit logs enabled and retained
5.3.5	Anti-malware cannot be disabled or altered by users
5.4.1	Processes and mechanisms to protect personnel against phishing
6.1.1	Requirement 6 security policies and procedures documented and in use
6.2.1	Bespoke and custom software developed securely
6.2.2	Software development personnel trained at least every 12 months
6.2.4	Software engineering techniques prevent common software attacks
6.3.1	Security vulnerabilities identified and ranked
6.3.2	Inventory of bespoke and custom software and components
6.3.3	Security patches and updates installed
6.4.1	Public-facing web applications protected against known attacks
6.4.2	Automated solution detects and prevents web-based attacks
6.4.3	Payment page scripts authorised, integrity-checked and inventoried
6.5.1	Changes to production system components follow established procedures
6.5.2	PCI DSS requirements confirmed after significant changes
7.2.2	Access assigned based on job classification and least privilege
7.2.3	Required privileges approved by authorised personnel
7.2.4	User accounts and access privileges reviewed every six months
7.2.5	Application and system accounts assigned least privilege
8.1.1	Requirement 8 security policies and procedures documented and in use
8.2.1	Unique ID assigned to every user
8.2.2	Shared and generic accounts used only by exception
8.2.4	User ID and authentication factor changes managed
8.2.5	Access for terminated users immediately revoked
8.2.6	Inactive accounts removed or disabled within 90 days
8.2.7	Third-party remote access accounts managed
8.2.8	Re-authentication after 15 minutes of session inactivity
8.3.1	User access authenticated with at least one factor
8.3.2	Authentication factors unreadable in transmission and storage
8.3.3	User identity verified before changing authentication factors
8.3.4	Invalid authentication attempts limited
8.3.5	Passwords set and reset securely
8.3.6	Minimum password complexity
8.3.7	Reuse of the last four passwords prevented
8.3.8	Authentication policies communicated to users
8.3.9	Passwords used as a single factor changed or dynamically analysed
8.3.11	Physical and logical authentication tokens assigned to individuals
8.4.1	MFA for non-console administrative access into the CDE
8.4.2	MFA for all access into the CDE
8.4.3	MFA for remote network access
8.5.1	MFA systems configured to resist misuse
8.6.1	Interactive use of system and application accounts managed
8.6.2	System and application account passwords not hard-coded
8.6.3	System and application account passwords protected against misuse
9.2.1	Facility entry controls restrict physical access to the CDE
9.4.1	Media with cardholder data physically secured
9.4.1.1	Offline media backups stored securely
9.4.2	Media with cardholder data classified
9.4.3	Media sent outside the facility secured
9.4.4	Management approval for media moved outside the facility
9.4.6	Hard-copy materials with cardholder data destroyed
10.2.1	Audit logs enabled and active
10.2.1.1	Audit logs capture user access to cardholder data
10.2.1.2	Audit logs capture administrative actions
10.2.1.3	Audit logs capture access to audit logs
10.2.1.4	Audit logs capture invalid logical access attempts
10.2.1.5	Audit logs capture changes to identification and authentication credentials
10.2.1.6	Audit logs capture initialisation, stopping or pausing of audit logs
10.2.1.7	Audit logs capture creation and deletion of system-level objects
10.2.2	Audit log entries record required event details
10.3.1	Read access to audit logs limited
10.3.2	Audit log files protected from modification
10.3.3	Audit logs promptly backed up to a central log server
10.3.4	File integrity monitoring on audit logs
10.4.1	Security event and critical system logs reviewed daily
10.4.1.1	Automated mechanisms perform audit log reviews
10.4.2	Logs of other system components reviewed periodically
10.4.2.1	Frequency of other log reviews set by targeted risk analysis
10.4.3	Exceptions and anomalies from log reviews addressed
10.5.1	Audit log history retained for at least 12 months
10.6.1	System clocks synchronised
10.6.2	Systems configured to correct and consistent time
10.6.3	Time synchronisation settings and data protected
11.3.2	External vulnerability scans by an ASV every three months
11.3.2.1	External vulnerability scans after significant changes
11.4.1	Penetration testing methodology defined and implemented
11.4.3	External penetration testing at least every 12 months
11.4.4	Penetration testing findings corrected
11.4.5	Segmentation controls penetration tested
11.5.1	Intrusion detection or prevention in place
11.5.2	Change-detection mechanism such as file integrity monitoring
11.6.1	Change and tamper detection for payment pages
12.1.1	Information security policy established and disseminated
12.1.2	Information security policy reviewed at least every 12 months
12.1.3	Information security roles and responsibilities defined
12.1.4	Executive responsibility for information security assigned
12.3.1	Targeted risk analysis for flexible-frequency requirements
12.6.1	Formal security awareness programme
12.6.3.1	Awareness training covers phishing and social engineering
12.8.1	List of third-party service providers maintained
12.8.2	Written agreements with TPSPs maintained
12.8.3	Due diligence process for engaging TPSPs
12.8.4	TPSP PCI DSS compliance monitored at least every 12 months
12.8.5	Responsibility matrix of requirements managed by each TPSP
12.10.1	Incident response plan ready to be activated
12.10.3	Incident response personnel available 24/7

Always check the official SAQ A-EP text for the exact wording.

SAQ A-EP FAQs

What is SAQ A-EP?

SAQ A-EP is a PCI DSS Self-Assessment Questionnaire published by the PCI Security Standards Council for e-commerce merchants that partially outsource payment processing. The merchant website does not receive card data, but it controls how customers or their card data are sent to a PCI DSS compliant payment provider, so it can affect the security of the transaction. The current version is aligned with PCI DSS v4.0.1.

What is the difference between SAQ A and SAQ A-EP?

The difference is how much control your website has over the payment page. SAQ A suits merchants that fully outsource payment pages, for example through a redirect or an iframe served entirely by a compliant provider. SAQ A-EP applies when your own website delivers the payment page or its elements, such as a direct post form or JavaScript form, so many more requirements apply to your web environment.

Who is eligible to complete SAQ A-EP?

Merchants are eligible when they accept only e-commerce transactions, outsource all processing of account data except the payment page to a PCI DSS compliant provider, and do not electronically store, process or transmit account data on their own systems. Every element of the payment page must come from the merchant website or a compliant provider. Check eligibility with your acquiring bank before you start.

How many requirements are in SAQ A-EP?

SAQ A-EP for PCI DSS v4.0.1 contains 139 requirements drawn from all 12 PCI DSS principal requirements. They cover network security controls, secure configuration, anti-malware, secure development, payment page script management, access control and MFA, logging, quarterly external vulnerability scans, penetration testing, tamper detection on payment pages, security policy, third-party management and incident response.

What happens if a merchant does not comply with SAQ A-EP?

Non-compliance is handled contractually rather than by a regulator. PCI SSC does not issue fines itself; acquiring banks and card brands enforce PCI DSS through merchant agreements. Consequences can include fees or penalties passed on by the acquirer, higher transaction costs, stricter validation requirements and, in serious cases, losing the ability to accept card payments. A breach can also lead to forensic investigation costs.

How does SAQ A-EP relate to ISO 27001?

They overlap but do not replace each other. ISO 27001 is a certifiable information security management system, while SAQ A-EP validates specific PCI DSS technical and process requirements for an e-commerce website. Controls such as access management, logging, vulnerability management, supplier oversight and incident response support both, so evidence collected once can often count towards each.

What scans and tests does SAQ A-EP require?

SAQ A-EP requires external vulnerability scans by a PCI SSC Approved Scanning Vendor at least once every three months and after significant changes, under Requirement 11.3.2. It also requires external penetration testing at least once every 12 months and after significant changes, a defined testing methodology, and correction of exploitable findings. Payment pages need change and tamper detection under Requirement 11.6.1.

Does OneClickComply support SAQ A-EP?

Yes, on request. SAQ A-EP is mapped in OneClickComply's control library and is available on request rather than as a standard live framework. Once enabled, you can track each requirement, collect evidence automatically from connected tools, generate policies and get guidance from our in-house audit team. OneClickComply does not issue attestations; your SAQ and Attestation of Compliance are submitted to your acquirer.

Related standards

All standards

Get SAQ A-EP ready, not stressed

Automate controls, gather evidence continuously and stay audit-ready, all on one platform.