Skip to main content
PCI DSS v4.0 has 12 requirements with ~329 sub-requirements. SaaS at SAQ A-EP scope satisfies ~146 of them. This page lists the highest-traffic sub-requirements and their evidence sources. Companion to the PCI DSS framework guide.

Requirement 1 — Network security controls

1.2.5 — Allowed services, protocols, ports

Cloud connector pulls security group rules per VPC. Codex flags:
  • Any inbound rule allowing 0.0.0.0/0 on ports other than 80/443 (default-deny exception)
  • Outbound rules allowing arbitrary destinations
  • Default security groups in use (vs purpose-built groups per service)

1.4 — Network connections between trusted and untrusted networks

Per-environment network segmentation evidence:
  • CDE (cardholder data environment) accounts/projects vs non-CDE
  • VPC peering rules between them (only allowlisted services)
  • Service-to-service authentication enforced (mTLS, IAM roles)

Requirement 2 — Secure configurations

2.2.1 — Configuration standards

Terraform/Pulumi commit history pulled from code host:
  • Per-resource baseline (e.g. aws_db_instance with required encryption + backup settings)
  • Drift detection from cloud-config tooling
  • PR review history showing changes were reviewed

2.3 — Default credentials

Cloud IAM inventory + secrets-management connector:
  • AWS root user — no active access keys (red flag if present)
  • Database admin passwords — managed via Secrets Manager / Vault, not hardcoded
  • Application service accounts — have passwords/keys rotated within policy window

Requirement 3 — Account data protection

3.5.1 — PAN encryption / tokenization

For SAQ A and A-EP, you should be tokenizing — Codex looks for direct PAN storage as a critical exception:
  • Database column scan for PAN-shaped data (16-digit numbers)
  • Log scan for PAN appearing in application logs (huge red flag)
  • Cache scan for PAN in Redis/Memcached
For SAQ D: direct PAN storage requires KMS + tokenization vault evidence.

3.6 — Cryptographic key management

KMS connector evidence:
  • Per-key purpose + rotation policy
  • Key access audit log (who decrypted what, when)
  • Cryptographic key inventory + lifecycle status

Requirement 4 — Transmission protection

4.2.1 — Strong cryptography on public networks

TLS coverage scan across all public endpoints:
  • TLS 1.2 minimum (1.3 preferred)
  • No weak ciphers (RC4, 3DES, NULL, EXPORT)
  • Certificate validity + expiration tracking
  • HSTS enforced
Per-endpoint compliance status with last-scan timestamp.

Requirement 5 — Malware protection

5.2 — Anti-malware on at-risk systems

EDR coverage from CrowdStrike / SentinelOne:
  • Coverage rate (% of in-scope endpoints with EDR)
  • Definitions current (% within 24h of latest)
  • Detection events + outcomes

Requirement 6 — Secure system development

6.2.4 — Secure coding training

LMS records for developers:
  • OWASP top 10 training
  • Secure coding course completion
  • Cadence: annual mandatory

6.3.1 — Vulnerability identification

Per-vulnerability lifecycle:
CVE: CVE-2024-XXXX
Discovered: 2026-04-12 (Snyk dependency scan)
Severity: High (CVSS 8.4)
Affected component: api-gateway → express@4.17.1
Triaged: 2026-04-12 (PR #2143 opened)
Resolved: 2026-04-13 (PR merged + deployed to prod)
SLA window: 30 days for High ✓

6.4.3 — Public-facing web app protections

WAF connector evidence:
  • WAF deployed in front of all public web apps
  • Rule set matches a baseline (OWASP CRS, AWS Managed Rules, Cloudflare Managed)
  • Rule violations + outcomes (blocked, alerted, allowed)

Requirement 7 — Access restriction

7.2 — Role-based access control

Per-app role assignments from IdP + cloud + SaaS connectors. PCI-specific cuts:
  • Per-role: which CDE resources accessible
  • Per-user: which roles assigned (vs the role baseline for their job function)
  • Quarterly access review attestations

7.3 — Access control system

Default-deny enforcement evidence:
  • IAM policies use explicit allow + implicit deny (no *:* policies)
  • Network ACLs default-deny
  • Application authorization checks at every endpoint (code review evidence)

Requirement 8 — Identification and authentication

8.3 — Strong authentication for non-CDE

IdP MFA enforcement reports filtered to non-CDE-administrating users.

8.4 — MFA for CDE access

Conditional access policies showing:
  • All CDE access requires MFA
  • Specific MFA factor types accepted (no SMS for CDE — must be authenticator app, security key, or biometric)
  • MFA enrollment rate (must be 100% for CDE-accessing users)

8.5 — Multi-step authentication

Per-CDE-user MFA factor inventory:
  • Primary factor (password + complexity)
  • Secondary factor type (TOTP, FIDO2, push)
  • Backup factor (recovery codes)

8.6 — Authenticator account management

Service account inventory with last-rotation timestamp + lifecycle status.

Requirement 10 — Logging and monitoring

10.2 — Audit log generation

Per-system logging coverage:
  • Per CDE system: logging enabled, what events, retention period
  • Per user: per-day activity log inventory
  • Privileged operations specifically logged (admin actions, schema changes, key access)

10.3 — Log integrity

Cloud-config evidence:
  • CloudTrail / Activity Log → immutable storage (S3 Object Lock, Azure Immutable Blob)
  • Log forwarding to SIEM with cryptographic verification

10.6 — Log review

Log review activity records:
  • Who reviewed which log set
  • When (date + time)
  • Findings (anomaly count, escalations)
PCI requires daily review of critical logs — Codex flags any 24h gap as an exception.

Requirement 11 — Security testing

11.3 — External vulnerability scans

Quarterly ASV (Approved Scanning Vendor) scan reports — you upload them, Codex stores with:
  • Scan date
  • ASV vendor name
  • Pass/fail status
  • Vulnerability count by severity
  • Remediation status
PCI requires quarterly clean ASV scans — Codex tracks the cadence.

11.4 — Internal pen tests

Annual + after-significant-change pen test reports — uploaded with:
  • Test date + scope
  • Tester identity (internal or external firm)
  • Findings + remediation status
  • Re-test results (for findings)

Requirement 12 — Information security policy

Linked policy documents + annual review attestations + acknowledgment records.

What this catalog isn’t

PCI DSS has prescriptive control parameters that vary by environment scope — Codex’s evidence catalog reflects what auto-evidence can capture; specific configuration values (password length minimums, session timeout maximums, etc.) need to be set in your tooling per the PCI DSS standard. See the PCI DSS framework guide for SAQ selection and full requirement coverage.