ISO 27001 Configuration Management: Complete 2026 Guide

ISO 27001 configuration management is the requirement in Annex A control 8.9 that your hardware, software, services and networks are configured deliberately, written down, actually deployed, watched for drift and reviewed — and it is one of the eleven controls that did not exist in the 2013 edition. That last point matters more than it sounds. Every other technological control in your Statement of Applicability probably inherited a document from your old ISMS. This one inherited nothing.

I see the same gap in audit after audit: a company with a mature change process, a tidy asset register and a decent vulnerability scanner, and no answer at all to “show me the approved baseline for this server, and show me the list of settings where you deliberately deviated from it.” This guide covers what A.8.9 actually says, where to get baselines that someone else maintains for free, and the single artifact that turns ISO 27001 configuration management from a claim into evidence.

What ISO 27001 configuration management requires under Annex A 8.9

The control is short. Configurations — including security configurations — of hardware, software, services and networks are to be established, documented, implemented, monitored and reviewed. Five verbs, and most implementations stop after three.

Read the verbs as five separate tests, because that is how an auditor will sample your ISO 27001 configuration management:

Verb in A.8.9	What it means in practice	Typical evidence
Established	A defined target state exists for each asset type — not “whatever the vendor shipped”	Named baseline per platform, with an owner
Documented	The target state is written down and version-controlled	Hardening standard, IaC repository, group policy export
Implemented	The target state is applied to live assets before they go into service	Build checklist sign-off, pipeline output, MDM enrolment record
Monitored	Drift from the target state is detected, not assumed absent	Compliance scan reports, posture dashboards, alerting rules
Reviewed	The baseline itself is revisited as threats and platforms change	Dated review records, approved deviation register

Two things follow from the wording. First, in ISO 27001 configuration management the word documented sits inside the control statement itself, so you cannot evidence this one with practice alone the way you can with some behavioural controls — if A.8.9 is applicable, a written baseline is not optional. Second, monitored is a continuous verb. A one-off hardening project delivered eighteen months ago does not satisfy it, and a Stage 2 auditor who asks for last month’s drift report will find that out in about ninety seconds.

The current edition of the standard is ISO/IEC 27001:2022, edition 3, published October 2022, with the free climate-action Amendment 1:2024 — you can confirm the edition and amendment on ISO’s own page for ISO/IEC 27001. Annex A carries 93 controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological. A.8.9 is one of the technological 34.

Why A.8.9 has no 2013 ancestor — and what that means for transitioned ISMSs

Eleven controls were genuinely new in the 2022 edition. ISO 27001 configuration management is one of them, which means mapping tables from the old standard leave its source column blank:

New in ISO/IEC 27001:2022	Control title	Maps from 2013
A.5.7	Threat intelligence	—
A.5.23	Information security for use of cloud services	—
A.5.30	ICT readiness for business continuity	—
A.7.4	Physical security monitoring	—
A.8.9	Configuration management	—
A.8.10	Information deletion	—
A.8.11	Data masking	—
A.8.12	Data leakage prevention	—
A.8.16	Monitoring activities	—
A.8.23	Web filtering	—
A.8.28	Secure coding	—

If you transitioned from the 2013 edition rather than certifying fresh, the practical consequence is that your document set has a visible seam. Access control, cryptography, backup and supplier controls all point at policies that predate 2022. ISO 27001 configuration management points at nothing, or at a paragraph someone bolted onto the IT security procedure during the transition project to close the gap on paper. Auditors know this. Of the eleven new controls, A.8.9 and A.8.16 are the two that most often get sampled hard for exactly that reason, so it is worth reading our walkthrough of ISO 27001 logging and monitoring requirements alongside this one.

For the full picture of how the themes and control families fit together, start from our overview of the 93 ISO 27001 Annex A controls.

ISO 27001 configuration management versus change management (A.8.32)

