Every PCI Compliance Audit check

PCI-DSS 4.0 Req 3.2 and 3.4 prohibit storing raw cardholder data outside an isolated, documented Cardholder Data Environment (CDE). A general-purpose database containing card numbers or CVVs is fully in scope for a Level 1 PCI audit — expanding your compliance surface and dramatically raising breach risk. Under OWASP A02 (Cryptographic Failures), exposed card numbers in an unprotected schema are trivially dumped via SQL injection or misconfigured backups. CWE-312 (Cleartext Storage) applies when tokenization is skipped. Req 12.4 requires that scope documentation exists; without it you cannot demonstrate compliance at all.

Why this severity: Critical because raw cardholder data in an undocumented or non-isolated environment is a direct PCI audit failure and exposes card numbers to mass exfiltration with no compensating control.

PCI-DSS 4.0 Req 3.5 mandates encryption of stored account data; Req 3.3 prohibits storage of sensitive authentication data post-authorization. A database without encryption at rest means any storage-layer compromise — a stolen disk, a snapshot shared to the wrong account, or a cloud misconfiguration — exposes cardholder data in plaintext. NIST SP 800-53 SC-28 and OWASP A02 (Cryptographic Failures) both treat unencrypted data stores as high-severity findings. For managed services like RDS or Supabase, missing `storage_encrypted = true` means the infrastructure configuration actively opts out of protection that is trivially available.

Why this severity: Critical because an unencrypted database volume means a storage-layer breach yields plaintext cardholder data with no decryption barrier, satisfying PCI-DSS Req 3.5 as a direct violation.

PCI-DSS 4.0 Req 2.1 requires that all default passwords and unnecessary default accounts are removed before system components enter production. Req 8.3 mandates strong authentication for all users. Hardcoded credentials — `postgres:postgres` in a Dockerfile, `sk_live_` keys in a `.env` committed to git — are the lowest-effort, highest-yield targets for attackers. CWE-798 (Use of Hard-coded Credentials) and CWE-1188 (Initialization with Default Value) are both directly exploitable. OWASP A05 (Security Misconfiguration) rates this category as endemic. A leaked Stripe live key means unauthorized charges or refunds; a leaked DB admin password means direct CDE access.

Why this severity: Critical because a hardcoded live credential found in a public or semi-public repository enables immediate unauthorized access to payment systems or the database with no additional exploitation needed.

PCI-DSS 4.0 Req 4.2.1 prohibits transmitting PANs over end-user messaging technologies or unprotected open networks; Req 4.1 requires a targeted risk analysis for any TLS configuration below 1.2. Transmitting cardholder data over HTTP or TLS 1.0/1.1 exposes it to BEAST, POODLE, and CRIME class attacks — protocol-level attacks that allow passive decryption. CWE-319 (Cleartext Transmission) is exploitable at any network vantage point on the path. OWASP A02 (Cryptographic Failures) and NIST SC-8 both require encryption in transit as a baseline control. Incomplete enforcement — HSTS present but no redirect from port 80 — leaves a real downgrade path.

Why this severity: Critical because cardholder data sent over unencrypted or downgraded TLS connections can be intercepted in transit by any network-position attacker, directly violating PCI-DSS 4.0 Req 4.2 and exposing PANs.

Password-only admin access means one phished or brute-forced credential hands an attacker complete administrative control. PCI DSS 4.0 Requirements 8.4 and 8.5 mandate multi-factor authentication for all access to the Cardholder Data Environment; NIST 800-53 rev5 IA-2(1) and IA-2(2) require MFA for privileged accounts. CWE-308 (Use of Single-Factor Authentication) and OWASP A07 both list missing MFA as a primary cause of privileged account compromise. A stolen admin password without a second factor exposes every user record, payment record, and configuration secret in the system.

Why this severity: High because admin account compromise via password alone escalates immediately to full data breach; MFA is the primary control preventing lateral movement from a single credential leak.

