Skip to main content
 

Part 2. Information Technology

Chapter 150. Configuration and Change Management

Section 2. Configuration Management (CM) Process

2.150.2 Configuration Management (CM) Process

Manual Transmittal

May 18, 2026

Purpose

(1) This transmits revised IRM 2.150.2 Configuration Management (CM) Process.

Material Changes

(1) IRM 2.150.2.1 Program Scope and Objectives. Revised to modernize and streamline program governance content, aligning Configuration Management to IEEE 828, ITIL 4 Service Configuration Management, ISO/IEC 20000 standards, and enterprise CSDM implementation.

(2) IRM 2.150.2.1.1 Background. Revised to streamline legacy narrative content and modernize the definition of Configuration Management, aligning it to Software Configuration Management and ITIL 4 Service Configuration Management while removing outdated ITSM framework language and secure configuration overlap.

(3) IRM 2.150.2.1.2 Authority. Updated to explicitly align the process with IEEE 828-2012, ITIL® 4 Service Configuration Management, and ISO/IEC 20000-1 and 20000-2 standards, clarify implementation under the IRS Change Management process, and formally establish interim CMDB governance authority pending issuance of a separate CMDB Policy.

(4) IRM 2.150.2.1.3 Roles and Responsibilities. Restructured to define clear enterprise governance roles, including CM Process Owner, CM Process Manager, CMDB Platform Owner, Service Configuration Management Authority, and System Owner, replacing legacy CCB-centric role descriptions with lifecycle-aligned governance accountability.

(5) IRM 2.150.2.1.4 Program Management and Review. Revised to strengthen enterprise oversight responsibilities, define governance review expectations, reinforce alignment to IRM 2.150.1 and related processes, and formalize continuous process improvement and standards conformance monitoring.

(6) IRM 2.150.2.1.5 Program Controls. Updated to define enforceable compliance controls across planning, identification, control, status accounting, audit, and cloud governance domains, including verification of CMDB structure, naming conformance, and CSDM-aligned hierarchy integrity. Comprehensively revised to remove legacy terminology, align definitions to IEEE 828, ITIL 4, and CSDM constructs, add cloud-native and lifecycle governance terminology (e.g., CII, CMP DID, OneSDLC, TMS), and eliminate obsolete or unused acronyms.

(7) IRM 2.150.2.1.6 Terms and Acronyms. Comprehensively updated to remove obsolete and unused terminology, incorporate CSDM-aligned service definitions, introduce cloud-native and lifecycle governance terminology, and standardize definitions consistent with IEEE 828 and ITIL 4.

(8) IRM 2.150.2.1.7 Related Resources. Updated to reflect current authoritative IRM cross-references, incorporate ISO/IEC 20000 standards and CSDM framework alignment, and remove outdated ITIL v3 and legacy framework references.

(9) IRM 2.150.2.2 Configuration Management Process. Reorganized from a legacy process-flow structure into a lifecycle-governed framework aligned to IEEE 828 configuration management functions and ITIL 4 Service Configuration Management practices, incorporating CSDM service modeling and cloud governance controls. Introduced clear separation of core CM functions and supporting activities.

(10) IRM 2.150.2.2.1 Configuration Management Planning. Revised to formalize CM Plan requirements aligned to IEEE 828 and ITIL 4, strengthening governance structure, baseline strategy definition, repository designation, and integration with Change Management and cloud boundaries.

(11) IRM 2.150.2.2.2 Configuration Identification. Comprehensively updated to institutionalize structured Configuration Identification through a defined CII framework, standardized CI categorization, CSDM-aligned service modeling hierarchy, formalized CI structure, naming standards, relationship modeling, pre-registration validation, baseline mapping, and cloud configuration identification requirements.

(12) IRM 2.150.2.2.3 Configuration Control. Restructured into a lifecycle-based configuration governance model defining formal change initiation, evaluation, approval, implementation, verification, baseline management, repository control, version control, and continuous compliance validation consistent with IEEE 828 and ITIL 4 practices..

(13) IRM 2.150.2.2.4 Configuration Status Accounting. Updated to establish the CMDB as the authoritative enterprise configuration status record, including defined data quality controls, lifecycle state visibility, relationship integrity, reconciliation practices, and alignment with CSDM standards.

(14) IRM 2.150.2.2.5 Configuration Audit. Enhanced to define formal audit requirements, including Functional Configuration Audit (FCA), Physical Configuration Audit (PCA), cloud compliance review, and integration with automated DevOps validation to ensure baseline integrity and configuration accuracy.

(15) IRM 2.150.2.2.6 Configuration Management in Cloud and Managed Service Environments. Expanded to incorporate cloud-native configuration governance requirements, including Infrastructure as Code (IaC), immutable infrastructure principles, drift detection, shared responsibility boundaries, and automated pipeline traceability controls integrated with Configuration Control and Status Accounting.

(16) IRM 2.150.2.2.7 Measurement and Continuous Improvement. Added structured performance measurement criteria to support governance oversight and continual improvement through defined CM process metrics and compliance indicators.

(17) IRM 2.150.2.2.8 Integration with OneSDLC. Added lifecycle integration requirements to ensure Configuration Management is initiated early, maintained through development, testing, production, sustainment, and retirement, and aligned to readiness decision points within the One Solution Delivery Lifecycle (OneSDLC).

Effect on Other Documents

IRM 2.150.2 dated April 18, 2025 is superseded.

Audience

The Configuration Management Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for configuration, management, oversight, and successful day-to-day operations of the IRS IT enterprise hardware, software, and applicable documentation.

Effective Date

(05-18-2026)


Kaschit Pandya
Chief Information Officer

2.150.2.1 (04-18-2025)

Program Scope and Objectives

  1. Purpose. This section defines the Configuration Management (CM) Process, including the lifecycle activities, controls, and procedures used to manage configuration items (CIs), baselines, and configuration data across the system lifecycle.

  2. The Configuration Management process establishes standardized procedures to:

    • Identify, classify, and structure CIs using defined naming, modeling, and categorization standards.

    • Establish, baseline, and maintain approved configuration states aligned with lifecycle decision points.

    • Control configuration changes through integration with the enterprise Change Management process.

    • Record, maintain, and reconcile configuration status information within authoritative repositories, including the CMDB.

    • Verify configuration integrity through audit, reconciliation, and validation activities.

    • Monitor configuration states to detect unauthorized changes and deviations from approved baselines.

    This process applies to software-based systems and supporting services across on-premises, hybrid, cloud, and managed service environments and is executed throughout all lifecycle phases.

    Secure configuration requirements are governed separately under IRM 10.8.1 and are implemented in coordination with this process.

  3. Audience. This process is performed by personnel responsible for executing configuration management activities, including System Owners, Configuration Managers, development and engineering teams, DevSecOps and release personnel, CMDB administrators, and operations staff. Participants perform roles defined within this process to ensure configuration integrity, traceability, and alignment with approved baselines.

  4. Policy Owner. Strategy & Product Management (S&PM) - IT.

  5. Program Owner. Infrastructure Tech Ops (ITO) Product Management within S&PM - IT.

  6. Primary Stakeholders. Primary stakeholders in this process include IT organizations and personnel that participate in the execution of configuration management activities, including those responsible for managing CIs, controlling changes, maintaining configuration data, and supporting system and service operations within defined system boundaries.

  7. Contact Information. To recommend changes or to make any suggestions to this IRM section, email the CM Program Management Office (PMO): it.cm.process@irs.gov