This is the ISO 27001 configuration management distinction people get wrong most often, and the one that produces duplicated documents. A.8.9 governs the state. A.8.32 governs the transition between states.

Question	A.8.9 Configuration management	A.8.32 Change management
What is controlled	The approved target configuration of an asset	The process for altering a configuration
Primary artifact	Baseline / hardening standard per platform	Change record with assessment and approval
Failure mode	Drift, vendor defaults, unknown current state	Unauthorised or untested change, no rollback
Test an auditor uses	“Compare this live host to its baseline”	“Show me the record for this change”
Who usually owns it	Platform or infrastructure engineering	Change authority or release management

They interlock: a configuration change that bypasses A.8.32 is an A.8.9 finding as well, because the live state no longer matches an approved baseline. Note too that A.8.32 in the 2022 edition merged the old operational change control with three separate development change controls, so one process now has to cover the deploy pipeline and the 2am firewall rule — we unpack that in the ISO 27001 secure development policy guide. A.8.9 also leans on your asset inventory under A.5.9 and feeds vulnerability management under A.8.8: you cannot harden assets you have not listed, and you cannot judge whether a missing patch matters without knowing what is running.

Where ISO 27001 configuration management baselines come from: CIS, DISA, NSA, CISA and NIST

ISO 27001 configuration management does not name a single hardening source, and the standard does not expect you to invent one. The standard’s guidance explicitly points at freely available vendor and open-source configuration instructions, provided you check them against your own minimum security requirements. That is permission to stop writing hardening standards from scratch.

The most useful free catalogue is NIST’s National Checklist Program repository at checklists.nist.gov, which holds machine-readable and prose checklists for commercial, open-source and government products. The governing publication was updated this year: NIST SP 800-70 Revision 5, published May 2026, superseded Revision 4 (February 2018), which NIST formally withdrew on 8 May 2026.

Two changes in that revision matter for ISO 27001 configuration management, and most guidance written before mid-2026 gets them wrong:

• The United States Government Configuration Baseline (USGCB) programme is retired. Revision 5 removed the USGCB section and its appendix entirely. Older sources — including NIST’s own SP 800-128 — still list USGCB as a baseline source. Do not cite it in a 2026 policy.
• CISA is now named as an authoritative source of government checklists alongside DISA and NSA. Revision 5 sets a precedence order for federal civilian users: NIST-produced checklists first, then DISA, NSA or CISA, then vendor checklists, then anything else on the repository.

Revision 5 also carries a warning that belongs in every baseline decision: government-sourced checklists, military ones in particular, can represent a high-water mark that needs tailoring before civilian adoption. If someone has told your team to “just apply the STIG” to a customer-facing SaaS estate, that sentence is your counter-argument.

Baseline source	Best for	Cost	Watch out for
CIS Benchmarks	Operating systems, cloud platforms, databases, browsers	Free PDFs; paid tooling and automated content	Level 1 vs Level 2 profiles are very different bars
DISA STIGs	Deep, prescriptive OS and network device hardening	Free	Written for defence risk tolerance; expect to tailor
NSA / CISA guidance	Cloud, identity and network hardening advisories	Free	Advisory in style; fewer per-setting checks
NIST National Checklist Program	Finding whatever exists for a given product, in SCAP form	Free	Coverage varies by product and version
NIST macOS Security Compliance Project	Mac fleets; generating a baseline from a rule library	Free, open source	Needs someone comfortable with the tooling
Vendor hardening guides	Niche or new products with no third-party benchmark	Usually free	Vendors optimise for support cost, not your risk

If you are already using CIS content, our CIS Controls to ISO 27001 mapping shows how the safeguards line up against Annex A.

The deviation register is the real ISO 27001 configuration management evidence

Here is the part almost no guidance on ISO 27001 configuration management covers, and it is the part that decides whether your audit goes well.

