SAQ A-EP Checklist — PCI DSS for partial-outsource e-commerce

0 / 18 controls complete

Scope & eligibility0 / 2

scope.1E-commerce only with partial outsourcing
SAQ A-EP is for online merchants who use a third-party payment page (iframe or redirect) but where your own webpage is what loads the iframe. Your server is in scope because a compromised page could redirect the customer somewhere malicious.
scope.2No card data ever touches your environment
Your server never sees the PAN. If it does, you're on SAQ D, not A-EP.

1.2Restrict inbound and outbound traffic
Firewall rules between your web server and the rest of the world should block everything except what's explicitly allowed. Document each rule with a business reason.
Evidence: Firewall rule list + last review date
1.4Personal firewalls on portable computing devices
Any laptop that connects to your environment from outside the office needs a host firewall (Windows Defender Firewall is fine, just configured properly).
Evidence: Endpoint config baseline document
2.1Change vendor-supplied defaults
Default passwords on routers, admin accounts, database installs — change all of them before going live. The 'admin/admin' router behind your office network counts.
Evidence: Hardening checklist for each system
2.3Encrypt non-console admin access
SSH, RDP, web admin panels — all over TLS or stronger. Telnet is dead.

4.1Encrypt cardholder data in transit
Even though card data shouldn't touch your server, the redirect/iframe must use TLS 1.2 or above. Disable older protocols.
Evidence: SSL Labs scan showing A or A+

5.1Anti-malware on all systems
Every server and workstation that's commonly affected by malware needs anti-malware software, kept up to date.
6.1Process for identifying vulnerabilities
Subscribe to security mailing lists (US-CERT, your OS vendor, your CMS vendor). Someone reads them weekly.
6.2Patch within one month of release
Critical security patches go on within a month. Track them in a ticket system so you can show the auditor.
Evidence: Patch log with dates
6.4Separate dev/test/prod environments
Production runs on different infrastructure from staging. Live card data never appears in test environments.
6.6Web application firewall OR code review
Either run a WAF in front of the web server, or get the code reviewed by someone qualified before each release.

7.1Restrict access to data by job role
Define which job roles can access which systems. Default to 'no access' and grant explicitly.
Evidence: Access matrix per role
8.2Strong authentication for all users
Passwords meet a minimum length (12+ characters is sensible). MFA for any admin access and any remote access.
8.3Multi-factor authentication for non-console admin
Anyone administering the environment from outside the office network — MFA is non-negotiable.

10.2Audit logs for all in-scope systems
Log every admin action, every login attempt, every change to user accounts. Keep logs for at least a year, with at least 90 days immediately available.
11.2Quarterly external vulnerability scans
Use an Approved Scanning Vendor (ASV). Scan your external IPs every three months and after any major change.
Evidence: ASV scan reports for last 4 quarters
11.3Annual penetration test
Once a year, get a CREST or equivalent pen test against your in-scope environment. Plus after any significant change.
Evidence: Annual pen test report