Argo CD for DORA ICT change management

How Argo CD supports DORA change management for Kubernetes workloads

A financial entity in scope of DORA must run ICT change management under Article 9(4)(e) of Regulation (EU) 2022/2554 and Article 17 of Delegated Regulation (EU) 2024/1774, and it wants to know whether Git-driven delivery with Argo CD helps. Argo CD helps evidence the parts of that article that concern recording and approving changes, separating approvers from implementers, and reviewing changes against a documented baseline. It does not satisfy the requirements on risk assessment, testing quality, emergency change decisions taken by people, or the security assessment of each change, because those depend on your own procedures and staff. DeployOpen prepares the systems, configuration and evidence trail for these controls. It does not issue audit reports, attestations or certifications, and the regulatory obligations remain the institution's responsibility, to be assessed by its competent authority and its own auditors.

Most of the evidence comes from the Git flow. Each desired-state change is a commit with an author, a reviewer and a timestamp, and each sync is recorded in Argo CD's application history, with the revision deployed. Argo CD projects and RBAC can restrict which people and service accounts may sync applications to production, so the person who merges a change is not necessarily the one who syncs it. Confirm with your own environment how Git hosting approvals, branch protection and Argo CD roles map to your approval matrix, and confirm which audit logs your Argo CD version retains and for how long. The Argo CD security documentation is the starting point for how the API and component access is protected.

Mapping DORA and RTS Article 17 requirements to Argo CD capabilities

This table maps each DORA and RTS Article 17 change management requirement to the Argo CD capability that supports it, the configuration needed and the gap that remains with your own processes. Read each row as a question to answer for your environment: the capability supplies evidence and enforcement, while approval policy, testing content and emergency governance stay with your organization.

Requirement	Argo CD capability and configuration	Residual gap to close outside Argo CD
Separation of approvers and implementers	Changes arrive as Git commits reviewed in pull requests. Use Git branch protection so the implementer cannot approve their own change, and set Argo CD RBAC so sync rights are not granted to the authors of commits.	Git hosting roles, reviewer assignment and the approval matrix are defined by your organization, and must be confirmed against the Git host's own permission model.
Documented purpose, scope, timeline and expected outcome	The commit message, pull request description and the Argo CD Application manifest record what changed and where. Link each pull request to a change ticket in your ITSM tool.	Argo CD does not hold the change request itself. Purpose, timeline and expected outcome must be written into your change template.
Fall-back and abort procedures	Rollback is performed by reverting the Git commit so the desired state returns to the earlier version, and Argo CD syncs the cluster to match. Confirm that reverted states are tested before relying on them.	Revert does not undo database migrations, external side effects or data changes. Document those steps separately and confirm them with the application owner.
Controlled testing and quality assurance roles	Separate Argo CD Projects and destination clusters for pre-production and production let the same manifests run in a test environment before promotion.	Test scope, test evidence and QA sign-off are defined by your process. Argo CD proves where a change was deployed, not that it was tested adequately.
Assessment of impact on existing security measures	Pull requests can carry the security review of manifests, and the Argo CD security documentation notes that repo-server runs Helm and Kustomize on repository content, so restrict which repositories Projects may use.	Impact assessment is a human judgment. Argo CD does not evaluate whether a change weakens a control.
Emergency changes reviewed after implementation	Emergency changes still pass through Git so they are recorded. Sync history and Kubernetes events show what ran and when, which supports a post-implementation review.	Emergency access rules, who may bypass normal review and the deadline for after-the-fact approval must be set in your emergency change procedure.
All changes recorded, tested, approved, implemented and verified	Git history records each change and approval. Argo CD sync status and drift detection show whether the live state matches the approved Git state.	Retention of Git and Argo CD records, and their export to your evidence store, must be designed and confirmed with your compliance team.
Strong authentication	Argo CD authenticates API requests with JSON Web Tokens and supports SSO through bundled Dex or a direct OIDC provider. Set admin.enabled to false once SSO or local users are configured.	Multi-factor enforcement sits with the identity provider. Confirm that MFA is required there, since Argo CD inherits its strength.
Protection of cryptographic keys and credentials	Argo CD uses TLS for its traffic, including between components, and redacts cluster, Git and OAuth2 credentials from API responses and logs. Repository credentials must be stored as Kubernetes Secrets in Argo CD 3.0 and later.	Key generation, encryption at rest and key rotation are handled by your cluster and secrets tooling. Argo CD does not manage those keys.