Nobody applies a benchmark in full. You adopt CIS Level 1 for your Linux fleet, and eleven recommendations break something — a required legacy protocol, a monitoring agent that needs a permission the benchmark closes, a vendor appliance that will not support the TLS floor. The honest outcome is not “we are 100% CIS compliant.” It is a baseline plus a short, dated, approved list of settings where you knowingly differ, each with a reason and a compensating control.

ISO 27001 configuration management does not use the word “deviation” anywhere. But three independent primary sources treat the deviation record as the deliverable, which is why an auditor recognises it on sight:

Source	What it requires
NIST SP 800-53 Rev. 5, CM-6(c)	Identify, document and approve any deviations from established configuration settings, based on defined operational requirements
NIST SP 800-128, §3.2.2	Where secure settings break functionality, resolve the problem or document it as a deviation or exception, approved through change control, and record it in the baseline
NIST SP 800-70 Rev. 5 (May 2026)	A checklist is a starting point; customise it with specific deviations carrying documented justifications, risk acceptance and compensating controls

SP 800-70 Rev. 5 goes a step further and states a preference most compliance teams would never dare write down themselves: scoped, documented deviations for the subset of users or devices that genuinely need them are preferable to blocking people from doing their jobs, as long as an authorising official accepts the risk — and preferable to relaxing the setting across the whole estate. That is a defensible position in an ISO audit too, because clause 6.1.3 already expects risk treatment decisions to be owned and accepted. CISA takes the same line in its own cloud directive: agencies may accept risk for deviations from the mandatory baselines to meet operational needs, provided the deviation is identified and explained.

A workable deviation register needs seven columns: asset or asset group, baseline and setting reference, required value, actual value, business reason, compensating control, and the owner plus review date. If your risk work is already structured, link each row to the relevant entry — our guide to the ISO 27001 Statement of Applicability explains how applicability decisions and risk acceptance hang together.

Cloud and SaaS: the half of A.8.9 that people forget

Ask a 60-person software company where its ISO 27001 configuration management risk lives and you will hear “the servers.” Then look at the estate: a handful of managed container services, and Microsoft 365 or Google Workspace holding every document, every mailbox and every identity. The tenant admin console is a configuration surface with hundreds of settings, no vendor-default hardening, and no CIS build script running at provisioning time.

There is now a free, maintained ISO 27001 configuration management baseline for exactly that. Through its Secure Cloud Business Applications project, CISA publishes secure configuration baselines for Microsoft 365 and Google Workspace, plus open-source assessment tools — ScubaGear for M365 tenants and ScubaGoggles for Workspace — that scan a live tenant and report every setting that misses the baseline. The published product baselines cover Entra ID, Exchange Online, SharePoint and OneDrive, Teams, Defender and Power Platform on the Microsoft side; Gmail, Drive and Docs, Calendar, Chat, Meet, Groups for Business and common controls on the Google side.

These are mandatory for US federal civilian agencies under Binding Operational Directive 25-01, issued 17 December 2024: identify tenants by 21 February 2025, deploy the assessment tools by 25 April 2025, and implement the mandatory Microsoft 365 policies by 20 June 2025. CISA’s required-configurations page lists 1 December 2026 for the Google Workspace policies, so the Workspace half is live federal policy within weeks of this being written. You are almost certainly not a federal agency — but a free baseline and a free scanner for the SaaS where your data actually sits is the cheapest ISO 27001 configuration management win available, and the tool output is exactly the kind of drift report A.8.9’s “monitored” verb is asking for.

Mapping ISO 27001 configuration management to NIST and CIS

Annex A gives ISO 27001 configuration management one sentence. If you want a structure to build against, borrow one. NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems (August 2011, updated 10 October 2019), splits the discipline into four phases that line up almost exactly with A.8.9’s verbs:

