Argo CD for ISO 27001 change management

How Argo CD supports ISO 27001 change management evidence

If you run ISMS responsibilities for production Kubernetes, you need to show that changes follow controlled procedures. Argo CD helps with A.8.32 change management and A.8.9 configuration management by holding desired state declaratively in Git and recording what was synced to each cluster, but it does not write your ISMS procedures, approve changes or certify anything. Those decisions stay with your change board, your control owners and your certification body. Keep that boundary clear in your scope document from the start. For context, A.8.32 merges four controls from the 2013 edition (A.12.1.2, A.14.2.2, A.14.2.3 and A.14.2.4), and the 2022 standard lists 93 Annex A controls in total. ISO does not issue certificates, and neither does DeployOpen. Accredited certification bodies do, so confirm early which evidence they expect to sample.

The evidence an auditor samples usually comes from three places: the Git history of the repository that holds the Application manifests and their Kustomize or Helm inputs, the approval record on the pull request that changed them, and the Argo CD sync history for the matching Application. Together they show what was proposed, who agreed to it, and what actually reached the cluster. Decide which branch or tag is the only source for production, who can merge to it, and whether the Argo CD Application tracks that same ref. A mismatch between those three is the most common gap auditors find, so test it with a sample change before the audit window opens. Argo CD's security documentation also notes that the repo-server runs Helm and Kustomize on repository content, so restrict which repositories may be used as sources.

Drift detection supports configuration management evidence, but only if you decide what happens to it. Argo CD reports applications that differ from Git, and you should define whether that state is treated as an unauthorized change, a deviation to record, or a condition to correct by sync. Access controls matter here too: under Argo CD 2.14 to 3.0, update and delete RBAC apply only to the application itself, and the admin account should be disabled once SSO or local users are configured. Confirm these settings in your own environment and export them as records, since the auditor will ask how you know they were in force during the period under review.

Mapping ISO 27001 A.8.32 and A.8.9 to Argo CD capabilities

This table maps each relevant Annex A control and NIST crosswalk entry to the Argo CD capability that supports it, the configuration it depends on, and the work that stays with your people and processes. Read each row as a claim you must still evidence, since a supported control is not the same as a satisfied one. The main takeaway is that Git and Argo CD produce strong change records, but the approval rules, emergency process and ISMS documentation remain your responsibility.

Requirement	Argo CD capability and source	Configuration needed	What remains manual
A.8.32 Change management: changes to information processing facilities and systems follow change management procedures	Git commits and pull requests record each desired-state change, and Argo CD syncs only what is declared in the repository	Protect the production branch, require reviews before merge, and point each production Application at that branch only	Defining the change procedure, risk assessment, approval thresholds and emergency change rules
A.8.9 Configuration management: configurations, including security settings, are established, documented and monitored	Git holds the declared desired state, and Argo CD reports drift between Git and the live cluster	Store manifests in version-controlled repositories, enable self-heal where appropriate, and keep the admin user disabled with admin.enabled set to false	Approving the baseline configuration, deciding which drift is acceptable, and documenting the security settings
A.8.19 Installation of software on operational systems: software is installed under controlled procedures	Argo CD deploys only images and manifests referenced in approved Git revisions, and the sync history records what was applied	Pin image digests or versions in Git, restrict repository access, and use Projects to limit which sources and destinations each team can use	Vetting third-party charts and images, and deciding who may add a new source repository
A.8.31 Separation of development, test and production: environments are separated	Argo CD Projects scope which repositories, clusters and namespaces an Application may use	Create separate Projects and clusters or namespaces for non-production and production, with RBAC restricting who can sync production	Confirming that network and account separation exists in your infrastructure, which Argo CD does not enforce on its own
NIST SP 800-53 CM-3 Configuration change control (crosswalk to A.8.32)	Auditable Git history plus Argo CD sync records support change control evidence	Require signed or reviewed commits if your policy demands it, and retain Git and Argo CD audit logs outside the cluster	Change board decisions and approval records, which must exist outside Git if your process needs them
NIST SP 800-53 CM-5 Access restrictions for change (crosswalk to A.8.32)	Argo CD RBAC limits who can sync, update or delete Applications, and Projects restrict targets	Map SSO groups to roles, keep update and delete permissions narrow, and grant the logs permission only where needed	Periodic access reviews of groups, roles and service accounts
Mapping caveat from NIST: mapped controls are not always equivalent	The crosswalk relates control IDs but does not show that one tool satisfies both controls	Document which parts of each control Argo CD covers and which parts your procedures cover	Confirming equivalence with your certification body or auditor, since DeployOpen does not issue audit opinions