How a pull request becomes a recorded, approved change

In a GitOps flow, the pull request is the change record, so its content has to carry what Article 17 of Delegated Regulation (EU) 2024/1774 asks for: the purpose, scope, timeline and expected outcome, the fall-back and abort steps, and the security impact assessment. Put these in a pull request template that the Git host enforces, with fields for the affected Argo CD Application, the target cluster and namespace, the expected Kubernetes objects that will change, and a link to the test evidence from the pre-production project. The commit history then records who proposed each change, what was reviewed and when it merged. Argo CD adds the sync record on top: it deploys the commit it was pointed at, and the sync history shows the revision that reached each cluster. Argo CD does not decide whether a change was approved. It only applies what Git already contains, so the approval has to be enforced before the merge.

The approval control lives in the Git host, not in Argo CD. Required reviews, code owner rules for the Argo CD project directories, blocked direct pushes to the target branch, and required status checks for manifest validation all have to be configured in repository settings. Confirm for your Git host whether an approver can also be the author of the commit, whether approvals are dismissed when new commits are pushed, and whether administrators can bypass branch protection. Those settings decide whether the implementer and approver are really different people. Use separate identities for both, and make sure the Argo CD sync permission is not held by the author. Otherwise the same person can merge and sync, and the separation Article 17 requires exists only on paper.

Argo CD should sync only the approved commit. Set the target revision of each production Application to a protected branch or tag, and avoid automatic sync against a branch that anyone can push to. Automated sync is a design decision to record: it removes the manual gate, so it fits only where the merge itself is the approval. The platform also cannot see what was tested or whether the test ran on the same commit, so the pipeline should link the merged commit to the test result. Plan the fall-back as a revert commit that goes through the same review, and confirm with your team how a revert is approved during an incident. Labeled as an example: a team might require two approvals for projects/payments changes but one for documentation-only folders.

Evidence Argo CD produces and how to retain it

Most of the evidence for an ICT change under Article 17 sits in three places: Git, the Argo CD control plane and the destination cluster. Each source has its own export method and its own retention gap, so the change record is only complete when all three are captured. Retention periods and formats are decisions your institution must confirm against its supervisor-facing policy.

Git commit and pull request history

The pull request is the approval record: the request, the reviewers, the approval and the merge commit that Argo CD syncs. Confirm your Git host keeps approvals and review comments, not only the merged diff, and that protected branches stop force pushes that would rewrite the record. Export pull request metadata on a schedule, because the host's own retention settings may be shorter than your policy. Check that the approver and the author are different accounts.

Argo CD sync history and application events

Argo CD records each sync with its revision, timestamp and initiating user, and application events show health and sync status changes. Capture these through the API or CLI and store them outside the Argo CD instance, since history depends on the cluster's Argo CD state. Verify that a sync triggered by automation is attributed to the automation identity, not to a shared human account. This is the record that ties a merged commit to a deployed change.

Kubernetes events and audit logs

Kubernetes events show what the controller applied, failed or retried, but they expire quickly by default, so they need to be shipped to central storage. The Kubernetes API audit log is the stronger record of who changed an object directly. Check that API audit logging is enabled on each destination cluster and that Argo CD's service account activity is included. Use these records to spot out-of-band changes that bypassed Git.

RBAC definitions and SSO group mappings

Argo CD projects, RBAC policies and the mapping of identity provider groups to roles define who can approve, sync and administer. Export these definitions from Git as versioned manifests so that each state is traceable to a commit. Where roles come from SSO group claims, retain the group membership snapshot or the identity provider's audit trail, because a change in group membership changes effective access. Note the Argo CD 3.0 change to the user ID claim when reviewing mappings.

Admin account disablement records

The built-in admin account should be disabled once local users or SSO are configured. Keep a record of the setting change, the commit or manifest that made it, and the date it took effect. Confirm the disablement by checking the configuration and by testing that a login with the admin account fails. Store the identity provider's record of who holds emergency access, since that is what an examiner will ask to see when reviewing privileged access.

Retention periods and export format

Your supervisor-facing policy decides how long each record is kept, what format it takes and who can read it. Agree these with the compliance owner before the first audit cycle, and map each source above to a retention owner. Test a restore of an exported sync history so you know the file remains readable. Immutable or write-once storage helps prevent later alteration, but confirm the choice fits your data classification rules.