2.150.2.1.1 (08-19-2020)

Background

  1. Configuration Management is performed through a defined set of lifecycle activities that establish and maintain the integrity, traceability, and reproducibility of software CIs and service configuration data. These activities ensure that CIs are identified, controlled, and maintained in alignment with approved baselines throughout the system lifecycle.

  2. The Configuration Management process integrates with change management, release and deployment, and operations activities to ensure that configuration changes are controlled, configuration records are accurately maintained, and system states remain consistent with approved baselines. This supports reliable service operations, enables effective incident resolution, and ensures configuration information is available for audit, impact analysis, and lifecycle decision-making.

2.150.2.1.2 (08-19-2020)

Authority

  1. This process operates in alignment with the following Internal Revenue Manuals (IRMs), which define governing policy, security requirements, and related processes that integrate with Configuration Management activities:

    • IRM 2.150.1 Configuration Management Policy

    • IRM 2.125.1 Change Management Policy

    • IRM 2.125.2 Change Management Process

    • IRM 2.31.1 One Solution Delivery Lifecycle Guidance

    • IRM 10.8.1 Security Policy

  2. All IT organizations managing software CIs or service configuration records implement this process when performing configuration management activities.

  3. The ServiceNow CSDM is used as the enterprise framework for structuring CIs, service relationships, and configuration data within the CMDB. Configuration Management activities integrate with Change Management processes defined in IRM 2.125.1 and IRM 2.125.2 to ensure configuration changes are authorized, implemented, and traceable.

  4. Until a formal CMDB Policy is established and approved, the CMDB structural standards, naming conventions, relationship constraints, and data governance requirements defined in this process are used as the enterprise standard for managing configuration data. Upon issuance of a CMDB Policy, CMDB structural and data governance standards will be governed by that policy, while this process continues to define configuration management lifecycle activities.

2.150.2.1.3 (04-18-2025)

Roles and Responsibilities

  1. Configuration Management activities are performed through defined roles that execute lifecycle tasks related to configuration planning, identification, control, status accounting, and verification. These roles operate in coordination to ensure CIs, baselines, and configuration data are managed consistently across systems and environments.

    1. Role Responsibilities
      Configuration Management (CM) Process Owner Defines and maintains the Configuration Management process and associated procedures. Ensures the process is updated to reflect operational practices, integrates with related lifecycle processes, and provides guidance for implementation across systems and environments.
      Configuration Management (CM) Process Manager Executes and manages day-to-day Configuration Management activities. Coordinates configuration activities across teams, monitors process execution, supports reporting and audits, and ensures configuration controls are applied consistently.
      Configuration Management Database (CMDB) Platform Owner Maintains and administers the CMDB platform to support configuration status accounting and service modeling. Ensures configuration data is stored, structured, and maintained in accordance with defined standards, and supports system integrations and data quality activities.
      Configuration Manager Develops and maintains the Configuration Management Plan (CMP). Performs configuration identification, baseline management, status accounting, and audit coordination. Ensures configuration records are complete, accurate, and aligned with approved baselines.
      Development and Engineering Teams Create and maintain CIs, including source code and configuration artifacts, within approved version control systems. Ensure build reproducibility, apply versioning practices, and maintain traceability of changes to approved change records.
      Operations Personnel Maintain configuration integrity in operational environments. Monitor for unauthorized or unintended changes, perform reconciliation activities, and ensure runtime configurations remain aligned with approved baselines.
      Release and Deployment Management Deploy approved and version-controlled CIs to target environments. Maintain release traceability and verify that deployed configurations match approved baselines.
      Service Configuration Management Function Supports the implementation of service modeling, CI classification, and relationship management within the CMDB. Ensures service structures and relationships are applied consistently to support impact analysis and service visibility.
      System Owner Ensures Configuration Management activities are performed within the system boundary. Maintains system configuration artifacts, ensures alignment with approved baselines, and supports traceability of changes within designated repositories.

      Contractors and vendors performing Configuration Management activities execute process responsibilities in accordance with their assigned roles.

2.150.2.1.4 (08-19-2020)

Program Management and Review

  1. Configuration Management activities are performed and periodically evaluated to ensure the process is effectively executed, configuration data remains accurate, and configuration controls are consistently applied across systems and environments.

    1. Process Management. Configuration Management process activities include maintaining process procedures, supporting documentation, and implementation guidance to reflect current operational practices. Process documentation, templates, and supporting materials are updated as needed to support execution of configuration management activities throughout the lifecycle.

    2. Monitoring and Review. Configuration Management activities are monitored to verify that CIs, baselines, and configuration records are established, maintained, and updated in accordance with defined process requirements. Monitoring activities include:

      • Reviewing Configuration Management Plans (CMPs) for completeness and accuracy.

      • Validating configuration baseline integrity.

      • Performing CMDB reconciliation and data quality checks.

      • Verifying traceability between approved changes and CIs and baselines.

      • Identifying and documenting discrepancies in configuration records or processes.

      Identified issues are documented and addressed through corrective actions to ensure configuration data and baselines remain accurate and aligned with approved system states.

    3. Process Improvement and Update. Configuration Management process activities are periodically reviewed to identify opportunities for improvement and to ensure continued effectiveness and integration with related processes. Updates to procedures, documentation, and supporting materials are made to reflect changes in operational practices, system environments, or integration points with other lifecycle processes. Revisions to this IRM section are performed in accordance with established IRM update procedures.

2.150.2.1.5 (08-19-2020)

Program Controls

  1. Configuration Management controls are applied to ensure that configuration management activities defined in IRM 2.150.2.2 are performed consistently across systems and environments.

  2. Systems performing Configuration Management activities implement process requirements for configuration planning, identification, control, status accounting, audit, and cloud-related configuration management, where applicable.

  3. Process execution is validated through routine verification activities, including:

    • Reviewing CMPs for completeness and alignment with system scope

    • Validating that CIs and baselines are maintained within authorized configuration repositories

    • Performing CMDB reconciliation and data quality checks to ensure configuration records are accurate and complete

    • Verifying traceability between approved changes, CIs, and associated baselines

    • Conducting configuration audits and tracking identified discrepancies

    • Validating that CI structure, classification, naming conventions, and relationships are applied consistently in accordance with defined modeling standards

  4. When discrepancies or deviations are identified, corrective actions are documented, tracked, and resolved to ensure CIs, baselines, and configuration records remain accurate and aligned with approved system states. Where necessary, implementation activities may be delayed until configuration discrepancies are addressed.

2.150.2.1.6 (05-18-2026)

Terms/Definitions/Acronyms

  1. The tables in the Terms and Definitions and Acronyms sections define terms and acronyms used in this IRM.

