PCI DSS Compliance

Why Engineers Should Care

PCI DSS (Payment Card Industry Data Security Standard) exists because credit card breaches are expensive for everyone. If your company processes, stores, or transmits cardholder data, you are subject to PCI DSS. The penalties for non-compliance after a breach can exceed $500,000, plus the cost of forensic investigation, card replacement, and customer notification. The engineering goal is simple: minimize the systems that touch card data so that the compliance scope stays as small as possible.

The Scope Reduction Strategy

The single most impactful engineering decision for PCI compliance is not handling card data yourself. Use a payment processor's hosted payment page (Stripe Elements, Braintree Drop-in UI, Adyen Web Components) so that card numbers never touch your servers.

If cards must be processed server-side, use tokenization: the payment processor returns a non-sensitive token that represents the card. Your database stores tokens, not PANs (Primary Account Numbers). This reduces your SAQ level from D (250+ controls) to A (22 controls), which is a massive reduction in audit scope and engineering effort.

Network Segmentation

For systems that must handle cardholder data, network segmentation is the primary architectural control. The Cardholder Data Environment (CDE) must be isolated from the rest of your network:

• Dedicated VPC/subnet - CDE systems live in a separate network segment with strict ingress and egress rules.
• Firewall rules - Only explicitly authorized traffic flows between the CDE and other segments. Default deny everything.
• Micro-segmentation - Within the CDE, further isolate components. The payment processing service should not share a network segment with the reporting dashboard.
• Jump boxes - Administrative access to CDE systems goes through a hardened bastion host with MFA and session recording.

SAQ Levels Explained

Your Self-Assessment Questionnaire level determines how many controls you must validate:

The engineering objective is to architect your way to the lowest SAQ level possible. Every system removed from card data flow removes controls from your audit scope.

PCI DSS v4.0 Changes

Version 4.0 (mandatory by March 2025) introduces the customized approach: instead of following prescriptive controls, you can define custom controls that meet the same security objective. This gives engineering teams flexibility to use modern architectures (serverless, containers, zero-trust) that do not map cleanly to the original prescriptive requirements. That said, customized validation requires more documentation and auditor expertise, so it is best suited for mature security organizations.

Encryption Requirements

• In transit - TLS 1.2+ for all cardholder data transmission. TLS 1.0 and 1.1 are explicitly prohibited.
• At rest - AES-256 or equivalent for stored cardholder data. Key management must follow documented procedures with split knowledge and dual control.
• Key rotation - Cryptographic keys must be rotated at least annually, with documented key management lifecycle procedures.