Configuration, Baseline, and Technical-Data Management Across the SDLC - Systems Development Lifecycle (SDLC) Best Practices

Configuration, Baseline, and Technical-Data Management Across the SDLC

(Chapter 89 of Systems Development Lifecycle (SDLC) Best Practices)

Executive Summary: Chapter Overview

IF4IT

The Bottom Line

Configuration confidence links lifecycle evidence to the actual state evaluated, authorized, deployed, operated, recovered, and retired.

Core Concepts

Concept	Definition & Strategic Role
Governing Principle	Identify and control the configuration states and baselines required to understand, build, test, authorize, operate, recover, change, and retire each Solution and Release.
Lifecycle Accountability	Enduring ownership and Release-specific coordination remain explicit.
Evidence	Claims and decisions are supported by attributable, current, relevant, and sufficient evidence.
Risk-Based Tailoring	Depth changes with context; minimum outcomes and accountability remain.

Quick Q&A

Question: How do configuration, baseline, and technical-data management differ?

Answer: Configuration management controls component states and changes; baselines identify approved reference states; technical-data management preserves the authoritative information needed to understand, reproduce, operate, support, and retire them.

Question: Why must baselines span more than source code?

Answer: The operated Solution may depend on infrastructure, cloud settings, identities, data schemas, models, supplier versions, runbooks, and Environment configuration.

Question: What is the key lifecycle outcome?

Answer: The enterprise should know which state was planned, built, tested, accepted, deployed, operated, recovered, and retired, with traceable evidence for each.

Defines Configuration Management and baseline control as lifecycle disciplines for identifying, versioning, relating, controlling, verifying, and preserving authoritative Solution states.

Governing Principle

Identify and control the configuration states and baselines required to understand, build, test, authorize, operate, recover, change, and retire each Solution and Release.

Required Lifecycle Treatment

Area	Required treatment
Configuration Items	Govern independently meaningful requirements, Designs, source, packages, Products, infrastructure, schemas, interfaces, policies, Models, prompts, feature flags, procedures, and supplier dependencies.
Baselines	Establish approved reference states for requirements, Architecture, Design, Build, integration, acceptance, Release, Production, recovery, and retirement as applicable.
Status accounting	Record identities, versions, relationships, states, locations, approvals, Releases, Environments, exceptions, and lifecycle status.
Verification and drift	Compare approved, declared, deployed, and active state; detect, classify, reconcile, and correct material drift.
Federated authority	Use appropriate authoritative repositories for each Configuration Item class rather than assuming one CMDB contains all truth.

Application Through the SDLC

Apply this discipline from Intake through Retirement. Early phases establish ownership, risk, and evidence needs in the Utilization Profile; Requirements through Build translate the principle into testable conditions; SIT through Staging generate decision-ready evidence in representative Environments; Production and Operations verify and monitor the authorized state; Retirement closes remaining obligations with evidence.

Governance and Evidence

Name accountable owners for the Solution, Release, and applicable discipline, along with evidence producers, reviewers, and a Risk Owner. Scale rigor to actual risk and reversibility, and keep Risks, exceptions, and Technical Debt in authoritative systems rather than narrative status. AI may assist with analysis and drafting but should never independently accept Risk or authorize Production.

Use Technology Portfolio Management (TPM) Best Practices and the Software Technologies Inventory and Attributes to select approved technologies, expose standards exceptions, record configuration baselines, and manage supportability and obsolescence. Use the Data and Information Inventory and Attributes, the Integrations Inventory and Attributes, and Best Practices for Making Legacy Data Semantic and AI-Ready to govern source meaning, mappings, lineage, reconciliation, validation, and migration evidence.

Each Release should read authoritative lifecycle records and update affected inventories, identifiers, relationships, ownership, status, evidence, configuration, and retirement information as governed outputs, per Enterprise Inventory Management Best Practices.

For Configuration, Baseline, and Technical-Data Management Across the SDLC, IT leaders and managers should establish explicit decision rights, accountable ownership, proportional controls, evidence expectations, performance measures, and continuous-improvement feedback tied to enterprise value.

How to cite this page

When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.

Example (informal web citation):

The International Foundation for Information Technology (IF4IT), LLC. Configuration, Baseline, and Technical-Data Management Across the SDLC | Systems Development Lifecycle (SDLC) Best Practices. https://if4it.org/best-practices/systems-development-lifecycle-sdlc/configuration-baseline-and-technical-data-management-across-the-sdlc/ (accessed 2026-09-04).

See About Us for content governance and site-wide citation guidance.

Legal Disclaimers

Governing Principle

Required Lifecycle Treatment

Application Through the SDLC

Governance and Evidence

Connections to Related IF4IT Practices and Inventories

How to cite this page