How Git, projects and sync controls form the change record

The change record for an Argo CD deployment starts in Git, not in Argo CD. A proposed change is a pull request against the repository that holds the desired state, and the review, approval and merge metadata that the Git host keeps is the first link an auditor can follow. Argo CD then syncs the merged commit to the cluster, and the sync operation, the revision it applied and the resulting Kubernetes events form the second link. To trace a sampled change back to an approver, the reader should be able to start from the Kubernetes object or the Argo CD application history, read the commit revision it recorded, and find the merged pull request and its reviewers in the Git host. Confirm that your Git host retains pull request and approval records for the retention period your ISMS sets, because Argo CD itself does not hold them.

Argo CD's own controls decide who can trigger and observe that second link. In Argo CD 3.0, repositories must be defined as Kubernetes Secrets rather than in the argocd-cm ConfigMap, so the set of repositories an application may sync from is itself a managed object that should be changed through the same reviewed flow. The 2.14 to 3.0 upgrade notes also state that update and delete RBAC now apply only to the application itself, so a role that can sync an application does not automatically gain rights over the resources it manages, and that logs access requires an explicit get permission on logs. Record which roles hold sync, update and logs permissions in each project, because an auditor sampling a change will ask who could have run it and who could read the output. Confirm these grants against your own RBAC policy after each upgrade, since the notes describe them as changed behavior.

Projects are the boundary that ties these records together. A project restricts which repositories, destination clusters and namespaces an application may use, so the evidence that a production change came from an approved repository and landed in an approved target is the project definition plus the application's sync history. Keep project definitions in Git under the same pull request process, and treat any edit to a project as its own change with its own approval. Ask your implementation team to show, for a sample application, how the project limits its source and destination and how that limit is recorded in version control.

Evidence auditors sample from Argo CD and how to keep it

An auditor testing A.8.32 and A.8.9 will ask who approved a change, what was deployed, when it reached the cluster, and whether the running state still matches the approved baseline. Each card below is a record Argo CD or Git already produces, along with how to export it and keep it. Retention periods come from your own ISMS and its risk and legal requirements, not from Argo CD.

Git commit and pull request approvals

Every desired-state change should exist as a reviewed pull request. Export the merge history, reviewer approvals and branch protection settings from your Git host, and retain them in your evidence store. Check that the approval rule blocks direct pushes to the branch Argo CD tracks, and that approvers are not the same people who authored the change. Ask whether your Git host can export approval records in a form your auditor can sample without manual reconstruction.

Argo CD application sync history

Argo CD records each sync operation with its revision, initiator and result. Capture this history through the Argo CD API or CLI on a schedule, because the in-cluster history is limited and can be pruned as applications change. Confirm that syncs triggered by automation are attributable to a specific identity, and that manual syncs from the UI or CLI are not indistinguishable from automated ones.

Kubernetes events and audit logs

Kubernetes events show what Argo CD applied and what changed outside it, while API server audit logs show which identity made each request. Forward both to your central log platform and set retention there. Confirm that the audit policy captures create, update and delete calls against the namespaces Argo CD manages, since events alone expire quickly and do not identify the requester reliably.

RBAC and SSO configuration as code

Argo CD roles, project bindings and SSO group mappings decide who can sync and who can change what. Store them as declarative manifests in Git so every permission change has its own commit and approval. Pay attention to the Argo CD 3.0 changes: repositories now live in Kubernetes Secrets, and Dex RBAC keys on the federated_claims.user_id claim, so exported configuration from older versions needs review before it can serve as evidence.

Admin.enabled false evidence

The built-in admin account should be disabled once SSO or local users are configured. Record the admin.enabled value in the declared Argo CD configuration and keep a dated export showing it is false. Also retain the exported list of accounts and their capabilities, so the auditor can see that no shared credential can bypass Git-based change flow.

