PCI-DSS encryption documented with AES-256 minimum

PCI-DSS 4.0 Req-3.5 requires that primary account numbers (PANs) stored anywhere be protected with strong cryptography. Without documentation stating the algorithm and key length, a QSA cannot verify compliance — and organizations that delegate card processing to Stripe must still document that delegation explicitly with the processor's PCI certification level. NIST SC-13 requires that cryptographic module usage be documented and approved. A vague security policy that says "we use encryption" fails both standards: the specific algorithm, key length, and applicable data scope must be named. FFIEC examiners reviewing a financial institution's IT controls will request this documentation as a baseline artifact.

Create a docs/pci-dss-compliance.md or add a PCI section to SECURITY.md. The document must name the algorithm, key length, and the scope of cardholder data it covers:

# PCI-DSS 4.0 Encryption Compliance

## Cardholder Data Scope
- Card processing: Delegated to Stripe (PCI DSS Level 1 Service Provider)
- Local storage: None — no PANs, CVVs, or full card data stored in our database
- Reference: Stripe PCI Attestation of Compliance available at stripe.com/docs/security

## Encryption (non-card sensitive data)
- Algorithm: AES-256-GCM (NIST SP 800-38D)
- Key length: 256 bits
- Key management: AWS KMS (automatic annual rotation)
- Data protected: SSNs, account numbers, bank routing numbers

## Last reviewed: 2026-03-01
## Next review: 2027-03-01

If card data is processed directly (not delegated), pursue formal PCI DSS Level 1 or 2 assessment — documentation alone is insufficient.

• ID: finserv-encryption.pci-alignment.pci-dss-aes256-documented
• Severity: medium
• What to look for: Count all PCI-DSS compliance documents and security policies. Quote the actual encryption algorithm and key length specified. Verify documentation explicitly states AES-256 or stronger for cardholder data. A vague mention of "encryption" without algorithm or key length does not count as pass.
• Pass criteria: At least 1 PCI-DSS compliance document exists explicitly stating AES-256 (or stronger) for cardholder data encryption. If no card data is stored locally, at least 1 document explicitly states this with processor reference. Report the count even on pass (e.g., "1 PCI document found stating AES-256-GCM for cardholder data, Stripe PCI Level 1 certified").
• Fail criteria: No PCI-DSS documentation (0 documents), or documentation states weaker than AES-256, or vague encryption claims without algorithm/key length.
• Skip (N/A) when: Project uses a PCI-compliant processor and does not store or process card data directly — cite the actual processor and PCI level found.
• Detail on fail: "0 PCI-DSS documents found" or "Security policy mentions 'encryption' but 0 references to specific algorithm or key length"
• Remediation:
  • Create PCI-DSS compliance documentation:

    # PCI-DSS Encryption Compliance
    ## Data Protection
    - Cardholder Data Storage: N/A (processed via Stripe)
    - OR
    - Encryption Algorithm: AES-256-GCM
    - Key Management: AWS KMS (automated rotation)
    - Implementation: Database-level encryption (TDE) + application-level field encryption
    
    ## Compliance Status
    - P2PE Validation: [Provider name/date]
    - Self-Assessment: [Yes/No and date]
    - Last audit: [date]
    

  • If handling cards directly: pursue PCI-DSS Level 1 or 2 certification.