Control 8.9 asks you to manage the configuration of software, hardware, services and networks through their life, so systems stay secure and unauthorised changes are prevented. Auditors check that configurations are defined, documented, implemented, monitored and reviewed. It is new in ISO 27001:2022.
What it covers
The guidance lists technology broadly: software, hardware, services and networks. The aim is adequate system security over the whole lifecycle and prevention of unauthorised or inappropriate changes.
A process, not a spreadsheet
You need a way to propose, review and approve security configurations, and ways to manage and monitor them afterwards. Smaller organisations may manage this without extra tools. Larger ones may need software that enforces defined configurations.
Five verbs auditors use
The guidance says auditors may check whether the configuration is defined, documented, implemented, monitored and reviewed. Turn each into a question you can answer:
- Defined: is there a stated secure setup for each system type?
- Documented: where is it written down?
- Implemented: does the running system match it?
- Monitored: how do you notice drift?
- Reviewed: who revisits the definition, and when?
What works for engineering teams
Keeping configurations as code in version control gives you a lot of this for free. The pull request is the review and approval. The history is the record of change. A pipeline check that compares the running state to the code covers monitoring.
For systems not managed as code, keep a short baseline document for each type: operating system images, databases, network devices, cloud accounts. Record who approved it and when.
Training
Train people on why strict configuration control matters and how to define and apply security configurations. This includes people with cloud console access, since console changes are the common source of drift.
Documents
The guidance says the control must be documented. Smaller and mid sized companies can cover it in a security procedures document for the IT team. Larger companies may write a configuration management procedure. A list of security configurations is also in the set of documents tied to Annex A that become mandatory when your risks call for this control.
Related control
Configuration management sits close to the control on management of technical vulnerabilities. Insecure defaults and unpatched components are two sides of the same hygiene.
Evidence to gather
- The baselines and their approvals.
- A sample of changes with review records.
- A drift check output or monitoring record.
- The date of the last review.
Quick check
Do we need a configuration management database?
The control does not name one. Smaller organisations may not need extra tools. What you need is a reliable way to define, track and review configurations.
Does infrastructure as code satisfy the control?
It can provide much of the evidence, since it records definition, approval and change. You still need monitoring for drift and a periodic review.
Sources
Last reviewed: 19 October 2026.