Separating approvers from implementers in Argo CD

A single-project model places every application in one Argo CD project and relies on RBAC policy alone to separate roles. It is the simplest layout to install and the easiest to misconfigure, because every user who can sync one application can usually sync all of them. It can be defensible for a small estate with one change board, but the separation then rests on policy text and on who holds the admin role, which auditors will test.

Shared sync rights: Any role granted applications, sync in the project can deploy to every environment the project targets.
Limited boundary: The project's allowed destinations and source repositories are the only hard fences, so production and test clusters must be separated by policy rather than by project.
Simple evidence: One project and one policy file are easy to export, but a single mistake in the policy affects all environments.
Approval outside Argo CD: Approval must be enforced in Git (protected branches, required reviewers) because Argo CD alone cannot tell who approved a change.

Before relying on this model, confirm with your change board whether a single project meets the separation expectation for each system in scope.

Configuration sequence for a DORA-aligned change flow

This sequence turns a default Argo CD installation into a controlled change path, where access, approval and rollback are set up before any production sync is allowed. Each step ends with a check you can record as evidence for the change management procedure.

Connect single sign-on and disable the admin user
Connect Argo CD to your identity provider, either through the bundled Dex connectors or directly through an existing OIDC provider, so every person signs in with a named account. Once local users or SSO are working, set admin.enabled to false, as the user management documentation recommends for the built-in admin user. Done means a test login succeeds through SSO and the admin login is refused, and you have saved both results with the change records.
Define projects for each environment
Create one Argo CD project per environment or trust boundary, such as a separate project for pre-production and one for production. Limit each project to its approved source repositories, destination clusters and namespaces, so an application in one environment cannot deploy into another. Done means you can show the project definitions in Git and a test application that targets the wrong cluster is rejected.
Configure RBAC for separated roles
Map identity provider groups to Argo CD roles so that people who request changes, people who approve them and people who operate the platform hold different permissions. Remember that since Argo CD 2.14 to 3.0, update and delete permissions apply only to the application itself, and log access needs an explicit logs, get permission. Done means a test account in the requester role cannot sync production, and an access review export lists who holds each role.
Enforce pull request review in the Git host
Set branch protection on the repositories that hold Argo CD application and configuration manifests so that changes reach the deployed branch only through a pull request with a required approver who is not the author. The Git host, not Argo CD, is the control that records the approval, so confirm the exact settings with your Git host's documentation. Done means a direct push to the protected branch is refused and each merged pull request shows its reviewer.
Set sync policies deliberately per environment
Choose automated sync for non-production projects where fast feedback is useful, and manual sync for production projects so that a named operator triggers each deployment after approval. Keep self-heal and pruning decisions documented for each application, because they determine whether out-of-band changes are reverted automatically. Done means the policy for each project is recorded in Git and a production application shows manual sync in its settings.
Define repositories as Kubernetes Secrets
Register every Git repository and its credentials as a Kubernetes Secret, since Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap. Restrict who can read and change these Secrets with the same access controls you apply to the cluster. Done means the repository list shows only approved sources and the Secrets are absent from the Git repositories.
Document the rollback procedure by reverting commits
Write a fall-back procedure that reverts the offending commit on the protected branch through a reviewed pull request, then lets Argo CD sync the previous desired state. Include the abort criteria, the owner who decides to roll back and the steps for an emergency change that is reviewed after implementation. Done means the procedure is approved, and a rehearsal in a non-production project shows the cluster returning to the earlier revision.

What Argo CD does not cover for DORA change management

Argo CD records and enforces what is merged and synced, but several Article 17 duties sit outside the cluster. The cards below name those gaps and say which ones the institution must answer through its own ITSM tooling and change policy.

Impact assessment on existing measures

Article 17 requires an assessment of how each change affects existing security measures. Argo CD shows the diff that will be applied, but it does not judge whether a network policy, admission control or logging rule is weakened by that diff. Put the assessment in the pull request template or the ITSM change record, and require the approver to sign it before the sync is allowed. Ask who owns that review for each application.

Testing and quality assurance roles

