PCI DSS and CI/CD Security

PCI DSS v4.0: Securing the Software Delivery Chain for Cardholder Data Environments

The Payment Card Industry Data Security Standard (PCI DSS) v4.0 governs any organisation that processes, stores, or transmits cardholder data. With version 4.0 now fully in effect — including the future-dated requirements that became mandatory in March 2025 — the standard places significantly greater emphasis on securing the software development and deployment lifecycle. For organisations delivering applications to the Cardholder Data Environment (CDE) through CI/CD pipelines, the pipeline itself becomes a critical component within the assessment scope.

This hub page provides comprehensive guidance on aligning CI/CD security controls with PCI DSS v4.0 requirements, understanding scoping implications, preparing for Qualified Security Assessor (QSA) examinations, and addressing the most common assessment findings in software delivery environments.

PCI DSS v4.0 Overview

PCI DSS v4.0 is structured around 12 principal requirements, organised into six control objectives. The standard applies to all entities involved in payment card processing — merchants, service providers, acquirers, and issuers — with the level of assessment determined by transaction volume and entity type.

Assessment Methods

  • Self-Assessment Questionnaire (SAQ): A self-validation tool for smaller merchants and service providers that meet specific eligibility criteria. Multiple SAQ types exist depending on how cardholder data is handled.
  • Report on Compliance (ROC): A detailed assessment conducted by a QSA, required for Level 1 merchants and service providers. The ROC documents the assessor’s findings against every applicable requirement.
  • Qualified Security Assessor (QSA): An independent assessor certified by the PCI Security Standards Council to evaluate compliance. QSAs conduct on-site assessments, review evidence, interview personnel, and observe processes.

The Customized Approach

PCI DSS v4.0 introduces a customized approach as an alternative to the defined approach for meeting requirements. Organisations may implement controls that differ from the prescriptive defined approach, provided they can demonstrate through a targeted risk analysis that their controls meet the objective of each requirement. This is particularly relevant for CI/CD environments where modern DevSecOps practices may achieve the same security outcome through different means than those prescribed in the defined approach.

When CI/CD Is in Scope for PCI DSS

PCI DSS scoping determines which systems, processes, and people are subject to assessment. CI/CD pipelines enter scope when they:

  • Deploy to the CDE: Pipelines that deliver code, configuration, or infrastructure changes to systems that process, store, or transmit cardholder data are directly in scope.
  • Handle cardholder data: Pipelines that process test data containing real PANs, or that manage encryption keys or tokenisation systems, are in scope.
  • Connect to CDE systems: Pipelines that have network connectivity to the CDE — even if they do not directly handle cardholder data — may be classified as connected-to or security-impacting systems.
  • Affect CDE security: Pipelines that manage security controls, firewall rules, access configurations, or monitoring systems for the CDE are security-impacting and therefore in scope.

Segmentation Considerations

Organisations can reduce their PCI DSS scope through network segmentation — isolating the CDE from other systems. For CI/CD, this means considering whether pipeline infrastructure can be segmented so that only specific pipeline stages or runners have access to the CDE. However, the pipeline components that deploy to or configure the CDE will remain in scope regardless of segmentation. The segmentation itself must be validated as part of the assessment, and QSAs will verify that pipeline systems outside the defined CDE boundary genuinely cannot affect cardholder data security.

Key Requirements for CI/CD Environments

Requirement 6 — Develop and Maintain Secure Systems and Software

Requirement 6 is the most directly relevant requirement for CI/CD pipelines and addresses the full software development and deployment lifecycle:

  • 6.2 Secure development: Secure coding practices must be defined and enforced. Developers must be trained on secure coding techniques relevant to the technologies in use. The organisation must maintain secure coding standards that are applied through pipeline enforcement — not just documented in policy.
  • 6.3 Vulnerability management: Vulnerabilities in custom code and third-party components must be identified, prioritised, and remediated within defined timelines. This includes maintaining an inventory of third-party components (SBOM), monitoring for vulnerability disclosures, and applying patches promptly. CI/CD pipelines should integrate vulnerability scanning (SCA) and block deployments when critical vulnerabilities are identified.
  • 6.4 Public-facing web applications: Applications exposed to the internet must be protected against common attacks. This includes integrating DAST into the deployment pipeline, conducting regular vulnerability assessments, and deploying web application firewalls (WAFs) where applicable.
  • 6.5 Change management: All changes to system components in the CDE must follow a documented change management process. This includes code review by individuals other than the author, documented approval before deployment to production, functionality testing to verify changes work as intended, and rollback procedures. CI/CD pipelines should enforce these requirements through technical controls — branch protection, mandatory reviews, approval gates, and automated testing.
  • SAST and DAST integration: Static application security testing must be performed on custom code before release, and dynamic testing must be conducted on deployed applications. Pipeline integration ensures these requirements are met consistently for every release.

Requirement 7 — Restrict Access to System Components and Cardholder Data

  • Least privilege: Access to pipeline systems that deploy to the CDE must be restricted to the minimum necessary for each role. Pipeline service accounts must have only the permissions required for their specific function.
  • RBAC: Access control must be role-based with documented role definitions, approved access grants, and regular reviews to identify and remediate excessive permissions.
  • Access provisioning and deprovisioning: Processes must exist for granting access to new personnel and promptly removing access when roles change or personnel depart. This applies to CI/CD platform accounts, repository access, and deployment credentials.

