SDLC Conformance, Deviations, Exceptions, and Risk Acceptance

Defines the distinct governance concepts used to determine whether lifecycle work conforms to the approved SDLC, differs through authorized tailoring, departs through an exception, or proceeds through explicit residual Risk acceptance.

Governing Principle

Evaluate conformance against the approved Enterprise SDLC, applicable SDLC Path, and Release-specific SDLC Utilization Profile. Distinguish authorized tailoring from an exception and distinguish both from an ungoverned nonconformance.

Core Distinctions

Conformance means applicable obligations and outcomes are satisfied through approved mechanisms. Tailoring selects an authorized way to satisfy those outcomes. A deviation is an observed difference from the expected method or state and must be classified. An exception is a formally authorized, bounded departure from an applicable requirement. Risk acceptance is an authorized decision to retain identified residual Risk; it does not by itself waive an SDLC requirement or replace an exception.

Nonconformance and Corrective Action

A nonconformance exists when an applicable obligation is not satisfied and no valid tailoring decision, alternative method, exception, or other authorization applies. Record the affected requirement, condition, evidence, consequence, owner, corrective action, due date or trigger, and escalation. Material nonconformance should prevent progression unless an authorized decision explicitly governs the exposure.

Lifecycle Application

Assess conformance throughout planning, Requirements, Design, Build, testing, Gates, Production authorization, Operations, and Retirement. Reassess exceptions and accepted Risks when scope, configuration, supplier, Environment, evidence, threat, regulation, or operational consequence changes.

Common Antipatterns

Enterprises should avoid allowing a Release to progress with unauthorized nonconformance. A nonconformance without valid tailoring, an alternative method, or an exception is an unauthorized departure, not a governed one; allowing a Release to progress anyway, without an authorized decision explicitly governing the exposure, lets ungoverned Risk enter Production unnoticed.

Connections to Related IF4IT Practices and Inventories

Make sure security, privacy, Risk, compliance, audit, and authorization controls run throughout this chapter’s decisions and responsibilities, keeping required evidence, exceptions, residual Risk, and accountable approvals visible and governed.

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