2.150.2.1.6.1 (05-18-2026)
Terms and Acronyms

  1. The following terms and definitions are used in this IRM.

    Term Definition
    Baseline An approved and formally established version of a CI or set of CIs that serves as a reference point for change control and verification.
    Build Artifact A compiled or packaged output generated from source code and configuration files that is ready for deployment.
    Common Service Data Model (CSDM) A standardized framework for defining and relating services and CIs within a CMDB. CSDM provides structured guidance for modeling Business Services, Application Services, and Technology Management Services and their relationships to ensure consistent service mapping, dependency visibility, and data integrity.
    Configuration Audit Activities performed to verify that CIs conform to approved baselines and associated documentation.
    Configuration Identification Index (CII) A structured artifact used to define CI categories, naming conventions, lifecycle states, baseline groupings, and relationship models for a system.
    Configuration Item (CI) Any software component, artifact, service element, or infrastructure element placed under configuration control and necessary to deliver or support an IT service.
    Configuration Management (CM) A set of lifecycle activities performed to identify, control, record, and verify CIs and baselines.
    Configuration Management Database (CMDB) The system used to store, manage, and maintain CI records and relationships supporting configuration management activities.
    Configuration Management Plan (CMP) A document used to define how configuration management activities are performed for a system or service.
    Configuration Management Plan Data Item Description (CMP DID) The formal documentation structure defining required content and organization of a Configuration Management Plan.
    Configuration Status Accounting Activities performed to record, maintain, and report CI status information, including version history and change activity.
    Configuration Verification Activities performed to confirm that CIs and baselines align with approved configurations.
    Drift An unapproved deviation of a CI from its defined baseline.
    Infrastructure as Code (IaC) The management of infrastructure configurations using version-controlled, machine-readable definition files.
    Model A representation of CIs and their relationships used to support dependency mapping, impact analysis, and service structure within the CMDB or CMS.
    Service A means of delivering value to customers by facilitating desired outcomes without the customer having to manage specific costs and risks. In the context of Configuration Management, a service is supported by one or more CIs and may be classified as a Business Service, Application Service, or Technology Management Service.
    Application Service A logical representation of an application or system capability that provides specific functionality and supports one or more business services. An application service may consist of multiple software components, modules, or CIs.
    Business Service An IT-enabled service that delivers business functionality or outcomes to internal or external stakeholders and is supported by one or more application and technology management services.
    Technology Management Service (TMS) A shared technical capability that supports Application Services, such as platform services, middleware, database services, network services, or cloud infrastructure services.
    As-Built-Architecture (ABA) The enterprise architectural standard used to define approved application and service naming and classification structures.
    One Solution Delivery Lifecycle (OneSDLC) The enterprise lifecycle framework governing system development, deployment, sustainment, and retirement activities.
2.150.2.1.6.2 (05-18-2026)
Acronyms

  1. The following acronyms are used in this IRM

    Acronym Definition
    CI Configuration Item
    CII Configuration Identification Index
    CM Configuration Management
    CMDB Configuration Management Database
    CMS Configuration Management System
    CSDM Common Service Data Model
    IaC Infrastructure as Code
    FCA Functional Configuration Audit
    PCA Physical Configuration Audit
    SCM Software Configuration Management
    TMS Technology Management Service
    ABA As-Built-Architecture
    OneSDLC One Solution Delivery Lifecycle (OneSDLC)
2.150.2.1.7 (08-19-2020)

Related Resources

  1. The following sources provide additional guidance and are related to the Configuration Management Process:

    • IRM 2.5.1 Systems Development

    • IRM 2.22.1 Unified Work Request (UWR) Process

    • IRM 2.127.1 IT Test Policy

    • IRM 2.127.2 IT Testing Process and Procedures

    • IRM 10.8.1.4.5 Configuration Management Policy and Procedures

    • IEEE-828 Standard for Software Configuration Management in Systems and Software Engineering

    • ITIL 4, Service Configuration Management Practice Guidance

    • ISO/IEC 20000-1:2018, Information Technology — Service Management — Service Management System Requirements (Clause 8.3 — Service Configuration Management)

    • ISO/IEC 20000-2, Information Technology — Service Management — Part 2: Guidance on the Application of Service Management Systems

    • ServiceNow Common Service Data Model (CSDM) Framework

2.150.2.1.8 (04-18-2025)

Training

  1. Configuration Management training ensures personnel understand their roles and responsibilities in performing Software Configuration Management and Service Configuration Management activities. Training resources are available through IRS Integrated Talent Management and Skillsoft Percipio platforms and include:

    • Configuration Management Overview (CBT) (Course 23279)

    • Change Management Process Overview (CBT) (Course 43161)

    • Software Configuration Management Handbook, Third Edition

    • LLPKG - Overview of the ITIL Service Lifecycle

    • ITIL® 4 Foundation: Introduction

    • ITIL® 4 Foundation: Service Management Practices (Part 1)

    • ITIL® 4 Foundation: Service Management Practices (Part 2)

    • ITIL® Service Desk, IT Asset, Service Configuration, and Change Control Management

    Personnel performing Configuration Management activities should complete applicable training consistent with their assigned role. Additional technical training related to Configuration Management is available through IRS Integrated Talent Management and Skillsoft by searching for “Configuration Management.”

2.150.2.2 (08-19-2020)

Configuration Management Process

  1. The Configuration Management Process defines the lifecycle execution of configuration management activities used to establish, control, maintain, and verify CIs, baselines, and configuration data across the system lifecycle.

  2. The process is executed through the following lifecycle activities:

    • Configuration Management Planning

    • Configuration Identification

    • Configuration Control

    • Configuration Status Accounting

    • Configuration Audit

  3. These core functions are supported by additional activities, including cloud and managed service configuration management, measurement and continuous improvement, and integration with OneSDLC.

  4. Each activity is performed in an integrated manner to maintain configuration integrity, traceability, and reproducibility across development, test, production, and sustainment environments.

  5. Configuration Management activities are operationally integrated with:

    • Change Management processes (IRM 2.125.2) for authorization, implementation, and traceability of changes.

    • Security controls and secure configuration baselines defined in IRM 10.8.1.

    • Service Configuration Management practices aligned to ITIL 4 and CSDM for service modeling and dependency management.

    • IEEE 828 configuration management functions for lifecycle consistency.

    • ISO/IEC 20000 service management requirements for configuration control and auditability.

  6. Continuous monitoring is performed to maintain alignment between actual configuration states and approved baselines. Monitoring activities include:

    • Detection of configuration drift and unauthorized changes.

    • Comparison of runtime and deployed configurations against approved baselines.

    • Initiation of analysis, reconciliation, and corrective action through Change Management and Incident processes.

  7. Configuration Management applies to software-based systems and supporting services across on-premises, hybrid, cloud-hosted, and managed service environments. It encompasses both Software Configuration Management and Service Configuration Management activities.

  8. Configuration Management focuses on lifecycle control and governance of CIs and baselines. Technical secure configuration standards and implementation requirements are defined separately in IRM 10.8.1 and are applied through configuration baselines, monitoring, and audit activities within this process.

  9. Configuration Management activities include continuous monitoring of configuration states to detect unauthorized changes, configuration drift, and deviations from approved baselines across all environments.

2.150.2.2.1 (08-19-2020)