Retained declarative manifests as baselines

The manifests in Git, tagged or recorded at each release, serve as the configuration baseline against which running state is compared. Keep periodic snapshots of rendered manifests and the Argo CD drift status for each application, so you can show what the approved configuration was at a given date. Confirm how your team handles drift that Argo CD reports but nobody resolves, because unresolved drift is a finding in its own right.

What Argo CD covers versus what your ISMS must provide

Argo CD can enforce parts of change control in the cluster. It cannot decide which changes are acceptable, and it does not produce an approved procedure. The platform side is the set of settings you own and can show an auditor: how users authenticate, which Git branches and paths feed each Application, which projects can deploy where, and whether automated sync is switched on for each environment.

Local admin account: The user management documentation recommends using the built-in admin user only for initial setup and disabling it with admin.enabled set to false once SSO or local users exist.
Project boundaries: Projects, RBAC policies and allowed source repositories and destination clusters limit which changes a team can make and where.
Sync policy: Decide per environment whether automated sync, self-heal and pruning are enabled. Production often requires manual sync after review.
Repository definitions: Repositories must be defined as Kubernetes Secrets since Argo CD 3.0, so record where those definitions are stored and who can change them.
Version currency: Confirm the minor version you run still receives patch releases under the project's release cadence.

Check that each setting is recorded in Git or your configuration baseline, with a dated owner, so the platform configuration can be compared with what is running.

Controls on people are where most change management failures appear in practice. Argo CD can separate who merges from who syncs, but only if your organization names the people, assigns the roles and keeps those assignments current. Identity provider groups, Argo CD roles and approval records must agree with each other.

Named approvers: Assign approvers by name or group for each project, and record who holds that authority and when it was granted.
Role separation: Use RBAC so that people who author changes cannot also approve or sync production without a second person involved.
Group mapping: Map identity provider groups to Argo CD roles through SSO, and review those mappings on a schedule. Dex RBAC uses the federated_claims.user_id claim in Argo CD 3.0 and later.
Automation accounts: Document which service accounts can sync and what they are allowed to change.
Access reviews: Remove leavers and role changes promptly and keep the review record.

Check that the people listed in your procedure match the groups and roles in the cluster, and that an auditor can trace each sync back to an identifiable person or approved automation.

Gaps Argo CD does not close for ISO 27001

Argo CD gives you a declared desired state and a sync record, but it does not decide whether a change is safe, cover every system that affects production, or protect what sits outside Git. Each card below marks a boundary your ISMS procedures must cover with other controls and records.

Change impact assessment and testing

A merged pull request shows who approved a manifest, not whether anyone assessed the change's effect on availability, data or dependent systems, or tested it beforehand. Those assessments and test results usually live in a ticketing system or test report. Confirm that every change class in your A.8.32 procedure links to an impact assessment and test evidence, and that the Git change record points to them.

Emergency changes made outside the flow

Anyone with cluster access can run kubectl or edit a resource directly, and Argo CD will show the result as drift without recording who made it or why. Your procedure must define the break-glass path, its approver, and the follow-up step that brings Git back in line. Confirm that emergency changes are logged in your change system and reconciled into Git within a time limit you set.

Drift in resources Argo CD does not manage

Argo CD only compares resources that belong to an Application it tracks. Cluster-level objects, resources created by other operators, and anything in namespaces outside the Application's destinations fall outside its view. Inventory which resource kinds and namespaces are in scope for your configuration baseline, and confirm a separate detection method covers the rest.

Secrets stored outside Git

Git holds references to secrets, not their values, and the secret store, its access policy and its rotation records sit with a different system. An auditor testing configuration management will ask how secret values reach the cluster and who can read them. Confirm which secrets operator or external store your design uses, and keep its access and rotation logs in scope for the same audit.

Repo-server risk from untrusted repositories

The repo-server runs Helm and Kustomize against repository content, so a repository you do not control, or a chart that pulls files from outside its directory, can influence what Argo CD renders. Argo CD's security documentation calls out this exposure. Confirm which repositories are allowed in each project, who can change them, and whether out-of-tree file access is restricted in your configuration.

Patching within supported minor versions

