Configuration management

Configuration management is an audit-grade way to answer a simple question: “What do we run, what depends on what, and who approved the last change?” ISO/IEC 20000-1:2018 Clause 8.2.6 turns that question into a requirement: you must define and control the configuration items required to deliver services, and maintain a configuration management system that contains accurate configuration information, with records available as documented information (ISO/IEC 20000-1:2018 Information technology — Service management).

For a CCO, GRC lead, or service management owner, the fastest route to compliance is to treat this as a data governance and change control problem, not a tooling project. Tools help, but auditors will test whether (1) your CI scope is deliberate, (2) records match reality, (3) changes are controlled, and (4) you can produce evidence quickly.

This page gives requirement-level implementation guidance: what to include in scope, how to structure ownership and workflows, what artifacts to retain, and where teams typically fail (for example, keeping a CMDB that looks complete but cannot be reconciled to production).

Regulatory text

Requirement (verbatim): “The organization shall define and control the configuration items needed to deliver services and maintain a configuration management system containing accurate configuration information. Configuration records shall be available as documented information.” (ISO/IEC 20000-1:2018 Information technology — Service management)

Operator interpretation (what the auditor expects you to be able to show):

1. You decided what CIs matter for delivering and supporting your services (not a random inventory dump).
2. You control those CIs through governed processes (typically change management, access control, and standard builds).
3. You run a configuration management system (a CMDB or equivalent) that holds configuration information and relationships.
4. Your configuration information is accurate in a testable way (reconciliation, review, and correction mechanisms).
5. Records are “documented information”: retained, versioned where applicable, and retrievable on demand.

Plain-English requirement: what it means in practice

You need a reliable, maintained “source of truth” for the service components that matter, plus a disciplined way to keep that truth aligned with reality. That includes:

• What exists (assets/components that enable service delivery).
• How it is configured (key attributes that affect security, availability, and supportability).
• How it connects (dependencies and relationships that drive incident impact and change risk).
• How it changes (traceability from change requests to CI updates).
• How you prove it (documented records and repeatable checks).

Who it applies to

Entities: Any organization delivering services in scope for ISO/IEC 20000-1 certification or alignment (ISO/IEC 20000-1:2018 Information technology — Service management).

Operational contexts where configuration management is examined hardest:

• Customer-facing production services (SaaS, managed services, internal IT shared services).
• Hybrid environments (on-prem + cloud + third-party platforms).
• High-change environments (CI/CD, infrastructure-as-code).
• Outsourced components (critical third parties hosting, operating, or supporting key service components).

Typical owners: Service Management Office, IT Operations, SRE, Platform/Cloud Ops, Security Engineering, and an accountable service owner per service.

What you actually need to do (step-by-step)

1) Define CI scope and CI classes

Start by writing a CI Scope Statement that answers:

• Which services are in scope for ISO/IEC 20000-1?
• For each service, which CI types are mandatory to track?

A practical minimum CI class set usually includes:

• Service (the business-facing service definition)
• Applications (customer-facing apps, internal apps supporting delivery)
• Infrastructure (compute, containers, clusters, network components)
• Data stores (databases, queues, object storage)
• Identity & access components (IdP tenants, key vaults, privileged roles)
• Monitoring/alerting (where absence breaks supportability)
• Third-party dependencies (where failure breaks service delivery)

Document in-scope CI inclusion rules (example: “Any component whose outage causes customer impact, or any component requiring controlled change, is a CI.”). The standard requires you to define CIs needed to deliver services, so avoid tracking items that create noise but do not improve control (ISO/IEC 20000-1:2018 Information technology — Service management).

2) Set required CI attributes and relationship model

Define the minimum attributes per CI class that make the record useful and auditable. Examples:

• Unique ID, name, environment, owner, support group
• Location/tenant/subscription/account
• Criticality tier, data classification impact (if you already have those concepts)
• Approved baseline configuration reference (standard image, template, IaC repo)
• Lifecycle state (planned, active, retired)
• Linked change records and incident/problem records (where relevant)