Requirement 8 — Identify Users and Authenticate Access

  • MFA for administrative access: All administrative access to pipeline systems, including CI/CD platform configuration, secrets management, and production deployment controls, must require multi-factor authentication.
  • No shared or generic accounts: Every action in the CI/CD environment must be attributable to an individual. Shared service accounts must be eliminated or compensated with additional logging and controls that maintain individual accountability.
  • Credential management: Pipeline credentials must be rotated at defined intervals, stored securely in secrets management systems, never embedded in code or configuration files, and immediately revoked when compromised or no longer needed.

Requirement 10 — Log and Monitor All Access

  • Pipeline audit trails: All pipeline activities must be logged — builds, tests, deployments, configuration changes, access grants, and administrative actions. Logs must include who performed the action, what was done, when it occurred, and whether it succeeded or failed.
  • Log retention: PCI DSS requires a minimum of twelve months of audit log retention, with at least three months immediately available for analysis. Pipeline logs must meet this requirement.
  • Alerting: Automated alerts must be configured for security-relevant pipeline events — failed authentication attempts, configuration changes, deployment failures, access to sensitive systems, and anomalous activity patterns.

Requirement 11 — Test Security of Systems and Networks Regularly

  • Penetration testing: Pipeline infrastructure that is in scope for PCI DSS must be included in the organisation’s penetration testing programme, with both internal and external testing conducted at least annually and after significant changes.
  • Vulnerability scanning: Internal and external vulnerability scans must cover in-scope pipeline components, with identified vulnerabilities remediated and rescanned to confirm resolution.
  • Change detection: Mechanisms must be in place to detect unauthorised changes to pipeline configurations, deployment scripts, and critical system files. File integrity monitoring or equivalent controls should cover pipeline infrastructure.

Requirement 12 — Support Information Security with Organisational Policies and Programmes

  • Security policies covering CI/CD: The organisation’s information security policies must explicitly address CI/CD environments, including acceptable use, access control, change management, incident response, and vendor management for pipeline components.
  • Incident response: The incident response plan must include scenarios relevant to CI/CD — pipeline compromise, secret leakage, supply chain attacks, and unauthorised deployments — with defined response procedures, responsibilities, and escalation paths.
  • Risk assessments: The organisation’s risk assessment must cover CI/CD-specific threats, including supply chain attacks, pipeline compromise, credential theft, and environment contamination. Risk assessments must be reviewed at least annually and updated when significant changes occur.

PCI DSS v4.0 Changes That Impact CI/CD

Several changes introduced in PCI DSS v4.0 have particular significance for CI/CD environments:

  • Customized approach: Organisations can now meet requirements through alternative controls, provided they demonstrate equivalent security through targeted risk analysis. This is valuable for CI/CD environments where automated, continuous controls may differ from the traditional periodic controls described in the defined approach but achieve the same or better outcomes.
  • Targeted risk analysis: v4.0 requires documented targeted risk analyses for specific requirements, allowing organisations to determine the frequency of certain activities (such as access reviews and vulnerability scans) based on their risk profile rather than following a one-size-fits-all schedule.
  • Future-dated requirements (effective March 2025): Several requirements that were best practices during the transition period became mandatory in March 2025. These include enhanced authentication requirements, automated mechanisms for reviewing audit logs, and more rigorous change management processes — all of which directly affect CI/CD operations.
  • Evolved software security requirements: v4.0 places greater emphasis on automated security testing, software composition analysis, and the governance of third-party software components — aligning closely with modern DevSecOps practices in CI/CD pipelines.

Common Assessment Findings

QSAs frequently identify the following issues when assessing CI/CD environments against PCI DSS requirements:

  • Uncontrolled access to production: Developers or pipeline service accounts have broader access to CDE systems than necessary, violating the principle of least privilege. Access is granted for convenience rather than business need.
  • Missing log retention: Pipeline logs are retained for weeks rather than the required twelve months, or logs from the early part of the assessment period have been purged and cannot be produced during the QSA review.
  • No vulnerability management for pipeline components: While application code is scanned, the CI/CD infrastructure itself — runners, plugins, base images, pipeline tools — is not included in the vulnerability management programme.
  • Environment bleed: Development and production environments share network segments, credentials, or pipeline runners, undermining the required separation and creating pathways for unauthorised access to the CDE.
  • Inadequate change management evidence: Changes are deployed to the CDE without documented code review, testing evidence, or approval records. Emergency change procedures exist but are used routinely without post-implementation review.
  • Shared accounts in pipelines: Pipeline service accounts are shared across teams or environments without individual accountability, making it impossible to trace specific actions to specific individuals.
  • Incomplete scoping: CI/CD systems that deploy to or affect the CDE are excluded from the PCI DSS scope assessment, creating uncontrolled pathways into the cardholder data environment.

Deep Dive Articles

Explore detailed guidance on specific aspects of PCI DSS compliance in CI/CD environments:

Related Content

Cross-Framework References

PCI DSS requirements frequently overlap with controls from other regulatory frameworks. Organisations subject to multiple compliance obligations can build a unified control environment that satisfies PCI DSS alongside other standards:

  • ISO 27001 and CI/CD Security — The international ISMS standard with extensive control overlap, particularly in access control, change management, and secure development
  • SOC 2 and CI/CD Security — Trust Service Criteria with strong alignment to PCI DSS logical access, change management, and monitoring requirements
  • DORA and CI/CD Security — Digital Operational Resilience Act requirements for financial entities, relevant where payment processing intersects with EU financial regulation
  • NIS2 and CI/CD Security — Network and Information Security Directive requirements for essential and important entities across the EU