PCI DSS v4.0.1 Audit-Readiness Rubric — Payment Card Data Security
What this is: relevant if a biotech/pharma customer sells direct-to-consumer via their own website.
Sourcing note: unlike ISO, PCI SSC publishes the full standard free — this rubric is sourced directly from the official PCI DSS v4.0.1 PDF (June 2024, current; v4.0 retired 31 Dec 2024). See regscribe-iso27001-pcidss-research memory for full citations. No quantified failure-pattern data was researched for this standard — the failure-pattern column is omitted rather than fabricated.
Rubric legend
Each row: Requirement (plain language) → Citation → Evidence that demonstrates compliance
| # | Requirement | Citation | Evidence of compliance |
|---|---|---|---|
| 1 | Network security controls installed and maintained | PCI DSS v4.0.1, Requirement 1 | Network diagrams; firewall/router configuration standards; rule review records |
| 2 | Secure configurations applied to all system components (no vendor defaults) | PCI DSS v4.0.1, Requirement 2 | Configuration standards; hardening checklists; default-credential change records |
| 3 | Stored account data protected (encryption, truncation, masking, retention limits) | PCI DSS v4.0.1, Requirement 3 | Data retention/disposal policy; encryption implementation evidence; data discovery/scanning results |
| 4 | Cardholder data protected with strong cryptography during transmission over open, public networks | PCI DSS v4.0.1, Requirement 4 | TLS configuration evidence; certificate management records |
| 5 | Systems and networks protected from malicious software | PCI DSS v4.0.1, Requirement 5 | Anti-malware deployment and update records; scan logs |
| 6 | Secure systems and software developed and maintained (patching, vulnerability management, secure coding, script/tamper controls for payment pages) | PCI DSS v4.0.1, Requirement 6 | Patch management records; vulnerability remediation evidence; script inventory/authorization records (Req. 6.4.3) for the merchant's own payment-adjacent pages |
| 7 | Access to system components and cardholder data restricted by business need to know | PCI DSS v4.0.1, Requirement 7 | Access control policy; role-based access matrix |
| 8 | Users identified and authenticated before accessing system components | PCI DSS v4.0.1, Requirement 8 | User account inventory; authentication policy; MFA evidence |
| 9 | Physical access to cardholder data restricted | PCI DSS v4.0.1, Requirement 9 | Physical access controls documentation; visitor logs (if applicable to on-prem card data) |
| 10 | Access to system components and cardholder data logged and monitored | PCI DSS v4.0.1, Requirement 10 | Logging configuration; log review records; payment-page tamper-detection evidence (Req. 11.6.1 cross-reference) |
| 11 | Security of systems and networks tested regularly (vulnerability scans, penetration testing) | PCI DSS v4.0.1, Requirement 11 | Quarterly ASV scan reports; annual penetration test reports |
| 12 | Information security supported with organizational policies and programs | PCI DSS v4.0.1, Requirement 12 | Information security policy; incident response plan; security awareness training records; third-party/vendor management records |
Which self-assessment path applies (the key decision fork for a DTC site)
- SAQ A — fully outsourced checkout (redirect or iframe, e.g. Stripe Checkout); card data never touches the merchant's own systems (~24 requirements)
- SAQ A-EP — self-hosted checkout page with a tokenized field library embedded directly in the merchant's own form (e.g. Stripe Elements embedded, not redirected) — a much bigger lift (~140 requirements)
- Since 31 March 2025, SAQ A/A-EP eligibility also requires attesting the site isn't susceptible to script-based/e-skimming attacks (Req. 6.4.3, 11.6.1)
- SAQ D applies if the merchant doesn't qualify for a shorter SAQ
What audit readiness means (not one-size-fits-all, not PCI-SSC-defined)
Formal QSA-led audit (Report on Compliance) only required for Level 1 merchants; most merchants self-assess via SAQ + signed Attestation of Compliance, plus quarterly ASV scans and annual penetration testing if internet-facing systems are in scope. Merchant levels (1-4) are card-brand-defined (Visa/Mastercard/etc.), not PCI-SSC-defined. Most early/mid-stage biotech-pharma DTC sites land at Level 3-4 (self-assessment territory).
Documents/evidence needed
Completed SAQ (or ROC) with per-requirement status; signed Attestation of Compliance; network diagrams and cardholder-data-environment scope documentation; evidence of quarterly ASV scans and internal vulnerability scans; evidence of annual penetration testing; incident response plan; security awareness training records; third-party/vendor management records.