Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Starter Kit · Policy

Configuration & Change Management Policy

Updated on 6 min Reviewed by: Cenedril Editorial
A.8.9A.8.32 ISO 27001BSI OPS.1.1.3CIS Benchmarks

Every production environment relies on configurations — operating systems, network devices, databases, cloud services. If you do not know how your systems are configured, and if changes happen without a traceable process, you lack the foundation for every other security measure.

ISO 27001 addresses this with two Annex A controls: A 8.9 (Configuration Management) and A 8.32 (Change Management). BSI IT-Grundschutz dedicates several modules to the topic (OPS.1.1.1, OPS.1.1.2, OPS.1.1.3, APP.6). CIS Benchmarks provide the concrete hardening templates. Further down you will find the complete template in English and German.

What does it actually cover?

A server that has been running unchanged since initial installation almost certainly has unnecessary services enabled, default passwords in configuration files and outdated protocols. The policy defines how you prevent this state — and how you ensure that every subsequent change happens in a controlled manner.

Configuration management answers the question: what should our systems look like? You define hardened templates based on recognised benchmarks — CIS, BSI, DISA STIGs. Every new system is built from these templates. The CMDB documents the target state and makes it auditable.

Change management answers the question: how do we ensure that changes happen in a controlled and traceable way? Every change follows a defined process — from planning through impact assessment to approval, implementation and post-implementation review.

Why does it matter so much?

Reducing the attack surface. Every service, every open port and every enabled protocol is a potential entry point. Hardened configurations minimise this attack surface systematically. CIS Benchmarks regularly show that default installations have dozens of unnecessary services enabled.

Traceability during incidents. When a system is compromised, the first question is: what changed? Without change records and an up-to-date CMDB, that question is almost impossible to answer. The target-actual comparison instantly shows which configurations deviate from the intended state.

Operational stability. Most severe outages are caused by uncontrolled changes. A formal change process with impact assessment, testing phase and rollback procedures catches errors before they reach production.

What goes into it?

The template covers two major areas — here are the key contents:

Configuration Management (A 8.9):

  • Hardened standard templates — built from CIS Benchmarks, BSI recommendations and DISA STIGs, tested in an isolated environment
  • Identity hardening — minimise privileged accounts, disable unnecessary built-in accounts, service minimisation (only required services, protocols and functions enabled)
  • CMDB — every configuration item with responsible person, last change date, template version and dependency relationships
  • Target-actual comparison — automated compliance scanning, deviations assessed and remediated

Change Management (A 8.32):

  • Formal change process — planning with impact assessment, authorisation levels (routine / significant / major), communication to affected parties
  • Testing in a segregated environment — every significant change is tested before production deployment, including deployment plan and rollback procedures
  • Change Advisory Board — committee for significant changes with representatives from IT operations, information security and affected business units
  • Emergency changes — expedited authorisation process, same documentation requirements, post-implementation review
  • Documentation obligations — operating documentation and continuity plans are updated after every change

How to roll it out

  1. 01

    Survey the current configuration state

    Before you define target configurations, you need a picture of the current state. Which systems are running in production? Which of them have documented configurations? Where do default installations without hardening still exist? This survey shows you where the biggest gaps are — and provides the basis for prioritisation.

  2. 02

    Create hardened templates

    For each system category (operating systems, databases, network devices, cloud services), pick a recognised benchmark as the starting point — CIS Benchmarks are freely available and well documented. Adapt the requirements to your environment and test every template in an isolated environment before deploying it to production.

  3. 03

    Build and populate the CMDB

    The CMDB does not have to be an enterprise tool. What matters is that it becomes the authoritative source for configuration state. Per item: name, responsible person, template version, last change date, dependencies. Start with the critical systems and expand incrementally.

  4. 04

    Define and communicate the change process

    Set the authorisation levels: routine changes (pre-approved), significant changes (formal approval from the Change Advisory Board), major changes (approval from top management). Define the flow from request through impact assessment to rollback procedures. Communicate the process to everyone who performs or requests changes.

  5. 05

    Set up automated target-actual comparison

    Implement compliance scanners that regularly check configurations against the hardened templates. Deviations are automatically flagged, assessed and fed into the remediation process. Without automation, the target-actual comparison remains a manual exercise that quickly hits its limits as the system landscape grows.

Where it goes wrong in practice

From audit experience, sorted by frequency:

1. Configurations without a baseline. Systems are installed, manually configured and never checked against a defined standard. Every server looks different, nobody knows which services are enabled. When the next vulnerability advisory arrives, there is no basis to assess whether your systems are affected.

