How Argo CD helps meet NIS2 configuration and change management duties
An essential or important entity under NIS2 must show that its systems run secure configurations and that changes to them are controlled. Argo CD supports points 6.3 and 6.4 of Annex to Implementing Regulation (EU) 2024/2690 by making a Git repository the declared desired state for Kubernetes workloads, recording every sync in its history, and flagging when live resources drift from what Git says they should be. It does not issue any certificate of compliance, and no national authority certifies a deployment as NIS2 compliant. What it produces is evidence that an assessor can sample during an inspection or security audit.
Several parts of the duty stay with the organization. Its risk assessment decides which configurations are secure and how often they are reviewed. It sets the policy for when a change must be tested before implementation, who approves exceptions, and which compensating measures apply when an exception is granted. Argo CD can carry those decisions in Git, through protected branches, pull request approvals and Argo CD Project boundaries, but it cannot make them. Confirm with your national competent authority and your legal team which obligations apply to your entity, since NIS2 is transposed through national law and Member States may set stricter rules under Article 5.
The ENISA technical guidance of June 2025 lists documented baseline configurations, approved exceptions with compensating measures, configuration snapshots before and after changes, and alerts on unexpected configuration changes as examples of evidence. Git history covers the baseline and approval trail, while Argo CD sync records and drift status cover the deployed state. Your team should decide how often snapshots are exported and retained, and which drift alerts route to on-call staff. Confirm with your Argo CD version that the sync and drift data you plan to retain is available in the installed release, and check the Argo CD release process and cadence page for the patch support window.
Mapping points 6.3 and 6.4 to Argo CD capabilities and configuration
This table pairs each NIS2 implementing requirement in points 6.3 and 6.4 with the Argo CD capability that supports it and the configuration to set. Read each row as a question an assessor will ask, then check the configuration against your own cluster and Argo CD version. The main takeaway is that most of the evidence comes from Git history, Argo CD RBAC settings and sync records, so those settings must be fixed and kept under review.
| Requirement | Argo CD capability | Configuration to set and evidence to keep |
|---|---|---|
| Point 6.3: establish, document and implement configurations | Git as the desired state for each application | Store manifests, Helm values and Kustomize overlays in Git repositories with branch protection. Keep the baseline as the reviewed main branch and retain commit history as the record of what was configured. |
| Point 6.3.2: secure configurations on new systems | Projects restrict source repositories, destination clusters and namespaces | Define one AppProject per environment or team with sourceRepos, destinations and cluster resource allowlists limited to approved values. Export the project manifests from Git as the documented secure baseline. |
| Point 6.3.2: enforcement tools on systems in operation | Automated sync with self-heal and prune | Enable automated sync with selfHeal for production applications where the baseline is final, and review prune settings before enabling them. Confirm the settings per application during the readiness review. |
| Point 6.3.3: periodic and event-driven review | Git review and recorded configuration changes | Schedule reviews of AppProject, RBAC and repository definitions and record them in your change system. After a significant incident or change in operations, review the affected applications and projects and link the review to the commits that changed them. |
| Point 6.4: documented changes | Pull request workflow and Argo CD sync history | Require pull requests with at least one approver who is not the author. Keep sync history and the Git commit SHA deployed to each application as the link from change record to live state. |
| Point 6.4: risk-based testing and assessment before implementation | Separate pre-production and production projects and clusters | Route changes through a non-production Argo CD application and promote the same commit to production. Document which change types need additional testing based on risk, such as changes to ingress, RBAC or network policy. |
| Access control for changes: who can merge and who can sync | Argo CD RBAC policy and SSO group mapping | Set admin.enabled to false once SSO and local users are configured. In 3.0 and later, bind RBAC roles to the federated_claims.user_id claim from Dex where Dex is used. Remove sync and override permissions from developer roles on production projects. |
| Detecting unexpected configuration changes | Drift detection in the Application view and notifications | Confirm each production application shows OutOfSync when the cluster differs from Git. Configure Argo CD Notifications to alert the operations channel on sync failures and drift, and test the alert path before relying on it. |
| Repository inputs under change control | Repository credentials and repo-server behavior | Since Argo CD 3.0, define repositories as Kubernetes Secrets rather than in argocd-cm. Limit which repositories each project can read, because the repo-server runs Helm and Kustomize on repository content. |
Which evidence Argo CD produces for NIS2 auditors
ENISA's June 2025 guidance names a small set of evidence types for points 6.3 and 6.4. Argo CD produces part of each from Git history, pull request reviews, sync records, Kubernetes events and notifications, but not all of it, and the gaps need their own retention plan.
Documented secure baselines
The baseline is the desired state stored in Git: manifests, Helm values and Kustomize overlays for each cluster and project. Tag or protect the release branch that holds the approved baseline so auditors can see which version was live on a given date. Confirm that your repositories keep the baseline separate from ad hoc changes, because an auditor will ask what was approved versus what was merged later.
Approved exceptions and compensating measures
Argo CD does not record why a deviation was accepted. Keep exceptions as reviewed Git changes, with a documented owner, expiry and compensating control, such as a narrower RBAC role or an alert rule. Use a dedicated Argo CD project for exceptions so they are visible. Ask your team to confirm how exceptions are reviewed before they expire, since the tool will keep running them until someone removes them.
Snapshots before and after changes
Git commits give the before and after state of declared configuration, and the sync history in Argo CD records which revision was applied and when. Together they show the exact change set. Note that sync history is kept by Argo CD and may be pruned, so export it on a schedule. Check that your retention settings cover the review period your policy defines.
Pull request approvals as change records
Pull request reviews, approvers and timestamps show who authorized a configuration change before it reached the cluster. This is the strongest evidence for the point 6.4 requirement that changes are documented and assessed before implementation. Confirm that branch protection requires review, that the author cannot approve their own change, and that the Git host retains these records outside your Argo CD installation.
Drift alerts and Kubernetes events
Argo CD marks applications as OutOfSync when the live state differs from Git, and Kubernetes events record resource changes. Argo CD Notifications can send an alert on sync failure or health change to your monitoring or ticketing tool. Test that an out-of-band change actually produces an alert and a ticket, and record that test as evidence. Verify your alert routing with the team that owns the on-call rota.
Records to keep outside Argo CD
Argo CD is not an archive. Store exported sync history, audit logs from the API server, Git repository backups, approval records and alert tickets in a system that your retention policy governs. Confirm with your compliance lead how long records must be kept and who can access them, since access to these records should be controlled separately from the cluster.
Configuring Argo CD for NIS2 change evidence
This sequence sets up Argo CD so that every configuration change to a cluster passes through a reviewed Git commit, every sync and drift event is recorded, and the evidence needed for points 6.3 and 6.4 of Implementing Regulation 2024/2690 can be produced on request.
Restrict the admin user and enable SSO
The platform team installs Argo CD in the cluster it manages, then connects an identity provider through bundled Dex or a direct OIDC integration so people sign in with their own accounts. Once local users or SSO work, set admin.enabled to false, as the user management documentation recommends for the built-in admin account. Confirm the step by signing in with an SSO account, checking that the admin login is refused, and keeping a documented break-glass procedure that the security team has approved. Note that Argo CD 3.0 changed Dex-based RBAC to use the federated_claims.user_id claim, so verify group-to-role mappings against that claim before you rely on them.
Deploy Argo CD in high availability mode
Run the HA manifests on a cluster with at least three nodes, because the HA manifests rely on pod anti-affinity rules to spread replicas. Confirm the cluster is not IPv6-only, since the HA documentation says those clusters are not supported. Because Argo CD keeps its state in Kubernetes objects and treats Redis as a disposable cache, the change record survives component restarts, which supports the continuity of the evidence trail. The step is complete when the application controller, repo-server and API server pods are distributed across nodes and a restart of a single pod does not change application state.
Separate repository and cluster access
Define each Git repository as a Kubernetes Secret, since Argo CD 3.0 no longer reads repository configuration from the argocd-cm ConfigMap. Give repository credentials read access only, and give cluster credentials to the controller rather than to developers. Engineers who merge changes should not hold cluster credentials that let them apply changes directly, so the person who approves a change is not the person who deploys it. The step is complete when a test user can read applications in the UI but cannot run a manual sync against production, and the list of repository Secrets and cluster registrations is stored under change control.
Protect main branches with required reviews
In the Git host, protect the branch that Argo CD tracks for each environment so that changes reach it only through pull requests with at least one approving review from someone outside the author's team. Require status checks for manifest validation where the team has them. This makes Git the approval record for each configuration change, which is the basis for the change documentation that point 6.4 requires. The step is complete when a direct push to the tracked branch is rejected and a merged pull request links to the approval, the commit and the affected application.
Define Projects per environment
Create one Argo CD Project for each environment, such as development, test and production, and restrict each Project to its allowed source repositories, destination clusters and namespaces. Limit Project roles so that only the production approvers can sync production applications. Apply the same discipline to the RBAC policy so that update and delete permissions apply to the application itself, as the 2.14 to 3.0 upgrade notes describe, and grant the logs get permission only where operators need it. The step is complete when an application pointing at a repository or namespace outside its Project is refused, and the Project definitions are versioned in Git with the rest of the platform configuration.
Configure sync policy and drift alerting
Decide per environment whether automated sync and self-heal are enabled. Automated self-heal in production returns resources to their Git state when someone changes them by hand, which keeps the running configuration aligned with the reviewed baseline. Where the team prefers manual sync for production, configure the application to show OutOfSync so the drift is visible and handled through a Git change. Record the choice in the baseline documentation. The step is complete when a deliberate manual change to a test workload is either reverted automatically or shown as OutOfSync in the UI, depending on the chosen setting.
Enable notifications for unexpected changes
Enable Argo CD Notifications and route alerts for sync failures, health degradation and out-of-sync production applications to the team that monitors security events. Send the alerts to a channel that the security operations team reads and that retains messages long enough for review. ENISA's guidance lists alerts on unexpected configuration changes as evidence, so the alert rules should be stored in Git with the rest of the configuration. The step is complete when a test drift on a non-production application produces a notification that reaches the monitored channel.
Set snapshot and retention practices
Record the Git commit that each application syncs to, and keep the sync history that Argo CD retains for each application. Because the desired state lives in Git, the commit history serves as the configuration snapshot before and after each change, which ENISA's guidance lists as evidence. Agree a retention period for the Git history, the Argo CD sync history and the notification records with the compliance owner, and confirm that those periods meet the national transposition requirements and the entity's own policy. The step is complete when a sample change can be traced from the approved pull request to the commit, the sync event and the resulting cluster state, and the retention settings are documented in the change procedure.
Questions about NIS2 configuration evidence with Argo CD
Does using Argo CD make our organization NIS2 compliant?
No. Argo CD is one open-source tool that can supply evidence for points 6.3 and 6.4 of Implementing Regulation (EU) 2024/2690, but compliance depends on your whole risk-management program under Article 21 of NIS2, your national transposition law and your own governance. Argo CD helps with secure configurations enforced from Git, reviewed changes, sync history and drift alerts. You still need documented baselines, approved exceptions, risk-based testing and people who own the process. Ask your national competent authority or legal counsel how the directive applies to your entity, and confirm which controls your sector guidance expects.
Does NIS2 issue a certificate after we implement these controls?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34. DeployOpen prepares systems, controls and evidence for those assessments, but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work where a scheme requires it, and your authority decides what it accepts as proof.
What drives the cost of an Argo CD configuration evidence project?
Cost follows the written scope, so the main drivers are the number of clusters and environments, how many applications and repositories need Git-enforced baselines, the state of your existing SSO and RBAC, whether you need snapshot and alerting pipelines, and how much policy mapping your compliance team wants documented. Most engagements are fixed-scope, so the quote lists deliverables and timelines before work starts. Ask for the cost split between one-time build work, documentation and recurring support, and whether upgrades or continuous testing are priced as a retainer. DeployOpen does not publish a price list.
How long does an Argo CD setup for NIS2 evidence take?
Duration depends mainly on environment count. A single non-production cluster with one Git repository and a clear review flow is a smaller job than several production clusters, each with separate projects, SSO groups, sync windows and alerting. Plan additional time for identity integration, for mapping existing change records to Git history, and for review cycles with your compliance and operations teams. DeployOpen states timelines in the written scope agreed before work starts, so ask for a milestone plan tied to each environment rather than a single estimate.
What do we need from our own team for this work?
Expect to supply people and access, not just approvals. You need an owner for the Git repositories and branch protection rules, administrators for each target cluster, an identity team that can register groups with your SSO provider, and a security or compliance contact who can confirm which baselines and exceptions are approved. Operations staff must be available to review drift alerts and to take part in a tested rollback. Access to your cloud accounts, data centers or air-gapped networks is also needed, since the work runs in infrastructure you control.
Can our own engineers build this without outside help?
Yes, if your team already runs Kubernetes, understands GitOps and can own the controls after go-live. The harder parts are usually not the Argo CD installation itself but the policy decisions: which configurations count as the secure baseline, how exceptions are approved and compensating measures recorded, how snapshots are retained, and how alerts are routed. Confirm your internal capacity for those tasks, plus ongoing upgrades. Argo CD's upgrade notes, such as the 2.14 to 3.0 changes to RBAC and repository configuration, need planned testing, which teams without that experience often underestimate.
How does the 2026 NIS2 amendment proposal affect our planning?
The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13), including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, and Commission pages describe it as a proposal. Until it is adopted, plan against the current directive, your national transposition law and Implementing Regulation (EU) 2024/2690. Build the Git-based controls so they can be reused if obligations change, and ask your legal team to track the outcome, since your category and obligations could shift.
What happens to the evidence if a configuration change goes wrong?
Git history and Argo CD sync records let you show what changed, who approved it and which revision was live at a given time, and a revert commit returns the cluster to the prior declared state. Pair this with configuration snapshots before and after significant changes and with alerts on unexpected drift. Confirm during scoping how long your Git hosting, Argo CD history and snapshot storage retain records, and who is authorized to make emergency changes outside the normal flow.
Why Git review and sync records must be read together
An auditor testing point 6.4 will not accept a Git history and an Argo CD sync log as two separate piles of evidence. They will pick a change, ask who approved it, then ask what state the cluster actually reached and when. The link between the two records has to be provable: the merged commit SHA recorded in the pull request should match the revision Argo CD reports for the Application's sync, and the sync timestamp should fall after the approval and before any later change. Before the first audit sample, run this trace yourself on a few real changes, using the Application's sync history and the commit it lists, and confirm that your Git platform and Argo CD retain these records long enough for your review cycle.
Argo CD works as a reconciliation loop. It compares the desired state rendered from the Git revision the Application tracks with the live state in the destination cluster, and it reports the result as sync status and health. With automated sync and self-heal enabled, a manual change in the cluster shows up as drift and is reverted toward the Git state, which supports the monitoring of unexpected configuration changes in point 6.3. That behavior is also a risk: a change that is reverted within seconds may leave no durable record unless alerts or Kubernetes events are retained. Decide in advance which drift events you will alert on and where they are stored, and verify that a manual edit produces a visible trail rather than a silent correction.
A revert of a bad commit is itself a change, and it needs its own record. When a team falls back by reverting the offending commit, the revert should go through the same review path as any other change, and the auditor should be able to see the revert commit, its approver, and the sync that applied it. Confirm that your process does not allow a direct push to the tracked branch to bypass review during an incident, and document how emergency reverts are approved after the fact. Without this, the fallback step can look like the unrecorded change the control is meant to prevent.
Responsibilities split between the entity, Argo CD and DeployOpen
NIS2 places the configuration and change management duties on the entity, not on the tool. Argo CD supplies enforcement and records from Git, while the entity keeps the decisions, the evidence habits and the final say on what counts as compliant.
Policy and risk assessment
The entity decides which configurations are secure baselines, which changes count as significant, and how risk drives the level of testing before a change goes live. Point 6.3.3 ties reviews to planned intervals and to significant incidents or changes, so those triggers need written definitions. Check that the baseline policy names an owner, a review interval and the approval path for exceptions, because Argo CD will enforce whatever the policy is translated into but cannot judge whether it is adequate.
Git and Argo CD configuration
This is shared work. The entity defines the Git repositories, branch protections, required reviewers and the Argo CD projects that limit which repositories and clusters each team can sync. DeployOpen can build and document that setup in your infrastructure. Confirm that sync permissions, automated sync and self-heal settings match the change procedure you have written, because a setting that differs from the documented process becomes a finding during review.
Evidence retention and review cadence
The entity keeps the records that show changes were documented, tested and assessed, along with configuration snapshots taken before and after changes and the alerts raised on unexpected drift. ENISA's guidance lists these as examples of evidence. Decide where Git history, Argo CD sync records and Kubernetes events are exported, who reviews them and how often. Ask your retention policy owner to confirm the period, because no retention figure is set by the regulation itself.
Patching and upgrades
The entity owns the schedule for applying Argo CD releases. The project provides patch releases only for its three most recent minor versions, and a new minor version ships every three months, so an unpatched install can fall out of support quickly. DeployOpen can support upgrades and patching under a retainer, including reading the upgrade notes for breaking RBAC and repository changes before each move. Agree in writing who tests upgrades in a non-production cluster and who signs off on production.
Independent assessment
NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Auditors and authorities assess the evidence the entity produces, not the Argo CD installation alone. DeployOpen prepares systems, controls and evidence for those assessments but does not issue audit reports or attestations. Ask your national authority which supervision regime applies to your entity and what they expect to see.
How DeployOpen scopes and delivers NIS2 configuration evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Argo CD. For NIS2 configuration and change management, we set up the Git flow, RBAC, sync controls and drift alerting so the records your team and the assessing authority review are produced by the platform as it runs.
How we scope
- Engagements are fixed-scope, with the covered clusters, Argo CD projects and configuration baselines agreed in writing before work starts.
- The written scope names which points of Implementing Regulation 2024/2690 the evidence is meant to support, so gaps are visible early.
- We confirm which identity provider, Git host and clusters are in scope, and who approves changes in each environment.
How we build
- We set up Git-hosted baselines, protected branches and review rules so that no configuration reaches production without an approved change.
- We configure Argo CD projects, RBAC and disabled local admin access, then test that unauthorized sync and deletion attempts are refused.
- We configure drift detection and alerting, and verify that a manual change to a managed resource produces a visible, recorded alert.
How we hand over
- You receive the documented baseline set, approval workflow, exception process and the steps to export sync history and snapshots.
- We provide a test record showing each control was exercised, so your team can repeat the checks after changes.
- Runbooks cover reviews after significant changes, rollback by reverting commits and how to answer an information request from a competent authority.
How we support
- Ongoing support, Argo CD upgrades and continuous testing are available as retainers, and the upgrade path is planned with your team.
- We review Argo CD upgrade notes and release changes for effects on RBAC, repository definitions and tracking behavior before each upgrade.
- We confirm with your compliance lead which evidence the authority or auditor will request, since DeployOpen prepares evidence but does not issue certifications.