Only the three most recent minor versions of Argo CD receive patch releases, so a deployment that stays on an older minor loses security fixes. Patching also changes the configuration baseline, because upgrade notes can alter RBAC and tracking behavior. Confirm your upgrade window, who approves each minor version change, and how you test the new baseline before promoting it.

Configuring Argo CD for an auditable change flow

This sequence turns Argo CD into a change path where every production state traces back to an approved Git commit, a named role and a sync record. Each step produces a specific artifact that an auditor can sample against the ISMS change procedure.

Confirm the ISMS change procedure first
Before any configuration, the information security or change owner confirms the written change management procedure: what counts as a standard, normal and emergency change, who approves each class, and what record must exist before a change reaches production. The Argo CD setup is then designed to enforce that procedure rather than invent a new one. The step is complete when the procedure is approved, versioned and mapped to the Git and Argo CD controls in the following steps.
Protect the Git branch and require reviews
The platform team configures the Git host so the branch Argo CD tracks for production cannot be changed by direct push. Required pull request reviews, status checks and restrictions on who can merge are set to match the approval roles in the procedure. Confirm the exact branch protection options with your Git host, since they vary by product. The step is complete when a test commit to the protected branch is rejected and a test pull request cannot merge without the required approvals.
Create projects per environment with restricted destinations
The platform team creates one Argo CD Project for each environment, such as development, test and production, and limits each Project's source repositories, destination clusters and namespaces. Production Projects should not accept applications from development repositories, which keeps unreviewed changes out of the production path. Cluster-scoped resource permissions are restricted to the minimum the workloads need. The step is complete when an application pointed at a disallowed destination is rejected by Argo CD and the Project definitions are stored in Git.
Configure SSO with group mapping
The identity team connects Argo CD to the organization's identity provider, either through the bundled Dex with a supported connector or through a direct OIDC integration. Provider groups are mapped to Argo CD roles so that access follows the identity lifecycle and no one gets local accounts. In Argo CD 3.0 and later, the upgrade notes change how Dex-based RBAC reads the federated_claims.user_id claim, so check that mapping during the build. The step is complete when a test user from each group signs in and sees only the permissions assigned to that group.
Set RBAC so sync rights differ from merge rights
The Argo CD RBAC policy grants sync and override permissions to the operations group and leaves merge rights in Git with the reviewer group, so the person who approves a change is not the person who deploys it. Update and delete permissions apply only to the application itself, and logs access requires an explicit permission, which should be granted only to roles that need it. The step is complete when a test account in the operations group can sync an approved application but cannot merge to the protected branch, and the policy file is versioned.
Disable the built-in admin user
Once SSO and named local accounts are working, the platform team sets admin.enabled to false, as the user management documentation recommends for production. The admin account is used only during initial setup, and its password is stored under the break-glass process defined in the procedure. Any emergency access then goes through named identities that appear in the audit trail. The step is complete when a login attempt with the admin account is refused and the configuration change is recorded in Git.
Enable drift detection and alerts
The platform team confirms that automated sync is set deliberately for each Project and that self-heal is enabled only where the procedure allows it, since unmanaged manual changes should be detected and reconciled. Notifications are sent to the operations channel and the security monitoring tool when an application falls out of sync or when a sync fails. The step is complete when a manual change to a test resource produces a drift event and an alert, and that event is visible in the notification history.
Define HA and backup so records survive
The platform team deploys Argo CD with the high availability manifests on a cluster that meets the documented minimum of three nodes, since pod anti-affinity rules require it, and confirms that IPv6-only clusters are not used. Because Argo CD keeps its state in Kubernetes objects and Redis is a disposable cache, the backup plan focuses on the Git repositories, the Argo CD custom resources and the cluster configuration, and includes a tested restore. Confirm recovery objectives with the business owner, since the documentation does not set them. The step is complete when a restore into a separate cluster reproduces the applications and their sync state.
Document the evidence export routine
The compliance owner writes a routine that exports the evidence an auditor samples: protected branch settings, approved pull requests and their reviewers, Project and RBAC definitions, sync history, drift and failure notifications, and Kubernetes events for the period. Each export is stored with a date, the person who ran it and the Git commit it reflects, and the routine states how often it runs and where it is kept. Ask your auditor which samples they will take before finalizing the list. The step is complete when a sample change can be traced from request to approval to sync to record using only the exported files.

