AUTOMATED No cardholder data in files, exports, or backups

Why it Matters

Payment data in files, exports, media folders, database dumps, or archived backups is easy to copy and hard to govern. These locations are frequently transferred to staging, attached to support tickets, synced to cloud storage, or accidentally exposed by webroot mistakes.

Keeping cardholder data out of files reduces breach impact and prevents old artifacts from becoming long-lived payment data liabilities.

Verification Steps

# Scan high-risk paths for card data terms and payment payloads
grep -RIE "(card_number|cvv|track|payment_payload|pan)" var/ pub/media/ export/ 2>/dev/null

# Inspect backup/export names and retention
find var pub/media -type f \( -iname "*.sql" -o -iname "*.csv" -o -iname "*.zip" \)

Remediation / Fix Guidance

1. Delete or quarantine files containing cardholder data according to an approved incident process.
2. Move exports and backups outside the public webroot.
3. Mask payment fields before exporting operational reports.
4. Apply retention policies so old exports and backups are removed automatically.
5. Add file-content scanning for high-risk paths during maintenance.

Examples

pub/media/export/orders_full.csv
# Contains card_number and cvv columns → FAIL

var/export/orders_masked.csv
# Contains payment_method and card_last4 only → PASS

References

• PCI DSS v4.0.1
• OWASP Top 10 — A02: Cryptographic Failures
• OWASP Top 10 — A05: Security Misconfiguration