Configuration Management Planning

  1. Configuration Management Planning defines how configuration management activities are implemented, governed, and integrated across the system lifecycle. Planning establishes the structure, scope, controls, and operational approach for managing CIs, baselines, and configuration data.

  2. Configuration Management Planning is initiated early in the OneSDLC and maintained throughout development, deployment, operations, and sustainment. Planning outputs are established prior to applicable lifecycle decision points and updated through approved change control as system scope, architecture, or operational conditions evolve.

  3. Each system shall develop and maintain a CMP that serves as the authoritative implementation artifact for configuration management activities. The CMP is maintained under configuration control and aligned with the Configuration Management Plan Data Item Description (CMP DID), ensuring consistency with IEEE 828 configuration management planning practices.

  4. The CMP serves as the authoritative implementation and governance artifact for Configuration Management, defining system context, organizational responsibilities, interfaces, tools, environments, and lifecycle configuration management activities.

  5. Configuration Management Planning includes the following activities:

    • Scope Definition. Define the system or service boundary, including in-scope CIs, environments, and supporting services. This includes identification of on-premises, cloud, hybrid, and provider-managed components within defined responsibility boundaries.

    • Governance and Roles. Establish roles, responsibilities, and authorities for performing configuration management activities, including configuration control authority, CMDB governance, and integration with Change Management approval structures.

    • Configuration Identification Framework. Define the Configuration Identification Index (CII), including CI categories, naming conventions, lifecycle states, baseline structures, and relationship modeling approach aligned with CSDM service modeling standards.

    • Baseline Strategy. Define baseline types, baseline composition, lifecycle alignment, and criteria for baseline establishment, modification, and protection. Baselines shall support lifecycle decision points, audit requirements, and traceability.

    • Configuration Management Interfaces and Dependencies. Define integration points between Configuration Management and related enterprise processes, including Change Management, Release and Deployment Management, Security Authorization and Continuous Monitoring, Incident and Problem Management, and Supplier or provider management processes.

    • Configuration Repositories and Tools. Designate the CMDB and approved system repositories as authoritative sources of record for configuration data and artifacts, and maintain traceability across changes, baselines, and deployed states to support audit and impact analysis.

    • Cloud and Provider-Managed Configuration Boundaries. Define configuration ownership, control boundaries, and shared responsibility for cloud and managed service environments. This includes identification of Infrastructure-as-Code (IaC) artifacts, provider-managed components, and enforcement of configuration control over cloud resources.

    • Environment Definition. Define logical environments where CIs are developed, tested, deployed, and operated, including on-premises, cloud, and hybrid environments, to support baseline management, change control, and auditability.

    • Configuration Control Integration. Define how configuration changes are initiated, evaluated, approved, implemented, and verified through integrated Change Management processes. This includes alignment with standard, normal, and emergency change types and enforcement of traceability.

    • Configuration Status Accounting and Reporting. Define how configuration data is recorded, maintained, reconciled, and reported. This includes identification of required data elements, reporting mechanisms, and integration with CMDB and system repositories.

    • Verification and Audit Approach. Define methods for verifying configuration integrity, including audit planning, reconciliation activities, and alignment with functional and physical configuration audit requirements.

  6. The CMP shall be reviewed for completeness and alignment with system scope, architecture, and lifecycle requirements prior to approval. Updates to the CMP shall be performed through approved configuration control to ensure continued accuracy and traceability.

2.150.2.2.2 (05-18-2026)

Configuration Identification

  1. Configuration Identification defines and maintains the set of activities required to uniquely identify, describe, and manage CIs and their relationships throughout the lifecycle. These activities are initiated during planning and performed throughout the lifecycle to support control, status accounting, and audit functions.

  2. The following activities are performed:

    • Identify and record CIs, including assigning unique identifiers and documenting relevant attributes to support traceability and management.

    • Classify CIs into appropriate categories and types to ensure consistent organization and alignment with service and system structures.

    • Define and maintain CI records within the approved repository to ensure accuracy, completeness, and alignment with enterprise data standards.

    • Establish and maintain relationships and dependencies among CIs to support impact analysis, change management, and service modeling.

    • Establish and manage configuration baselines at defined lifecycle points to provide reference states for control and audit purposes.

    • Align CIs with enterprise architecture, service models, and cloud environments, as applicable, to ensure consistency across platforms and implementations.

2.150.2.2.2.1 (05-18-2026)
Configuration Identification Index (CII)

  1. The CII defines and maintains the structure used to consistently identify and organize CIs and associated baselines throughout the lifecycle.

  2. The CII supports:

    • Consistent identification of CIs

    • Logical grouping of CIs into baselines

    • Representation of relationships to support impact analysis

    • Traceability across lifecycle artifacts

    • Auditability of CI records

  3. The CII provides a structural framework for CIs and their relationships and is maintained to reflect current lifecycle states. It does not serve as a detailed CI inventory.

  4. The CII is a structural artifact referenced by, but distinct from, the CMP and operational repositories such as the CMDB.

  5. The CII is defined and maintained in accordance with enterprise service modeling standards, including the application of service classification and naming conventions described in IRM 2.150.2.2.2.5, to support consistency across systems and services.

  6. The CII is defined using the CI Structure described in IRM 2.150.2.2.2.2 to ensure consistency in categorization and modeling.

  7. The CI structure defined by the CII is translated into the CMDB data model through the implementation of CI classes, attributes, and relationship types. The CMDB uses this structure to support configuration management activities and maintain CI data.

2.150.2.2.2.1.1 (05-18-2026)
CII Development and Maintenance Activities

  1. The following activities are performed to develop and maintain the CII:

    • Define the structure and content of the CII to align CIs with enterprise architecture and service models.

    • Document CIs within the CII, including identifiers, classifications, attributes, and relevant metadata to support traceability and management.

    • Maintain the CII to reflect current and accurate CI information as changes occur throughout the lifecycle.

    • Update CI records and associated relationships to support impact analysis, change management, and operational visibility.

    • Align CIs represented in the CII with approved baselines and configuration control processes.

    • Maintain traceability between CIs and related lifecycle artifacts, including requirements, design elements, and operational components.

2.150.2.2.2.2 (05-18-2026)
CI Structure

  1. CI structure defines and maintains the standardized organization, categorization, and relationships of CIs to support consistent identification, traceability, and lifecycle management across systems and services.

  2. The CI structure includes the following categories of CIs:

    • Infrastructure CIs, including physical and virtual compute, storage, and network components

    • Platform CIs, including operating systems, middleware, databases, and container platforms

    • Application CIs, including applications, modules, services, and microservices

    • Data CIs, including databases, data stores, schemas, and data assets

    • Integration CIs, including APIs, interfaces, messaging components, and middleware

    • Environment CIs, including development, test, staging, and production environments

    • Cloud CIs, including provider-managed services and resources aligned with shared responsibility models

    • DevOps and Automation CIs, including IaC, pipelines, scripts, and deployment configurations

  3. CI structure supports logical relationships across service layers, including:

    • Business Services

    • Application Services

    • Technology Management Services

    • Infrastructure CIs

  4. Relationships between CIs are defined and maintained to represent dependencies, associations, and service compositions. These relationships support impact analysis, change management, and operational understanding of how components interact within and across systems.

  5. CI structure is maintained to support consistency across lifecycle stages and traceability between CIs and related artifacts, including requirements, design components, and operational elements.

  6. Service relationship modeling is defined and maintained in the Service Relationship Modeling section (IRM 2.150.2.2.2.6) to provide consistent representation of service dependencies and interactions across the enterprise.

  7. The CI structure is implemented within the CMDB data model through CI classes, attributes, and relationship types, enabling the consistent representation and management of CIs across systems and services.

2.150.2.2.2.3 (05-18-2026)
CI Identification and Naming

  1. CI identification and naming define and maintain a consistent approach for uniquely identifying CIs and supporting traceability throughout the lifecycle.

  2. Each CI is assigned a unique identifier and a descriptive name that supports clarity, consistency, and alignment with enterprise architecture and service models.

  3. CI naming is applied consistently across CI types, including services, application components, infrastructure, and other configuration elements. Naming practices support clear differentiation without embedding variable attributes that are managed through configuration data.

  4. CI names are structured to:

    • Reflect the role or function of the CI

    • Align with associated service or system context, where applicable

    • Support traceability across lifecycle artifacts and relationships

    • Remain stable across releases and technology changes

  5. Variable attributes such as environment, version, or deployment-specific details are maintained as CI attributes, metadata, or lifecycle and version control mechanisms rather than embedded within the CI name.

  6. CIs are distinguishable across environments through the use of attributes, metadata, or relationships rather than naming variations.

  7. CI identification and naming are maintained to support consistency across lifecycle stages and configuration control, impact analysis, and auditability.