Define relationship types you will maintain, such as “Service depends on Application,” “Application runs on Cluster,” “Cluster uses Network Segment,” “Service uses Third Party.”

3) Assign ownership and accountability (RACI that works)

Audits fail when nobody owns data quality. Set:

• CI Owner (accountable for accuracy and timely updates)
• CI Custodian (operational team maintaining the CI)
• Configuration Manager (process owner for configuration management)
• Approvers (often via change management)

Make ownership explicit in the CMS and in documented roles/responsibilities. The goal is control, not just documentation (ISO/IEC 20000-1:2018 Information technology — Service management).

4) Establish control points: baseline, change, and access

Implement three control mechanisms:

A. Baseline control

• Define standard builds (gold images, templates, hardened configs, IaC modules).
• Record the baseline reference in CI attributes (for traceability).

B. Change integration

• Require that approved changes which modify a CI also update:
  • CI attributes (version, configuration details, lifecycle state)
  • CI relationships (new dependencies, removed components)
• Add a “CI update required?” field in change records, with closure criteria: “CI record updated and validated.”

C. Access control

• Restrict who can create/edit CI records.
• Separate requesters from approvers for high-risk CI classes.
• Log changes to CI records (who changed what, when).

5) Keep configuration information accurate: reconciliation and review

“Accurate” must be operationalized. Do two things:

A. Reconcile against reality

• Compare CMS data to authoritative sources (cloud inventory, endpoint management, IaC state, directory services, service catalogs).
• Track exceptions, assign remediation, and close the loop.

B. Run periodic quality reviews

• Completeness checks (missing owner, missing relationships).
• Correctness checks (wrong environment tags, retired systems still active).
• Relationship sanity checks (service dependencies updated after releases).

Document your reconciliation method and outcomes as documented information (ISO/IEC 20000-1:2018 Information technology — Service management).

6) Ensure records are “documented information” and retrievable

Define retention and retrieval rules for:

• CI records and relationship maps
• CI record change history/audit logs
• Reconciliation reports and remediation tickets
• Configuration management procedure, scope statement, and attribute standards

Auditors will ask you to produce configuration records quickly, and to show that they are controlled documents/records, not ad hoc spreadsheets that change without traceability (ISO/IEC 20000-1:2018 Information technology — Service management).

Required evidence and artifacts to retain

Keep these in a controlled repository (or within the CMS with export capability):

1. Configuration Management Policy/Procedure describing CI definition, control approach, and CMS operation (ISO/IEC 20000-1:2018 Information technology — Service management).
2. CI Scope Statement mapping services to CI classes and inclusion criteria.
3. CI Data Standard (required attributes by CI class; relationship types).
4. Roles and responsibilities (RACI, named process owner).
5. CMS extracts/screenshots showing CI records, relationships, and ownership.
6. Change records showing CI impact assessment and CI record updates tied to approved changes.
7. Reconciliation reports and exception/remediation tracking.
8. Audit logs for CI record modifications (or system logs that evidence control).
9. Sampling pack: for a small set of critical services, provide end-to-end traceability (service → CIs → recent change → CI updated → validation evidence).

Common exam/audit questions and hangups

Auditors and ISO assessors typically probe for these failure modes:

• “Show me how you define a CI.” They want a documented rule and consistent application across services.
• “Prove your CMDB/CMS is accurate.” Expect sampling. They will pick a CI and ask you to validate key attributes against reality.
• “How do changes update CI records?” They want workflow evidence, not a statement of intent.
• “Can you produce configuration records as documented information?” They will test retrievability and version/record control.
• “What about third-party components?” If a third party is a material dependency, you should represent it and its interfaces/SLAs in the configuration model for impact analysis and support.

Frequent implementation mistakes (and how to avoid them)

