SAQ D Checklist — Comprehensive PCI DSS self-assessment

0 / 34 controls complete

Scope warning — read first0 / 2

scope.1You're on SAQ D because nothing simpler fits
SAQ D is the catch-all. If you store, process, or transmit cardholder data in a way that doesn't fit A, A-EP, B, B-IP, C-VT, C, or P2PE — you're on D. The scope is your full Cardholder Data Environment plus everything connected to it.
scope.2Phone payments? Read this carefully.
Agents typing card numbers into a CRM during a phone call brings the entire call recording, the agent's PC, the network, and often most of the office into PCI scope. A descope solution like Paytia removes the cardholder data from the agent and the call recording entirely — typically reducing SAQ D scope to SAQ A.

1.1.4Firewall between any wireless network and the CDE
If your office WiFi can reach the systems handling card data, you have a problem. Either segment WiFi off entirely or treat it as in-scope (you don't want the latter).
1.2.1Restrict inbound and outbound traffic to that necessary
Default deny. Each allow rule needs a documented business justification and an owner.
1.3.6Database servers in an internal network zone, not the DMZ
Card-data databases are not directly accessible from the internet. Web servers in DMZ talk to DB in internal zone via tightly restricted rules.

2.1Change vendor defaults
Default passwords, default community strings, default service accounts — change all before deploying.
2.2Hardening standards for each system type
One hardening standard per OS / service type, based on a recognised baseline (CIS, NIST). Every new system built to that standard.
2.6One primary function per server
Don't run the database, web server, and mail server on the same host. Either separate hosts or strong virtualisation isolation.

3.2Don't store sensitive authentication data after authorisation
Full magstripe, CVV, PIN — never stored, even encrypted. The moment after authorisation, it's gone.
3.3Mask PAN when displayed
Show first 6 + last 4 at most, by default. Full PAN visible only to those with a documented business need.
3.4Render stored PAN unreadable
Strong encryption with proper key management, or one-way hashing, or truncation, or tokenisation. Don't roll your own crypto.
3.5Document and protect cryptographic keys
Keys are stored in HSMs or equivalently protected. Key custodians have signed responsibility statements.
4.1Encrypt cardholder data in transit over public networks
TLS 1.2 or above. Disable weak ciphers. Annual SSL Labs scan should be A or A+.

5.1Anti-malware on commonly-affected systems
Endpoint protection on workstations and servers. Updates automatic. Logs sent to central monitoring.
6.2Patch within one month of release
Critical patches go on within a month. Tracked in a ticketing system with deployment dates.
6.5Address common coding vulnerabilities
Developers trained in secure coding (OWASP Top 10 minimum). Code reviews check for the common stuff. SAST/DAST tooling helps but isn't sufficient alone.
6.6WAF or code review for public-facing web apps
Either a WAF in front of every public-facing web app, or every code change reviewed by qualified personnel.

7.1Need-to-know access
Default deny. Access granted by job role. Reviewed at least every 6 months.
8.3Multi-factor authentication for all admin and remote access
MFA for every admin login. MFA for every remote access into the network. Push notifications or hardware tokens, not SMS.
8.5.1No shared accounts
Every person has their own login. No 'admin' account that three people use.
9.1Physical access controls to systems
Server rooms locked. Access logged. Visitors escorted.

10.2Log security-relevant events on every in-scope system
Logins, admin actions, access to cardholder data, changes to user accounts, system clock changes, log access, all critical errors.
10.5.5File integrity monitoring on critical files
FIM on system binaries, configuration files, and audit logs themselves. Alerts on unauthorised change.
10.6Daily log review for security events
Either a SIEM with alerting or a person who genuinely reviews the daily summary. Document who did the review and what they found.
10.7Retain audit logs for at least one year
Three months immediately available, the rest in colder storage.

11.2Quarterly external ASV scans
Approved Scanning Vendor scans every quarter and after significant change. Address findings.
11.2.1Quarterly internal vulnerability scans
Internal scans by qualified personnel. Same cadence as external.
11.3Annual external + internal pen tests
Full pen test once a year and after significant change. Methodology documented. Findings tracked to closure.
11.5Change-detection mechanism
Detect unauthorised modification of system files, config files, content files. Alert on change. Investigate.

12.1Maintain an information security policy
Comprehensive policy covering all 12 PCI requirements. Reviewed annually. Distributed to staff.
12.3Acceptable use policies for technologies
Policies for laptops, tablets, removable media, internet, email — covering authorised use, owners, accepted use, network locations.
12.6Security awareness programme
Training at hire and annually. Multiple methods (email, posters, training modules). Sign-off after each training.
12.8Manage service providers
List all third parties with access to cardholder data. Written agreements. Annual AOC review. Document who's responsible for what (you vs them).
12.10Incident response plan
Documented, tested annually, includes notification of card brands and acquirer, roles assigned, communication procedures.