PCI DSS v4 Engineering Controls

PCI DSS v4.0 (effective March 2025) is the security standard for any organization that stores, processes, or transmits payment card data. The goal is simple: protect cardholder data. The implementation is rigorous — 12 requirements spanning network security, access control, monitoring, and testing.

---

Scope Reduction

The most important PCI strategy: Reduce scope.

Full Scope (worst case):
  Your servers handle raw card numbers
  Your ENTIRE infrastructure is in scope
  Every server, network, process, person → assessed
  Cost: $$$$$, 200+ controls

Reduced Scope (tokenization):
  Payment processor handles raw cards
  You only store tokens (not card numbers)
  Only the token integration point is in scope
  Cost: $$, focused controls

Minimal Scope (redirect):
  Customer redirected to payment processor's page
  No card data touches your systems
  Only the redirect mechanism is in scope  
  Cost: $, minimal controls

Strategy:
  1. Never store card numbers if possible
  2. Use a payment processor (Stripe, Braintree)
  3. Use tokenization for recurring billing
  4. document your Cardholder Data Environment (CDE)

---

Network Segmentation

Internet
  │
  ▼
┌──────────────┐
│   DMZ Zone   │ ← WAF, Load Balancer
│              │
└──────┬───────┘
       │  (Firewall: only HTTPS)
       ▼
┌──────────────┐
│  App Zone    │ ← Web/API servers
│              │ ← NO card data stored here
└──────┬───────┘
       │  (Firewall: only API calls)
       ▼
┌──────────────┐
│  CDE Zone    │ ← Payment processing servers
│  (Cardholder │ ← Tokenization service
│   Data Env)  │ ← Encrypted card vault
│              │ ← MOST RESTRICTED ACCESS
└──────┬───────┘
       │  (Firewall: only DB protocol)
       ▼
┌──────────────┐
│  Data Zone   │ ← Encrypted database
│              │ ← Key management (HSM)
└──────────────┘

Rules:
  ☐ CDE isolated in its own network segment
  ☐ Firewalls between every zone
  ☐ Default deny, explicit allow
  ☐ No direct internet access to CDE
  ☐ Quarterly penetration testing of segmentation

---

Key Management

class PCIKeyManagement:
    """Cryptographic key management for PCI compliance."""
    
    requirements = {
        "key_generation": {
            "method": "HSM or secure random number generator",
            "strength": "AES-256 minimum for data at rest",
            "ceremony": "Dual control key generation (two custodians)",
        },
        "key_storage": {
            "method": "Hardware Security Module (HSM) or encrypted key store",
            "access": "Split knowledge — no single person has full key",
            "backup": "Encrypted key backup in separate location",
        },
        "key_rotation": {
            "frequency": "Annual rotation (or on compromise)",
            "method": "Re-encrypt data with new key",
            "old_keys": "Retain for decryption of old data, then destroy",
        },
        "key_destruction": {
            "method": "Cryptographic erasure or physical destruction",
            "evidence": "Destruction certificate, audit log",
        },
    }

---

Anti-Patterns

Anti-Pattern	Consequence	Fix
Store raw card numbers	Maximum PCI scope, maximum risk	Tokenize via payment processor
Flat network (no segmentation)	Entire infrastructure in scope	Network segmentation with firewalls
Log card numbers	PAN in logs = massive violation	Log masking, never log full PAN
Shared admin accounts	Cannot trace access to individuals	Unique accounts, MFA, access logging
Annual assessment only	364 days of unmonitored drift	Continuous compliance monitoring

The best PCI strategy is to reduce your Cardholder Data Environment to the smallest possible footprint. Use tokenization, use a payment processor, and never store what you do not need to store. The less card data you touch, the fewer controls you need.