2. Changes without impact assessment. A patch is applied, a service enabled, a firewall rule changed — all without prior analysis of the consequences. The Monday morning outage traces back to the Friday change that nobody reviewed.

3. CMDB exists but nobody maintains it. The database was built once and has been outdated for two years. New systems are not registered, changes are not tracked. In an audit, an outdated CMDB is worse than none at all — it suggests an overview that does not exist.

4. Emergency changes as the norm. The expedited approval process for emergencies becomes the standard path because it is faster. After six months, 40 % of all changes run as emergencies — with correspondingly patchy documentation.

5. No rollback procedure. The change goes wrong, but there is no documented way back. The team improvises under time pressure — and makes additional mistakes in the process. Every significant change needs a tested rollback plan before it goes to production.

Template: Configuration & Change Management Policy

Full policy text

Configuration & Change Management Policy

.md · EN.md · DE

Document control
Owner: [POLICY_OWNER_ROLE, e.g. Information Security Officer]
Approved by: [APPROVER_NAME_AND_ROLE]
Version: [VERSION]
Effective date: [EFFECTIVE_DATE]
Next review: [NEXT_REVIEW_DATE]

1. Legal/Regulatory Basis

ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Annex A — Technological Controls:

  • A 8.9 — Configuration Management
  • A 8.32 — Change Management

BSI IT-Grundschutz:

  • OPS.1.1.1.A5 (Definition of Hardened Standard Configurations)
  • OPS.1.1.1.A7 (Ensuring Proper IT Operations)
  • OPS.1.1.1.A8 (Regular Target/Actual Comparison)
  • OPS.1.1.2.A11 (Documentation of IT Administration Activities)
  • OPS.1.1.2.A26 (Configuration Backup)
  • APP.6.A4 (Rules for the Installation and Configuration of Software)
  • OPS.1.1.3.A1 (Concept for Patch and Change Management)
  • OPS.1.1.3.A2 (Definition of Responsibilities)
  • OPS.1.1.3.A5 (Handling of Change Requests)
  • OPS.1.1.3.A6 (Coordination of Change Requests)
  • OPS.1.1.3.A7 (Integration of Change Management into Business Processes)
  • OPS.1.1.3.A10 (Ensuring the Integrity and Authenticity of Software Packages)
  • OPS.1.1.3.A11 (Continuous Documentation of Information Processing)

Additional jurisdiction-specific laws and regulations are listed in the Legal Register and incorporated by reference.

2. Purpose & Scope

This policy establishes rules for managing the security configurations of hardware, software, services and networks, and for controlling changes to information processing facilities and information systems at [YOUR_ORGANISATION_NAME]. It ensures that IT components operate with required security settings throughout their lifecycle and that changes are implemented in a controlled, documented manner that preserves information security.

The policy applies to all IT systems, applications, services, networks and infrastructure components operated by or on behalf of the organisation, including cloud-hosted environments. It covers all personnel and third parties who configure, administer, change or maintain these components.

Configuration management and change management are complementary disciplines: configuration management defines and enforces the secure baseline state of IT components, while change management ensures that any deviation from or update to that baseline is planned, authorised, tested and documented. Together they address a fundamental cause of security failures — uncontrolled configurations and unmanaged changes.

3. Secure Configuration Management (A 8.9)

Configurations — including security configurations — for hardware, software, services and networks are established, documented, implemented, monitored and reviewed. IT components are categorised and a hardened standard configuration is defined for each category. These templates implement the security requirements of the organisation and incorporate vendor recommendations and publicly available security guidance. Software is installed with minimum required functionality and minimum necessary permissions, with data-minimising privacy settings applied by default. All configuration data is protected against unauthorised access and its integrity is preserved.

3.1 Hardened Standard Templates

  • Publicly Available Guidance: Hardened standard templates are developed using publicly available guidance, including vendor security baselines, recommendations from recognised security organisations (e.g. BSI IT-Grundschutz, CIS Benchmarks, DISA STIGs) and industry best practices. The source references for each template are documented alongside it.
  • Protection Level Determination: The required level of security for each configuration template is determined by the protection needs of the IT component category — specifically the confidentiality, integrity and availability requirements of the data processed and services provided. Higher protection needs result in stricter configuration baselines.
  • Policy Alignment: Every configuration template is aligned with the organisation's information security policy, topic-specific policies, applicable standards and other security requirements. Templates are reviewed for consistency with the access control policy, data classification scheme and applicable compliance obligations before deployment.
  • Feasibility & Applicability: Before a configuration template is finalised, its feasibility and applicability within the organisation's specific operational context are assessed. Where a security requirement from a reference baseline cannot be applied without breaking functionality or creating disproportionate operational impact, a compensating control is documented and approved.

