How SDLC Exceptions Should Be Tracked Through Operations and Maintenance - Systems Development Lifecycle (SDLC) Best Practices
How SDLC Exceptions Should Be Tracked Through Operations and Maintenance
(Chapter 69 of Systems Development Lifecycle (SDLC) Best Practices)
Executive Summary: Chapter Overview
IF4ITThe Bottom Line
Core Concepts
| Concept | Definition & Strategic Role |
|---|---|
| Governing Principle | An SDLC exception remains an active lifecycle obligation until its requirement is satisfied, the exception is formally closed or superseded, or the governed Solution is retired. Production authorization does not erase the exception, transfer it implicitly to Operations, or make temporary compensating controls permanent. |
| Operational Handoff | Before Production, transfer each active exception to the enduring Solution or Service owner and the operational functions responsible for its controls and remediation. The authoritative record should preserve the requirement, scope, affected configuration, owner, Risk Owner, compensating controls, monitoring, expiration or reassessment trigger, remediation plan, evidence, and escalation path. |
| Monitoring and Reassessment | Operations should verify that compensating controls continue to operate and that the exception remains within its approved scope. Reassess after material Release, configuration change, supplier change, Incident, control failure, vulnerability, audit finding, or expiration. A changed condition may require revised controls, a new Risk decision, immediate remediation, or withdrawal of authorization. |
| Renewal and Closure | Do not renew exceptions automatically. Renewal should require current evidence, a continuing rationale, updated residual Risk, accountable authority, and a credible remediation path. Closure should demonstrate that the original requirement is now satisfied, the affected configuration has been verified, temporary controls are retired appropriately, and linked records are updated. |
| Operational Reporting and Improvement | Include active exceptions in Service reviews, control-health reporting, Release planning, Technical Debt analysis, and lifecycle metrics. Repeated exceptions should trigger root-cause analysis of Standards, platforms, supplier constraints, funding, skills, or governance rather than routine renewal. |
Quick Q&A
Question: Who owns an exception after the Project closes?
Question: Can an exception remain open indefinitely?
Question: What should happen if a compensating control fails?
Read More Below
Explains how approved SDLC exceptions, compensating controls, residual Risks, conditions, and deferred remediation should remain visible and governed after Production rather than disappearing when the delivery team or Project closes.
Best Practice: Establish the Governing Principle for SDLC Exceptions Should Be Tracked Through Operations and Maintenance
An SDLC exception remains an active lifecycle obligation until its requirement is satisfied, the exception is formally closed or superseded, or the governed Solution is retired. Production authorization does not erase the exception, transfer it implicitly to Operations, or make temporary compensating controls permanent.
Benefits: Making clear that Production authorization doesn’t erase or implicitly transfer an exception prevents a common assumption failure: that once a Release with an accepted exception goes live, the exception itself somehow becomes resolved rather than remaining an active obligation.
Best Practice: Apply Operational Handoff
Before Production, transfer each active exception to the enduring Solution or Service owner and the operational functions responsible for its controls and remediation. The authoritative record should preserve the requirement, scope, affected configuration, owner, Risk Owner, compensating controls, monitoring, expiration or reassessment trigger, remediation plan, evidence, and escalation path.
Benefits: Transferring each active exception to the enduring owner before Production, with its full context preserved, means Operations inherits genuine understanding of what’s being tolerated and why, rather than discovering an undocumented compensating control during an Incident.
Best Practice: Apply Monitoring and Reassessment
Operations should verify that compensating controls continue to operate and that the exception remains within its approved scope. Reassess after material Release, configuration change, supplier change, Incident, control failure, vulnerability, audit finding, or expiration. A changed condition may require revised controls, a new Risk decision, immediate remediation, or withdrawal of authorization.
Benefits: Verifying that compensating controls continue operating, not just assuming they still do, catches the case where a control quietly stopped functioning long before anyone noticed the exception it was supposed to offset had become genuinely unmitigated.
Best Practice: Apply Renewal and Closure
Do not renew exceptions automatically. Renewal should require current evidence, a continuing rationale, updated residual Risk, accountable authority, and a credible remediation path. Closure should demonstrate that the original requirement is now satisfied, the affected configuration has been verified, temporary controls are retired appropriately, and linked records are updated.
Benefits: Requiring current evidence and a credible remediation path for renewal — rather than automatic extension — means each renewal decision is a genuine reassessment, not a rubber stamp that lets an old exception persist indefinitely on outdated justification.
Best Practice: Apply Operational Reporting and Improvement
Include active exceptions in Service reviews, control-health reporting, Release planning, Technical Debt analysis, and lifecycle metrics. Repeated exceptions should trigger root-cause analysis of Standards, platforms, supplier constraints, funding, skills, or governance rather than routine renewal.
Benefits: Including active exceptions in Service reviews and Technical Debt analysis keeps them visible to the people who prioritize remediation, rather than existing only in a compliance tracker no one outside of audit season ever actually looks at.

Best Practice: Advance Maturity Deliberately for How SDLC Exceptions Should Be Tracked Through Operations and Maintenance
At Crawl maturity, the enduring owner tracks handed-off exceptions in a simple list reviewed periodically alongside other operational obligations. At Walk maturity, exceptions are tracked in the same system used for Service reviews and Technical Debt, so Operations has one place to check compensating-control status and upcoming renewal dates. At Run maturity, compensating-control health is monitored continuously and integrated with Incident and Risk systems, so a control failure or approaching expiration triggers automatic escalation rather than depending on someone noticing during a periodic review.
Benefits: A simple periodically-reviewed list at Crawl maturity is enough to keep a handful of operational exceptions from being forgotten after go-live. Tracking exceptions alongside Service reviews and Technical Debt at Walk maturity gives Operations one place to check status instead of a separate, easily-neglected exception log. Continuous monitoring integrated with Incident and Risk systems at Run maturity catches a failed compensating control immediately, rather than at the next scheduled review.
Best Practice: Avoid Common Antipatterns in How SDLC Exceptions Should Be Tracked Through Operations and Maintenance
Enterprises should avoid letting an exception drift into a permanent, unmanaged operating condition. This appears when an exception has no owner, expiration, trigger, remediation plan, or closure evidence; when it is renewed repeatedly without new analysis; or when teams cite a historic approval as standing permission for later Releases and changed conditions.
| Antipattern | Why it fails |
|---|---|
| Allowing temporary SDLC exceptions to become permanent | Compensating controls age and assumptions change while exposure is normalized and invisible, so the enterprise loses a defensible basis for continued acceptance. |
Benefits: Avoiding this antipattern keeps exceptions bounded, owned, and time-limited rather than becoming de facto standards. It preserves a defensible, current basis for every accepted departure and surfaces recurring exceptions as a signal that the underlying Path or control needs to change.
Connections to Related IF4IT Practices and Inventories
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.
Keep security, privacy, Risk, compliance, audit, and authorization controls integrated throughout this chapter’s decisions so required evidence, exceptions, residual Risk, and accountable approvals remain visible and governed.
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. How SDLC Exceptions Should Be Tracked Through Operations and Maintenance | Systems Development Lifecycle (SDLC) Best Practices. https://if4it.org/best-practices/systems-development-lifecycle-sdlc/how-sdlc-exceptions-should-be-tracked-through-operations-and-maintenance/ (accessed 2026-08-24).
See About Us for content governance and site-wide citation guidance.
Copyright for The International Foundation for Information Technology (IF4IT), LLC: 2008 - Present
Legal Disclaimers