Prove Across the SDLC That the Tested and Approved Configuration Is the Configuration Deployed

Release confidence depends on proving that the configuration evaluated through Verification, Validation, Assurance, and acceptance is the configuration actually deployed and activated in the intended IT Operating Environment. Enterprises should preserve attributable provenance from approved source and supplier states through Build, package, Deployment, runtime configuration, feature activation, migration, and post-Deployment verification.

Best Practice: Define the Configuration Equivalence Claim

The enterprise should define a bounded claim that the deployed and active Production state is equivalent, within authorized variance, to the state that was tested, accepted, and approved. The claim should include software, supplier Product, infrastructure, schema, interfaces, identities, feature flags, data migration, and operational controls where material.

Benefits: Defining exactly what ’equivalent to what was tested’ means — including infrastructure, feature flags, and data migration, not just application code — closes the common gap where a Release is verified at the code level while its actual runtime configuration was never formally compared to what was approved.

Best Practice: Establish an Approved Release Baseline

The Release baseline should identify the complete authorized state, including component versions, Build artifacts, acquired-Product versions, configuration, infrastructure definitions, database changes, integration packages, documentation, migration assets, and known approved differences.

Benefits: Capturing the complete authorized state, including acquired-Product versions and known approved differences, gives the enterprise one definitive reference for what a Release was actually supposed to contain, instead of reconstructing that answer after the fact from scattered notes and memory.

Best Practice: Preserve Build and Artifact Provenance

The enterprise should relate the deployable artifact to approved source, commit, dependencies, toolchain, Build process, runner, controls, signatures or hashes, repository, and Release. Supplier artifacts should identify Product, version, edition, source, integrity information, and applicable evidence.

Benefits: Tracing a deployable artifact back to its exact source commit and Build process means a security or licensing question about what’s running in Production has a precise, verifiable answer instead of an approximate one based on when the deployment probably happened.

Best Practice: Apply Promote the Same Immutable Artifact Where Practical

Where feasible, the same immutable package or uniquely attributable artifact should move through controlled Environments. Rebuilding separately for each Environment can introduce untested variance unless the Build is reproducible and the resulting differences are verified.

Benefits: Promoting one immutable artifact through every Environment, rather than rebuilding separately at each stage, is what actually guarantees that what was tested is what reaches Production. A separate rebuild for each Environment can introduce untested variance even when the source code is identical.

Best Practice: Control Environment-Specific Configuration

Environment-specific endpoints, identities, secrets, scale, data, integrations, and feature states should be parameterized, versioned or otherwise controlled, and compared with the approved deployment model. Authorized variance should be explicit.

Benefits: Explicitly parameterizing and versioning Environment-specific settings — rather than leaving them as untracked local edits — means the difference between Staging and Production configuration is a known, authorized variance instead of an undocumented discrepancy discovered during an Incident.

Best Practice: Verify the Deployment Target and Execution Context

Deployment records should identify the source artifact, target Environment Instance, executing identity, time, change or Release authority, deployment procedure, result, and resulting configuration. The enterprise should prevent accidental deployment to the wrong account, region, cluster, tenant, or database.

Benefits: Recording exactly which Environment Instance, identity, and authority performed a deployment is what prevents, or at minimum quickly diagnoses, an accidental deployment to the wrong account, region, or tenant — a mistake that’s far more common, and far more damaging, than it might seem.

Best Practice: Verify Database and Data-Migration State

Schema versions, migration scripts, transformation rules, execution order, reconciliation results, rollback or recovery state, and data-quality evidence should be attributable to the approved Release. Successful application deployment does not prove successful or semantically correct data migration.

Benefits: Verifying data-migration results separately from application deployment success closes a real gap: a Release can deploy its application code flawlessly while its data migration silently failed or produced semantically incorrect results that only surface much later.

Best Practice: Govern Feature Flags and Runtime Activation

A deployed package may behave differently according to feature flags, routing, tenant configuration, prompts, Model endpoints, or dynamic policy. Material runtime controls should be included in the Production baseline and verified after activation.

