ISO 27001:2022 Annex A 8.9 configuration management: enforce baselines

The due-diligence questionnaire asks whether you run hardened builds against a recognised benchmark, and the honest answer is a Word document nobody has opened since the last audit. This guide explains ISO 27001:2022 Annex A 8.9 configuration management for UK regulated firms and SaaS scale-ups of 25 to 250 people, and shows how to define lean baselines, enforce them as code and detect drift.

You will also see where the control stops and change management begins, which evidence an auditor accepts, and what the room sounds like on the day. The aim is a baseline that enforces itself, so proving the control costs almost nothing.

What does ISO 27001 A.8.9 require?

ISO 27001 A.8.9 requires you to decide how your hardware, software, services and networks should be securely set up, write that down, apply it, and keep checking and updating it. In practice, that means one hardened baseline per platform family, applied when systems are built and checked on a cycle so live systems never quietly drift.

The NIST SP 800-128 Guide for Security-Focused Configuration Management frames the goal well: manage and monitor configurations so security is adequate and the system still does its job. That second half matters, because a baseline that breaks the service soon gets switched off.

Five verbs describe the work:

• Establish what secure means for each kind of system: laptops, servers, cloud accounts and network kit.
• Document it as a baseline, ideally as code rather than prose.
• Implement it when the system is built, not afterwards.
• Monitor live systems against the target.
• Review the baseline when the estate or the threat picture changes.

Classed as preventive, the ISO 27001:2022 Annex A 8.9 configuration management control touches confidentiality, integrity and availability, because one wrong setting can leak data, allow tampering or take a service down. Hardening removes the easy openings before anyone uses them.

Why do default settings fail under ISO 27001:2022 Annex A 8.9 configuration management?

Nothing ships secure out of the box. Factory passwords, open storage buckets and exposed admin ports need no skill to exploit, and a hardened estate erodes one undocumented tweak at a time. Annex A 8.9 makes you decide what secure means for each platform, then keep proving reality matches it.

Defaults fail for a structural reason. Vendors ship systems that work for everyone on first boot, which is a different goal from being safe inside your estate.

For a 25 to 250-person firm, the quieter danger is drift. A laptop gets local admin for a one-off install, a firewall rule opens for a vendor demo, a bucket goes public for a handover. None of it is logged as a decision, and the controls you are certified against slowly stop existing in practice.

The cost arrives before any auditor does. Security questionnaires and cyber insurance proposals now ask directly whether you run hardened builds against a recognised benchmark. A questionnaire row that cites Annex A 8.9 ISO 27001:2022 wants a yes, a named benchmark and a way to show it.

How do you choose and tailor a baseline for each platform?

Start from a recognised reference, such as CIS Benchmarks, NCSC platform guides or the vendor's hardening guide, then cut to what fits your estate. Write one lean baseline per platform family: endpoint, server, cloud account, network device and key SaaS. Every build then inherits the same core rules.

Two public references cover most estates. The CIS Benchmarks List offers consensus-based, prescriptive configuration recommendations across major operating systems, cloud providers and network devices. The NCSC Device Security Guidance Platform Guides detail how to securely configure the device platforms commonly used in the UK, including Windows, macOS, iOS, Android and Chrome OS.

Auditors recognise CIS as the safe default, and vendor hardening guides or NIST material work too. What matters is that you started from a recognised reference and can explain every deviation. The simplest way to do that is a one-line reason beside each deviation in the baseline itself, such as a setting that breaks a line-of-business app, so the explanation travels with the definition.

Then cut ruthlessly. We recommend keeping the settings that fit your estate and protection needs and dropping the rest. A 50-person regulated firm might end up with five baselines, and a larger estate adds families rather than pages per family.

Bake these core rules into every baseline:

• Replace factory credentials before a system joins the network.
• Remove guest and dormant accounts.
• Switch off ports and services nothing needs.
• Lock down powerful admin utilities.
• Set idle-session timeouts.
• Confirm software licences are legitimate.
• Point every system at the same NTP source, so timestamps agree when you investigate something.

The pitfall to design out is factory settings surviving into production. Default admin usernames and passwords remain the classic finding, usually on a network appliance nobody thought of as a server. Make credential replacement a build step with a recorded result, not a line in a reminder.

How do you enforce baselines as code instead of documents?

Enforce the baseline through tooling you already own: Intune or Jamf pushes endpoint policy, and Terraform or similar defines cloud infrastructure as code. The baseline, its enforcement and its change history become one artefact, so applying the baseline and proving it are the same act.

Endpoints are the easy half. An Intune or Jamf compliance policy states the target, devices that fall short are flagged, and enrolment applies the baseline without anyone typing a setting. In Microsoft 365, pair the policy with conditional access, so a device that falls out of line loses access to email and files until it is fixed.

For cloud, Terraform modules carry the hardened defaults, so a new account or storage bucket starts compliant. Running a Terraform plan against live infrastructure also shows any setting that no longer matches the code, which is drift detection you already own.

Keep the definitions in version control and require a reviewed approval before a baseline changes. The pull request is the approval, and the git log is the audit trail. Day-to-day configuration changes still ride the change route under A.8.32, so don't build a parallel process.

A hardening standard that engineers must remember is not enforced; it is hoped for.

Restrict who can touch production settings as well: admin roles only, least privilege, and MFA in front of the consoles. Otherwise the pipeline enforces the baseline while the console quietly overrides it.

Two pitfalls undo the approach:

• Hand-built machines. As the estate grows, every machine is built by hand and no two end up configured alike.
• Unversioned baseline documents. The "current baseline" becomes whichever copy someone opened last.

