Configuration and Asset Management Procedure

1. Introduction

Every service depends on a set of components: servers, software, network devices, licences, documents, people and agreements. If nobody knows exactly what those components are, how they are connected and which version is running, changes become guesses and incidents take longer to diagnose. This procedure keeps a trusted record of those components and the links between them, together with a register of the assets the Organisation owns and the financial and contractual facts about them.

2. Purpose

The purpose is to make sure that the components needed to deliver each service are identified, that accurate information about them is available to incident, problem, change, release and continuity work, that changes to them are made only through authorised change records, and that the records are verified against the real environment on a fixed schedule.

It also makes sure that each asset has an owner, a lifecycle status and a record from acquisition to disposal, so that licences are not overused, warranties are not missed and retired equipment is not left connected.

3. Objectives

• Every component of a catalogued service is recorded as a configuration item before it enters production, with an owner and its relationships.
• The configuration management database (the CMDB) is accurate enough to be relied on: at least [98%] of audited records match reality.
• No change to a production configuration item is made without an approved change record, and the CMDB is updated within [2 working days] of change closure.
• Baselines exist for every tier 1 service and are restored or compared to when a change fails.
• Each hardware, software and licence asset has a named custodian and is reconciled with the asset register at least [twice a year].
• Unauthorised or unknown items found on the network are investigated within [5 working days].

4. Scope

• In scope: configuration items that support services in the service catalogue, meaning hardware, virtual and cloud resources, software and licences, network and security devices, data stores, applications and their interfaces, documentation, service components provided by suppliers, and the services themselves.
• In scope: the asset register for all IT and service assets above the value threshold of [the asset value threshold], and all licensed software regardless of value.
• In scope: relationships between configuration items, for example application to server, service to supplier, and item to the documents that describe it.
• Out of scope: personal items and consumables below the threshold, and customer-owned assets, which are recorded only where the Organisation operates or depends on them.
• Applies to: the configuration manager, asset custodians, change authority, release manager, service owners, resolver groups and any team that creates, changes or retires a configuration item.

5. Terms and definitions

6. Roles and Responsibilities

7. Configuration and Asset Management Process

7.1 Inputs and outputs

7.2 Process flow

1. Service design or procurement identifies a new component and raises a request to create a CI.
2. The CI owner identifies the CI using the naming rule and category, and records its attributes and relationships.
3. The configuration manager checks the record, sets the status to planned and links the approving change.
4. On release the CI status changes to active and the baseline is taken.
5. Every later change updates the CI record, keeping the history of values.
6. Automatic discovery and manual reconciliation compare the CMDB with reality and raise differences.
7. Differences are investigated, corrected or raised as incidents or unauthorised changes.
8. Audits report accuracy to the process owner and management review.
9. When a component is withdrawn, the CI is retired, the asset is disposed of and the records are closed.

7.3 CI categories

The CI model uses the categories below. A new category needs the approval of the process owner so that records stay comparable.

7.4 Establishing configuration items

A CI is established when a new component is designed, bought or discovered. The rule for what to record is practical: an item becomes a CI if its failure or change could affect a service, if it needs a version or a licence to be tracked, or if an engineer would need to know about it during an incident or change.

1. RequestThe service owner, project or procurement raises a CI creation request through the ticketing tool, naming the service and the approving change or purchase. Owner: requester. Target: before the component is built or connected.
2. IdentifyThe CI owner gives the item a unique identifier using the rule [category code, location code, sequence number], and chooses the category. Owner: CI owner.
3. Record attributesMandatory attributes are entered: owner, custodian, status, location, version, supplier, support dates, classification and link to the service. Target: [2 working days].
4. Record relationshipsAt least the service it supports, the item it runs on, the items it connects to and the supplier or document it depends on are linked.
5. VerifyThe configuration manager checks completeness and uniqueness and sets the status to planned. Target: [1 working day].
6. ActivateWhen the release record is closed the status becomes active, and the date and approving change are stored.

7.5 Maintaining the CMDB

The CMDB is kept current by three routes working together: automatic feeds from authorised sources, updates driven by change records, and manual reconciliation. A record may be changed directly only by its CI owner or the configuration manager, and every change to a record stores the previous value, the date and the person or feed that made it.