Why certification stays with an accredited certification body

ISO does not certify organizations. Certification to ISO/IEC 27001 is issued by an accredited certification body after it audits your information security management system against the standard. Accredited ISMS certification bodies work to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. Your Argo CD evidence, such as Git history, pull request approvals, RBAC settings and sync records, is only input to that audit. The auditor decides whether it is sufficient, and the auditor's sampling will shape what you need to produce.

Certification also runs on a cycle. Under ISO/IEC 17021-1, a management system certificate lasts three years, and the certification body must carry out at least one audit, either surveillance or recertification, in every calendar year of that cycle. Plan for that rhythm rather than a single pre-audit push: the change records and the Argo CD configuration you show in year two should match what you showed in year one. Ask your certification body which audit plan it will apply and how it expects evidence to be packaged for each visit. If your organization still holds a certificate to the 2013 edition, note that under IAF MD 26:2023 those certificates had to expire or be withdrawn by 31 October 2025, so the 2022 edition is the one your Argo CD mapping must support.

DeployOpen prepares the system, the controls and the evidence. We can configure projects, RBAC, sync policies and retention of change records in your environment, and document how they map to A.8.32 and A.8.9. We do not issue audit reports, attestations or certifications, and the mapping in this guide does not replace the assessment your certification body performs. Before scoping any readiness work, confirm with your certification body which evidence it will sample, and confirm with your own compliance lead which Argo CD records your retention policy requires.

Questions buyers ask before hiring help for ISO 27001 change controls

Can our in-house team configure Argo CD for change control on its own?

Yes, many platform teams install and configure Argo CD without outside help, but the work is more than installing a controller. Your team needs to design the Git repository layout, branch protection and review rules, Argo CD projects and RBAC, SSO integration, and the evidence you will keep. Ask whether anyone on the team has run Argo CD in production with SSO and project boundaries, and whether they have time to document the control design for an auditor. An outside partner is most useful when the team lacks that experience or when the change records must be assembled in a short window before an assessment.

What drives the effort of an Argo CD change control project?

The main drivers are the number of clusters and environments, how mature your current GitOps practice is, and how much identity and evidence scope you need to cover. Each cluster adds registration, network paths and access rules to review. Teams that already deploy from Git with pull requests need less redesign than teams deploying by hand or from CI pipelines with direct cluster access. SSO scope matters because group-to-role mapping must be tested against each identity provider. Evidence scope matters because the sample sets an auditor selects must be traceable across Git, Argo CD and Kubernetes events. Ask for each of these to be listed as a separate line in the written scope.

What does a fixed-scope engagement need from our side?

A fixed-scope engagement needs named owners and decisions made before work starts. You should provide access to the Git hosting platform, the target clusters and the identity provider, plus a list of the environments and applications in scope. You also need to confirm who approves production changes, which roles map to which teams, and which records your change process already produces, such as tickets or review approvals. Your security and compliance leads should agree the control statements the evidence will support. Most delays come from unresolved approval rules or from waiting for access, so schedule those inputs with the written scope.

How long does an Argo CD change control project take?

Duration depends on the scope you agree in writing, not on a standard timeline. A single cluster with one identity provider and a clear approval process is a much smaller job than several clusters, multiple teams and an existing set of manual deployments to migrate. Ask the partner to show which phases are included, such as design, build, verification and evidence walkthrough, and what each phase depends on from your side. Also confirm how the timeline changes if access or approvals arrive late. Because no duration is fixed for this topic in advance, treat any number you hear before the scope is written as a guess.

Does Argo CD alone make us compliant with ISO 27001?

No. Argo CD supports controls such as A.8.32 change management and A.8.9 configuration management by keeping desired state in Git, enforcing controlled promotion and surfacing drift, but it does not make an organization compliant. ISO/IEC 27001 is assessed at the management system level, so you still need documented policies, risk decisions, roles, review procedures and internal audit activity. Certification is issued by an accredited certification body, not by a tool or by DeployOpen. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors decide conformity. Ask any partner to show how each claim maps to a specific record an auditor can sample.