A baseline in a repository with a protected main branch removes both failure modes in one move. If you already run an MDM, the work is writing definitions, not buying tools.

How do you detect and manage configuration drift?

Drift is detected continuously, not discovered at audit. Cloud posture tooling and your MDM's compliance view diff live state against the defined target, and each deviation either self-heals or raises a ticket for human judgement. A light quarterly spot-check of sampled systems backs that up.

Decide per platform what a deviation triggers. Low-risk, reversible settings, such as a screen-lock policy, can self-heal back to target. Anything where reverting might break a live service, such as a production firewall rule, should raise a ticket for a human to judge. Either way, the auto-revert log or the closed ticket shows detection working.

A baseline checked only at audit time is a snapshot, not a control.

The quarterly spot-check is the backstop, not the mechanism. Sample a handful of systems against their baseline, record findings and closures, and clear out orphaned admin accounts while you are there.

The pitfall is hardening once at go-live and assuming it holds. Without monitoring or spot-checks, erosion goes unseen until a customer's tester or an auditor finds it. The table below compares the methods most firms combine.

How does A.8.9 differ from change management under A.8.32?

A.8.9 defines and monitors the secure target state of a system; A.8.32 governs how systems are changed. You need both: a target state, and a controlled way to move it. Asset inventory under A.5.9 comes first, because it tells you which systems need a baseline.

Think of A.8.9 as the answer to "what should this system look like?" and A.8.32 as the answer to "who approved moving it, and was the move tested?" ISO 27001:2022 A.8.9 configuration management supplies the reference point that every change is measured against.

A change process with no defined target state approves movement, not security.

When the two blur, a reviewer has nothing to compare a change against. An approved ticket reading "open port 8443" says nothing about whether the result still matches the hardened build. When a change is accepted, update the baseline definition in the same pull request so the target never lags reality.

Sequence the dependencies like this:

1. Asset inventory (A.5.9). The inventory tells you what exists, so it tells you what needs a baseline. Record against each asset the baseline it should carry.
2. Baselines (A.8.9). One per platform family, written and enforced as code.
3. Privileged access (A.8.2). Lock down the admin roles that could bypass the baseline.
4. Network controls (A.8.20). Bring routers, firewalls and switches under a baseline of their own.
5. Change management (A.8.32). Send every change through approval, measured against the baseline you now hold.

Order matters because a baseline written before the inventory exists covers the systems you remember, not the ones you run.

What evidence pack proves A.8.9 to an auditor?

The strongest evidence pack is the IaC repository that is the baseline, plus its enforcement pipeline. Add MDM or posture-tool compliance exports with explained exceptions, version and approval history, drift alerts with their remediation tickets or auto-revert logs, spot-check reports, and records that configuration data is backed up and restorable.

Add a handful of change tickets that show configuration changes going through change management. The pack then covers both ends: the target state, and the controlled moves away from it.

Four gaps weaken an otherwise strong pack:

• Compliance exports with exceptions listed but never explained.
• Drift alerts with no recorded resolution.
• Baseline approvals buried in chat messages instead of the repository.
• Backups that have never been test-restored to a known-good state.

Store the pack by quarter, so an auditor can sample any period without a scramble. A good drift record reads like a short story: the alert, who looked at it, what they decided and when the system came back into line.

What will an ISO 27001 auditor ask and sample for configuration management?

Expect the auditor to pick two or three live systems and compare actual settings with your claimed baseline, trace one configuration change to its approval, and probe a network device for surviving factory credentials. A claimed drift-detection capability gets tested by asking for a real alert and its resolution.

The questions tend to follow the lifecycle:

• "Show me your hardening standard for laptops, and the one for your cloud environment."
• "How would you know if someone changed a production setting outside the process?"
• "Walk me through a new server or cloud account from provisioning to go-live. Where does the baseline get applied?"
• "Who can modify production configuration, and what protects that access?"
• "When did you last check systems against the baseline, and what did you find?"

Auditors testing ISO 27001 2022 A.8.9 configuration management ask for real artefacts, not descriptions of them.

Grading follows certification-body practice. No baselines at all, or default credentials found live in production, is an absence of the requirement and grades major. A baseline document that lags the deployed reality, one sampled system out of line or a missed spot-check grades minor, and a pattern of minors can add up to a major.

Rehearse the sample yourself. Pick two or three systems at random, compare them with the baseline, and check one network device for factory credentials. Anything you find first is a ticket; anything the auditor finds first is a finding.

What can you automate in configuration management with GRC engineering?

Configuration is the most automatable control in Annex A because the target state can literally be code. Baseline-as-code, continuous drift detection, audit packs generated on demand and new-asset hooks that apply the baseline at enrolment turn the quarterly review into reading a report, not building one.

Baseline as code and drift detection are covered above. Two further automations finish the job:

• Audit packs on demand. Compliance-percentage exports, exception lists and drift-resolution records assemble from the tooling when asked.
• New-asset hooks. A device enrolling or a cloud account appearing triggers the baseline, so unmanaged kit stops piling up.

The first pass is smaller than it looks. In a cloud-native estate, writing baselines, pushing endpoint policy and switching drift alerts on takes two to three weeks of effort. As a side effect, that work discharges chunks of A.8.2, A.8.5 and A.8.20.

Under ISO 27001 2022 Annex A 8.9 configuration management, the result is a control that runs itself between audits, answers the insurer's benchmark question with evidence, and leaves nothing to rebuild before the next audit.

Frequently asked questions