Testing

PCI-DSS Testing Requirements: A Developer Checklist

HelpMeTest

HelpMeTest

— 6 min read
PCI-DSS Testing Requirements: A Developer Checklist

If your application processes, stores, or transmits cardholder data, PCI-DSS (Payment Card Industry Data Security Standard) applies to you. And unlike some compliance frameworks, PCI-DSS has explicit, mandatory testing requirements — not suggestions.

This checklist covers the testing requirements developers and engineering teams are responsible for in PCI-DSS v4.0.

What PCI-DSS Requires (Testing-Specific)

PCI-DSS v4.0 requirements most directly relevant to development and testing:

  • Requirement 6.3.2: Application security testing — all software developed for or deployed in the cardholder data environment must be tested for security vulnerabilities before deployment.
  • Requirement 6.4.3: Payment page scripts must be managed and verified as authorized.
  • Requirement 11.3: External and internal vulnerability scans quarterly minimum.
  • Requirement 11.4.1: Penetration testing at least annually and after significant infrastructure changes.
  • Requirement 11.5: Change detection mechanisms (file integrity monitoring).

The testing requirements span the full SDLC, not just a pre-release checkbox.

Pre-Deployment Application Security Testing

Requirement 6.3.2 mandates that all custom code is reviewed prior to release for common security vulnerabilities. This can be done by internal code review or automated tooling, but it must happen.

What to Test Before Deployment

Injection vulnerabilities:

  • SQL injection: Are all database queries parameterized? Use static analysis (Semgrep, SonarQube) plus dynamic testing.
  • Command injection: Does the application pass user input to system commands?
  • XSS: Is output properly encoded? Is Content-Security-Policy configured?

Authentication and session management:

  • Are session IDs regenerated after login?
  • Do sessions expire after inactivity?
  • Is there account lockout after failed attempts?
  • Are passwords hashed with strong algorithms (bcrypt, Argon2)?

Sensitive data exposure:

  • Is PANs (primary account numbers) ever logged?
  • Is cardholder data ever stored in client-side storage (localStorage, cookies)?
  • Are API responses stripping sensitive fields before returning to clients?

Access control:

  • Are all cardholder data API endpoints authenticated?
  • Is authorization checked server-side (not just in the UI)?
  • Can a user access another user's payment data by manipulating IDs?

Automated Security Testing in CI/CD

PCI-DSS doesn't mandate automation, but it's the only practical way to test every deployment. Set up:

# Example CI security checks
security-scan:
  steps:
    - name: SAST scan
      run: semgrep --config=p/pci-dss src/

    - name: Dependency vulnerability scan
      run: npm audit --audit-level=high

    - name: Secrets detection
      run: detect-secrets scan src/

    - name: DAST scan (against staging)
      run: zap-cli quick-scan --self-contained --start-options "-config api.disablekey=true" $STAGING_URL

Block deployment if high/critical vulnerabilities are found.

Vulnerability Scanning Requirements

External Vulnerability Scans (Requirement 11.3.2)

Frequency: Quarterly minimum, and after any significant network changes.

Who can do it: Only PCI-approved scanning vendors (ASVs) for external scans submitted to card brands. Use an ASV for scans used in compliance reporting.

What's scanned: All internet-facing IP addresses and domains in scope.

Pass criteria: No high-severity vulnerabilities (CVSS 4.0+). Disputed vulnerabilities require documented dispute resolution.

For development teams:

  • Know which IP ranges are in scope
  • Coordinate with security team on remediation timelines
  • Fix vulnerabilities within the timeframe defined in your vulnerability management policy

Internal Vulnerability Scans (Requirement 11.3.1)

Frequency: Quarterly minimum, and after any significant changes.

Who can do it: Internal qualified security staff or approved vendor.

Pass criteria: All high and critical vulnerabilities resolved; medium vulnerabilities addressed per policy.

For development teams:

  • Internal scans often surface development/staging systems that shouldn't be accessible from the cardholder data environment
  • Patch cycles must meet your vulnerability management policy (typically 30 days for critical)

Penetration Testing Requirements

Annual Penetration Test (Requirement 11.4.1)

Frequency: At least annually and after significant changes to infrastructure or applications.

Scope: Both network-layer and application-layer testing. Must cover the entire CDE (cardholder data environment) perimeter and critical systems.

Who can do it: Internal qualified security personnel or qualified external third party. Tester must be independent of the tested environment.

What's tested:

  • Network segmentation validation
  • Application vulnerabilities (OWASP Top 10 and beyond)
  • Authentication and session management
  • Business logic vulnerabilities
  • Social engineering (depending on scope)

What developers need to provide:

  • Application architecture documentation
  • API documentation
  • Test credentials for each user role
  • Access to source code (for white-box testing)

Penetration Testing After Significant Changes