PCI-DSS 4.0 Req 7.1 requires a formal model where access to system components is restricted on a need-to-know basis; Req 7.2 mandates that the access control model documents each user's required access level. Without RBAC, every authenticated user is implicitly authorized to access all data — a customer account can query transaction records for other customers, or a support agent can issue refunds. CWE-285 (Improper Authorization) and OWASP A01 (Broken Access Control) are the most exploited vulnerability class across web applications. NIST AC-2 requires that accounts are managed with assigned access rights enforced in code.

Why this severity: High because missing or unenforced role separation means any authenticated user can access data or perform actions beyond their authorization scope, directly violating PCI-DSS 4.0 Req 7.2 and enabling horizontal privilege escalation.

PCI-DSS 4.0 Req 7.2.2 requires that privileges assigned to accounts and roles are based on least privilege. Req 8.2.1 limits account use to the single purpose for which it was created. A reporting cron job running with full database admin credentials means a compromised job scheduler has write access to the entire CDE. CWE-250 (Execution with Unnecessary Privileges) and OWASP A01 (Broken Access Control) both flag over-privileged service accounts as exploitable. NIST AC-6 (Least Privilege) mandates that each automated process is granted only the minimum rights required for its function.

Why this severity: Low because over-privileged service accounts expand blast radius when compromised but typically require an upstream component compromise first — the risk is real but conditional on a prior step in the attack chain.

PCI-DSS 4.0 Req 8.3.6 sets the minimum password complexity requirements; Req 8.3 requires strong authentication for all user IDs. A minimum password length of 6 characters with no complexity rules is crackable in seconds with commodity GPU rigs and common wordlists. CWE-521 (Weak Password Requirements) and OWASP A07 (Identification and Authentication Failures) both identify inadequate password policy as a direct authentication failure. NIST IA-5 provides the baseline: minimum 8 characters, not in a known compromised password list. Admin accounts with weak passwords in a CDE represent a trivial brute-force vector.

Why this severity: Low because weak password policy increases susceptibility to brute-force and credential-stuffing attacks but is mitigated in part by account lockout and MFA — it raises risk without being an immediate critical vector on its own.

PCI-DSS 4.0 Req 12.1 requires that an overall information security policy exists and is reviewed at least annually; Req 12.3 mandates a targeted risk analysis process documented for each requirement. Without a compliance documentation file that states your SAQ type and CDE scope, you cannot demonstrate PCI compliance to an auditor, a payment processor, or an enterprise customer requesting your AOC. ISO 27001:2022 A.5.1 and SOC 2 CC2.2 both require written policies before any technical controls are assessed. A project with good technical controls but no documentation fails a PCI audit regardless of its actual security posture.

Why this severity: High because the absence of a documented SAQ type and CDE scope means no audit trail exists for your compliance posture — you cannot satisfy a QSA assessment or payment processor inquiry regardless of your technical controls.

PCI-DSS 4.0 Req 1.2 requires that network security controls are defined, implemented, and maintained; Req 1.3 prohibits direct connections between the internet and any component in the CDE. A flat network where your payment webhook receiver, application database, and CDE share a single VPC and security group means any web-layer compromise — SSRF, RCE in a dependency — provides direct lateral movement to cardholder data with no network barrier. CWE-668 (Exposure of Resource to Wrong Sphere) and NIST SC-7 (Boundary Protection) both require explicit network segmentation between trust zones. OWASP A05 (Security Misconfiguration) flags flat networks as a routine finding.

Why this severity: High because a non-segmented network allows lateral movement from an internet-facing component directly into the CDE with no firewall or zone boundary requiring breach — one exploited webhook is full CDE access.

PCI-DSS 4.0 Req 1.2.1 requires that inbound and outbound traffic is restricted to that which is necessary; Req 1.4 prohibits direct public access to any CDE component. A security group with `0.0.0.0/0` on port 22 (SSH) or 5432 (PostgreSQL) means your database is reachable from the entire internet — any brute-force or credential-stuffing attack against it requires only a public IP. CWE-183 (Permissive List of Allowed Inputs) and NIST SC-7 both require deny-by-default firewall posture. A single overly permissive rule can invalidate an otherwise well-segmented network architecture.