Each configuration template is version-controlled, uniquely identifiable and stored in a secure, access-controlled location. Templates are tested in an isolated environment before being deployed to production systems. Security updates for software are applied before components enter production use.

3.2 Identity & Access Hardening

  • Minimisation of Privileged Identities: The number of identities with privileged or administrator-level access rights on any IT component is minimised. Shared or generic administrator accounts are avoided; where technically unavoidable, their use is strictly controlled and every action is attributable to an individual person. Role separation between administrative and normal operational functions is enforced through distinct account identities.
  • Disabling Unnecessary Identities: Unnecessary, unused or insecure built-in accounts and identities (e.g. default guest accounts, anonymous access accounts, vendor service accounts no longer required) are disabled or removed as part of the initial hardening process and on an ongoing basis. When personnel leave the organisation or change roles, their associated identities are reviewed and disabled promptly.

3.3 Service & Function Minimisation

  • Disabling Unnecessary Functions & Services: Only services, protocols, functions and features that are required for the operational purpose of an IT component are enabled. Unnecessary functions — including unused network services, demonstration or sample applications, unused scripting engines and surplus operating system components — are disabled or uninstalled. Software is installed with the minimum required functional scope.
  • Restricting Access to Utility Programs & Host Parameters: Access to powerful utility programs (e.g. shell interpreters, registry editors, diagnostic tools, bootloader configuration interfaces) and host parameter settings is restricted to authorised administrators. Where possible, access is controlled via role-based permissions and logging is enabled for all use of such utilities.

3.4 System Baseline Settings

  • Clock Synchronisation: Clocks on all IT components are synchronised to an authoritative time source using NTP or an equivalent protocol. Accurate and consistent timestamps across systems are required for log correlation, incident investigation, certificate validation and audit evidence.
  • Vendor Default Authentication Information: Vendor-supplied default passwords, authentication tokens, certificates and other default authentication information are changed immediately after initial installation, before any system is connected to the production network. Other important default security-related parameters (e.g. default community strings, default API keys, default encryption settings) are reviewed and updated as part of the initial configuration process.
  • Automatic Session Time-Out: Time-out facilities are configured on all interactive computing devices and sessions to automatically log off or lock the device after a defined period of inactivity. The inactivity threshold is set in accordance with the sensitivity of the system and data accessible through the session.

3.5 Licence Verification

  • Licence Compliance: Configuration templates and deployment processes include a verification step confirming that licence requirements for all software components are met before installation. The software licence register (see the IPR Compliance Policy) is consulted to confirm that the number of installations does not exceed licensed entitlements and that licence terms are respected in the deployment configuration.

3.6 Template Review & Updates

  • Periodic Template Review & Update: All hardened standard configuration templates are reviewed periodically and updated when new threats or vulnerabilities affecting the relevant component category are identified, when new software or hardware versions introduce security-relevant changes, or when vendor security guidance is updated. After each review, updated templates are version-incremented, tested and re-deployed to affected systems.

4. Configuration Records & Monitoring (A 8.9)

Configuration records for all IT components are maintained in a configuration management database (CMDB) or equivalent inventory system. The CMDB is the authoritative source for configuration state and supports both operational management and security monitoring. Access to configuration records is restricted to authorised IT operations personnel.

4.1 Configuration Records

  • Owner & Contact Information: Each configuration record includes the current owner or designated point of contact for the asset — the person accountable for the IT component's security configuration and responsible for approving configuration changes.
  • Last Configuration Change Date: The date and nature of the most recent configuration change are recorded for each asset, enabling IT operations to identify components that have not been updated within expected maintenance cycles and to correlate configuration changes with incident timelines.
  • Configuration Template Version: The version of the hardened standard configuration template currently applied to each asset is recorded. This enables rapid identification of components that are not running the current approved template and facilitates targeted remediation after a template update.
  • Dependency Relations: Configuration records capture relationships and dependencies between assets — for example, which servers depend on a shared database configuration, which applications rely on a specific middleware version and which network devices enforce access control for a given server segment. These dependency mappings are used in impact assessments for configuration changes.

