The baseline nobody updated.
ISO 27001:2022 A.8.9 (configuration management) expects security configurations for hardware, software, services, and networks to be established, documented, implemented, monitored, and reviewed, and for what actually runs to match that baseline. In practice the baseline usually lives as code: a shared manifest, module, or template that every service or resource is meant to start from. The control weakens when deployed configuration diverges from that baseline without authorization, documentation, or monitoring, not when a reviewed exception is made on purpose.
The shapes the same control failure takes.
A.8.9 weakens when the running configuration and the documented baseline drift apart. The recurring shapes:
A hardening default is overridden in place
A service's manifest sets a security-relevant setting against the shared baseline to unblock something specific, instead of fixing the underlying need or updating the baseline.
A copied template diverges silently
A new service starts from the shared config template, is customized ad hoc, and the two drift apart with nothing tracking that they no longer match.
An exception ships with no expiry
A one-off override (a relaxed setting, a debug flag left on) is meant to be temporary but has no review date, so it just stays.
A live resource is changed by hand
Someone edits a running resource directly (a console click, an ad hoc CLI command) instead of through the versioned config that is supposed to be the source of truth, so the two no longer agree.
A new resource type ships with no baseline
A new kind of resource (a queue, a database engine) is introduced with nothing defining its secure configuration, so each instance gets configured ad hoc.
A hardening default overridden to unblock a deploy.
The org's shared Kubernetes base manifest runs every service as non-root with a read-only root filesystem, the documented baseline. A new worker needs to write a temp file at startup, and running it as root is the fastest way to unblock the deploy, so its manifest overrides the baseline directly instead of mounting a writable volume or updating the shared base. The service now runs with more privilege than the documented baseline allows, and nothing about the baseline itself changed, so nobody reviewing it would see the drift.
containers: - name: worker- securityContext:- runAsNonRoot: true+ securityContext:+ runAsNonRoot: false # needs to write a temp file at startupThis opts one service out of the shared hardening baseline (`runAsNonRoot: true`) directly in its own manifest, instead of through the reviewed baseline. A.8.9 expects the deployed configuration to match what is established and documented, and this drifts from it without anyone touching the baseline itself. Fix the actual write path (mount a writable volume for the temp file), or document and approve a time-boxed exception through the configuration-management process, rather than opting one service out in place.
Configuration is checked against what actually runs, not just the document.
An auditor looks at whether your running configuration matches your documented secure baseline, not just whether the baseline document exists. A service quietly opted out of a hardening default, a hand-edited resource that drifted from its tracked config, or a new resource type with no baseline at all is the kind of mismatch that becomes a finding. It usually traces back to one change that took a local shortcut instead of updating or exception-ing the baseline.
A review, not your configuration baseline.
heygrc flags changes that touch A.8.9 and cites the control so the fix happens in the pull request. It does not define your baseline or manage your infrastructure. It catches the moment a change quietly drifts from the documented configuration, at the diff.