Why this severity: High because one allow-all or `0.0.0.0/0` rule on a sensitive port (SSH, database) exposes the CDE directly to internet-sourced attacks, negating any network segmentation investment.

PCI-DSS 4.0 Req 11.3 requires that vulnerabilities in system components are identified and addressed via a vulnerability management program; Req 6.3 requires that security vulnerabilities are identified and ranked by risk. Without automated scheduled scanning, a critical CVE in an npm dependency or a container base image can linger for months before anyone notices. SLSA L2 requires build provenance and dependency tracking. CWE-1357 (Reliance on Uncontrolled Component) is exploitable whenever a dependency with a known CVE is in the production dependency tree and no process monitors for it.

Why this severity: High because undetected vulnerabilities in dependencies or infrastructure components accumulate silently and create exploitable attack surfaces that a scheduled scanner would catch within days of CVE publication.

PCI-DSS 4.0 Req 1.3 requires that direct connections between the internet and CDE components are prohibited; Req 1.5 requires that risks from devices connecting to both untrusted networks and the CDE are addressed. Without a DMZ or filtering layer, internet traffic reaches CDE resources in one hop — a malformed webhook payload or HTTP flood hits the database network directly. CWE-668 (Exposure of Resource to Wrong Sphere) captures exactly this architecture gap. NIST SC-7 requires boundary protection at network perimeters. A WAF or reverse proxy in the DMZ also enforces rate limiting, which blocks credential-stuffing and payment enumeration attacks before they reach business logic.

Why this severity: Medium because the absence of a DMZ increases attack surface and removes a filtering layer that would otherwise block or rate-limit malicious traffic before it reaches CDE resources.

PCI-DSS 4.0 Req 11.5 requires that a change-detection mechanism is deployed to alert personnel to unauthorized modifications of critical files; Req 10.7 requires failures of critical security controls to be detected and reported promptly. Without IDS/IPS or network flow monitoring on the CDE network, an attacker who has established a foothold can exfiltrate cardholder data over days or weeks without generating any alert. ISO 27001:2022 A.8.16 and NIST SI-4 both require continuous network monitoring. VPC Flow Logs and GuardDuty together provide the minimum signal set required by Req 11.5 for cloud-hosted CDEs.

Why this severity: Medium because without network monitoring an active intrusion or data exfiltration event produces no alert, extending mean-time-to-detection and turning a recoverable incident into a reportable breach.

PCI-DSS 4.0 Req 10.5 requires audit logs to be retained for at least 12 months, with at least 3 months immediately available; Req 10.2 requires specific event types to be logged. Logs retained for only 7 or 30 days mean that a breach discovered 60 days after the intrusion has no forensic record — you cannot determine how much data was taken, when, or by whom. SOC 2 CC7.2 and ISO 27001:2022 A.8.15 both require log availability for incident investigation. NIST AU-11 sets the retention baseline. Short-retention configurations that are left at default (often 7 days for CloudWatch) are a routine PCI audit failure.

Why this severity: Medium because insufficient log retention destroys forensic evidence after an incident, preventing breach scope determination and triggering PCI-DSS Req 10.5 compliance findings during assessment.

PCI-DSS 4.0 Req 10.3 requires that audit logs are protected from destruction and unauthorized modifications; Req 10.4 mandates that log content is reviewed at least once daily. Logs stored only on the same server they monitor can be deleted by an attacker to cover their tracks. CWE-778 (Insufficient Logging) combined with writable log storage means a compromised host can silence its own forensic record. NIST AU-9 requires protection of audit information. S3 Object Lock (WORM) combined with KMS encryption satisfies Req 10.3 — an attacker with application-level access cannot delete an Object Lock-protected log archive.

Why this severity: Medium because logs stored in mutable, non-centralized locations can be deleted by a compromised component, eliminating forensic evidence and violating PCI-DSS 4.0 Req 10.3's tamper-evidence requirement.

