Most development teams encounter PCI-DSS requirements for the first time during a compliance audit. By then, the expensive work is already done: systems built without security controls, test environments containing real card data, third-party dependencies with untracked vulnerabilities. Remediating compliance gaps after a system is built means rewriting authentication flows, adding audit logging to production infrastructure, and removing card data from test environments under deadline pressure. It costs far more than building correctly from the start.
This guide covers what PCI-DSS v4.0 requires of software development teams: how to scope the Cardholder Data Environment, the Requirement 6 controls that govern your SDLC, how to integrate compliance into a CI/CD pipeline, and the five mistakes that cause audit failures.
What Is PCI-DSS?
PCI-DSS (Payment Card Industry Data Security Standard) is a set of security requirements for organizations that store, process, or transmit cardholder data. It is maintained by the PCI Security Standards Council (PCI SSC), a body founded by Visa, Mastercard, American Express, Discover, and JCB. Compliance is contractually required by card networks for any entity handling card payments. Non-compliance can result in fines, increased transaction fees, or suspension of card processing privileges. According to Verizon's Payment Security Report, only 43% of organizations maintain full PCI-DSS compliance year-round.
PCI-DSS v4.0.1 is the current version. PCI-DSS v4.0 was released in March 2022. v3.2.1 was retired on March 31, 2024. PCI-DSS v4.0.1, a maintenance release with minor corrections, was published in June 2024. All references in this guide are to v4.0.1. Organizations still operating against v3.2.1 are non-compliant.
Scoping the Cardholder Data Environment (CDE)
Before assessing which requirements apply, the Cardholder Data Environment must be scoped correctly. The CDE consists of system components that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD); system components that connect to or could impact the security of those systems; and the network segments on which those components reside.
CDE scope directly controls compliance burden. A development team building a payment flow that touches the CDE is subject to the full set of applicable PCI-DSS technical requirements. A team whose application redirects to a payment processor's hosted payment page, or uses a tokenization service that removes card data from their environment, may qualify for a reduced-scope Self-Assessment Questionnaire rather than a full Report on Compliance.
The first question for any new system or feature involving payments is: does this place cardholder data within our environment, or does it flow through systems we control? That answer determines CDE scope, and scope determines the development requirements that apply. Reducing CDE scope through tokenization, hosted payment pages, or network segmentation is a legitimate compliance strategy, not a shortcut.
Which PCI-DSS Requirements Apply to Development Teams?
PCI-DSS v4.0 has 12 top-level requirements. Four have direct relevance to software development teams:
- Requirement 3: Protect Stored Account Data. Governs what cardholder data can be stored, how it must be encrypted, and when it must be purged. Development teams are responsible for ensuring applications do not log card data in plain text, that stored data uses approved encryption, and that retention and deletion logic is correctly implemented.
- Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission. Requires TLS 1.2 or higher on all transmissions of cardholder data. Development teams must confirm that all API endpoints and web forms handling card data use current, approved cryptographic protocols and that deprecated protocols (SSL, TLS 1.0, TLS 1.1) are not in use.
- Requirement 6: Develop and Maintain Secure Systems and Software. The primary development requirement. Covers secure coding standards, code review, vulnerability management, environment separation, and change management. Full breakdown in the next section.
- Requirement 11: Test Security of Systems and Networks Regularly. Requires internal vulnerability scanning (minimum quarterly), penetration testing (minimum annually), and application security testing for public-facing systems. Development teams are responsible for remediating findings within PCI-DSS timeframes by severity.
Requirement 6 in Detail
Requirement 6 is the section of PCI-DSS v4.0 that directly governs software development practices. These are the controls most relevant to engineering teams, organized by sub-group:
Secure development practices (6.2.x)
6.2.2: Developer security training All personnel developing bespoke or custom software must receive training on secure development techniques at least once every 12 months. Training must be relevant to the technologies used and must cover current security threats. Completion must be documented and retainable on request. Code reviews and general security awareness sessions do not satisfy this requirement on their own.
6.2.3: Pre-production code review All bespoke and custom software must be reviewed for potential coding vulnerabilities before release to production. Reviews can be performed by a technically qualified internal reviewer, an external security firm, or automated scanning tools, provided the tooling covers the vulnerability categories listed in 6.2.4. Review results and remediation must be documented.
6.2.4: Secure coding techniques Software engineering techniques must be defined and in use to prevent or mitigate common attacks. PCI-DSS v4.0 lists these explicitly: injection attacks (SQL, LDAP, XPath, OS command), cross-site scripting, broken authentication and session management, insecure cryptographic implementations, cross-site request forgery, and insecure deserialization. These categories align directly with the OWASP Top 10.
Vulnerability management (6.3.x)
6.3.1: Vulnerability identification and ranking Security vulnerabilities must be identified through recognized channels such as NIST NVD or vendor security advisories, and ranked using an industry-recognized classification such as CVSS scores. High and critical vulnerabilities must be addressed on a defined timeline tied to severity; Requirement 6.3.3 mandates critical patches within one month of release.
6.3.3: Patching All system components must be protected against known vulnerabilities by installing applicable security patches. Critical-severity patches must be installed within one month of release. Requirement 6.3.2 also calls for a maintained inventory of software components, including third-party libraries and open-source dependencies, to enable systematic patching across the stack.
Application security for public-facing systems (6.4.x)
6.4.1: Public-facing web application reviews All public-facing web applications must be reviewed for new threats and vulnerabilities at least once every 12 months or after any significant change. The review must be performed by a qualified organization using manual review techniques or automated dynamic analysis.
6.4.2: Web application protection A web application firewall (WAF) or equivalent automated technical solution must be deployed in front of public-facing web applications in the CDE to actively detect and block web-based attacks, not simply log them.
Environment and change controls (6.5.x)
6.5.3: Environment separation Pre-production environments (development, test, staging) must be separated from the production environment in both network segmentation and access controls. Developers with access to non-production systems should not have standing access to production without separate, logged authorization.
6.5.5: No live PANs in test environments Live Primary Account Numbers cannot be used in pre-production environments. Test card numbers must be used instead. If legacy test environments contain real card data, that must be remediated before the audit, not flagged as a finding during it.
Integrating PCI-DSS Controls Into Your CI/CD Pipeline
PCI-DSS v4.0 does not prescribe specific tools, but its controls map directly onto automated pipeline checks. Running these in the CI/CD pipeline makes compliance continuous rather than periodic:
- Static application security testing (SAST): Supports 6.2.3 (code review before production) and 6.2.4 (prevention of common attacks). SAST tools scan source code without execution. Findings at high or critical severity should gate merges to main. Tools: SonarQube, Semgrep, Checkmarx.
- Software composition analysis (SCA): Supports 6.3.2 (component inventory) and 6.3.3 (patching known vulnerabilities) by scanning third-party dependencies against CVE databases. SCA should run on every build and block deployment when critical CVEs are present. Tools: Snyk, OWASP Dependency-Check, GitHub Dependabot.
- Dynamic application security testing (DAST): Supports 6.4.1 (testing public-facing applications for new threats) by scanning running applications for exploitable vulnerabilities. Most appropriate in staging environments before production deployment. Tools: OWASP ZAP, Burp Suite.
- Secret scanning: Prevents PANs, cryptographic keys, and authentication tokens from appearing in source code or commit history. Particularly important for Requirement 3 compliance: card data in a code repository is a material audit finding. Tools: GitGuardian, TruffleHog, GitHub Secret Scanning.
- Pipeline access controls: Requirements 7 and 8 apply to deployment pipelines. Production deployment capability should require separate authorization, be limited to a named set of principals, and all production deployments should be logged with the individual responsible.
Five Mistakes Dev Teams Make Before a PCI-DSS Audit
- Scoping the CDE too broadly. Including every system to be safe increases compliance burden without improving security. Work with your Qualified Security Assessor (QSA) to reduce CDE scope through tokenization, network segmentation, or hosted payment solutions before the assessment begins.
- Real card data in test environments. This is a direct violation of Requirement 6.5.5. Card networks publish test card numbers specifically to prevent this. If historical test environments contain live PANs, remediate before the audit, not during it.
- No documented developer security training. Requirement 6.2.2 mandates annual, documented training for all personnel developing in-scope software. Evidence must be retainable on request. Ad hoc awareness sessions and code review participation do not satisfy this requirement on their own.
- Code reviews without security scope. Functional code review does not satisfy Requirement 6.2.3. The review must specifically assess security vulnerabilities. Automated SAST results with tracked remediation, or documented manual security reviews, provide the required evidence trail.
- No third-party dependency inventory or patching cadence. Requirement 6.3.2 calls for a software component inventory. Requirement 6.3.3 requires timely patching. Dependency management done when time allows will not satisfy a PCI auditor. SCA tooling in the pipeline produces both the inventory and the remediation record automatically.
Frequently Asked Questions
What does PCI-DSS compliance require from software development teams?
PCI-DSS compliance requires software development teams to implement secure coding practices (6.2.4), conduct security-focused code reviews before production (6.2.3), maintain a software component inventory and patching process (6.3.2 and 6.3.3), separate pre-production from production environments (6.5.3), and ensure developers receive annual security training (6.2.2). The scope depends on whether the team's systems fall within or connect to the Cardholder Data Environment.
Which version of PCI-DSS is currently in force?
PCI-DSS v4.0.1 is the current version. PCI-DSS v3.2.1 was retired on March 31, 2024. PCI-DSS v4.0 introduced explicit requirements for developer security training, mandatory pre-production code review, and automated web application protection for public-facing systems.
Does PCI-DSS require SAST or automated security testing?
PCI-DSS v4.0 does not mandate specific tools, but Requirement 6.2.3 requires code review before production, 6.4.2 requires automated protection for public-facing web applications, and 6.4.1 requires regular application security testing. Integrating SAST, SCA, and DAST into the CI/CD pipeline is the most practical way to satisfy these requirements at development scale and produce the evidence records needed for a compliance assessment.
How does tokenization affect PCI-DSS compliance obligations for development teams?
Tokenization replaces PANs with surrogate values, removing cardholder data from the merchant's environment. If the development team's systems only handle tokens and not real card data, CDE scope is materially reduced. A properly implemented tokenization solution can reduce compliance obligations from a full Report on Compliance to a lower-tier Self-Assessment Questionnaire, depending on merchant level and architecture. Reduced scope through tokenization should always be validated with a QSA before treating requirements as reduced.
What is a Qualified Security Assessor and when is one required?
A Qualified Security Assessor (QSA) is an organization certified by the PCI SSC to conduct PCI-DSS compliance assessments. Level 1 merchants (more than 6 million card transactions annually) and Level 1 service providers must have an annual Report on Compliance conducted by a QSA. Smaller organizations may complete a Self-Assessment Questionnaire without a QSA. Engaging a QSA to review CDE scope and compliance posture before the formal assessment is common practice for organizations in regulated financial services.
Building secure delivery pipelines for FinTech products? The Scrums.com engineering intelligence platform gives FinTech engineering teams deployment visibility, DORA metrics, and release pipeline tracking for regulated environments. Or read the broader context in the FinTech engineering playbook, or the regulatory deadline playbook for managing PCI-DSS alongside GDPR and EU DORA.