2.150.2.2.2.4 (05-18-2026)
Application Component Modeling

  1. Application component modeling (or application modeling) defines and maintains the structure and relationships of application services, application components, and supporting infrastructure to support consistent representation across systems and services.

  2. Application component modeling defines the internal composition of application services and is distinct from service modeling and service relationship modeling. Service modeling establishes the logical service hierarchy (Business, Application, and Technology Management Services), while service relationship modeling and CI relationship management define how services, components, and infrastructure are linked to support impact analysis and operational visibility.

  3. Application components are defined and organized to distinguish clearly between:

    • Application Services, representing business-facing or externally consumed capabilities

    • Application Components, representing internal functional elements that realize application services

    • Infrastructure CIs, representing the underlying platforms and resources that support application execution

  4. Application components are modeled to maintain clear separation from other service layers and to avoid misclassification across service types.

  5. Relationships between these elements are defined and maintained to reflect how application services are realized by application components and supported by Infrastructure CIs. These relationships support service visibility, impact analysis, and alignment with enterprise service models.

  6. Application components relate to:

    • Their parent Application Service using an “implements” or “realizes” relationship

    • Supporting Technology Management Services, where applicable

    • Hosting Infrastructure CIs

  7. Application component naming follows a consistent pattern to support clarity and traceability. A commonly used format combines an application service identifier with a component descriptor (for example, ApplicationServiceAcronym-ComponentDescriptor).

  8. The following examples illustrate typical application component representations:

    • IRWORKS-WEB

    • IRWORKS-API

    • TDANOTICES-BATCH

    • ACA4980H-REST

  9. Examples that may reduce clarity in modeling include:

    • IRWORKS-WEB-PROD (environment-specific naming embedded in the component)

    • IRWORKS-WEB-V2 (version-specific naming embedded in the component)

    • WebServer01 (infrastructure-oriented naming used for an application component)

  10. Application component modeling is maintained to support consistency across lifecycle stages and traceability across services, components, and supporting infrastructure.

  11. Service instances are not modeled as Application Components.

2.150.2.2.2.5 (05-18-2026)
Service Naming, Classification, and Instance Modeling

  1. Service naming, classification, and instance modeling define and maintain a consistent approach to representing services within the CMDB in alignment with enterprise architecture and service modeling practices, including As-Built Architecture (ABA), ServiceNow CSDM, and ITIL 4.

  2. Services are defined and organized to reflect business capabilities and supporting technical services while maintaining appropriate levels of abstraction. Service naming supports clear identification and alignment with business and system context without embedding technical implementation details.

  3. Service modeling distinguishes the following service types:

    • Business Services

    • Application Services

    • Technology Management Services

    • Service Instances

  4. Each service type represents a distinct layer within the service hierarchy and is modeled to support visibility, traceability, and relationship mapping across the enterprise.

  5. Service classification and relationships are defined and maintained to ensure clear separation between business-facing capabilities and supporting technical services. This structure supports impact analysis, change management, and alignment with enterprise service models.

  6. Service instances represent deployable or operational realizations of services and support differentiation across environments and deployments. Service instances are modeled separately from logical service definitions to preserve clarity between design and runtime representations.

  7. Detailed naming conventions, formatting rules, and examples are defined in enterprise standards and are not repeated within this section.

2.150.2.2.2.5.1 (05-18-2026)
Business Service

  1. Business Services represent business-facing capabilities or outcomes delivered to stakeholders.

  2. During interim service modeling, Business Services may align with approved ABA Business Application identifiers. Descriptive service information is maintained in service attributes or description fields to support clarity and context.

  3. Business Service naming is applied consistently to support:

    • Alignment with approved ABA Business Application identifiers during interim modeling

    • Clear identification of business-facing capabilities at an appropriate level of abstraction

    • Consistency across services without embedding variable attributes such as environment or version

  4. Variable attributes such as environment, version, or deployment-specific details are maintained through service attributes or metadata rather than embedded within the service name.

  5. As formal enterprise Business Service definitions are established, Business Services are updated to align with approved enterprise service designations in accordance with established governance processes.

  6. Examples that illustrate typical Business Service naming representations:

    • IMF

    • BMF

    • IRWORKS

  7. Examples that may reduce clarity in Business Service naming include:

    • IMF-PROD (environment-specific detail embedded in the service name)

    • BMF_v2 (version-specific detail embedded in the service name)

    • IRWORKS-DB (technical implementation detail embedded in the service name)

2.150.2.2.2.5.2 (05-18-2026)
Application Service

  1. Application Services represent logical runtime application capabilities that support Business Services.

  2. Application Service naming is applied to support clear identification, consistency, and alignment with enterprise architecture and service modeling practices, including ABA.

  3. Application Service names are structured to:

    • Reflect the associated application capability at an appropriate level of abstraction

    • Align with related Business Services and enterprise application context

    • Maintain consistency across services without embedding variable attributes such as environment, version, or infrastructure-specific identifiers

  4. Variable attributes such as environment, version, or deployment-specific details are maintained through service attributes or metadata rather than embedded within the service name.

  5. Naming conventions may follow established enterprise patterns, including the use of concise identifiers and standard character formats, as defined in applicable enterprise standards.

  6. The following examples illustrate typical Application Service naming representations:

    • IRWORKS

    • IRWORKS-MID

    • TDANOTICES

    • ACA-4980H

    • RPA-SBSE-ALP

  7. Examples that may reduce clarity in Application Service naming include:

    • IRWORKS-PROD (environment-specific detail embedded in the service name)

    • IRWORKS_MID (non-standard character usage)

    • IRWORKS.MID (non-standard character usage)

    • IRWORKS MID (space included in name)

    • IRWORKS-MID-V2 (version-specific detail embedded in the service name)

    • IRWORKS-MID-01 (instance-specific detail embedded in the service name)

    • IRWORKS-MID-SVCS (overly complex naming that reduces clarity and combines multiple descriptors)

  8. Application Services are distinguished from Service Instances, which represent environment-specific or deployment-specific realizations as defined in IRM 2.150.2.2.2.5.4.