PCI-DSS 4.0 Req 12.10.1 requires that an incident response plan is implemented and ready to be activated immediately upon a suspected or confirmed breach; Req 12.10 requires annual testing of the plan. Without a written plan that explicitly addresses cardholder data, a breach response becomes ad-hoc: notifications are delayed, containment steps are missed, and regulatory timelines (Stripe requires notification within 24 hours) are violated. ISO 27001:2022 A.5.26 and NIST IR-8 both require documented, tested procedures for responding to information security incidents.

Why this severity: Medium because an undocumented or incomplete incident response plan delays breach containment and regulatory notification, converting a manageable incident into a reportable PCI-DSS violation with potential fines.

PCI-DSS 4.0 Req 6.3 requires that security vulnerabilities in all system components are identified and ranked by risk; Req 6.3.3 requires that all system components are protected from known vulnerabilities by installing applicable security patches. Without a documented patch policy with SLA timeframes, a critical CVE in a production dependency may sit unaddressed for weeks while your CDE remains exposed. CWE-1357 (Reliance on Uncontrolled Component) is the mechanism by which supply-chain vulnerabilities become active exploits. NIST SI-2 and SSDF RV.1 both require a defined remediation timeline tied to severity.

Why this severity: High because a missing patch management SLA means critical CVEs remain in production components without a required remediation deadline, leaving the CDE exposed to known, publicly documented exploits.

PCI-DSS 4.0 Req 11.4 requires that internal and external penetration testing is performed at least once every 12 months; Req 11.4.1 requires that testing uses industry-accepted methodologies. An annual penetration test is the only way to verify that your security controls work under real-world attack conditions — automated scanners find known CVEs, but pentesters find business logic flaws, authentication bypasses, and chained exploits that tools miss. ISO 27001:2022 A.8.8 and NIST CA-8 both require periodic security testing. A test report older than 12 months is a direct PCI audit finding.

Why this severity: Low because penetration testing is a verification activity rather than a preventive control — its absence does not directly expose data, but it means you have no assurance that other controls are working as intended.

PCI-DSS 4.0 Req 12.8 requires that policies and procedures for managing service providers who handle cardholder data are documented and implemented; Req 12.8.4 requires that the compliance status of service providers is monitored at least annually. Every third-party service that touches your CDE — payment processor, hosting provider, monitoring platform — extends your PCI scope. If Stripe, AWS, or a logging vendor has a compliance gap you haven't verified, that gap becomes your liability. ISO 27001:2022 A.5.19 and SOC 2 CC9.2 both require third-party risk management as a formal program.

Why this severity: Low because vendor compliance gaps require both the vendor being compromised and your systems being affected — the risk is real but mediated by the vendor's own controls, placing direct impact one step removed.

PCI-DSS 4.0 Req 3.2 limits cardholder data storage to the minimum required for business or legal needs; Req 3.2.1 requires that data retention and disposal policies are defined and implemented. Data that is never deleted accumulates indefinitely — old failed transaction records, expired tokens, and support tickets create a growing pool of sensitive data that broadens breach impact year over year. GDPR Art. 5(1)(e) (storage limitation) and NIST SI-12 both require data to be disposed of when no longer needed. Without automated purging, retention policies are aspirational rather than enforced.

Why this severity: Low because data accumulation expands breach impact over time but does not itself enable unauthorized access — the risk compounds gradually rather than presenting an immediate exploitable condition.

PCI-DSS 4.0 Req 12.3 requires that a targeted risk analysis is performed for each PCI requirement that provides flexibility; Req 12.3.1 requires it to be documented and reviewed at least annually. A risk assessment is the mechanism by which you discover gaps before an auditor or attacker does — it forces enumeration of CDE assets, threat actors, and compensating controls. ISO 27001:2022 A.6.1.2 (Information Security Risk Assessment) and NIST RA-3 both require periodic, documented risk assessments as the foundation of a security program. Without one, your security posture is reactive rather than managed.

Why this severity: Info because the absence of a risk assessment is a process gap rather than a direct technical vulnerability — it does not expose data directly but means threats are unanalyzed and residual risks are unknown.