Argo CD can gate a sync on a passing pipeline, but it does not define who tests, what test evidence is acceptable, or who signs off quality assurance. Those roles and their criteria belong in your change procedure. Confirm that the test result is linked from the merge request so the auditor can trace a change to its test.

Emergency change review after implementation

Emergency changes may be applied with safeguards and must be reviewed after implementation. An out-of-band kubectl edit or a manual sync override will show as drift, but Argo CD does not record why the change was made or who approved it afterwards. Require a retrospective ticket for every emergency sync and commit the change back to Git, then reconcile the two records during review.

Stress testing after significant changes

The Article 17 stress-testing requirement applies to central counterparties and central securities depositories. Argo CD has no stress-testing function, so the test plan, load profile and results must come from your test environment and testing program. If your entity falls under that scope, confirm the requirement with your competent authority before you scope the work.

Patch and update policy

Article 9 requires documented patch and update policies. Argo CD's release process ships minor releases on a three-month cadence and only patches the three most recent minor versions, so an older release falls out of patch coverage quickly. Write the upgrade window, the supported version range and the owner of each decision in your policy, then track current versions in your inventory.

Change records for non-Git changes

Changes made outside Git, such as cloud console edits, database schema changes, firmware updates or network device changes, are not captured by Argo CD. Your ITSM system must record them with purpose, scope, timeline, fall-back and abort steps. Ask whether your ITSM tool can link those records to the Git commit history where a related Kubernetes change exists.

Repo-server risk from untrusted content

The Argo CD repo-server runs Helm and Kustomize against repository content, so a malicious or unreviewed repository can affect manifest generation and reach files outside its intended path. This is a security control, not a change-record gap, but it affects whether a reviewed commit is the thing that actually deploys. Restrict repositories to approved sources and review chart and overlay changes with the same rigor as application code.

Handling emergency changes and fall-back under Article 17

Article 17 of Delegated Regulation (EU) 2024/1774 requires emergency changes to follow safeguards and to be reviewed and approved after implementation, so the institution must design the emergency path before it is needed. In an Argo CD setup, the simplest record is a dedicated emergency route in Git: the implementer commits the fix to the branch the Application tracks, the pull request or commit message carries the emergency reference, and a named approver reviews the change after the sync. Teams should decide in advance who may invoke the route, which Argo CD projects and Applications it covers, and whether direct kubectl edits are blocked for everyone else. Argo CD records the sync, but it does not perform the post-implementation review. That review is a human control, and the institution must assign the reviewer, set a deadline and keep the approval with the change record.

Reverting a commit is a practical fall-back, because Argo CD syncs the cluster back to the prior desired state from Git. The institution still has to document the fall-back and abort procedure itself: which commit is the known-good baseline, who decides to revert, how a revert interacts with database migrations or other changes that cannot be undone by re-syncing, and when the team stops and escalates instead. Confirm with your own engineers whether automated sync with self-heal is enabled for the affected Applications, since that setting determines whether a manual change is overwritten during an incident. Test the revert path in a pre-production project so the timing and side effects are known before a real emergency. The written procedure should name the verification steps after a revert, such as checking health status and the sync result.

What do financial entities ask before hiring help with DORA change evidence?

Does Argo CD alone satisfy DORA change management requirements?

No. Argo CD is a delivery tool, and DORA Article 17 of Delegated Regulation (EU) 2024/1774 requires a documented ICT change management procedure that your institution owns and runs. Argo CD can supply part of the evidence: Git pull requests as the record of request and approval, sync history as the record of implementation, and reverts as the fall-back path. Your procedure still has to define risk assessment, testing roles, emergency change review and how each change's impact on security measures is assessed. Treat the tool as one control inside a documented process, and have your compliance function confirm the mapping before relying on it.

How much effort does DORA change evidence work take and what drives it?

The effort depends on how many systems are in scope, how many clusters and environments exist, how mature your Git workflow already is, and how much of the change procedure must be written from scratch. Cost has two parts. The first is one-time work: designing branch protection, project boundaries, RBAC and the approval path, then documenting the procedure and running a controlled test. The second is recurring work: reviewing change records, reviewing access, and updating the procedure when Argo CD is upgraded. Ask any partner for a quote that breaks these parts out and names the systems covered, since a fixed-scope written agreement is the normal basis for an engagement.

What does the institution's team need to provide for this work?