"Significant changes" includes:

  • New applications or major features handling cardholder data
  • Infrastructure changes in the CDE
  • Changes to network segmentation
  • New payment integrations

For development teams: have a clear definition of what constitutes a "significant change" in your context. A new payment flow is significant. A CSS update is not.

Segmentation Testing

PCI-DSS allows reducing scope by network segmentation — keeping systems that handle cardholder data on isolated network segments. But segmentation must be tested.

Requirement 11.4.5: If network segmentation is used to reduce scope, penetration testing of segmentation controls must occur at least every six months.

What to verify:

  • Systems outside the CDE cannot reach systems inside the CDE on any port
  • CDE systems cannot initiate connections to out-of-scope systems
  • Development/test environments are not connected to the CDE

Automated segmentation test:

# From an out-of-scope host, verify CDE systems are unreachable
nmap -p 1-65535 10.0.1.0/24  <span class="hljs-comment"># CDE subnet
<span class="hljs-comment"># All ports should be filtered/closed from outside CDE

File Integrity Monitoring (Requirement 11.5)

Changes to critical system files must be detected and alerted. This is technical but relevant to deployment processes.

What must be monitored:

  • System executables, libraries, and configuration files
  • Application code in production
  • Security-relevant files (password files, audit log configurations)

For development teams:

  • Deployments should go through a controlled process that's logged
  • Ad-hoc file modifications on production systems should trigger alerts
  • FIM tools: Tripwire, AIDE, Wazuh, or cloud-native equivalents

Payment Page Security (Requirement 6.4)

PCI-DSS v4.0 added specific requirements for payment pages — particularly e-commerce checkout pages:

Requirement 6.4.3: All payment page scripts must be:

  • Authorized and inventoried
  • Verified that script integrity is maintained
  • Confirmed as necessary

This targets Magecart and similar supply chain attacks that inject skimmers into payment pages.

What to test:

  • Enumerate all scripts loaded on payment pages
  • Verify each script has Subresource Integrity (SRI) hashes
  • Test that script-src CSP prevents unauthorized script execution
  • Verify third-party scripts (analytics, chat, etc.) can't access payment form fields

Automated payment page script audit:

// Check all script tags on payment page
const scripts = document.querySelectorAll('script[src]');
scripts.forEach(script => {
  if (!script.integrity) {
    console.error(`Script missing SRI: ${script.src}`);
  }
});

Code Review Requirements

PCI-DSS v4.0 Requirement 6.2.4 requires that software development practices prevent common software attacks. This includes:

  • Training developers on secure coding for the languages they use
  • Defined software development coding techniques to prevent vulnerabilities

For testing purposes:

  • Secure code review should be part of every PR process
  • Automated SAST tools catch the majority of common vulnerabilities
  • Manual review focuses on business logic and architecture-level issues

PCI-DSS Testing Checklist

Use this for each release involving cardholder data environment:

Before every deployment:

  • SAST scan run; critical/high findings resolved
  • Dependency vulnerability scan; no high/critical vulnerabilities
  • Secrets scan confirms no credentials in code
  • All cardholder data flows tested for proper encryption
  • New API endpoints verified for authentication and authorization
  • Payment page scripts inventoried and SRI validated

Quarterly:

  • External vulnerability scan (ASV if submitting to card brands)
  • Internal vulnerability scan
  • Patch status review (all critical patches applied within policy period)

Annually:

  • Full penetration test (network + application layer)
  • Segmentation test if segmentation used to reduce scope
  • Developer security training completion verified

After significant changes:

  • Penetration test (or scope reassessment with security team)
  • Updated system inventory and data flow diagrams
  • Risk assessment for new components

Log and Monitoring Testing

Requirement 10 covers logging and monitoring. For developers:

What logs must exist for cardholder data access:

  • User access to system components (successful and failed)
  • Administrative actions
  • Access to audit logs
  • Invalid logical access attempts
  • Use of and changes to identification and authentication mechanisms
  • Initialization, stopping, and pausing of audit logs
  • Creation and deletion of system-level objects

Test log completeness:

  • Perform each type of action and verify the log entry
  • Test that failed access attempts are logged
  • Verify log entries contain required fields (timestamp, user, event type, record affected)
  • Confirm logs cannot be modified by application-level users

Conclusion

PCI-DSS testing requirements are extensive but well-defined. The framework tells you exactly what to test — the challenge is building processes that make compliance continuous rather than point-in-time.

The highest-leverage investment for development teams is integrating security testing into CI/CD. SAST scanning, dependency checking, and secrets detection run automatically on every build. Dynamic testing runs against staging before production deployment. What used to be a quarterly compliance exercise becomes a continuous background process.

That shift — from compliance as event to compliance as continuous practice — is what separates teams that pass assessments to teams that genuinely maintain secure payment applications.

For automated testing of your payment application flows and security controls, HelpMeTest supports continuous E2E test execution in CI/CD pipelines.

Read more