4.2 Configuration Monitoring Scope

  • Maintenance Utilities: Maintenance tools with access to system configurations (e.g. software deployment agents, patch management clients, firmware update utilities) are included in the configuration monitoring scope. Their own configuration is subject to the same hardening and review requirements as the systems they manage.
  • Remote Support Tools: Remote support and remote administration tools (e.g. VPN gateways, jump servers, remote desktop services, out-of-band management interfaces) are included in configuration monitoring. Access via these tools is logged and the configurations of the remote support infrastructure are maintained in accordance with the same hardened templates as other production components.
  • Enterprise Management Tools: Enterprise IT management platforms (e.g. configuration management databases, IT service management systems, monitoring platforms, identity management systems) are included in configuration monitoring. Because of their privileged access to the managed infrastructure, these systems are subject to heightened hardening requirements and regular configuration reviews.
  • Backup & Restore Software: Backup and restore software configurations are included in the monitoring scope. Configuration backups are performed at both the application level and the system level on a regular schedule. An additional configuration backup is taken before any IT administration activity with potentially wide-reaching impact. The restorability of configuration backups is verified periodically to confirm that a clean configuration state can be recovered when required.

4.3 Target-Actual Comparison

A regular target-actual comparison is performed for all IT components in scope — comparing the current configuration of each component against its defined hardened standard template. This comparison is performed using automated configuration compliance scanning tools wherever technically feasible, producing structured reports of deviations. Where automation is not possible, manual configuration audits are conducted on a defined schedule. Identified deviations are assessed for security impact, classified and remediated within timeframes proportionate to their risk. All deviations and their remediation status are tracked in the CMDB. Automation of configuration enforcement (infrastructure-as-code, desired-state configuration management) is used wherever operational conditions permit, to reduce the window between detection and remediation of configuration drift.

5. Change Management (A 8.32)

All changes to information processing facilities and information systems — including hardware replacements, software installations and updates, configuration modifications, network changes and changes to ICT services — are subject to a formal change management process. This process encompasses documentation, specification, testing, quality control and managed implementation. Inadequate change control is a recognised common cause of system and security failures; this policy ensures that every change is planned, approved, tested and recorded before production deployment. The change management process integrates ICT infrastructure and software changes and applies to production environments including operating systems, databases, middleware and application software. Software packages are sourced only from trustworthy suppliers and their integrity is verified via checksums or digital signatures before installation. Changes are tested in a segregated test environment before production deployment.

5.1 Change Planning & Impact Assessment

  • Planning & Impact Assessment: Every change request includes a documented impact assessment covering security implications, operational dependencies and potential effects on other systems and services. The dependency relations recorded in configuration records (Section 4.1) inform this assessment. All affected systems, services and stakeholder groups are identified before authorisation is sought. Where a change may affect information security controls or ICT continuity arrangements, the Information Security Officer is consulted as part of the assessment.

5.2 Authorisation

  • Authorisation of Changes: Every change requires explicit authorisation before implementation. Authorisation levels are defined by change category and potential impact: routine low-risk changes are authorised by the responsible IT operations team lead, significant changes with broader impact require approval from the Information Security Officer and the relevant asset owner, and major changes affecting core infrastructure or cross-organisational business processes require management-level approval. Unauthorised changes are treated as security incidents. For major changes, the Information Security Officer is involved in the authorisation decision.

5.3 Communication

  • Communication to Interested Parties: Authorised changes are communicated to all relevant interested parties before implementation. This includes affected business units, IT operations teams, system owners and, where the change affects externally visible services, relevant external stakeholders. For changes with broad impact, a change calendar or scheduled maintenance window is published in advance. The coordination process considers information security effects on all target groups and includes a defined escalation path for priority decisions.

5.4 Testing & Acceptance

  • Testing & Acceptance: All changes are tested before production deployment in a segregated test environment that replicates the production configuration as closely as practicable. Acceptance criteria are defined as part of the change plan and are demonstrably satisfied before the change proceeds to production. Acceptance is formally recorded with the name of the responsible person, date and result. Checksums or digital signatures of software packages are verified before installation.

5.5 Implementation & Deployment

  • Implementation & Deployment Plans: Changes are implemented according to a documented deployment plan that specifies the sequence of steps, the responsible persons, the implementation window, the configuration items affected and the post-implementation verification steps. Implementation is performed using the authorised configuration management tooling. Configuration records in the CMDB are updated to reflect the new state immediately upon successful deployment. All administrative activities performed during implementation are documented, recording what changed, when, who made the change and the basis or reason for the change.

5.6 Emergency & Rollback Procedures

  • Emergency & Rollback Procedures: Every change plan includes documented fallback and rollback procedures that describe how to restore the previous configuration state if the change fails, causes unexpected issues or needs to be reversed. A configuration backup is taken before any change with potentially wide-reaching consequences. Rollback procedures are tested during the test phase where feasible. For emergency changes — required to respond to critical security incidents or imminent system failures — an expedited authorisation procedure is defined that maintains accountability while enabling rapid response. Emergency changes are subject to the same documentation and post-implementation review requirements as standard changes.

