ISO 27001 A.8.9: Keep configurations secure and consistent

What A.8.9 requires in practice

A.8.9 covers configuration management for hardware, software, services and networks, including security configurations. It lists five activities: establish, document, implement, monitor and review. Together they ensure that settings are decided deliberately, applied consistently and not allowed to drift unnoticed.

In practice an organisation decides what secure settings each important system should have, writes that down in a form people can use and applies it when systems are built or changed. It then watches for differences between the intended state and the actual state, and reviews the settings from time to time so they remain suitable. Cloud services and network equipment are included, not only servers and workstations.

Outputs are defined and recorded configurations, systems deployed in line with them, a way of noticing change and evidence of review. The control does not demand any specific benchmark or tool. Using a published hardening guide as a starting point is one method Sterling's teams use, but the control leaves that choice open.

Define a baseline that fits the system's purpose

A baseline describes the intended state for an identifiable class of asset or service. It should reflect the information handled, the function provided and relevant security requirements. Vendor recommendations and recognised technical guidance can inform it, but applying every available setting without testing can interrupt necessary business functions.

Consider the settings that materially affect protection: enabled services, administrator access, default accounts, session behaviour and other relevant features. Explain justified differences between system types. A public application server and an employee workstation need related governance, but they should not be forced into an identical configuration merely to simplify a spreadsheet.

Connect the approved state with the deployed state

Identify which baseline applies to each relevant asset and which version was implemented. Keep changes traceable to a responsible person and decision. This can be achieved through appropriate system records, controlled configuration files or another method suited to the environment. The outcome matters more than the name of the repository.

Integrate updates with change management. A change can be authorised while still leaving documentation stale, so include the baseline and operational records in the completion decision. Protect configuration information itself: it may reveal sensitive architecture or access details and should not become an unrestricted audit attachment.

Why secure configuration matters to the business

Many incidents come not from sophisticated attacks but from settings left open, default accounts left active or systems that differ from each other without anyone knowing. Inconsistent configuration also makes outages harder to diagnose and repairs slower. A business that knows what its systems should look like, and can tell when they stop looking like that, avoids a large class of avoidable problems. Customers value the predictability: services behave the same way across sites and environments. Configuration discipline also supports change control and recovery, because rebuilding a system from a known state is far faster than reconstructing it from memory. Auditors treat it as a reliable indicator of operational maturity.

How to implement A.8.9

Work out the approved state first, then show that real systems match it. Keep the baseline practical: a short standard that people follow is worth more than a long one that nobody reads.

1. List the system types that matter, including network devices, cloud services and applications as well as servers and laptops.
2. Define a secure baseline for each type, using supplier and community guidance where suitable and adapting it to your purpose.
3. Record the baseline somewhere people can reach, with an owner who keeps it current.
4. Apply it during build and change, so new systems start in the approved state, and link configuration changes to your normal change approval.
5. Choose how drift will be detected, and decide how justified differences are approved and recorded.
6. Review baselines when systems, threats or services change, and when a supplier alters the default settings of a product you use.
7. Test a sample of live systems, including cloud and network settings, against their baseline and act on differences, recording justified exceptions.

Illustrative software example: the emergency setting that survived

Illustrative BPO example: inconsistent workstations across sites

A hypothetical BPO business operates the same customer workflow at two sites. Devices at the newer site use an approved build, while older devices retained settings from an earlier project. Managers assume that identical application screens mean the underlying security configuration is also identical.

The organisation samples actual settings against the appropriate baseline and discovers unexplained differences in local privileges and session behaviour. It plans controlled correction, tests the impact on the customer workflow and confirms the resulting state. The evidence connects each site's operating environment with an approved requirement, rather than relying on the age or appearance of the workstation.

Detect drift and distinguish it from justified variation

Drift is a difference between intended and actual configuration. It can result from an unauthorised action, a failed deployment, a supplier change or an approved modification that was not incorporated into the baseline. A detected difference needs interpretation; it is not automatically proof of malicious activity.

Choose monitoring and review methods proportionate to the environment. Automated comparison can help at scale, while careful sampling may be appropriate for a smaller set of systems. Define who investigates differences and how exceptions are approved, reviewed and removed. Repeatedly suppressing a warning without understanding its cause can turn monitoring into a misleading display.

Evidence and tests that establish control

Common nonconformities with A.8.9

Configuration findings usually involve a documented standard that live systems do not follow.

• A baseline exists, but a sample of servers or devices shows settings that differ with no approval recorded.
• Default accounts or sample settings left active on newly installed systems.
• Network and cloud settings never reviewed since they were first set up.
• Emergency changes made directly on a system and never reflected in the recorded configuration.
• No one is named as owner of the baseline, so it is out of date.