Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.9 — Configuration Management

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.9 ISO 27001ISO 27002BSI OPS.1.1.1

Two identical web servers running the same service — yet with different TLS versions, different firewall rules and different logging settings. One was set up manually two years ago, the other last week. A.8.9 requires that configurations for hardware, software, services and networks are documented, standardized and protected against unauthorized changes.

Configuration drift — the gradual divergence of configurations over time — is one of the most common security problems in IT environments. This control ensures systems remain securely configured throughout their entire lifecycle.

What does the standard require?

  • Define standard configurations. For each system type, a documented baseline exists based on vendor recommendations and security best practices.
  • Update baselines regularly. Baselines are reviewed and updated when new threats, software versions or organizational changes occur.
  • Control changes. Configuration changes follow the change management process and are logged.
  • Monitor compliance. Tools monitor systems for deviations from the baseline and report them automatically.
  • Protect configuration data. The configurations themselves are protected against unauthorized access — they often contain security-sensitive details.

In practice

Create configuration baselines per system type. For each type (Windows server, Linux server, network switch, firewall, cloud service) create a separate baseline. Use CIS Benchmarks or vendor recommendations as a foundation, supplemented with organization-specific requirements.

Implement configuration as code. Define configurations as code (Ansible playbooks, Terraform modules, Chef cookbooks). This makes the baseline versioned, testable and reproducible. Manual configuration changes become the exception.

Set up automated compliance checking. Tools like Ansible, InSpec or cloud-native services (AWS Config, Azure Policy) continuously verify whether systems conform to the baseline. Deviations trigger automatic alerts or corrections.

Maintain a configuration management database (CMDB). The CMDB documents the target configuration for each system and the current actual state. It forms the basis for deviation reports and audit evidence.

Typical audit evidence

Auditors typically expect the following evidence for A.8.9:

  • Configuration baselines — documented target configurations per system type (see Configuration and Change Management Policy in the Starter Kit)
  • Compliance reports — evidence of target-actual comparison
  • Change logs — evidence that configuration changes follow the change process
  • CMDB extract — current documentation of system configurations
  • Baseline review records — evidence of regular baseline updates

KPI

Percentage of systems with documented and verified security configurations

Measured as a percentage: how many of your systems have a documented baseline and pass the automated compliance check? Target: above 95%.

Supplementary KPIs:

  • Number of configuration deviations per month (target: decreasing)
  • Mean time between deviation detection and correction
  • Percentage of system types with a current baseline (target: 100%)

BSI IT-Grundschutz

A.8.9 maps to several BSI modules for IT operations and hardening:

  • OPS.1.1.1 (General IT Operations) — requirements for documenting and managing system configurations, regular review and protection against unauthorized changes.
  • CON.8 (Software Development) — configuration management in the development context, versioning of configurations.
  • SYS.1.1 (General Server) — specific hardening requirements for server configurations.
  • NET.3.1/NET.3.2 (Routers and Switches, Firewalls) — configuration management for network devices.

Sources

Frequently asked questions

What is a configuration baseline?

A documented standard configuration for a system type — e.g., a hardened Windows server. It defines all security-relevant settings: disabled services, firewall rules, password policies, logging levels. Every new system is provisioned from this baseline.

How often should configurations be reviewed?

Continuously, if possible through automation. Tools like Ansible, Puppet or Chef can continuously compare configurations against the baseline and flag deviations. At minimum, conduct a manual review quarterly to update the baseline itself.

Does Infrastructure as Code (IaC) count as configuration management?

Yes. IaC is an excellent implementation of A.8.9. Terraform, Ansible, CloudFormation or Pulumi define configuration as code, version it and make deviations immediately visible. The baseline is the repository itself.