> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Change Management

> How Ankra classifies the changes it makes to your clusters as pre-approved standard changes or normal changes, and how that record supports ISO 27001 change management.

ISO/IEC 27001:2022 control 8.32 asks that changes to information processing facilities follow a change management process. Most organisations meet it with three kinds of change: **standard changes** that are pre-approved because they are low-risk and repeatable, **normal changes** that are approved one at a time, and **emergency changes**.

Ankra records which kind each change is. When a change it makes to a cluster matches an entry in the standard-change catalogue below, the [Audit Log](/guides/audit-log) entry is marked as a pre-approved standard change, with the catalogue entry and the reason it qualified. Every other change is a normal change, approved through your own process: a reviewed pull request on your GitOps repository, an approved AI plan, or a change ticket.

Pre-approval is on for every organisation by default.

***

## The standard-change catalogue

Each entry states what qualifies and how the change is reversed. A change that does not meet every part of the criteria is a normal change.

| ID | Standard change | Qualifies when |
| - | - | - |
| SC-01 | Add-on security patch | One add-on's chart version moves forward, within the same major version, to a version that fixes at least one published security advisory (GHSA, CVE or OSV) Ankra has recorded against the installed version. Nothing else in the Stack changes. |
| SC-02 | Kubernetes patch upgrade | The cluster's Kubernetes version moves forward by a patch release within the same minor version. |
| SC-03 | Operating system patching | Security updates are applied to nodes inside the cluster's patch window. |
| SC-04 | Ankra agent upgrade | The Ankra agent moves to a released version under your organisation's auto-upgrade setting. |
| SC-05 | Autoscaling within configured bounds | The cluster autoscaler adds or removes nodes inside the minimum and maximum set for the node group. |
| SC-06 | Reconcile to the committed state | Ankra returns the cluster to the state already committed in its GitOps repository. |
| SC-07 | Certificate, DNS and credential rotation | A certificate renews, a DNS record is reconciled to its declared value, or a credential is rotated without changing what it grants. |
| SC-08 | Scheduled backup | A backup or snapshot runs on its schedule, or is taken on request, without changing the protected workload. |
| SC-09 | Scheduled power action | A cluster stops or starts as its power schedule or cost policy says. |
| SC-10 | Access revocation and self-heal | Expired access is removed, or Ankra restarts a control-plane node that stopped responding, within the attempt limit. |
| SC-11 | Non-production deploy on merge | An image built and scanned by the pipeline is deployed to a non-production environment after its pull request merged. A deploy to production, or to an installation with no environment set, is a normal change. |
| SC-12 | Ephemeral preview environment | A pull-request preview is created on your staging cluster and removed when the pull request closes. |

Every change on this list writes an audit entry, including the ones Ankra makes on its own: those are recorded with the actor `system` and say what started them.

***

## Security upgrades carry their reason

When you upgrade an add-on from a **Security update available** notice, Ankra looks up the advisories the new version fixes from its own advisory records. It does not rely on what the browser or CLI sent. The audit entry then names them, and so does the commit in your GitOps repository:

```text theme={null}
Security upgrade kyverno 3.8.2 -> 3.9.1 in stack 'ankra-security-baseline'

Fixes-Advisory: GHSA-xxxx-xxxx-xxxx (CVE-2026-xxxxx)
```

The repository history alone then answers why the change was made. An upgrade that fixes no recorded advisory, or that moves to a new major version, is recorded as a normal change.

***

## Reading the audit trail

In a cluster's **Settings > Audit**, an entry that qualified shows **Pre-approved SC-01** (or the matching ID) beside its action. Hover over it to see the catalogue entry and why the change qualified, for example the versions and advisories of a security patch. The full record is in the entry's details under `change_classification`:

```json theme={null}
"change_classification": {
  "class": "standard_preapproved",
  "standard_change_id": "SC-01",
  "standard_change": "Add-on security patch",
  "catalogue_version": "2026-10-17",
  "basis": "kyverno 3.8.2 -> 3.9.1 fixes GHSA-xxxx-xxxx-xxxx (CVE-2026-xxxxx)."
}
```

The classification is decided when the entry is written, and `catalogue_version` names the catalogue it was decided against. A later change to the catalogue does not rewrite earlier entries. Entries without a classification are normal changes, or events that are not changes at all, such as sign-ins.

[Export the audit log](/security/audit-export) to hand the record to an auditor.

***

## Requiring approval for every change

If your change process does not allow pre-approved changes, an organisation admin can turn off **Organisation settings > Security > Pre-approved standard changes**. From then on, changes that match the catalogue are recorded as normal changes. Each entry still names the catalogue entry it matched, and its basis says your organisation requires approval. Turning the setting off or on is itself recorded in the audit log.

Turning pre-approval off does not stop Ankra from making these changes. Autoscaling, power schedules and access expiry keep running as configured. If a change needs approval before it happens, make it through a reviewed pull request on your GitOps repository, or turn off the automation that makes it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.