PCI-DSS Testing: What Developers Need to Know

Payment Card Industry Data Security Standard (PCI-DSS) is the compliance framework that governs how organizations handle cardholder data. Version 4.0, which became mandatory in March 2024, brings significant changes that directly affect how development teams write, test, and deploy code. If your application touches payment card data — even indirectly — understanding which requirements apply to you is not optional.

This guide focuses on the requirements most relevant to engineering teams: Requirements 6, 10, and 11, plus the testing obligations that flow from them.

Why PCI-DSS Is a Developer Problem

Security and compliance teams traditionally owned PCI-DSS. That's changed. Requirement 6 in version 4.0 explicitly calls out software development lifecycle (SDLC) practices, developer training, and code review as in-scope controls. If your team writes code that processes, stores, or transmits cardholder data — or code that runs in the same environment as that data — you are now part of the audit surface.

The auditors will ask for evidence. That evidence comes from your tests, your CI/CD logs, and your code review records. If you don't generate it systematically, you'll be scrambling to reconstruct it before each assessment.

Requirement 6: Secure Development Practices

6.2 — Bespoke and Custom Software

Requirement 6.2 mandates that all bespoke and custom software developed for or by the organization follows a secure SDLC. Specifically, 6.2.4 requires that all software development personnel are trained at least once every 12 months in secure coding techniques, including how to avoid common vulnerabilities.

More operationally relevant: 6.3.2 requires organizations to maintain an inventory of bespoke and custom software. This sounds administrative, but auditors use it to bound the scope of testing — if your application isn't in the inventory, your tests for it aren't counted as evidence.

6.4 — Web-Facing Applications

For public-facing web applications, 6.4.1 requires either:

1. A Web Application Firewall (WAF) deployed in front of the application, or
2. An automated technical solution that continually detects and prevents web-based attacks

6.4.2 specifies that an automated technical solution must be actively running and generating alerts for the cardholder data environment. A WAF in detection-only mode does not satisfy this requirement.

What This Means for Your Test Suite

Your code review process needs to explicitly check for OWASP Top 10 vulnerabilities. In practice, this means integrating a SAST tool (Semgrep, Checkmarx, Veracode, or open-source alternatives like Bandit for Python or SpotBugs for Java) into your pull request workflow.

The auditor will ask: "How do you know your developers aren't introducing SQL injection or XSS into cardholder data flows?" Your answer needs to be a tool, a policy, and evidence — not a statement of intent.

# Example GitHub Actions step for SAST in a PCI-scoped repo
- name: Run Semgrep SAST
  uses: returntocorp/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/sql-injection
      p/xss
  env:
    SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

Keep the scan results as artifacts. Auditors need to see that findings were triaged and remediated, not just that the scan ran.

Requirement 10: Audit Logs

Requirement 10 mandates logging of all access to system components and cardholder data. From a testing perspective, what matters is that your log generation is correct and your log integrity is protected.

10.3 — Log Protection

Logs must be protected from destruction and unauthorized modification. Requirement 10.3.3 requires that log files are promptly backed up to a centralized, difficult-to-modify log server or media.

Testing log integrity means verifying:

• Logs are written atomically and cannot be truncated mid-entry
• Log deletion or modification triggers an alert
• Log entries contain the required fields: date, time, user identity, event type, and affected resource

Write integration tests that simulate log-generating events and then assert on what was written. A test that inserts a record and verifies the corresponding audit log entry was created is worth far more to an auditor than a configuration document.

10.7 — Failures of Critical Security Controls

New in PCI-DSS 4.0: 10.7.2 requires that failures of critical security controls are detected, alerted, and addressed promptly. This extends testing requirements into your monitoring layer. You need tests that verify that when logging fails (disk full, network partition to log server), an alert fires.

Requirement 11: Testing Security Systems

Requirement 11 is the most testing-intensive section of PCI-DSS. It covers vulnerability scanning, penetration testing, and intrusion detection.

11.3 — External and Internal Vulnerability Scanning

11.3.1 requires quarterly internal vulnerability scans and rescans after significant changes. 11.3.2 requires quarterly external scans by an Approved Scanning Vendor (ASV).

The phrase "significant changes" is important. Your change management process needs a definition of what constitutes a significant change in the cardholder data environment. Adding a new API endpoint that touches payment data? That's a significant change. Updating a CSS file? Probably not. But you need a written policy, not a gut feel.

For internal scanning, tools like OpenVAS, Nessus, or Qualys can be run on a schedule against your CDE. The scan reports — including authenticated and unauthenticated scan results — become audit evidence.