5.7 Change Records

  • Change Records: A complete record is maintained for every change, covering: the change request and its impact assessment, the authorisation decision with date and authorising person, the communication sent, test results and acceptance evidence, implementation details including the deployment plan, rollback procedure, and any deviations encountered, and the post-implementation verification outcome. Change records are stored in a tamper-evident system and retained according to the organisation's records retention schedule. Changes are documented across all phases, applications and systems.

5.8 Documentation Updates

  • Operating Documentation & User Procedures: When a change affects the operation of a system or service, the relevant operating documentation and user procedures are updated as necessary before or immediately after the change is deployed (see also the IT Operations Security Policy). Outdated documentation is superseded and archived rather than deleted, to preserve the change history.
  • ICT Continuity Plans & Recovery Procedures: When a change affects systems or services covered by ICT continuity plans or incident response and recovery procedures, those plans are reviewed and updated to reflect the changed environment before the change is closed. The change record captures whether continuity plans were reviewed and any updates made.

6. Roles & Responsibilities

  • Top Management: Approves this policy, provides resources for configuration management tooling and change management processes and decides on priority escalations for changes affecting core business processes.
  • Information Security Officer (ISO): Maintains this policy, reviews and approves hardened standard configuration templates for security adequacy, is consulted on all changes with significant security impact and is involved in major change authorisation decisions.
  • IT Operations: Develops, maintains and deploys hardened standard configuration templates; operates the CMDB; performs target-actual comparisons and remediation; implements approved changes in accordance with deployment plans; documents all administrative activities; performs configuration backups before high-impact changes. Responsibilities for patch and change management are defined for all organisational units.
  • Asset Owners / System Owners: Define the protection needs and operational requirements for their assets, approve configuration templates for their systems, authorise changes to their assets within their delegated authority level and ensure that operating documentation and continuity plans for their systems are kept up to date following changes.
  • Change Advisory Board (or equivalent function): Reviews and coordinates significant change requests, considers information security effects on all target groups and provides recommendations on authorisation and scheduling. Facilitates the escalation path to management for priority decisions.
  • All Personnel: Follow authorised configuration settings and report any observed unauthorised changes or deviations from expected system behaviour to IT Operations or the Information Security Officer.

7. Review & Maintenance

This policy and the associated configuration management procedures are reviewed:

  • At least annually, to verify alignment with current IT infrastructure, threat landscape and regulatory requirements.
  • When significant changes to the organisation's IT architecture, business processes or risk profile occur.
  • Following a security incident attributable to a configuration weakness or an unauthorised change.
  • When new IT component categories are introduced that require new hardened standard configuration templates.
  • When updated vendor security guidance, BSI IT-Grundschutz requirements or relevant external standards (e.g. CIS Benchmarks) are published that affect the content of deployed templates.

Configuration template currency is maintained on an ongoing basis: each template is reviewed whenever a new software or hardware version introduces security-relevant changes, and at a minimum annually as part of the overall policy review cycle. The CMDB and the change records it contains are maintained as living documentation throughout the year.

Sources

ISO 27001 Controls Covered

A.8.9 Configuration management A.8.32 Change management

Frequently asked questions

Do I need separate policies for configuration and change management?

One is enough. ISO 27001 lists two controls (A 8.9 and A 8.32), but the topics are so tightly coupled that a combined document reduces maintenance effort. Our template covers both in a single document with clear sections.

What belongs in a CMDB?

For each configuration item: name, responsible person, current configuration version, the template (baseline) the configuration is based on, date of last change, and dependency relationships to other items. The CMDB does not have to be an expensive tool — a well-maintained spreadsheet works as long as it remains the authoritative source.

How often do I need to run a target-actual comparison?

At least annually for all systems and after every significant change. For critical systems, CIS Benchmarks and BSI recommend a higher frequency — ideally automated through compliance scanners that flag deviations immediately.

What is the difference between a routine change and a significant change?

Routine changes are pre-approved, low-risk standard changes (e.g. password reset, patch after release approval). Significant changes affect multiple systems, carry higher risk or alter the architecture — they require a formal impact assessment and approval from the Change Advisory Board.

How do I handle emergency changes?

Emergency changes go through an expedited authorisation process, but the documentation requirements remain the same. Within five working days after the change, complete documentation is submitted and a post-implementation review is conducted.