2.150.2.2.2.5.3 (05-18-2026)
Technology Management Service

  1. Technology Management Services (TMS) represent shared technical capabilities that support one or more Application Services and provide underlying platform, infrastructure, or middleware functionality.

  2. Technology Management Services are defined and modeled in alignment with ServiceNow CSDM guidance and represent logical, shared service capabilities rather than physical implementations or environment-specific instances.

  3. A Technology Management Service may represent:

    • An enterprise-wide shared capability

    • A domain-scoped shared capability supporting multiple Application Services within a defined organizational or architectural boundary

  4. Enterprise Technology Management Services provide capabilities reusable across the enterprise, while domain-scoped Technology Management Services provide shared capabilities within a defined boundary such as a program, security boundary, data domain, or platform ecosystem.

  5. Technology Management Services are modeled to:

    • Represent shared logical capabilities

    • Support multiple Application Services

  6. Technology Management Services do not represent:

    • Single-application backend implementations

    • Specific infrastructure instances

    • Environment-specific deployments

    • Versioned platform releases

  7. Technology Management Service names reflect the logical capability. Implementation, environment, and instance details are maintained in supporting CIs and relationship records. Naming is applied and validated during service creation and update to maintain consistency with logical capability representation.

  8. Technology Management Services participate in the enterprise service hierarchy defined in IRM 2.150.2.2.2.6 and are related to Business Services through Application Service dependencies.

  9. Technology Management Services are categorized based on the type of technical capability they provide (e.g., compute, storage, network, identity, integration, platform, data, security) to support consistent service modeling and CMDB reporting.

  10. Configuration Management activities maintain relationships between Technology Management Services and supporting CIs, where CIs represent the underlying infrastructure, platform components, or runtime environments, enabling traceability between logical services and their underlying implementations.

  11. During CMDB maintenance and Change Management activities, Technology Management Service records are reviewed for naming consistency, appropriate classification, and completeness of relationships to supporting CIs and dependent Application Services. Identified discrepancies are corrected through Configuration Management data maintenance.

  12. The following examples illustrate enterprise Technology Management Service naming representations:

    • Enterprise Database Hosting Service

    • Enterprise API Gateway Service

    • Enterprise Identity and Access Management Service

    • Enterprise Container Orchestration Service

    • Enterprise File Transfer Service

    • Enterprise Data Integration Service

    • Enterprise Web Hosting Service

    • Enterprise Reporting Platform Service

    • Enterprise Search Service

  13. Examples that illustrate domain-scoped Technology Management Services include:

    • Document Management Platform Service (capability-scoped)

    • Digitalization Document Management Platform Service (program-scoped)

    • DEXP Document Management Platform Service (security boundary-scoped)

    • Case Data Document Management Platform Service (data domain-scoped)

    • Cloud Document Management Platform Service (platform ecosystem-scoped)

  14. Examples that may reduce clarity in Technology Management Service naming include:

    • API-Gateway-PROD (environment-specific detail embedded in the name)

    • IAM_v3 (version-specific detail embedded in the name)

    • WebHost-Cluster01 (infrastructure-specific reference)

    • ReportingService-DB (component-level detail included in the name)

    • Server123-Search (asset-based naming)

    • AppX-Database-Service (application-specific implementation rather than shared capability)

    • Oracle-Upgrade-v2 (activity or version-specific naming)

2.150.2.2.2.5.4 (05-18-2026)
Service Instance

  1. A Service Instance represents a deployment of an Application Service within a specific environment.

  2. Service instance modeling is distinct from logical service and application component modeling. It represents environment-specific deployments of services, while logical modeling defines service structure and relationships independent of environment.

  3. Service Instance naming is applied to support clear identification of environment-specific deployments while maintaining separation from logical Application Service definitions.

  4. Approved IRS primary environment identifiers include:

    • PROD

    • DEV

    • TEST

    • PRE-PROD

    • SBX

    • ASPE

  5. Service Instance names follow a consistent pattern that combines the Application Service name with an approved environment identifier.

  6. Service Instance naming typically follows the format: Application Service–Environment

  7. Service Instance naming extends the logical Application Service name in alignment with ABA naming standards. The ABA naming standard applies to the logical Application Service name, while environment identifiers appended for Service Instances represent deployment context and are applied in accordance with this section.

  8. Environment identifiers are applied to Service Instance records and are not embedded within the logical Application Service definition. Environment and deployment-specific details are maintained as attributes of the Service Instance.

  9. The following examples illustrate typical Service Instance naming representations:

    • IRWORKS-PROD

    • IRWORKS-MID-DEV

    • TDANOTICES-TEST

    • ACA-4980H-PRE-PROD

    • RPA-SBSE-ALP-SBX

    • MEF-ASPE

  10. Examples that may reduce clarity in Service Instance naming include:

    • IRWORKS-MIDPROD (missing separator between service and environment)

    • IRWORKS-MID_PROD (non-standard character usage)

    • IRWORKS-MID-V2-PROD (version-specific detail embedded in the name)

    • IRWORKS-MID-PRODUCTION (non-standard environment identifier)

    • IRWORKS-Prod (inconsistent environment identifier formatting)

    • IRWORKS-PROD-MID (environment identifier not applied in the expected position)

    • IRWORKS-MID-STAGE (environment identifier not included in the approved set)

2.150.2.2.2.6 (05-18-2026)
Service Relationship Modeling

  1. Service relationship modeling defines and maintains the standardized relationships between service layers and supporting components to ensure consistent representation of service dependencies and hierarchy across the enterprise. These relationships align with enterprise service modeling standards, including ABA and CSDM, and establish the allowed structure for linking Business Services, Application Services, Technology Management Services, Application Components, and Infrastructure CIs.

  2. Standard relationships include:

    • Application Services realize Business Services

    • Technology Management Services support Application Services

    • Application Components implement Application Services

    • Infrastructure CIs host Application Components

  3. Non-conforming relationships include:

    • Direct relationships between Technology Management Services and Business Services

    • Relationships that bypass the Application Service layer

  4. Service Instances:

    • Are instantiated from a single parent Application Service

    • Are not directly related to Business Services

    • Are not directly related to Technology Management Services

    • Do not bypass the Application Service layer

  5. Infrastructure CIs:

    • Are not directly related to Business Services

    • Do not replace the Technology Management Service layer in the service hierarchy

    • Represent hosting or platform implementation details only

  6. During service creation and structural updates, relationships are established in alignment with the defined service hierarchy. Configuration Management activities validate that:

    • Relationships follow the standard hierarchy

    • Non-conforming relationships are not introduced

    • Service Instances and Infrastructure CIs remain properly positioned within the model

  7. During CMDB maintenance and Change Management activities, service relationships are reviewed to identify hierarchy violations or improper linkages. Identified issues are corrected through Configuration Management data maintenance to maintain alignment with the defined service hierarchy.

2.150.2.2.2.7 (05-18-2026)
CI Relationships

  1. CI relationships extend the service relationship model defined in the preceding section by representing broader dependency and operational relationships across configuration items.

  2. CI relationships support:

    • Dependency mapping

    • Change impact assessment

    • Incident and problem resolution

    • Audit traceability

    • Cloud shared-responsibility modeling

  3. CI relationships are established and maintained as part of Configuration Management activities to reflect dependencies between services, applications, platforms, and infrastructure.

  4. During CMDB maintenance and Change Management activities, CI relationships are reviewed to ensure accuracy and completeness for impact analysis, operational support, and audit traceability. Identified discrepancies are corrected through Configuration Management data maintenance.

2.150.2.2.2.8 (05-18-2026)
Pre-Registration Validation

  1. All CIs must undergo Pre-Registration Validation (Baseline Qualification) prior to initial entry into the CMDB.

  2. Pre-Registration Validation ensures that each CI meets minimum data quality, completeness, and standards compliance requirements before being established as an authoritative record.

  3. Validation activities at this stage are point-in-time and gatekeeping in nature, and include:

    • Verification of required CI attributes (e.g., ownership, environment, system association)

    • Confirmation of alignment to approved naming conventions and classification standards

    • Validation of relationships to parent systems, business services, or security boundaries

    • Review for duplication or conflict with existing CIs

  4. CIs that fail Pre-Registration Validation are not registered in the CMDB until deficiencies are resolved.

  5. Responsibility for Pre-Registration Validation resides with the CI submitter and/or owning organization, with oversight by Configuration Management authorities as defined in this IRM.