1. Tracking everything, controlling nothing.
   Fix: define CI inclusion rules tied to service delivery and control objectives.

2. CMDB populated once, then ignored.
   Fix: make CI update a closure criterion in change management and run reconciliation.

3. No ownership for CI accuracy.
   Fix: assign CI owners and measure data quality exceptions to closure.

4. Relationships missing or stale.
   Fix: require relationship updates for changes that add/remove dependencies; review critical service maps.

5. Spreadsheet “CMDB” without control.
   Fix: if you start with a spreadsheet, enforce versioning, access control, and change logging, then migrate to a CMS that supports auditability as you mature.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement. Practically, the risk shows up as operational and assurance failures: slower incident restoration because dependencies are unclear, higher change failure rates because impact analysis is weak, and failed audits because configuration records are incomplete or cannot be validated against production (ISO/IEC 20000-1:2018 Information technology — Service management).

A practical 30/60/90-day execution plan

First 30 days (stand up the minimum compliant system)

• Publish CI scope statement for in-scope services and define CI classes.
• Establish CI attribute standards and relationship model for the top critical services.
• Assign process owner and CI ownership model (RACI).
• Stand up the CMS/CMDB structure (or controlled interim repository) and seed initial records for critical services.
• Update change management to include CI impact and CI update closure criteria.

By 60 days (prove accuracy and control)

• Implement reconciliation against at least one authoritative source per CI class.
• Run a data quality review and remediate exceptions.
• Produce an audit-ready “sampling pack” for critical services: CI record, relationship map, last change evidence, and validation.
• Restrict CI edit permissions and enable logging/audit trails for record updates.

By 90 days (scale and make it durable)

• Expand CI coverage to remaining in-scope services based on your CI inclusion rules.
• Mature relationship mapping for services with complex dependencies and third-party components.
• Operationalize recurring reviews (data quality, stale CIs, retired components).
• Build reporting for CI completeness/accuracy exceptions to management review.

Where Daydream fits (practitioner view)

If your bottleneck is evidence assembly and continuous readiness, Daydream can help by centralizing configuration management evidence (policies, CI standards, reconciliation outputs, change samples) and packaging auditor-ready exports without chasing screenshots across tools. Treat it as your compliance system of record while the CMS/CMDB remains the operational system of record.

Frequently Asked Questions

Do we need a CMDB to meet the configuration management requirement?

You need a configuration management system that maintains accurate configuration information and produces configuration records as documented information (ISO/IEC 20000-1:2018 Information technology — Service management). A CMDB is the common implementation, but the key test is control, accuracy, and retrievability.

What counts as a “configuration item” for ISO/IEC 20000-1?

A CI is any component you decide is needed to deliver or support an in-scope service and therefore must be controlled (ISO/IEC 20000-1:2018 Information technology — Service management). Define CI inclusion rules and apply them consistently.

How do we prove configuration information is accurate?

Use reconciliation against authoritative sources and retain the results as documented information (ISO/IEC 20000-1:2018 Information technology — Service management). Auditors typically validate by sampling CIs and comparing records to real environments.

How should configuration management connect to change management?

Changes that affect CIs should require CI record updates as part of change closure, with traceability from the change record to the updated CI record (ISO/IEC 20000-1:2018 Information technology — Service management). This is a primary control point for “define and control.”

What about third-party services (cloud providers, SaaS platforms) we depend on?

If the third party is required to deliver your service, represent that dependency in your configuration model and keep current information needed for support and impact analysis (ISO/IEC 20000-1:2018 Information technology — Service management). You do not control the third party’s internal configuration, but you do control your records and interfaces.

We use infrastructure-as-code. Do we still need configuration records?

Yes. IaC can be your baseline reference and an authoritative source, but you still need configuration records available as documented information and a way to demonstrate accuracy (ISO/IEC 20000-1:2018 Information technology — Service management). Many teams store CI attributes and relationships derived from IaC state plus runtime reconciliation.