The work needs named owners on your side before design starts. Typically this includes a change manager or compliance lead who can state the approval rules, a platform owner who controls the clusters and Git hosting, an identity team that provides SSO groups, and a security reviewer who signs off the risk assessment. You also need access to existing change tickets, incident records and current deployment practices so the new flow reflects what you already do. Confirm these roles in the written scope, because gaps in approval ownership are the most common reason change evidence fails to meet the procedure you documented.

Can our own engineering team implement this without a partner?

Yes, many institutions do this in house, and the Argo CD documentation covers the technical building blocks. The questions to answer honestly are whether your team has time to design and test the approval model, whether it can keep the procedure current through upgrades, and whether an independent reviewer exists who did not build the controls. Pay particular attention to the separation of approvers and implementers that the regulation requires. An outside partner can help with the design and evidence work, while your team keeps ownership of the procedure, approvals and day-to-day operation.

How long does a DORA change evidence engagement take?

Duration depends on scope, the number of environments and systems covered, and how much of the procedure and approval model already exists. It is not a figure this page can state. Ask for a timeline in the written scope, with milestones for design review, configuration, testing of the change flow and handover of the evidence records. Any timeline should be agreed in writing before work starts, and it should show which dependencies sit with your team, such as identity group provisioning and change approvals.

Who issues the attestation that our change controls comply with DORA?

DeployOpen does not issue audit reports, attestations or certifications. DORA sets no certification scheme, and competent authorities supervise compliance using their powers under Article 50. The only authority-issued attestation the Regulation provides for concerns a threat-led penetration test under Article 26(7). Your internal audit function, or an independent assessor appointed according to your supervisory expectations, performs the review of your change controls. DeployOpen prepares the systems, controls and evidence that those reviewers examine.

What does a quote for DORA change evidence depend on?

A quote follows from the written scope. DeployOpen does not publish a price list. The scope should name the Argo CD instances and clusters covered, the environments and Git repositories, the approval and emergency change paths, the identity integration, the testing approach for controlled changes, and the evidence records to be produced. Ask whether the quote separates one-time design and build work from any recurring retainer for ongoing support, upgrades and testing, and what your team must supply. Items left out of scope should be listed explicitly so both sides know what remains with your team.

Which DORA controls does the Argo CD evidence support, and which stay manual?

Argo CD supports the parts of Article 17 that concern recording and implementing changes from Git, including who requested and who approved a change, which revision was applied, and how to revert. Manual controls remain for risk assessment, impact on existing security measures, emergency change review after implementation, and any stress testing required after significant changes. Engineers should verify each mapping with their compliance lead and document where a control is performed by a person rather than by the tool.

How DeployOpen scopes and delivers DORA-aligned Argo CD configuration

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms in infrastructure you control. For Argo CD in a DORA change management context, we turn the Git change flow, projects, RBAC and sync controls into a written procedure and the records that support it, then leave your team able to run them.

How we scope

Engagements are fixed-scope, with the Argo CD clusters, repositories and change roles agreed in writing before work starts.
Scope maps each change type to the Article 17 documentation fields your procedure must hold.
We confirm which environments, projects and clusters count as production and which approvers and implementers are separated.
Quotes follow from the written scope, so ask for each workstream and deliverable to be itemized.

How we build

We configure Git branch protection, pull request approvals and Argo CD projects so that merging and syncing are done by different roles.
We set up SSO through your identity provider and map groups to Argo CD roles, with the built-in admin account disabled.
We document the emergency change path, including post-implementation review, and test fall-back by reverting commits in a non-production cluster.
We verify that sync history, audit records and drift alerts are retained where your assessors can sample them.

How we hand over

You receive the change management procedure, role matrix, Argo CD configuration and runbooks written for your own staff.
We walk your engineers through approval, sync, rollback and emergency change steps with the records each step produces.
Evidence samples are documented so your internal audit or compliance team knows what to pull and where it lives.
Your team owns the final sign-off on the procedure, and your legal and compliance advisers confirm how it maps to DORA.

How we support

Ongoing support, Argo CD upgrades and continuous testing are available as retainers, scoped in writing.
Upgrade reviews check RBAC, resource tracking and repository settings against the official upgrade notes before each move.
We agree with you how often role reviews, access reviews and fall-back tests are repeated and who records the results.
Support scope, response expectations and service levels are set in the retainer agreement, so confirm them before signing.