2.150.2.2.2.9 (05-18-2026)
Baseline Mapping

  1. Baseline mapping:

    • Identifies the CIs included within each baseline

    • Defines the baseline type and its lifecycle purpose

    • Supports impact analysis and change evaluation activities

    • Aligns baseline definitions with lifecycle decision points

  2. A configuration baseline represents an approved and documented configuration state that serves as a reference point for change control and future development.

  3. Baseline types include:

    • Functional, Allocated, Product

    • Security, Application, Infrastructure

    • Cloud and provider-managed

  4. Baseline composition is defined within the CII or CMP, as appropriate.

  5. Baseline mapping defines baseline structure only. Baseline approval, modification, and version control activities are addressed in IRM 2.150.2.2.3 , Configuration Control.

2.150.2.2.2.10 (05-18-2026)
Cloud and Managed Service Considerations

  1. For cloud and managed service environments, the CII identifies cloud-related CIs, including IaC artifacts, container and container orchestration definitions, cloud resource configuration templates, and provider-managed configuration components within defined responsibility boundaries.

  2. Cloud infrastructure CIs, including virtual machines, containers, storage resources, network components, platform services, and IaC artifacts, are uniquely identifiable and conform to approved enterprise cloud platform naming standards. Naming conventions support configuration identification, environment distinction, traceability to approved change records, and alignment with authoritative configuration repositories. Logical service naming standards defined in IRM 2.150.2.2.2.5 remain distinct from infrastructure resource naming standards.

  3. Cloud resources and provider-managed configuration elements are identified in alignment with this section. Cloud-specific control, governance, and remediation activities are addressed in IRM 2.150.2.2.6.

  4. Temporary cloud resources do not require CMDB tracking when managed through controlled, repeatable templates.

2.150.2.2.3 (05-18-2026)

Configuration Control

  1. Configuration Control defines and maintains the processes used to evaluate, approve, implement, and track changes to configuration items (CIs), baselines, and related artifacts throughout the lifecycle

  2. Configuration Management artifacts, including CMPs, CIIs, baselines, and configuration repositories, are maintained under configuration control and updated through approved Change Management processes.

  3. Configuration Control activities manage changes to CIs, baselines, and related artifacts to ensure integrity, traceability, and alignment with approved changes throughout the lifecycle.

  4. Configuration Control integrates with Change Management to support separation of approval and implementation responsibilities and to ensure controlled updates to configuration information.

  5. Configuration updates are reflected in the CMDB as part of controlled change implementation and verification activities.

2.150.2.2.3.1 (05-18-2026)
Continuous Compliance Validation and Remediation

  1. All registered CIs are subject to Continuous Compliance Validation and Remediation to ensure ongoing accuracy, completeness, and alignment with the ABA.

  2. Validation activities at this stage are continuous, event-driven, or periodic, and include:

    • Detection of configuration drift from established baselines

    • Reconciliation of CI data against authoritative sources and discovery tools

    • Verification of continued alignment to system, application, and infrastructure relationships

    • Identification of stale, orphaned, or non-compliant CIs

  3. When discrepancies or non-compliance are identified, remediation actions must be initiated, including:

    • Correction or enrichment of CI attributes

    • Re-establishment of accurate relationships

    • Decommissioning or archival of invalid or obsolete CIs

  4. Responsibility for Continuous Compliance Validation and Remediation is shared across:

    • Configuration Management authorities (governance and enforcement)

    • CI owners (data accuracy and correction)

    • Infrastructure Tech Ops (ITO) and system stakeholders (operational alignment and reconciliation)

  5. Failure to remediate identified issues within defined timeframes may result in escalation, reporting, or enforcement actions in accordance with Configuration Management policy.

2.150.2.2.3.2 (05-18-2026)
Change Initiation

  1. Proposed changes to CIs or baselines are formally documented, uniquely identified, and submitted through the enterprise change mechanism prior to baseline modification or production implementation.

  2. Application changes initiated through the Unified Work Request (UWR) process (IRM 2.22.1) are processed in alignment with enterprise Change Management and Configuration Control activities.

  3. Provider-initiated configuration changes are documented and processed through the same Change Management and Configuration Control activities.

2.150.2.2.3.3 (05-18-2026)
Change Evaluation

  1. Configuration changes are evaluated for:

    • Technical impact

    • Operational impact

    • Service impact

    • Dependency impact

    • Security impact

    • Cloud shared-responsibility impact (when applicable)

  2. Configuration change evaluation includes impacts to existing baselines and related CIs.

  3. Security impact evaluation includes performing Security Impact Analysis to identify affected CIs, assess impacts to security controls and baselines, and coordinate with security stakeholders.

2.150.2.2.3.4 (05-18-2026)
Change Approval

  1. Configuration changes are approved by designated authorities prior to implementation.

  2. Approval activities include:

    • Assignment of approval responsibilities

    • Separation of approval and implementation responsibilities

    • Inclusion of required security concurrence

  3. Change approval is performed in alignment with established Change Management processes prior to implementation and baseline update.

2.150.2.2.3.5 (05-18-2026)
Change Implementation

  1. Approved configuration changes are implemented in controlled environments in accordance with approved change records.

  2. Implementation activities ensure:

    • Traceability between implemented changes, associated configuration items, and approved change records

    • Rollback or corrective action capability

  3. Cloud implementation controls are addressed in IRM 2.150.2.2.6.

2.150.2.2.3.6 (05-18-2026)
Change Verification and Closure

  1. Implemented changes are verified and closed to confirm alignment with approved changes and to ensure configuration records are complete and accurate.

  2. Verification and closure activities include:

    • Validation that implemented changes align with approved baselines and change records

    • Confirmation that CI records and relationships are updated in authoritative repositories

    • Completion of formal change closure following verification of the implemented change

2.150.2.2.3.7 (05-18-2026)
Baseline Management

  1. Baseline composition and types are defined in IRM 2.150.2.2.2.9. This section addresses baseline approval, modification, and protection activities.

  2. Approved baselines are maintained under configuration control and protected from unauthorized modification.

  3. Baseline management activities include:

    • Approval of baselines prior to use as reference states

    • Updates to baselines through approved Change Management and Configuration Control processes

    • Maintenance of baseline integrity throughout the CI lifecycle

2.150.2.2.3.8 (05-18-2026)
Configuration Repository Control

  1. This section addresses control of technical configuration repositories. Enterprise service configuration records are addressed in IRM 2.150.2.2.4.

  2. CIs and baselines are maintained in authorized repositories designated as the authoritative repository of record.

  3. Configuration Management activities ensure that repositories:

    • Maintain CI records

    • Maintain CI relationships

    • Maintain baseline associations

    • Maintain repository-level configuration status metadata

    • Apply access controls

    • Maintain complete version history

    • Support audit logging

  4. Updates to production configuration artifacts occur through controlled repositories and in alignment with approved changes and established Change Management and Configuration Control processes.

2.150.2.2.3.9 (05-18-2026)
Version Control

  1. Version control defines and maintains version identification and traceability for CIs.

  2. Configuration Management activities ensure that:

    • Assignment and maintenance of version identifiers

    • Application of version updates in alignment with approved changes

    • Maintenance of traceability between versions, associated changes, and related baselines