SP 800-128 phase	A.8.9 verb it satisfies	Related NIST SP 800-53 Rev. 5 control
Planning	Established	CM-1 Policy and Procedures, CM-9 Configuration Management Plan
Identifying and implementing configurations	Documented, Implemented	CM-2 Baseline Configuration, CM-6 Configuration Settings, CM-7 Least Functionality, CM-8 System Component Inventory
Controlling configuration changes	Implemented (and A.8.32)	CM-3 Configuration Change Control, CM-4 Impact Analyses, CM-5 Access Restrictions for Change
Monitoring	Monitored, Reviewed	CM-6(d), CM-8, CM-11 User-Installed Software

SP 800-128’s Appendix F is more useful than most paid templates: ten best practices for establishing secure configurations — use common secure configurations as the basis; centralise policy and distribution; tailor settings to each component’s function and role; eliminate unnecessary ports, services and protocols; limit remote connections; set strong password policy; deploy endpoint protection; use cryptography; run a patch management process; and control software installation. Walk your baseline against those ten and you will find your gaps before an auditor does. Appendices D and I give a sample configuration management plan outline and a security impact analysis template, free.

On the operational side, CIS Controls v8.1 (June 2024) devotes Control 4 — Secure Configuration of Enterprise Assets and Software — to this, with twelve safeguards and, unlike ISO, actual numbers:

Safeguard	Requirement	Group
4.1	Documented secure configuration process for assets and software; review annually or on significant change	IG1
4.2	Documented secure configuration process for network devices; same review cadence	IG1
4.3	Automatic session locking — no more than 15 minutes on general-purpose OS, 2 minutes on mobile	IG1
4.4 / 4.5	Firewall on servers; host firewall or port filtering on end-user devices with default deny	IG1
4.6	Manage assets securely — version-controlled Infrastructure as Code, admin interfaces over SSH or HTTPS, no Telnet or HTTP unless essential	IG1
4.7	Manage default accounts such as root and administrator — disable or make unusable	IG1
4.8	Uninstall or disable unnecessary services	IG2
4.9	Configure trusted DNS servers	IG2
4.10	Device lockout on portable devices — max 20 failed attempts on laptops, 10 on tablets and phones	IG2
4.11	Remote wipe capability on enterprise-owned portable devices	IG2
4.12	Separate enterprise workspaces on mobile devices	IG3

Those intervals are CIS’s numbers, not ISO’s — ISO 27001 configuration management sets none of them. Which brings us to the most common mistake in this area.

What ISO 27001 configuration management does not say

ISO/IEC 27001:2022 states no frequency for ISO 27001 configuration management review. Not in Annex A, not in clause 9. The guidance standard says configurations should be monitored and reviewed, and that templates should be revisited in light of new threats, vulnerabilities and platform changes — but it gives no interval. Quarterly scans and annual baseline reviews are convention, and sensible convention, but if you tell an auditor “ISO requires quarterly” you have just told them you have not read the control.

Set your own interval, write down why it is justified for your risk, and be able to show you met it. Anchoring to an external number helps: CIS Safeguard 4.1 asks for annual review of the configuration process, and most drift tooling reports continuously, so “continuous automated monitoring plus annual baseline review, with out-of-cycle review on significant platform change” is a defensible policy sentence that you can actually evidence.

Three other things A.8.9 does not require, despite what you may read: a standalone configuration management policy document (it is not on the list of ISO 27001 mandatory documents — a hardening standard inside an existing IT procedure is fine), a particular tool, or a CMDB. A git repository of Infrastructure as Code with a review history satisfies “documented” and “established” better than most purpose-built databases.

The A.8.9 evidence pack that passes an audit

When the auditor reaches A.8.9, they will usually pick one or two live assets and work backwards through your ISO 27001 configuration management. Have these ready:

• A named baseline per asset type — server OS, end-user device, network device, cloud platform, SaaS tenant — each stating its source benchmark and profile level, its owner, and its version date.
• Proof the baseline is applied at build, not retrofitted: a pipeline log, an MDM enrolment record, a build checklist signed for the sampled host.
• A current drift report from the last monitoring cycle, with the exceptions either remediated or on the deviation register.
• The deviation register, dated, owned, with compensating controls and review dates.
• Change records for the configuration changes made to the sampled asset, tying A.8.9 to A.8.32.
• Restricted access to configuration tooling — the group policy console, the IaC repository, the MDM tenant. Configuration data tells an attacker exactly how you are defended, and the people who can edit a baseline should be the small set you manage under ISO 27001 privileged access requirements.
• A review record showing the baseline itself was reconsidered, with the trigger — a benchmark update, a platform version, a new threat.

Common ISO 27001 configuration management mistakes

• Treating the benchmark as the ISO 27001 configuration management baseline. CIS Level 1 downloaded and never tailored is not a baseline; it is someone else’s opinion. Your baseline is the benchmark plus your approved deviations.
• Documenting the current state instead of the target state. An export of how production is configured today is an inventory, not a standard. A.8.9 wants a target you can test against.
• No SaaS baselines. The M365 or Workspace tenant is usually the largest unhardened surface in the business.
• Monitoring without closing the loop. Drift reports nobody triages are worse than none — they prove you knew.
• Hiding deviations. A clean 100% claim invites one failed spot check to undo it. A frank register with eleven approved exceptions survives scrutiny.
• Letting the baseline go stale. A hardening standard citing an operating system you no longer run reads as a control that was never operated.
• Quoting USGCB or SP 800-70 Rev. 4. Both retired in 2026. Small detail, but it dates your document instantly.

ISO 27001 configuration management FAQ

Is a configuration management policy mandatory for ISO 27001?

A separate policy document is not mandatory. The seven documents and six record categories that clause 7.5 makes mandatory do not include one. But A.8.9’s own wording requires configurations to be documented, so if the control is applicable in your Statement of Applicability you need a written baseline somewhere — in a hardening standard, an IT operations procedure, or version-controlled Infrastructure as Code.

Can I exclude A.8.9 from my Statement of Applicability?

Realistically, no. Any scope that includes a laptop, a server, a cloud account or a SaaS tenant has configurations to manage. Excluding A.8.9 invites the auditor to ask how your assets got their current settings, and the only safe answer to that is the baseline you just said you do not need.

How often does ISO 27001 require configuration reviews?

It does not say. The standard requires configurations to be monitored and reviewed without naming an interval. Set a frequency, justify it against your risk assessment, and meet it. Continuous automated monitoring with an annual baseline review, plus out-of-cycle reviews on significant change, is a common and defensible pattern.

Do I need a CMDB to satisfy ISO 27001 configuration management?

No. You need to know which assets exist (A.5.9), what their approved configuration is, and whether reality matches. A CMDB is one way to hold that; an asset register plus an IaC repository plus a compliance scanner is another, and for most companies under a few hundred employees it is cheaper and more accurate.

How does A.8.9 relate to vulnerability management?

Closely enough that they are often audited together. A.8.8 covers patching and known vulnerabilities; A.8.9 covers settings. A missing patch and an enabled legacy protocol are different findings with the same root cause — nobody owns the target state of that platform. Scanners usually report both, which is why one tool can serve as evidence for both controls if you separate the reports.

Where to start

ISO 27001 configuration management is one of the cheapest controls to get right, because other people maintain the hard part for free. Pick your three largest asset populations. For each, choose a published benchmark, decide the profile level, apply it in a test environment, and write down what broke and what you decided to do about it. That last list is your deviation register, and the day you have it, ISO 27001 configuration management stops being the weakest control in your Statement of Applicability.

If you would rather not draft the baseline standard, deviation register, configuration review record and supporting procedures from a blank page, the ISO 27001 Toolkit — 165 editable templates covering all 93 Annex A controls and every mandatory clause document, $99 as a one-off download — gives you the document set to tailor instead. It is the same structure the evidence pack above assumes, so the mapping work is already done.