PCI-DSS Compliance Checklist for Product Teams
PCI-DSS v4.0 applies to any product that stores, processes, or transmits cardholder data. Compliance is not optional -- it is mandated by payment card brands (Visa, Mastercard) and enforced through financial penalties, increased processing fees, and ultimately losing the ability to accept card payments.
This checklist translates PCI-DSS v4.0 requirements into actionable product team tasks, focusing on the requirements most relevant to software product teams.
Template sections
5 sections covering the complete compliance workflow.
Cardholder Data Handling (Req 3-4)
PCI-DSS Requirements 3 and 4 govern how cardholder data is stored, processed, and transmitted. The simplest compliance strategy is to minimize cardholder data exposure: use tokenization (Stripe, Braintree) so your servers never touch raw card numbers. If you must handle cardholder data, encryption and access restrictions are mandatory.
Tokenization strategy: all card data handled by Stripe Elements (client-side). Our servers receive only a Stripe token, never the card number. PAN is never stored in our database. Card display: last 4 digits only, retrieved from Stripe API. Expiration date: stored for recurring billing. CVV: never stored anywhere (PCI-DSS explicitly prohibits post-authorization CVV storage).
Tips
- Use tokenization (Stripe Elements, Braintree Drop-in) to keep cardholder data off your servers
- Never store CVV/CVC after authorization - this is explicitly prohibited by PCI-DSS
- If you must store PAN, use AES-256 encryption with separate key management
- Display only last 4 digits of card numbers in all UI surfaces
Network Security (Req 1-2)
PCI-DSS Requirements 1 and 2 require network segmentation and secure configurations. Isolate the cardholder data environment (CDE) from the rest of your infrastructure. Default passwords must be changed, unnecessary services disabled, and network access restricted to only what is required for business function.
Network segmentation: payment processing microservice in isolated VPC subnet. Only API gateway can reach payment service (port 443 only). Payment service can reach Stripe API (outbound 443) and payment database (port 5432). No other services can access the payment subnet. Security groups reviewed quarterly. Default credentials changed on all network devices, databases, and application servers before deployment.
Tips
- Isolate payment processing in a separate VPC subnet with strict security groups
- Document all network flows to and from the cardholder data environment
- Review security group rules quarterly and remove unused rules
- Automate default credential checks in your deployment pipeline
Vulnerability Management (Req 5-6)
PCI-DSS Requirements 5 and 6 require vulnerability management and secure development. This includes antivirus/anti-malware, regular patching, secure coding practices, and vulnerability scanning. Product teams must integrate these into their development lifecycle, not treat them as post-deployment activities.
Secure development: OWASP Top 10 training for all developers (annually). Code review required for all changes touching payment logic (documented in PR comments). SAST scan (Snyk) runs on every PR targeting payment service. DAST scan (OWASP ZAP) runs weekly against staging payment endpoints. Dependency vulnerabilities: Snyk monitors payment service dependencies, critical vulnerabilities patched within 7 days. Quarterly ASV (Approved Scanning Vendor) external vulnerability scan.
Tips
- Run SAST on every PR touching payment code and DAST weekly against staging
- Patch critical vulnerabilities in payment services within 7 days
- Schedule quarterly ASV scans and track remediation of findings
- Require OWASP Top 10 training for all developers working on payment features
Access Control (Req 7-8)
PCI-DSS Requirements 7 and 8 require restricting access to cardholder data by business need-to-know and identifying users with unique IDs. No shared accounts, no generic admin credentials, and multi-factor authentication for all administrative access to the CDE.
Access policy: cardholder data accessible only to payment service (programmatic) and 3 authorized support agents (break-glass, logged). MFA required for all access to payment infrastructure (AWS MFA for console, SSH key + TOTP for servers). No shared accounts anywhere in the CDE. Quarterly access review: verify all accounts with CDE access are still authorized. Terminated employee access revoked within 24 hours.
Tips
- Implement MFA for all human access to the cardholder data environment
- Eliminate shared accounts - every person gets a unique credential
- Review CDE access quarterly and revoke unnecessary access promptly
- Automate access revocation tied to HR termination process
Monitoring and Testing (Req 10-11)
PCI-DSS Requirements 10 and 11 require logging, monitoring, and regular testing. All access to cardholder data must be logged. Logs must be reviewed daily. Penetration testing must be performed annually (and after significant changes). File integrity monitoring must detect unauthorized changes to critical systems.
Logging: all access to payment database logged with user ID, timestamp, query type. All API requests to payment service logged with source IP, endpoint, and response code. Log review: automated alerting for anomalous patterns (unusual query volumes, access from new IPs, after-hours access). Daily manual review of flagged events. Penetration test: annual test by qualified assessor, plus after any significant architecture change to payment infrastructure. FIM: file integrity monitoring on payment service binaries and configuration files.
Tips
- Automate log review with alerting for anomalous access patterns
- Schedule annual penetration test and budget for remediation afterward
- Implement file integrity monitoring on all CDE system binaries and configs
- Retain logs for at least 1 year with 3 months immediately accessible
Copy-paste template
# PCI-DSS v4.0 Compliance Checklist — Product Team ## Cardholder Data (Req 3-4) - [ ] Tokenization implemented (no raw card data on our servers) - [ ] CVV never stored post-authorization - [ ] PAN displayed as last 4 only - [ ] Encryption: AES-256 at rest, TLS 1.2+ in transit ## Network Security (Req 1-2) - [ ] CDE isolated in separate network segment - [ ] All network flows documented - [ ] Default credentials changed - [ ] Security groups reviewed quarterly ## Vulnerability Management (Req 5-6) - [ ] SAST on every payment PR - [ ] DAST weekly against staging - [ ] Critical vulns patched within 7 days - [ ] Quarterly ASV scan ## Access Control (Req 7-8) - [ ] MFA for all CDE access - [ ] No shared accounts - [ ] Quarterly access review ## Monitoring (Req 10-11) - [ ] All CDE access logged - [ ] Automated log review and alerting - [ ] Annual penetration test - [ ] File integrity monitoring active
Frequently asked questions
Generate instead of filling in templates
Connect your tools, and Vantage generates the content using real product data. Free to start.
Free to start. No credit card required.