The PCI-DSS CI/CD Compliance Checklist

A dim data center at night, rows of server racks glowing with blue LED lights, a lone engineer standing in the aisle reviewing a tablet, thick cable bundles running overhead like a pipeline's unseen arteries.

Most PCI-DSS failures inside a CI/CD pipeline do not trace back to a missing control. They trace back to a control that exists somewhere in the organization but was never wired into the pipeline itself, so the evidence an auditor wants simply does not exist at the moment they ask for it. This checklist walks through the six places scope and risk actually enter a pipeline, with a yes or no item at each one. Run it against your own setup in about ten minutes and you will have a working picture of where your pipeline stands, and where the gaps are concrete enough to fix this quarter.

Before You Start: Defining Your PCI-DSS Scope in the Pipeline

Scope comes first because every item below only matters if it sits inside, or touches, the cardholder data environment. A build job that never handles cardholder data and never has network access to a system that does is out of scope. A build job that deploys to a system inside the CDE, even if it never sees card data directly, is in scope.

Before scoring anything, confirm:

You have a current, written diagram of which pipelines deploy to in-scope systems.
Shared runners, shared build agents, and shared artifact repositories used by both in-scope and out-of-scope pipelines are either segmented or treated as fully in-scope.
Anyone who can trigger a deployment to an in-scope system is covered by your access control requirements, not just the people who wrote the application code.

If you cannot answer these three cleanly, stop and resolve scope before scoring the rest of the checklist. A clean score on a wrongly scoped pipeline tells you nothing.

Source Code and Secrets Checks to Automate Pre-Commit

A pre-commit or pre-push hook blocks commits containing API keys, database credentials, or card data patterns.
Secrets used by the pipeline are pulled from a dedicated secrets manager at runtime, never stored in repository files, CI variables left in plaintext, or build logs.
Every secret has an owner and a rotation schedule, not just a creation date.
Branch protection requires at least one reviewer on any change touching payment processing code or pipeline configuration files.

If secrets handling is inconsistent across teams rather than standardized, that is worth fixing on its own terms. Standardizing secrets management across fintech engineering teams covers how to get every team working from the same pattern.

Close-up of a developer's hands on a mechanical keyboard in a dim office, a small brass padlock resting beside the laptop, the screen's glow reflecting lines of code in their glasses.

Build Stage Controls: Dependency Scanning and Image Hardening

Stacked shipping containers in a dockside yard at dusk, painted in weathered blues and rust oranges, lit by a crane's floodlight as one container is lifted and inspected before being loaded onward.

Every build runs a software composition analysis scan against a defined vulnerability threshold, and the build fails closed, not open, when that threshold is crossed.
Base images are pulled from an internal, scanned registry rather than public registries directly.
Container images are scanned for known CVEs before being pushed to any registry the deployment stage can pull from.
Build artifacts are signed, and the deployment stage verifies that signature before accepting an artifact.

Test Stage Gates: Automated Evidence for Requirements 6 and 11

Requirement 6 wants proof that code changes are tested for security weaknesses before release. Requirement 11 wants proof of regular vulnerability scanning. A pipeline that runs these tests but discards the output on the next job run is not generating evidence, it is generating noise.

Static application security testing runs on every pull request, not on a schedule disconnected from the commit that introduced the issue.
Dynamic testing or API-level security testing runs against a staging environment before every production deployment.
Test results are retained and tied to the specific commit and build number that produced them, for at least as long as your audit retention policy requires.
A failed security gate blocks the merge or the deployment automatically, with no manual override that bypasses the record of why it was overridden.

Deployment Stage Controls: Access Logging and Change Proof

Every production deployment is tied to an approved change record, generated automatically rather than filled in after the fact.
Deployment permissions are enforced by role, and the list of who can approve a production deploy is reviewed on a set schedule.
Deployment logs capture who triggered the deploy, what was deployed, and when, in a format that cannot be edited after the fact.
Rollback procedures are tested, not just documented.

If your deployment target is a Kubernetes cluster, the orchestration layer adds its own scope questions around namespace isolation and network policy that this checklist does not cover in depth. Running Kubernetes in scope goes through the orchestration-specific controls an auditor will ask about separately.

A network operations center with large monitors mounted on a dark wall, soft blue light illuminating two engineers at a control desk, one pointing at a screen while the other types on a keyboard.

Monitoring Stage: Continuous Compliance Alerts and Drift Detection

A dark monitoring room with a wall of screens glowing amber and red, a lone operator leaning forward in a chair, the reflected alert light tracing across a glass desk surface.

Configuration drift between your documented baseline and the running environment triggers an alert, not a manual quarterly check.
File integrity monitoring covers configuration files and binaries in the CDE, with alerts routed to someone who acts on them.
Access logs, deployment logs, and security scan results feed into a central system that can produce an audit trail on demand, not one assembled by hand before an assessment.
Alert fatigue is measured. If your team routinely dismisses compliance alerts without investigating, the control exists on paper but not in practice.

Scoring Your Pipeline: What Your Checklist Results Mean

Count your “yes” answers out of the roughly twenty items above.

17 to 20: your pipeline has strong automated coverage. The remaining gaps are likely edge cases worth closing but unlikely to be audit blockers.
11 to 16: coverage is uneven. You probably have strong controls in one or two stages and real exposure in the others, usually the test and monitoring stages, which are the ones teams build last.
10 or fewer: scope and secrets handling need attention before anything else on this list. An auditor will find the gaps faster than your pipeline will.

This checklist tells you where the gaps are. It does not walk through how to close them, and some of these items, particularly the test stage gates and the evidence retention rules, take real engineering work to build correctly inside a pipeline. The full build-out, including how to wire each control into your existing CI/CD tooling, is covered in automating PCI-DSS compliance checks inside your CI/CD pipeline.