ISO 27001 A.8.9: Configuration Management

To satisfy ISO 27001 A.8.9, define a secure configuration baseline for your hardware, software, services, and networks, document every deviation from it with a justification, enforce it, and check on a schedule that systems have not drifted away from it. A.8.9 is new to the 2022 revision, and the action teams most often get flagged on is the first one: producing a justified baseline with documented exceptions rather than chasing a perfect benchmark score.

A.8.9 is a Technological control in Annex A of ISO/IEC 27001:2022. It maps fully to SOC 2 CC7.1 and CC8.1, so a team already running configuration management for SOC 2 has most of the evidence an ISO 27001 auditor will ask for.

What is ISO 27001 A.8.9?

ISO 27001 A.8.9, titled Configuration management, requires that secure configurations of hardware, software, services, and networks be established, documented, implemented, monitored, and reviewed. The intent, as expressed in ISO/IEC 27001:2022, Annex A, is that systems run with a known, hardened configuration rather than vendor defaults, and that the organization can detect and correct configurations that drift away from that standard.

A.8.9 is one of the eleven controls introduced in the 2022 revision. The 2013 version of the standard had no dedicated configuration management control; the expectation was spread thinly across other controls. The 2022 revision names it directly. The control covers the full lifecycle: define the baseline, apply it, watch for drift, and review it. It is deliberately tool-neutral. It does not name CIS benchmarks, a specific scanner, or a configuration management platform. What it expects is that configurations are deliberate, documented, and maintained rather than assembled by hand and forgotten. Baseline decisions of this kind are structural, part of the organization's security architecture, which is why they deserve deliberate design rather than inherited defaults.

How do you implement A.8.9?

Run configuration management as a repeatable cycle rather than a one-time hardening exercise. The sequence below is the same whether the infrastructure is cloud or on-prem:

1. Define hardening baselines per asset tier. Start from an established standard (CIS Benchmarks are the common reference) and set a baseline for each type of system. Not every asset needs the same rigor. A workable model is three tiers: Tier 1 production and internet-facing systems get a full benchmark baseline; Tier 2 hypervisors, storage, and internal management systems get a lighter documented standard; Tier 3 network devices and appliances need default credentials changed and the baseline state recorded. Matching the baseline to the asset's risk is what makes the program sustainable.
2. Document justified exceptions. The first benchmark scan of any system fails a large share of its rules by design, because a benchmark is a generic checklist rather than a tailored requirement. Review each failed or disabled item and assign one of three dispositions: remediate, accept with a written justification, or mark not applicable. Common justifications include revised guidance (password expiry is no longer recommended), a legitimate business use (a diagnostic protocol on network gear), and a rule that does not apply to the system's role (a print spooler on a database server). The output is a custom baseline policy that reflects your environment rather than the raw benchmark.
3. Enforce the baseline. Apply the approved configuration through images, golden templates, configuration management tooling, or infrastructure as code so systems are provisioned into the baseline rather than hardened by hand afterward.
4. Monitor for drift. Configuration is not static. Scheduled scans or continuous checks compare running state against the approved baseline and flag deviations. Drift detection is the step that turns a point-in-time hardening exercise into an operating control.
5. Review the baseline. On a defined cadence, revisit the baseline and its exceptions: confirm the justifications still hold, fold in new benchmark guidance, and re-approve. This review is what an auditor looks for to confirm the control operates over time.

In cloud environments

Cloud environments implement A.8.9 through infrastructure as code and managed posture tooling, which produce configuration evidence as a byproduct of how systems are built:

• Infrastructure as code (Terraform, CloudFormation, Ansible) defines the baseline in version control, so every configuration is reviewed, repeatable, and auditable through the commit history.
• Golden images and hardened base images bake the approved configuration into what every new instance or container starts from, rather than hardening after provisioning.
• Cloud security posture management (CSPM) tools and native services such as AWS Config or Azure Policy continuously evaluate running resources against baseline rules and flag violations.
• Automated drift detection compares deployed state against the code or the conformance pack and alerts when the two diverge, closing the gap between point-in-time provisioning and ongoing assurance.

One caution on infrastructure as code: provisioning is a point-in-time event. A periodic check that running state still matches the code is what carries the story from a Type 1 snapshot to ongoing assurance.

On-prem / self-hosted

On-prem environments reach the same outcomes through configuration management tools and scanned benchmarks that generate their own evidence. The SOC 2 configuration baselines for bare metal guide covers the full implementation; the shape is:

• Group Policy (GPO) and configuration management tooling (Ansible, Puppet, or similar) push the approved baseline to Windows and Linux fleets and re-apply it, so drift is corrected rather than just detected.
• Scanned CIS benchmarks through a tool such as Wazuh SCA or OpenSCAP measure each system against a custom policy that encodes the approved baseline and its exceptions, producing dated scan reports.
• Tiered scanning cadence matches frequency to risk: automated weekly scans on Tier 1 production systems, quarterly documented reviews on Tier 2, annual checks on Tier 3 network devices.
• Change default credentials and record the baseline on appliances and network gear that cannot run an agent, with the documented state stored in the asset inventory.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.9?

Evidence for A.8.9 is paired: a document defining the approved configuration, plus a record showing systems are held to it over time. Many teams collect the scan results and drift alerts through an automated evidence pipeline, the approach covered in GRC engineering, so the record accumulates without a manual sweep before each audit.

How does A.8.9 map to SOC 2?

A.8.9 is a Full overlap with SOC 2 CC7.1 and CC8.1. A team with those criteria in place has already built the configuration baselines, drift monitoring, and change controls A.8.9 asks for, and the same artifacts go into both audit packages.

The SOC 2 to ISO 27001 control mapping covers the full crosswalk and what transfers between the two frameworks.

Related controls

A.8.9 works alongside the controls that govern how a configuration changes and what a hardened baseline defends against. A.8.32 Change management governs how a system departs from and returns to its baseline through an authorized process, where A.8.9 defines the baseline itself. A.8.8 Management of technical vulnerabilities is the closely paired scanning control: A.8.8 finds missing patches and known vulnerabilities, A.8.9 finds insecure configuration. A.8.19 Installation of software on operational systems constrains what can be added to a system once it is baselined, and A.8.20 Network security applies the same hardening discipline to network devices and rules. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Part of Truvo's control-by-control ISO 27001 Annex A reference series. This post is part of the ISO 27001 certification guide. If you are building configuration management as part of an effective security program and want a second set of eyes on the baseline design, Truvo runs scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.9?

ISO 27001 A.8.9 Configuration management is a Technological control in Annex A of ISO/IEC 27001:2022. It requires that secure configurations of hardware, software, services, and networks be established, documented, implemented, monitored, and reviewed. In practice this means defining hardening baselines, recording justified exceptions, enforcing the baseline, and checking that systems have not drifted from it.

Is A.8.9 new in ISO 27001:2022?

Yes. A.8.9 is one of the eleven controls introduced in the 2022 revision. The 2013 version of the standard had no dedicated configuration management control, with the expectation spread across other controls. The 2022 revision names configuration management directly and defines its full lifecycle: establish, document, implement, monitor, and review.

What evidence satisfies A.8.9?

A.8.9 evidence is paired: a document defining the baseline plus a record showing systems are held to it. Auditors expect documented hardening baselines per asset tier, a custom scan policy or conformance pack recording exceptions, CIS scan results or CSPM reports, configuration drift reports, and a baseline review sign-off. The drift and review records are what demonstrate the control operates over time rather than existing only at setup.

Does A.8.9 require CIS benchmarks?

No. A.8.9 is tool-neutral and does not name CIS Benchmarks or any specific scanner. CIS Benchmarks are the common reference because they provide a ready-made hardening standard, but any documented, defensible baseline satisfies the control. What matters is that the baseline is established, tailored to the environment through justified exceptions, enforced, and monitored; the choice of starting benchmark is secondary.

How is A.8.9 different from A.8.32 change management?

A.8.9 defines and maintains the secure configuration baseline; A.8.32 governs the authorized process by which a system departs from and returns to that baseline. A.8.9 answers what the correct configuration is and whether systems still match it. A.8.32 answers whether a change to that configuration was requested, assessed, tested, and approved. The two work together: configuration management sets the standard, change management controls movement against it.

How does A.8.9 map to SOC 2?

A.8.9 maps as a Full overlap to SOC 2 CC7.1 and CC8.1. CC7.1 covers detecting and monitoring configuration and vulnerabilities; CC8.1 covers change management. Baseline configuration records, CIS scan results, configuration drift reports, and infrastructure-as-code change approvals produced for those criteria are reusable for the ISO 27001 A.8.9 requirement without adaptation.