How Argo CD supports PCI DSS requirement 6.5 change control
A QSA testing Requirement 6.5 will ask how each production change in the cardholder data environment (CDE) was documented, approved, tested and, if it failed, returned to a secure state. Argo CD can supply much of that trail, but only for the parts of 6.5 that run through Git and the cluster. Argo CD helps most with 6.5.1 (approval and rollback), 6.5.3 (separation of pre-production and production) and 6.5.4 (separation of roles). Its records of who merged a change, who synced it and what Kubernetes reported are the raw material for the approval trail. Git revert plus a sync is the mechanism for returning to a known state. Separate Argo CD projects and clusters give you the environment boundary. Confirm with your QSA how they will sample these records, because the evidence has to show the control operated, not just that it exists.
Several sub-requirements depend on your own procedures and testing. For 6.5.1, the security impact assessment, the test that security was not adversely affected, and the check of custom software against 6.2.4 must be performed and recorded by your team, and Argo CD only shows that the approved commit reached the cluster. For 6.5.2, confirming PCI DSS requirements after a significant change is a compliance task, and PCI SSC FAQ 1317 lists the kinds of changes that count, including changes to supporting infrastructure such as directory services and logging. For 6.5.5 and 6.5.6, removing live PANs from pre-production and test data and accounts before go-live depends on your data handling and account lifecycle, not on the deployment tool. Review the PCI DSS SAQ D for the exact wording of each sub-requirement before you map controls to it.
DeployOpen configures Argo CD, the Git workflow, RBAC and the evidence exports in your own infrastructure, and documents how each control maps to a sub-requirement. DeployOpen does not issue Reports on Compliance, Self-Assessment Questionnaires or Attestations of Compliance. Those come from a Qualified Security Assessor or from your own SAQ completion, and PCI SSC does not certify products or organizations. Before scoping the work, confirm with your acquirer or payment brand which validation level and SAQ type apply to you, and confirm with your QSA which evidence formats they accept.
Mapping PCI DSS 6.5.1 to 6.5.6 to Argo CD capabilities and configuration
This table maps each sub-requirement of PCI DSS requirement 6.5 to the Argo CD capability that supports it and the configuration the assessed environment needs. Read each row as a starting point for the evidence you collect, since the assessor decides whether the control is met in your environment. Requirements 6.5.5 and 6.5.6 depend mainly on data and account handling outside Argo CD, so the Argo CD column for those rows is limited.
| Sub-requirement | Argo CD capability | Configuration to confirm |
|---|---|---|
| 6.5.1 Change procedures and rollback | Git pull request review as the documented change record, with Argo CD syncing only approved commits and Git revert as the return path | Protected production branch requiring approval, sync limited to the production Application, documented revert and sync procedure for failed changes |
| 6.5.2 Confirmation after significant change | Pull requests can carry the PCI DSS impact assessment, and Argo CD sync history shows what was deployed and when | Checklist in the pull request template for significant change (see PCI SSC FAQ 1317), with a confirmation step recorded before merge |
| 6.5.3 Pre-production and production separation | Separate Argo CD Projects and destination clusters or namespaces for each environment, with destinations restricted per Project | Production Project allows only production clusters, pre-production Project cannot target the CDE, and separate Git paths or branches per environment |
| 6.5.4 Role separation | RBAC scoped by Project, with update and delete permissions applying only to the Application itself and logs access requiring an explicit logs, get permission (Argo CD 3.0 upgrade notes) | Developers hold sync rights in pre-production only, approvers and implementers are separate groups from SSO, and admin.enabled set to false |
| 6.5.5 No live PANs in pre-production | Argo CD does not inspect data, but its manifests and Git repositories can carry data if misused | Confirm with your data owners that no live card data reaches pre-production Git repositories, Secrets or test manifests. Use this control as a manual check, not an Argo CD setting |
| 6.5.6 Removal of test data and accounts before go-live | Argo CD can prune resources removed from Git, but pruning does not cover accounts or data stores | Remove test accounts from the identity provider and local Argo CD users, delete test Applications and Projects, and record the cleanup in the change ticket |
What 6.5.1 asks for and how a Git-based change maps to it
Requirement 6.5.1 asks for five things on every production change: a documented security impact, approval by authorized parties, testing that security is not adversely affected, testing of custom software changes against 6.2.4, and procedures to return to a secure state if the change fails. Argo CD does not produce any of these artifacts on its own. It gives you a place where they are attached to the change and a record of what was applied. In a Git-based flow, the pull request is the change record: the description holds the security impact statement, the required reviewers in the branch protection rules are the authorized approvers, and the commit history is the audit trail. The security impact analysis, the security test results and the 6.2.4 evidence for custom code must be written and retained by your team, typically as pull request templates, linked test reports or CI outputs that the reviewer checks before approving.
On the Argo CD side, the sync record ties the approved commit to the cluster state. Each sync shows which revision was deployed, who triggered it and what resources changed, so a reviewer can confirm that what was approved is what ran. Confirm with your own change policy whether the team that merges is also allowed to trigger syncs, since Argo CD automated sync removes the manual step entirely and an auditor may ask why that is acceptable for production.
For the failure path, the return to a secure state is usually a Git revert of the offending commit followed by a sync to the previous revision. Write that procedure down, test it in a pre-production project, and record the rollback steps in the change ticket. Ask your assessor whether a revert plus sync is enough evidence for your environment, or whether they expect a separate documented runbook for the cluster and data state that a revert cannot restore.
Configuring Argo CD for a PCI change control trail
This sequence sets up Argo CD so that every production change to the cardholder data environment passes through Git review, a separated approval path and a logged sync, with a tested way back to a known state. It gives an assessor one place to start when testing requirement 6.5.
Confirm the version and patch track
Choose the Argo CD minor version your team will run and record it in the change control documentation. The release process ships a minor version four times a year and patches only the three most recent minor versions, so the platform owner must watch the GitHub releases page and apply patch releases within the supported window. Done when the chosen version, its patch owner and the release watch are written into the platform standard and an older minor version is no longer in use.
Separate pre-production and CDE production
Create distinct Argo CD Projects for pre-production and CDE production, and register each as a separate destination cluster or, where your design allows it, a separate Argo CD instance. Restrict each project's source repositories, destination namespaces and permitted resource kinds so that an application in one project cannot deploy into the other. Done when a test application pointed at the production destination from the pre-production project is rejected, and the project definitions are stored in Git for review.
Enable SSO and map groups to roles
Connect Argo CD to your identity provider, either through the bundled Dex or directly over OIDC, and map identity provider groups to Argo CD roles. On Argo CD 3.0 and later, Dex-based RBAC uses the federated_claims.user_id claim, so confirm that claim is present for each test user before relying on it. Separate groups for approvers, release operators and read-only auditors. Done when each test user signs in with their own identity and sees only the projects their group allows.
Disable the built-in admin account
Use the built-in admin user only for initial setup, then set admin.enabled to false once SSO and local users are working. Keep a documented, access-controlled break-glass procedure for the rare case where SSO is unavailable, and record each use. Done when a login attempt as admin is refused and the break-glass procedure has been reviewed by the people who would invoke it.
Remove direct sync rights from developers in production
Write RBAC policies for the CDE production project that allow developers to view applications and logs but not to sync, override or delete them. Only the release operator group should hold sync permission there, and remember that on Argo CD 2.14 to 3.0 update and delete rights apply only to the application itself and logs access needs an explicit logs, get permission. A developer using a separate user-level account for production work fits the procedural option that the SAQ D note to Requirement 6.5.4 describes. Done when a developer test account can read production state but a sync attempt returns a permission error.
Define repositories as Kubernetes Secrets
On Argo CD 3.0 and later, repository configuration no longer lives in the argocd-cm ConfigMap, so register each Git repository as a Kubernetes Secret with read-only credentials scoped to the required path. Limit which repositories each project may use, and treat the repo-server as a privileged component because it runs Helm and Kustomize on repository content. Done when the repositories appear in Argo CD from their Secrets, and a project cannot pull from a repository outside its allowlist.
Require approval through branch protection
Protect the branch that Argo CD tracks for production so that changes need a pull request, at least one approval from someone who is not the author, and passing checks before merge. Keep merge rights and the Argo CD sync rights with different groups, so the person who approves a change is not the only person who can deploy it. Done when a direct push to the production branch is blocked and a sample change cannot merge without the required approval, with the review recorded in the Git host.
Test rollback with revert commits
Document the rollback path as a Git revert of the offending commit, followed by an Argo CD sync from the production project, and rehearse it in pre-production before go-live. Record the expected security state the cluster returns to, and confirm the rehearsal output is kept as evidence for the failure procedure in Requirement 6.5.1. Done when a rehearsal reverts a test change, the cluster returns to the prior declared state, and the revert, sync and Kubernetes events are retained together.
Evidence Argo CD produces for a QSA and how to keep it
An assessor testing Requirement 6.5 samples change records, not tool screens. Argo CD holds part of the trail in Git and in Kubernetes objects, but the approval record, the sync log and the access history need to be exported and kept under your own retention policy. The cards below cover each record, where it lives and what to export before it ages out.
Merged pull requests with approvals
The pull request is the primary change record: the diff, the security impact note, the reviewer approvals and the merge commit. It lives in your Git host, not in Argo CD, so the approval is only as durable as that host's retention and backup settings. Check that required reviewers are enforced by branch protection and that approvals are not dismissed silently. Export a sample of production pull requests with their review history into your evidence store on a fixed schedule. Git hosting is the system of record for approvals.
Sync history and Kubernetes events
Argo CD records which revision was synced, by whom and when, and the result of each sync operation. That history is kept in the Application status and is limited in depth, so it cannot be the only copy. Kubernetes events are short-lived and disappear quickly on most clusters. Forward both to your log platform and confirm that each production sync can be matched to a merged commit and an approval.
RBAC and Project definitions in Git
Argo CD Projects, RBAC policy and the project boundaries that separate pre-production from production should be declared as manifests in Git, not edited in the live cluster. Git history then shows when a role or destination changed and who approved it. Confirm that the cluster copies match the repository, because a manual edit that bypasses Git is the most common gap an assessor finds. This record supports the role separation expected under Requirement 6.5.4.
SSO group membership
Argo CD maps identity provider groups to its roles, so who can sync production depends on group membership held by your identity provider, not on Argo CD. Export the group membership list and its change history from that provider at regular intervals and keep the admin user disabled once SSO is configured. An assessor will compare the people who approved and synced changes against this list. Confirm which system is the source for removals when someone leaves or changes role.
Rollback commits and revert records
Requirement 6.5.1 expects a documented way to return to a secure state when a change fails. In a GitOps flow, the rollback is a revert commit or a restored revision, which should go through the same pull request and approval path as a forward change. Keep the revert pull request, the sync that followed it and the failure record that triggered it together. Note that rolling back an application in the Argo CD interface alone leaves Git and the cluster out of step, so it should be reconciled back into Git.
Argo CD audit and access logs
Argo CD's API server and controllers write logs that show logins, sync actions and resource operations. These logs are not kept by Argo CD for you, so ship them to a central store with retention set by your policy. Read access to logs is controlled by RBAC, so confirm that the team reviewing evidence has the permissions it needs. Redacted credentials in logs mean the exported files are safer to share with an assessor, but they still need your access controls.
Separating pre-production and production in one cluster or many
In a shared cluster, pre-production and production run as separate namespaces, and each environment has its own Argo CD Project. The Project decides which repositories, destination namespaces and resource kinds an Application may use. This is the lowest-overhead option, but the boundary is logical, so it depends on Kubernetes RBAC, network policies and Project settings all being correct and tested. The PCI SSC FAQ on significant change lists changes to supporting infrastructure as significant, so any shared component can pull the whole cluster into review.
- Scope: If production namespaces hold cardholder data environment (CDE) components, the cluster and its shared services may be treated as in scope.
- Blast radius: A node fault, a faulty admission policy or a compromised cluster credential can affect both environments at once.
- Project boundaries: Limit each production Project to the production repository path, the production namespace and an approved list of resource kinds.
- Operating load: One control plane to patch and back up, but more namespace policies to review on every change.
Confirm with your QSA whether namespace separation is accepted as segmentation for your scope, and keep test evidence that the Project and network boundaries block cross-environment deployments.
Separate clusters give the clearest boundary. Production clusters can sit in their own network segment with their own control plane, nodes, identities and backups. Argo CD can manage several clusters from one instance, but every registered production cluster adds a trust path from the Argo CD instance into production, and that path becomes part of the assessment.
- Scope clarity: The production cluster is simple to define. A pre-production cluster may fall outside scope if it has no live cardholder data and no connected path into the CDE, which the QSA must verify.
- Credential paths: Registering production with a central Argo CD makes that instance a route into production, so its access and logging become in-scope controls.
- Repetition: Each cluster needs its own platform components, policies, upgrades and backup jobs, and that work recurs for the life of the platform.
- Parity: Drift between environments makes pre-production tests less representative. Keep one set of manifests in Git and vary only the values that must differ.
Before choosing this model, document where the Argo CD control plane runs, which clusters it can reach and who can change those registrations.
A dedicated Argo CD instance for the CDE keeps the deployment tool's own credentials, repository access and cluster registrations inside the boundary. Teams often choose this when the rest of the organization runs a shared delivery platform. The Argo CD security documentation notes that the instance holds cluster, Git and OAuth2 credentials, and that the repo-server runs Helm and Kustomize on repository content. The controller therefore needs to be scoped and monitored as a security system in its own right.
- Smaller trust boundary: Only CDE clusters are registered, so a compromise of a non-CDE instance cannot reach them.
- Separate identity mapping: Map SSO groups to CDE roles only, so access to this instance is limited to named people and automation.
- Capacity and recovery: The high availability documentation states that HA manifests need at least three nodes because of pod anti-affinity rules, so the instance needs its own capacity and recovery plan.
- Two upgrade tracks: Each instance has its own upgrade schedule. The project patches only the three most recent minor versions, so plan upgrades to stay inside that window.
- Repository control: Allow the repo-server to read only approved repositories, because untrusted repository content is a documented risk.
Ask your QSA whether the Argo CD instance itself is a system component in scope, and whether its configuration, logs and access records are part of the evidence you will provide.
Requirement 6.5.4 asks for separation of roles between production and pre-production environments. The SAQ D note allows small teams to meet this through procedural controls, such as a developer using separate user-level accounts in production. This allowance still requires a written procedure and evidence that it is followed. An informal habit will not satisfy an assessor.
- Separate identities: Developers sign in with one account for development and a separate account for production actions. Map each account to a different Argo CD role.
- Read-first access: Grant developers view access to production Applications, and route sync rights for production through an approved path.
- Git review on production paths: Require a pull request review for changes under production paths, so a single person cannot both author and approve a production change.
- Built-in admin account: The Argo CD user management guidance recommends using the admin user only for initial setup and disabling it with admin.enabled set to false once SSO or local users are configured.
- Retained evidence: Keep the role mappings, RBAC configuration, pull request approvals and sync history for the assessment period.
Confirm with your QSA that the procedural approach fits your organization's size, your SAQ type and your payment brand's requirements before relying on it.
What Argo CD does not cover for requirement 6.5
Argo CD records and enforces how changes reach a cluster, but several requirement 6.5 obligations sit outside the tool. Each card names a gap, what it needs from your own process, and what to confirm with your assessor before relying on Argo CD as evidence.
Security impact analysis
Requirement 6.5.1 expects each production change to carry a documented security impact, approved by authorized parties. Argo CD shows what changed and who synced it, but it does not judge whether a manifest weakens a control. Your change ticket must hold the impact analysis, linked to the Git commit or pull request that Argo CD deploys. Confirm with your assessor which reviewers sign off and how the approval is recorded.
Custom software testing against 6.2.4
Where a change touches custom software, 6.5.1 requires testing that is aligned with the software security requirement in 6.2.4. Argo CD can gate deployment on a passing pipeline, but it does not run the tests or know which tests apply. Your CI pipeline must prove the test coverage, and your release record must show that the tested artifact is the one Argo CD syncs. Ask your QSA which test evidence they will sample.
Significant change classification
PCI SSC FAQ 1317 lists changes that count as significant, including new CDE software, changed data flows, CDE boundary changes and changes to supporting services such as directory services, time servers and logging. Argo CD does not decide which changes are significant. Your change board must classify each Git change and trigger the post-change confirmation of PCI DSS requirements when the change qualifies.
Live PAN handling and test data
Requirements 6.5.5 and 6.5.6 bar live primary account numbers from pre-production and require test data and accounts removed before go-live. Argo CD syncs whatever manifests and seed data Git contains, so a fixture with real card data would reach a non-production cluster unchecked. Scan repositories and cluster contents for PANs and test accounts in your own pipeline, and keep that scan output as evidence.
Dex and repo-server exposure
The security documentation notes that the repo-server runs Helm and Kustomize on repository content, so untrusted repositories and out-of-tree file access are risks to control. Dex brokers SSO through connectors that your identity design must secure. Restrict which repositories Argo CD may read, disable unused Dex connectors, and review the Dex and repo-server configuration as part of your access review.
No compliance enforcement or certification
The PCI SSC does not enforce compliance, and the payment brands decide who must validate. Assessments are documented on a Report on Compliance by a Qualified Security Assessor or on a Self-Assessment Questionnaire with an Attestation of Compliance. Argo CD and DeployOpen can prepare systems and evidence, but only your assessor issues the validation. Confirm the SAQ type and the evidence list with your assessor before the assessment window opens.
Keeping the Argo CD version and access settings assessable
Staying on a supported Argo CD minor release is the first condition for assessable evidence. The project ships a minor release four times a year, once every three months, and only the three most recent minor versions receive patch releases. An assessor testing change control under requirement 6.5 will look at whether the platform that approves and applies production changes still gets security fixes, so the team should record the running version, the date it was last checked, and the release it plans to move to next. Confirm the current patch versions on the Argo CD GitHub releases page before each audit window, because the supported set moves with every minor release.
Access settings need the same discipline, and the 2.14 to 3.0 upgrade changed what the evidence shows. Update and delete RBAC now apply only to the application itself, and reading logs requires an explicit logs, get permission. A role that once looked sufficient for an operator may now fail, or may quietly lose the ability to pull the logs an investigator needs. Re-run the role policy tests after any upgrade across that boundary, keep the policy.csv version alongside the change record, and disable the built-in admin account by setting admin.enabled to false once SSO or local users are in place. Repository definitions also moved into Kubernetes Secrets in 3.0, so their history belongs in the same change record.
Several platform controls support the access story but do not replace it. Argo CD authenticates API requests only with JSON Web Tokens, encrypts traffic between its own components with TLS, and redacts cluster, Git and OAuth2 credentials from API responses and logs. The main exposure is the repo-server, which runs Helm and Kustomize against repository content. A change to an untrusted repository, or a manifest that reads files outside its own tree, can execute logic that no reviewer read in the pull request. Decide which repositories are trusted for rendering, restrict who can add new sources to a project, and record that decision as part of the requirement 6.5.1 security impact review.
Questions teams ask before using Argo CD for PCI DSS 6.5
Does Argo CD alone satisfy PCI DSS requirement 6.5?
No. Argo CD is one tool that supports the change control evidence for requirement 6.5, but it does not make an entity compliant on its own. Requirement 6.5.1 also needs documented security impact, approval by authorized parties, security testing and a return-to-secure-state procedure, and those depend on your policies, people and assessment. The separation of pre-production and production (6.5.3), role separation (6.5.4) and the handling of live cardholder data and test accounts (6.5.5 and 6.5.6) also depend on how you design clusters, projects and access. Confirm with your Qualified Security Assessor or the payment brand which evidence they will accept for each sub-requirement before you design the setup.
What does Argo CD change control setup cost, and what drives it?
Argo CD is released under the Apache License 2.0 with no paid edition from the project, so the software itself has no license fee. The cost is in the work and the infrastructure: clusters for pre-production and production, identity integration, Git workflow design, RBAC and projects, backups, and the evidence process. Scope drives the price most: the number of clusters and applications, whether an identity provider already exists, how many approval paths you need, how much of the current change process must be documented, and whether a QSA review is expected. Ask any quote to itemize one-time design and build work separately from recurring support, upgrades and testing, and to state which environments and assumptions it covers.
How long does Argo CD configuration and evidence setup take?
Duration depends on how much of the change process already exists and how many environments are in scope. Teams with mature Git review, documented change tickets and separate clusters usually need less time than teams that must first define approvals, separate duties and collect historical evidence. The main drivers are the identity integration, the cluster inventory and network layout, the number of Argo CD projects and roles, and the time your process owners need to approve documented procedures. Ask for a timeline tied to a written scope and a list of your dependencies, rather than a generic figure, and confirm the review dates with your assessor.
What must our team provide before an Argo CD PCI DSS engagement starts?
Prepare four inputs before work starts:
- Named process owners for change management, security, and the cardholder data environment, with authority to approve changes.
- A contact at your Qualified Security Assessor or assessing organization, so evidence expectations are agreed early.
- A cluster and application inventory showing which systems are in the cardholder data environment, which are connected to it, and where pre-production and production run.
- Access to your current identity provider, Git hosting, and existing change tickets or policies.
The inventory matters most, because the significant change guidance in PCI SSC FAQ 1317 covers changes to supporting infrastructure such as directory services and logging, which affects what Argo CD must control.
Can an internal platform team set up Argo CD for PCI DSS 6.5 without a partner?
Yes, many internal teams can, provided they have Kubernetes, Argo CD and identity skills, and someone who understands the PCI DSS requirements in depth. The work involves more than installation: it includes role separation, project boundaries, secure repository configuration, backup and recovery, and evidence collection that an assessor will sample. The SAQ D note to Requirement 6.5.4 allows smaller teams to meet role separation with procedural controls, which can reduce the technical scope. Assess your internal capacity honestly, including the time needed to keep the setup current after upgrades, and compare it with a fixed-scope engagement that defines the deliverables in writing.
Does DeployOpen certify that our environment is PCI DSS compliant?
No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in infrastructure you control, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Compliance validation is carried out through a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance, and the payment brands decide who must validate. Your assessor determines whether the evidence meets the requirement. Ask any partner to state in writing which parts of the work are preparation and which parts belong to your assessor.
Which Argo CD settings do engineers need to verify before an assessment?
Engineers should confirm several settings in the running system, not only in documentation. Check that the built-in admin user is disabled with admin.enabled set to false once SSO or local users are configured. Confirm that repositories are defined as Kubernetes Secrets, because Argo CD 3.0 removed repository configuration from argocd-cm. Review RBAC rules, since update and delete permissions apply to the application itself, and log access requires an explicit logs, get permission. Verify that production syncs are tied to approved Git changes, and that the repo-server only processes repositories you trust. Record the Argo CD version and confirm it still receives patches, because only the three most recent minor versions do.
How DeployOpen scopes and delivers PCI change control configuration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Argo CD configured for PCI DSS requirement 6.5 change control. Each engagement starts from a written scope that sets out which clusters, projects and approval paths the Argo CD setup must cover.
How we scope
- We confirm which clusters, namespaces and applications fall inside the cardholder data environment and which sit outside it.
- We agree in writing how pre-production and production Argo CD projects, clusters and repositories will be separated.
- We record which roles approve, merge and sync changes, and which identity groups map to each role in Argo CD.
How we build
- We configure Git branch protection, pull request approvals and sync restrictions so production changes need documented review.
- We set up Argo CD projects and RBAC so developers cannot sync production directly, and we test those permissions.
- We configure SSO, disable the built-in admin user, and document the rollback procedure through Git revert and sync to a known good state.
How we hand over
- We deliver a written configuration record covering projects, RBAC policies, approval flow, sync settings and rollback steps.
- We document how sync history, Git commits and Kubernetes events are retained and where an assessor can find them.
- We walk your team through the change procedure and the records a Qualified Security Assessor is likely to request.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, including reviews after Argo CD minor releases.
- We can review RBAC and project changes after significant changes, so your records keep pace with the environment.
- Your quote follows from the written scope, and we will confirm with you which assessment evidence your organization still needs to collect.