11.4 — Penetration Testing

Penetration testing requirements in PCI-DSS 4.0 became significantly more prescriptive. 11.4.1 now requires a penetration testing methodology that includes:

• Industry-accepted approaches (PTES, OWASP Testing Guide, NIST SP 800-115)
• Coverage of the entire CDE perimeter and critical systems
• Testing from both inside and outside the network
• Validation of network segmentation controls

11.4.3 requires external penetration testing at least once every 12 months and after any significant change. 11.4.4 requires internal penetration testing on the same schedule.

Penetration tests must be performed by qualified internal resources or a qualified third party. If done internally, the tester must be organizationally independent from the system being tested — a developer cannot pen test their own code.

The pen test report must document:

• Scope and methodology
• Results of testing, including findings and their risk ratings
• Remediation steps for exploitable vulnerabilities
• Retest results confirming remediation

11.5 — Network Intrusion Detection

11.5.1 requires intrusion detection and/or prevention systems to monitor all traffic at the CDE perimeter and at critical points within the CDE. Testing these systems means verifying that they actually alert on known attack patterns — not just that they're installed.

Red team exercises that simulate known attack patterns (while coordinated with your security team to avoid disruption) are the right way to test IDS/IPS effectiveness. At minimum, run test traffic matching known signatures and verify alerts fire.

Integrating PCI-DSS Testing into CI/CD

The goal is to shift compliance testing left — catching issues before they reach the cardholder data environment.

Pipeline Gates

Structure your pipeline so that PCI-scoped changes cannot deploy without passing security gates:

PR opened
  → SAST scan (Semgrep, Checkmarx)
  → Dependency vulnerability scan (OWASP Dependency-Check, Snyk)
  → Secret detection (truffleHog, git-secrets)
  → Code review (required approval from security-trained reviewer)

Merge to main
  → DAST scan against staging environment (OWASP ZAP)
  → Container image scan (Trivy)

Deploy to production
  → Smoke tests against payment flows
  → Log integrity verification
  → Alerting verification

Each of these produces an artifact. Store them. Map them to specific PCI-DSS requirements in your evidence repository.

Evidence Collection

Auditors work from evidence. Build your CI/CD pipelines to produce structured evidence automatically:

• SAST results in SARIF format, archived as build artifacts
• Dependency scan reports in CycloneDX or SPDX format
• Deployment records showing who approved what, when
• Test results as JUnit XML with timestamps

If you're using GitHub Actions, the upload-artifact step makes this straightforward. If you're on Jenkins, archive artifacts in your pipeline definition. The point is: every meaningful security check generates a dated, immutable record.

Change Management Integration

PCI-DSS 6.5 requires that all security patches and software changes are managed through a defined change control process. Your CI/CD pipeline is part of that process. Pull request approvals, automated test gates, and deployment approval records are all evidence of a functioning change management process.

Document which tests correspond to which PCI-DSS requirements. A simple mapping table in your wiki is sufficient, but it needs to exist and be maintained.

Common Gaps Teams Discover During Assessment

Untested segmentation controls. Your network diagrams show that the CDE is isolated, but nobody has verified that a compromised system outside the CDE cannot reach payment data. Segmentation penetration testing is required by 11.4.5 and is often underdone.

Missing rescans after changes. The quarterly scan cadence is well understood. The "rescan after significant changes" requirement is frequently missed. Add a checklist item to your change management process: does this change require a rescan?

Log testing in isolation. Teams verify that the application writes logs but don't test the downstream pipeline — that logs arrive at the SIEM, that log tampering triggers an alert, that log retention policies are enforced. Test the full chain.

Developer training records. Requirement 6.2 mandates training records. A verbal briefing doesn't count. Use a platform that generates completion records, or run training through your LMS and keep the reports.

Where to Start

If you're not currently generating any compliance evidence from your CI/CD pipelines, start with two things:

1. Add a SAST scan to your pull request workflow. Pick one tool, configure it for OWASP Top 10, and require that it passes before merge. Archive the results.
2. Write tests for your audit log output. Pick the three most critical events in your payment flow and write tests that execute those events and assert on the log entries produced.

These two steps give you the start of an evidence trail and immediately improve your security posture. From there, expand systematically through Requirements 6, 10, and 11, mapping each control to a test or automated check that produces evidence.

PCI-DSS compliance is not a once-a-year audit event. The 4.0 requirement for continuous monitoring and automated testing reflects that reality. Teams that treat compliance as a continuous engineering practice — not a periodic review — consistently pass assessments with fewer findings and less scrambling.