Generate a PCI-DSS v4.0 code review checklist for payment processing applications with specific technical control checks.
You are a PCI-DSS qualified security assessor. Generate a code review checklist for payment applications. ## Application Details - **Application**: [APP e.g. payment gateway / e-commerce checkout / POS terminal software] - **Language/Framework**: [FRAMEWORK e.g. Java Spring / .NET / Node.js / Python] - **Payment Processor**: [PROCESSOR e.g. Stripe / Adyen / PayPal / direct bank API] - **Cardholder Data Environment**: [CDE e.g. tokenization only / full PAN handling / card-present] - **PCI-DSS Level**: [LEVEL e.g. Level 1 / Level 2 / Level 3 / Level 4] ## Checklist by PCI-DSS v4.0 Requirement ### Req 3: Protect Stored Account Data - [ ] PAN is never stored in plaintext (database, logs, files, cache) - [ ] If PAN stored: AES-256 encryption with proper key management - [ ] PAN masking: show only first 6 and last 4 digits - [ ] SAD (CVV, PIN, magnetic stripe) never stored post-authorization - [ ] Tokenization implementation review - [ ] Encryption key rotation mechanism - [ ] Secure key storage (HSM or key vault) - [ ] Data retention policy enforced in code - [ ] Search functionality does not expose full PAN - **Code patterns to check**: database queries, log statements, cache writes, file operations, API responses, error messages ### Req 4: Protect Data in Transit - [ ] TLS 1.2+ enforced on all cardholder data transmissions - [ ] Strong cipher suites configured (no RC4, DES, export ciphers) - [ ] Certificate validation not disabled in code - [ ] No PAN in URLs (query strings, path parameters) - [ ] Email/messaging never contains PAN - [ ] Internal service-to-service encryption for CDE traffic - **Code patterns to check**: HTTP client configs, TLS settings, URL construction, email/notification code ### Req 6: Secure Software Development - [ ] Input validation on all payment form fields - [ ] Output encoding to prevent XSS - [ ] Parameterized queries (no SQL string concatenation) - [ ] CSRF tokens on payment forms - [ ] Authentication on all payment API endpoints - [ ] Authorization checks before payment operations - [ ] Error handling does not expose payment details - [ ] Secure coding training verification for developers - [ ] Vulnerability scanning results reviewed - [ ] Code review by someone other than author ### Req 7: Restrict Access by Business Need - [ ] Role-based access control for payment functions - [ ] Separate roles for refunds, voids, adjustments - [ ] Admin functions require additional authentication - [ ] Audit trail for all payment operations - [ ] Access reviews documented ### Req 8: Identify Users and Authenticate Access - [ ] Unique user IDs for all payment system access - [ ] MFA for administrative access to CDE - [ ] Password complexity enforced (12+ chars minimum) - [ ] Account lockout after 10 failed attempts - [ ] Session timeout after 15 minutes of inactivity - [ ] Secure password change mechanism ### Req 10: Log and Monitor - [ ] All access to cardholder data logged - [ ] All administrative actions logged - [ ] Log entries include: user, event type, date/time, success/failure, affected data - [ ] Logs protected from tampering - [ ] Logs do not contain full PAN - [ ] Log retention: 12 months minimum, 3 months immediately available ### Req 11: Test Security Regularly - [ ] Quarterly vulnerability scans passing - [ ] Annual penetration test findings addressed - [ ] File integrity monitoring on payment code - [ ] Change detection on critical system files Provide specific code examples for [FRAMEWORK] to demonstrate compliant and non-compliant patterns.
Free to copy and use. Compatible with Claude 4 Opus, GPT-5, Gemini 2.5 Pro.
Specify your payment application details and framework. Work through each requirement checking your codebase. Document findings with file:line references. Prioritize Req 3 and 4 findings first.
Initial release
Sign in and download this prompt to leave a review.