What is configuration management?
Configuration management answers two questions: how should a system be configured, and is it still configured that way? The term comes from two fields. In IT service management under ITIL it means knowing the configuration items (CIs) of a service and their relationships, kept in a CMDB. In information security the focus is on the secure target state.
Both need the same foundation. A secure configuration can only be defined and checked for systems that are known, and an inventory without a target state says nothing about whether a system is configured correctly. How configuration management fits into an ISMS is covered in the guide to implementing an ISMS.
What do ISO 27001, NIS2 and DORA require?
ISO/IEC 27001 lists configuration management as control 8.9, the NIS2 Implementing Regulation prescribes it for the entities it covers, and DORA requires the configuration of ICT assets to be mapped:
| Framework | Provision | What is required |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 8.9 | establish, implement and monitor configurations, including security configurations, across their lifecycle; implementation guidance, for example on hardening templates and protection against unauthorized change, is in ISO/IEC 27002 |
| NIS2 Implementing Regulation | Annex, point 6.3, of Implementing Regulation (EU) 2024/2690 | for entities of the types listed in § 30(3) of the German BSI Act (BSIG), such as cloud computing service providers: establish, document, implement and monitor configurations including security configurations. They are enforced on newly installed systems and systems in operation and reviewed at planned intervals and after significant incidents or significant changes |
| BSIG | § 30(2), second sentence, no. 5 BSIG | security measures in the acquisition, development and maintenance of systems for essential and important entities. Under § 28(5) and (6) BSIG, § 30 does not, as a rule, apply to certain telecommunications and energy companies, nor to financial entities under DORA |
| DORA | Article 8(4) of Regulation (EU) 2022/2554 | financial entities map the configuration of their information and ICT assets and the links and interdependencies between them |
The baseline as the target state
A baseline is the documented, approved target state for a class of systems, for example all Windows servers, all firewalls or all databases of one type. The starting point is vendor recommendations and published hardening guides, adapted to your own risk assessment.
| Component | Example |
|---|---|
| Scope | all Linux servers in the production environment |
| Security settings | disabled default accounts, password and lockout policies, logging |
| Disabled services and protocols | no unencrypted administrative access |
| Approval | accountable role, date, version |
| Justified deviations | exception per system with a risk assessment and an expiry date |
| Review | interval and triggers for reviewing the baseline itself |
Enforce the baseline on new installation and restoration, ideally through templates or automation tools. Every change to systems and to the baseline itself goes through change management.
Measuring configuration drift: a comparison
Configuration drift is the gradual divergence of the actual configuration from the baseline. It comes from emergency fixes that were never reversed, manual changes made while troubleshooting, updates that reset settings, and systems built outside the regular process. Without regular comparison it stays invisible.
Fictional example: the figures are invented for illustration. A comparison against the baseline "Linux servers production" across 120 systems shows:
| Result | Systems | Share |
|---|---|---|
| matches the baseline | 102 | 85% |
| deviates, with an approved and valid exception | 9 | 7.5% |
| deviates, without an exception | 9 | 7.5% |
That makes 111 of 120 systems compliant (92.5%), 102 of them without an exception. For the nine deviations without an exception, look for the change record. If there is none, that is a finding in change management, not only in configuration management. The owner then decides per system: revert, or apply for a time-limited exception with a risk assessment.
Keep the comparison with its date, the baseline version and the decisions. With this record you can show an auditor that target configurations are defined, implemented and monitored. New systems that went live without a baseline and expired exceptions are the next things to check.
How do configuration management, change management and a CMDB differ?
Configuration management sets and checks the target state, change management decides on individual changes, and a CMDB records which components exist.
| Criterion | Configuration management | Change management | CMDB |
|---|---|---|---|
| Type | discipline | process | tool and data set |
| Guiding question | How should a system be configured, and is it? | May this change be made? | Which components exist, and how are they connected? |
| Output | baselines, configuration states, deviation reports | approved and documented changes | CIs with attributes and relationships |
| Reference in ISO/IEC 27002:2022 | control 8.9 | separate control 8.32 on change management | no control of its own, a possible source for the asset inventory |
Secure configuration in Rizzqo
In Rizzqo, the secure configuration requirements of frameworks such as ISO 27002 are attached to each relevant system. The responsible person uploads evidence, such as the latest check against the baseline. If hardening is missing, you assess the risk in euros and plan the hardening as a task that syncs both ways with Jira.