2.150.2.2.3.9.1 (05-18-2026)
Version Numbering

  1. Version identifiers are:

    • Uniquely assigned

    • Structured using a standardized numbering schema

    • Defined to reflect the nature of the change

  2. Version numbering includes:

    • Major versions that reflect baseline-impacting changes

    • Minor versions that reflect incremental enhancements

    • Revision or patch updates that reflect corrective changes

  3. Version increments occur following approved and verified configuration changes.

2.150.2.2.3.9.2 (05-18-2026)
Version Traceability

  1. Each version is traceable to:

    • An approved change record

    • Associated baseline versions

    • Deployment or release identifiers

    • Affected environments

  2. Traceability supports:

    • Audit review

    • Impact analysis

    • Rollback capability

2.150.2.2.4 (05-18-2026)

Configuration Status Accounting

  1. Configuration Status Accounting provides visibility into the current and historical state of CIs, configuration baselines, and approved changes.

  2. Configuration Management activities record and update configuration status information at each approved baseline establishment and at each change lifecycle milestone (for example: Submitted, Approved, Implemented, Verified, Closed). These activities support the production of configuration status reports and audit artifacts for authorized stakeholders.

  3. Authoritative configuration records for CIs, services, and their relationships are maintained within the enterprise CMDB.

  4. Configuration Management activities ensure that the CMDB:

    • Maintains CI attributes required for identification, lifecycle state management, and impact analysis

    • Maintains CSDM-aligned service hierarchies, naming standards, and relationship integrity

    • Supports automated or periodic reconciliation and data quality validation

    • Reflects approved baseline versions and change status

    • Prevents duplicate or conflicting service records through standardized naming and classification controls

  5. Configuration Management activities include periodic review of CMDB data quality, naming conformance, and CSDM model alignment to support accuracy and consistency of configuration information.

  6. Configuration Management activities include continuous monitoring and reconciliation of CMDB data to ensure alignment with approved baselines and actual configuration states.

  7. Enterprise configuration status information is maintained within the CMDB as the authoritative source of record.

2.150.2.2.5 (05-18-2026)

Configuration Audit

  1. Configuration audits verify:

    • Approved baselines are correctly implemented

    • Configuration records accurately reflect system state

    • Unauthorized changes are identified

  2. Audit types may include:

    • Functional Configuration Audit (FCA)

    • Physical Configuration Audit (PCA)

    • Cloud configuration compliance review (if applicable)

    • Provider-managed configuration review (if applicable)

  3. Configuration audits in Agile and DevOps environments are performed continuously through automated validation, integration pipelines, and deployment processes. These activities supplement formal audit practices by providing real-time verification of configuration integrity and compliance. Configuration Management activities in Agile and DevOps environments include:

    • Validation of configuration changes through automated build and deployment pipelines

    • Verification of IaC and configuration templates prior to deployment

    • Collection of audit evidence from pipeline execution logs, deployment records, and version control systems

    • Continuous monitoring of configuration compliance and drift

  4. Audit results are documented, and identified discrepancies are addressed through corrective action.

2.150.2.2.6 (05-18-2026)

Configuration Management in Cloud and Managed Service Environments

  1. Configuration Management activities ensure that cloud configurations are derived from approved, version-controlled baselines and remain reproducible, auditable, and aligned with defined shared responsibility boundaries.

  2. Configuration Management activities for cloud and managed service environments support configuration identification, control, status accounting, and verification activities throughout the CI lifecycle.

  3. Cloud configuration controls extend, and do not replace, enterprise Configuration Control requirements defined in IRM 2.150.2.2.3.

  4. Cloud resources and provider-managed configuration elements are managed in alignment with enterprise Configuration Control processes.

  5. Continuous monitoring and drift detection activities are integrated with Configuration Status Accounting, Configuration Control, and Configuration Audit processes to maintain alignment between deployed configurations and approved baselines.

2.150.2.2.6.1 (05-18-2026)
Infrastructure as Code (IaC)

  1. IaC is used to define and manage cloud infrastructure configurations in a consistent, automated, and repeatable manner.

  2. Configuration Management activities ensure that IaC artifacts:

    • Define infrastructure configurations as code

    • Are maintained under version control

    • Maintain traceability to approved change records and associated baselines

    • Support reproducibility, auditability, and consistent environment provisioning

  3. IaC artifacts are managed in alignment with Configuration Control, Version Control, and Configuration Repository Control processes to ensure consistency across environments and deployments.

2.150.2.2.6.2 (05-18-2026)
Infrastructure Baseline Integrity

  1. Infrastructure baseline integrity is maintained through practices that promote consistent, reproducible, and controlled configuration states.

  2. Where technically feasible, Configuration Management activities:

    • Replace Infrastructure CIs rather than modifying them in place to maintain alignment with approved baselines

    • Implement baseline changes through controlled, versioned build and deployment pipelines

  3. These practices support immutable infrastructure patterns and are applied in alignment with IaC, Configuration Control, and Version Control processes.

2.150.2.2.6.3 (05-18-2026)
Shared Responsibility Model

  1. Configuration Management activities define and maintain configuration ownership boundaries between IRS and cloud or managed service providers.

  2. Configuration Management activities ensure that:

    • Configuration ownership and responsibility boundaries are defined and documented in the CMP

    • Visibility is maintained into provider-managed CIs to support traceability and impact analysis

    • Changes to provider-managed configurations that impact system functionality or security posture are managed in alignment with IRS Change Management and Configuration Control processes

  3. Shared responsibility boundaries are applied in alignment with cloud service models to ensure clear accountability for configuration management activities across environments.

2.150.2.2.6.4 (05-18-2026)
Cloud and Automated Pipeline Requirements

  1. Configuration Management activities ensure that configuration artifacts used for build, deployment, and provisioning in cloud or automated environments are maintained in authorized, version-controlled repositories with enforced access controls and traceability to approved change records.

  2. Drift detection and reconciliation requirements are defined in IRM 2.150.2.2.6.5.

2.150.2.2.6.5 (05-18-2026)
Configuration Drift Detection

  1. Configuration drift detection is performed to identify deviations between deployed configurations and approved baselines in cloud-hosted environments.

  2. Configuration Management activities ensure that cloud-hosted environments:

    • Implement automated mechanisms to detect configuration drift

    • Reconcile detected drift against approved baselines

    • Document and remediate unauthorized deviations through Configuration Control processes

  3. Drift detection activities support continuous monitoring of configuration compliance and alignment with IaC, baseline definitions, and approved changes.

2.150.2.2.7 (05-18-2026)

Measurement and Continuous Improvement

  1. Configuration Management activities are measured to support process visibility and continuous improvement.

  2. Measures may include:

    • Baseline compliance rate

    • Unauthorized configuration change rate

    • CMDB accuracy percentage

    • Cloud drift occurrence rate (if applicable)

    • Change-to-baseline traceability completeness

  3. Measurement results are used to identify trends, improve Configuration Management practices, and support ongoing process refinement.

2.150.2.2.8 (05-18-2026)

Integration with OneSDLC

  1. Configuration Management activities are initiated early in the lifecycle and remain active throughout development, testing, production, sustainment, and retirement.

  2. Configuration Management activities:

    • Support readiness decision points

    • Maintain configuration control across development, testing, and production environments

    • Continue throughout sustainment and retirement phases

  3. Configuration Management activities are applied consistently across development methodologies, including Agile, DevOps, and managed service delivery models.