How do Argo CD upgrades affect our change evidence?

Upgrades can change how access, resource tracking and repository configuration behave, so each upgrade needs its own change record and verification. The 2.14 to 3.0 upgrade notes, for example, changed how update and delete RBAC applies, required an explicit permission to view logs, made annotation-based resource tracking the default, and moved repository definitions into Kubernetes Secrets. Before upgrading, record the target version, the tested behavior of your RBAC and sync rules, and the approval for the change. Patch releases on a supported minor version and minor releases on a published cadence should follow the same change path. Confirm with your partner how upgrade records are kept alongside the Git history.

Which Argo CD records would an auditor ask to sample first?

Auditors usually start with a sample of production changes and trace each one from request to approval to deployment. For Argo CD, that means the merged pull request or commit, its reviewer approvals, the sync operation that applied it, and the Kubernetes events showing the result. They also ask who had permission to sync production, whether admin access is disabled, and how drift was detected and resolved. Before the assessment, confirm which of these records your systems keep, for how long, and where they are stored. Ask your partner to demonstrate the trace on a real example from your environment rather than a sample from a demo.

Confirming your ISO 27001 scope before the first sync

Before any design work starts, agree in writing which clusters, namespaces and Argo CD applications fall inside your information security management system (ISMS) scope. The scope statement decides which Argo CD instances, Git repositories and projects an auditor will test against A.8.32 change management and A.8.9 configuration management. Confirm with your certification body whether a single Argo CD instance managing several clusters is in scope as one system, and whether the Git hosting platform, the secrets store and the container registry are included or treated as suppliers. Ask internal audit to walk through the asset inventory so that each cluster and its Argo CD applications map to a named owner and a named information system.

Next, ask the certification body and your internal auditors which change records they will sample. Typical samples include the Git merge or pull request that introduced a change, the approval recorded on it, the Argo CD sync history for the matching revision, and the Kubernetes events from the sync. Confirm how long those records must be retained, whether the auditor expects emergency changes to be listed separately, and how they want drift between Git and the live cluster reported. These answers determine whether the Argo CD Application status, the audit log and the repository history need to be exported or kept in place, so settle that before you configure retention or log forwarding.

Finally, list the framework crosswalks your customers and assessors actually ask about. NIST's published crosswalk relates A.8.32 to CM-3, CM-5, SA-10 and SI-2, but NIST notes that mapped controls are not always equivalent, so ask customers which mapping they accept before you write a control narrative around it. If you also operate under NIS2 or another regulation, confirm which mapping table your regulator references. Record these decisions in the scope document, because each one changes what evidence the design must produce.

How DeployOpen scopes and delivers ISO 27001 change evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted Argo CD inside your own clusters and networks. For ISO 27001 change and configuration management, the work is shaped around the records your team and your certification body will need to sample, not around a generic installation. Engagements are fixed-scope, with the scope agreed in writing before work starts.

How we scope

Written scope names the Argo CD clusters, Git repositories and environments that fall inside the A.8.32 and A.8.9 evidence boundary.
Scope lists which change types go through pull requests and which, if any, are handled as documented emergency changes.
Scope confirms with your certification body or internal audit which records they expect, and that each record has a named owner.

How we build

We configure Git as the declared desired state, with branch protection, required reviews and separate approver and implementer roles.
We set Argo CD projects, RBAC and SSO group mappings so only approved pipelines and people can sync production applications.
We test drift detection, sync history retention and rollback by reverting commits in a non-production environment before any production cutover.

How we hand over

You receive the configuration as code, the access model, and a control-to-evidence matrix mapping each Annex A reference to its records.
Handover includes a runbook for approvals, emergency changes, drift investigation and how to export sync and audit records for a sample.
We document what Argo CD and Kubernetes retain by default, and which records you must archive separately to meet your retention rules.

How we support

Ongoing support, version upgrades and continuous testing are available as retainers after handover.
Retainer work can include reviewing Argo CD release notes for changed defaults, such as RBAC or resource tracking behavior, before you upgrade.
We agree in writing which evidence reviews, access reviews and configuration checks recur, and who performs each one.

Argo CD for ISO 27001 change and configuration management