The Difference Between SDLC Tailoring and an SDLC Exception

Explains the governed distinction between SDLC tailoring, approved alternative methods, exceptions, risk acceptance, and nonconformance so that scaled delivery does not silently remove lifecycle obligations.

Governing Principle

Tailoring changes how an applicable lifecycle outcome is achieved; an exception authorizes a bounded departure from an applicable requirement.

Required Lifecycle Treatment

Application Through the SDLC

Apply this discipline across the full lifecycle, from Intake through Retirement. Establish applicability and ownership during Planning, translate it into testable requirements and decisions during Design and Build, generate decision-ready evidence through SIT, UAT, and Staging, verify and monitor it in Production and Operations, and close out remaining obligations at Retirement.

Governance and Evidence

Assign clear ownership — an enduring Solution owner, Release Owner, discipline owner, evidence producers, and Risk Owner — and scale rigor to the work’s criticality, complexity, and reversibility. Record Risks, exceptions, and Technical Debt in authoritative systems, not narrative status. Generative AI may assist with analysis and evidence organization, but only accountable roles may approve outcomes, accept Risk, or authorize Production.

Example

Omitting formal prototyping for a small enhancement is tailoring when the enterprise has an approved path that still satisfies required design, testing, security, approval, and operational outcomes. Deploying a high-volume service before performance testing is an exception because a required control is not being met. The exception requires a named risk owner, documented residual risk, traffic limits, enhanced monitoring, rollback readiness, an expiration date, and scheduled follow-up testing. Tailoring is a designed method of applying the SDLC; an exception is a governed departure from it.

Common Antipatterns

Enterprises should avoid treating Risk acceptance as equivalent to a formal SDLC exception. Accepting residual Risk addresses the consequence of an unmet requirement, but it does not by itself waive the requirement or substitute for the distinct governance an exception actually requires, so treating the two as interchangeable can leave an SDLC obligation technically unmet even after Risk has been formally accepted.

Connections to Related IF4IT Practices and Inventories

Use the IF4IT Enterprise Model together with Enterprise Capability Models and the Capabilities Inventory and Attributes to anchor this chapter’s decisions in enterprise structure, capability ownership, and measurable business outcomes.

Apply security, privacy, Risk, compliance, audit, and authorization controls throughout this chapter’s decisions and responsibilities to keep required evidence, exceptions, residual Risk, and accountable approvals visible and governed.

Apply Technical Debt Management Best Practices and the Technical Debt Inventory and Attributes to identify, qualify, record, prioritize, remediate, accept, and periodically reassess intentional, inherited, emergent, and deferred lifecycle obligations.