Benefits: Including feature flags and dynamic routing in the Production baseline — not just the deployed code — means the enterprise actually knows what behavior is live. Two Releases with identical code can behave completely differently depending on flag state, and only tracking the code misses that entirely.

Best Practice: Perform Post-Deployment Configuration Verification

After Deployment, automated and manual checks should compare the intended baseline with the observed runtime state. Verification may include package hashes, API queries, infrastructure-state comparison, schema checks, route tests, access checks, monitoring validation, and feature-state confirmation.

Benefits: Comparing the intended baseline against the observed runtime state after deployment — through package hashes, API queries, and route tests — is what actually confirms a deployment succeeded, rather than inferring success from the deployment tool reporting no errors.

Best Practice: Address Differences Through Impact Analysis

Any difference between tested, approved, deployed, and active states should be classified as authorized variance, harmless difference, configuration defect, unauthorized change, emergency change, or material untested condition. Material differences should trigger retesting, reassessment, rollback, exception, or Risk treatment.

Benefits: Classifying every difference between tested and deployed state as authorized, harmless, or a genuine defect — rather than assuming any difference found is automatically fine — is what prevents an unauthorized change from hiding behind the assumption that small deviations don’t matter.

Best Practice: Preserve Evidence for Audit and Incident Response

The enterprise should retain enough provenance and deployment evidence to reconstruct what was authorized, what was deployed, what became active, who performed the action, and what verification occurred. This evidence supports Incidents, Problems, supplier disputes, recovery, and future Releases.

Benefits: Retaining deployment and provenance evidence long after a Release closes means an Incident responder or auditor months later can actually reconstruct what was authorized and what happened, instead of relying on institutional memory that has since moved on to other work.

Best Practice: Apply to Supplier-Managed and Dynamic Services

For SaaS, managed platforms, serverless systems, and supplier-managed AI Models, exact internals may be unavailable. The enterprise should preserve the best available Product state, release notice, configuration export, effective date, regression evidence, monitoring, and acceptance decision.

Benefits: Preserving the best available evidence for SaaS and supplier-managed Models — release notices, configuration exports, regression evidence — closes the gap where the enterprise can’t directly inspect internals but still needs a defensible basis for what it accepted and when.

Best Practice: Advance Maturity Deliberately for Prove Across the SDLC That the Tested and Approved Configuration Is the Configuration Deployed

At Crawl maturity, record versions, artifacts, target Environments, and post-Deployment checks. At Walk maturity, integrate immutable artifacts, infrastructure as code, signatures, deployment records, baseline comparison, and drift detection. At Run maturity, use continuous provenance, policy enforcement, runtime attestation, and automated evidence-linked authorization.

Benefits: Starting with recorded versions and basic post-Deployment checks at Crawl maturity establishes the discipline that immutable artifacts and drift detection at Walk maturity depend on. Pursuing continuous runtime attestation at Run maturity before basic provenance is reliable tends to automate confidence the enterprise hasn’t actually earned yet.

Best Practice: Avoid Common Antipatterns in Prove Across the SDLC That the Tested and Approved Configuration Is the Configuration Deployed

Enterprises should avoid assuming deployment success means the tested configuration is what’s actually running. A deployment pipeline completing without error confirms the process ran; it does not confirm that the artifact actually deployed matches, exactly, the configuration that was tested and approved.

Benefits: Avoiding this antipattern replaces an assumption with independent verification. It catches the gap between a deployment process that reported success and a runtime state that actually matches what was tested and approved.

Connections to Related IF4IT Practices and Inventories

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 Capabilities Inventory and Attributes and the IF4IT Enterprise Model to evaluate whether delivered and operated outcomes actually improve the intended enterprise capabilities and value streams.

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

Use the Non-Functional Requirements (NFRs) Framework for Software Systems to tie quality expectations to validation methods, test evidence, acceptance criteria, readiness gates, and Production assurance.