Example of Policy for Configuration Management in Information Security Management System

Policy of Configuration Management

XXX uses a wide variety of components in creating and running its ICT infrastructure and end-user devices. These consist of hardware, software, cloud services and networks and all are potentially vulnerable to attack from threats from different sources. In order to lessen the risk of these components becoming compromised, it is important that we identify the most appropriate ways of configuring them and then ensure that these methods are used throughout our ICT landscape.
This policy describes the main principles on which such standard configurations must be based and sets out the rules for their use.
This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access toXXX’s systems.
The following policies are relevant to this document:

  • Information Security Policy
  • Mobile Device Policy
  • Network Security Policy
  • Cloud Services Policy
  • Configuration Management Process
  • Change Management Process

New components that make up ISMS hardware, software, services and networks must have their required security settings defined and correctly configured prior to their implementation within our ICT environment.
Configurations of existing components must be reviewed periodically to ensure they meet the requirements of this policy.
Such components will include, but are not limited to:

  • Endpoint devices, such as desktops, laptops, mobile phones and tablets
  • Physical network devices, such as routers, switches and firewalls
  • Physical servers, including system software such as operating systems, databases and web servers
  • Cloud infrastructure, such as virtual servers, networks and storage
  • Where possible, standard templates will be used to document the required configuration of ICT components. These templates will be subject to change and version control.
  • The configurations defined will take appropriate account of available sources of information about securing the relevant components, such as vendor templates, guidance from cyber security authorities and best practice organizations, system hardening guides and our own information security policies.
  • Details of configuration standards will be protected as sensitive information which would be of use to an attacker.
  • Configuration standards must be reviewed on a regular basis and kept up to date with changes in the components themselves (such as new hardware or software versions) and the threats and vulnerabilities they face.
  • The correct configuration of components will be monitored and instances where existing settings deviate from the established standard will be investigated and, if necessary, corrected.
  • Where feasible, automated software methods such as Infrastructure as Code (laC) will be used to create components with the correct configuration. Automated audit tools may also be used to check configurations regularly and report on and correct those found to be non compliant.


Configuration Management covers the identification, recording, and reporting of IT components, including their versions, constituent components and relationships. Items that should be under the control of Configuration Management include hardware, software and associated documentation. This procedure is applicable to XXX.


The basic activities of Configuration Management are as follows:

  • Planning. Planning and defining the purpose, scope, objectives, policies and procedures, and the organisational and technical context, for Configuration Management.
  • Identification. Selecting and identifying the configuration structures for all the infrastructure’s Configuration Item(CI), including their ‘owner’, their interrelationships and configuration documentation. It includes allocating identifiers and version numbers for CIs, labelling each item, and entering it on the Configuration management database (CMDB).
  • Control. Ensuring that only authorised and identifiable CIs are accepted and recorded, from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without appropriate controlling documentation, e.g. an approved Change request, and an updated specification.
  • Status accounting. The reporting of all current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance ‘under development’, ‘being tested’, ‘live’, or ‘withdrawn’.
  • Verification and audit. A series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Configuration management system.

Configuration management planning

. A Configuration Management plan should define:

  • the purpose, scope and objectives of Configuration Management
  • related policies, standards and processes that are specific to the support group
  • Configuration Management roles and responsibilities
  • CI naming conventions
  • the schedule and procedures for performing Configuration Management activities: configuration identification, control, status accounting, configuration audit and verification
  • interface control with third parties, e.g. Change Management, suppliers Configuration Management systems design, including scope and key interfaces, covering: CMDB
  • locations of Configuration Management data and libraries controlled environments within which CIs are manipulated
  • support tools (e.g. build and installation tools)
  • housekeeping, including licence management, archiving and the retention period for CIs
  • planned configuration baselines, major Releases, milestones, workload and resource plan for each subsequent period.
  • Checks should be made to ensure that the staff, IT resources, and support tools – including the size of the CMDB to be made available to Configuration Management – are likely to be adequate.Where deficiencies are identified, steps should be taken to obtain further resources or procure enhanced support tools.

Configuration identification

The IT infrastructure configuration should be broken down and uniquely identified to enable effective control, recording and reporting of CIs to the level that the business requires. The scope should include the hardware, and software used to build, release, verify, install, distribute, maintain, recover and decommission CIs. This includes any environments and software tools used to build a CI. Examples of the components that should be identified are:

  • hardware (including network components where relevant)
  • system software, including operating systems
  • business systems – custom-built applications
  • packages – commercial off-the-shelf packages, standard products, and database products,
  • physical databases
  • environments
  • feeds between databases, applications and EDI links
  • configuration baselines
  • software releases
  • configuration documentation, e.g. system and interface specifications, licences, maintenance agreements, SLAs, decommissioning statement
  • Change documentation, deviations and waivers
  • other resources e.g. Users, suppliers, contracts
  • other documentation e.g. IT business processes, workflow, procedures
  • network components


Dept. Head along with IT must implement a controlled change process and provide tailored methods and standard operating procedures for effectively planning, recording, controlling, and validating product requirements and data that contain the requirements. Tailoring will depend on the organization and the level of control or complexity needed.
Configuration management control is accomplished by utilizing the CMDB, a centralized configuration management database, or a series of databases that provide central, logical access to configuration data, containing relevant information such as the configuration items and their attributes, baselines, documentation, changes, and relationships. Requests for Changes must be stored in the CMDB.

Configuration status Accounting
The CMDB tool must be used to track submitted Requests for Changes. The objectives of the system are to provide enhanced coordination, visibility, and accountability. Records describing configuration items must be established and maintained in the CMDB. The tool must assign a unique identifier to each Request for Change and maintain a repository of all change requests. Dept. Heads must record actions in sufficient detail that the content and status of each
Configuration Item is known and previous versions can be recovered. Organizations must maintain product description records, configuration verification records, change status records, and history of change approvals.
The CMDB must contain relevant information about configuration items, their attributes, baselines, documentation, changes, and relationships. The recording of changes must include:

  • The reason for the changes
  • If a proposed change to the configuration item is accepted, a schedule for incorporating the change into the configuration item and other affected areas
  • Indication that changed configuration items have been released only after review and approval of configuration changes. Changes are not official until they are approved


Configuration auditing must be performed by ISMS coordinator to verify the integrity of the processes, systems, items, and baselines under Configuration Management control.

  • The ISMS coordinator conducts these audits to ensure baseline compliance of the configured assets’ hardware, software, and controlled documentation with established requirements, specifications, and functional parameters.
  • Change control processes are also subject to Configuration Management Audits.
  • Configuration Management Audits must be used to ensure the accuracy of the CMDB;
  • determine the accuracy and completeness of Configuration Management processes;
  • verify data and documentation;
  • ensure project compliance with requirements, standards, and conventions.

All audit records and respective deficiencies must be placed into the CMDB, which shall be used to track corresponding action items, suspense dates, and close-out activities. The ISMS coordinator can decide whether these attributes need to be tracked within the CMDB since he/she is responsible for conducting periodic audits. The CMDB must be used to maintain a historical file of all audit information throughout the applicable life cycle.
The ISMS coordinator must conduct its audits on a periodic basis following a defined audit sequence.
The ISMS coordinator must have the responsibility to initiate the audit sequence and oversee its implementation.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

Leave a Reply