1. Change-driven updateEach change record lists the CIs affected. When the change is implemented the CI owner updates attributes and relationships and attaches evidence. The change authority does not close the change until this is done. Target: [2 working days] after implementation.
2. Automated feedsDiscovery and cloud inventory feeds run at least [daily] for servers and [weekly] for other classes. Feed results are compared with the CMDB and differences are placed in a review queue.
3. Review queueThe configuration manager reviews the queue [every working day]. A difference is resolved as record error (corrected), approved change not recorded (record updated), or unapproved change (raised as an incident and a security event if needed). Target: [5 working days].
4. Incident and problem feedbackA resolver who finds a wrong record raises a record correction in the ticketing tool. The CI owner corrects it within [2 working days].
5. Duplicates and orphansEach month the configuration manager lists duplicate records and CIs with no relationship and resolves each with the owner.
6. Retention of historyRetired CI records stay in the CMDB for [3 years] after retirement, then are archived according to the Documents and Records Management Procedure.

7.6 Configuration baselines

1. SelectThe release manager and the service owner decide which CIs form the baseline: for example the full build of an application, its configuration files and the documents describing it.
2. CaptureThe baseline is captured before every release of a tier 1 service and after each major change to tier 2 services: the CI versions, configuration files, infrastructure definitions and settings. Owner: release manager.
3. ApproveThe service owner approves the baseline as correct. It is given a name and version and stored read-only in the definitive repository.
4. UseA change compares its proposed state with the baseline; a failed change is backed out to the baseline.
5. RetainThe last [5] baselines and every baseline of a production release in the last [12 months] are kept.

7.7 Integrity of the CMDB

• Access to the CMDB is by role. Read access is available to all support staff; write access is limited to CI owners for their own records and to the configuration manager.
• Authorised sources are listed and approved by the configuration manager. A feed that is not listed cannot write to the CMDB.
• Every write is logged with person or feed, time and old value. The log is reviewed monthly for unusual patterns.
• The CMDB is backed up under the Backup Management and Retention Procedure, with a restore test at least every [6 months].
• The definitive repository of software and licences is held separately from production and is writable only through the release process.
• Where the CMDB holds security-sensitive details (for example network layout), the classification of the whole record set is set to the highest classification of its content.

7.8 Status accounting

Each CI has a life cycle status, and status changes follow the rules below. The configuration manager reports the number of CIs in each status, by category, each month, and investigates anything that has been in a transitional status for longer than [30 days].

7.9 CMDB verification and audit

Accuracy is checked in two ways: continuous reconciliation, described above, and periodic audit by the configuration manager or an independent reviewer. Audits are planned in the annual audit programme and also happen after a major incident caused by wrong records, before a major release and before a significant change.

1. PlanDefine the sample: [10%] of records, with every tier 1 service fully covered at least once a year. Owner: configuration manager.
2. CompareCheck the record against the real item, physically or through its management interface: existence, version, location, owner and relationships.
3. Record findingsEach difference is classed as missing, extra, wrong value or wrong relationship, with the item, evidence and owner.
4. CorrectCI owners correct records within [5 working days]. Items with no authority are investigated as possible unauthorised changes.
5. ReportThe accuracy percentage, causes and actions go to the process owner within [10 working days] of audit end and to management review.

A record counts as accurate only if every mandatory attribute and relationship matches the real item. Accuracy below [95%] for any category opens a corrective action.

8. Asset Register and Asset Lifecycle

8.1 Asset register

The asset register records every asset above the value threshold and all licensed software. Where an asset is also a CI the two records are linked by the identifier. The asset register adds acquisition, cost, warranty, licence and financial data that the CMDB does not need. The detailed information security view of assets is in the Asset Management Procedure.

8.2 Software licences

• The configuration manager compares licences used with licences owned [quarterly] and reports any shortfall or surplus to finance.
• Software is installed only from the definitive repository or an approved source.
• An unlicensed installation found by discovery is removed or licensed within [10 working days].

9. Interfaces with other processes

10. Key Performance Indicators

11. Records and evidence

Annexure A: Configuration item record

Annexure B: Asset register template

Annexure C: CMDB audit record

Annexure: Document history

12. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

13. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

14. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Change Management Procedure
• Release and Deployment Management Procedure
• Asset Management Procedure
• IT Asset Management Policy
• Asset Disposal Process
• Secure Configuration Policy
• Service Catalogue Management Procedure
• Service Incident Management Procedure