Approve Only Justifiable Release Exceptions — With Documentation as a Fast Follower - Application Management Best Practices
Approve Only Justifiable Release Exceptions — With Documentation as a Fast Follower
(Chapter 44 of Application Management Best Practices)
Executive Summary: Chapter Overview
IF4ITThe Bottom Line
Core Concepts
| Concept | Definition & Strategic Role |
|---|---|
| Justifiable Release Exception | An approved bypass of the documentation gate, primarily for emergencies such as critical security patches and severe Production incident fixes, or where delay would clearly cause greater harm than a temporary gap. Ordinary schedule pressure never qualifies. |
| Documentation as a Fast Follower | The requirement that an excepted Release’s missing documentation be delivered by a defined deadline shortly after the Release. Until it is delivered, no further Release of the Application may reach Production except through another approved exception. |
| Exception Evaluation | Assessment of each exception request by Enterprise Architecture, Engineering, Security, and Change Management, followed by approval from the authority the policy designates. It keeps the Application team, which has the strongest incentive to skip documentation, from approving its own exceptions. |
Quick Q&A
Question: Why should ordinary schedule pressure never justify an exception to the documentation policy?
Question: What records must be kept for each documentation exception?
Read More Below
This chapter explains when an exception to the Minimum Application Documentation Policy is justified, who should approve it, and how the deferred documentation must follow.
Why Exceptions Must Exist
Rigid enforcement can occasionally create more risk than it prevents. The clearest example is a critical security patch: blocking an urgent fix for a known, actively exploited vulnerability until every documentation gap is closed would leave the enterprise exposed to a far greater danger. A sound policy therefore allows exceptions, but only justifiable ones, and never without a firm commitment to close the gap.
Establish the Exception Process
Justifiable cases only. Emergencies, such as critical security patches and fixes for severe Production incidents, are the primary justification. Other cases may be justified where delaying the Release would clearly create greater risk or harm than the temporary documentation gap, and only for a strictly limited time.
Evaluated by the right functions. Each exception request is evaluated by Enterprise Architecture, Engineering, Security, and Change Management, and approved by the authority the policy designates.
Documentation as a fast follower. The approved Release proceeds, but its missing documentation becomes a fast follower: it must be delivered by a defined deadline shortly after the Release.
Recorded as a risk. The documentation gap is recorded in the Enterprise Risk Register with its deadline.
Further Releases blocked. No further Release of the Application may be deployed to Production until the fast-follower documentation is delivered, except through another approved exception.
Document and Share Exceptions
Record every exception request, its justification, the evaluating functions’ assessments, the approval decision, the fast-follower deadline, and the date the documentation was actually delivered. Report exceptions to leadership as part of conformance reporting, so that a pattern of repeated exceptions is visible.
Best Practice: Approve Only Justifiable Release Exceptions, with Documentation as a Fast Follower
It is a best practice to both establish and document the solution for exceptions to the documentation policy: approve exceptions only where delay would create greater risk, have them evaluated by Enterprise Architecture, Engineering, Security, and Change Management, require the missing documentation as a fast follower with a deadline, record the gap in the Enterprise Risk Register, and block further Releases until it is delivered.
Benefits: A defined exception process lets the enterprise act quickly in a genuine emergency without abandoning its policy. Because every exception carries a deadline, a Risk Register entry, and a block on further Releases, exceptions remain rare, temporary, and visible, rather than becoming a routine way around the policy.
Common Antipatterns
| Antipattern | Why It Fails |
|---|---|
| Granting exceptions for ordinary schedule pressure | Every deadline becomes an emergency, and the policy is waived routinely. |
| Granting exceptions without a deadline for the documentation | The fast follower never follows, and the gap becomes permanent. |
| Letting the Application team approve its own exceptions | The people with the strongest incentive to skip documentation decide whether to skip it. |
Connections to Related IF4IT Practices and Inventories
The Release Management Best Practices addresses emergency Releases and their governance. The Service Management Best Practices addresses the incident and change processes through which emergency fixes are made.
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. Approve Only Justifiable Release Exceptions — With Documentation as a Fast Follower | Application Management Best Practices. https://if4it.org/best-practices/application-management-best-practices/approve-only-justifiable-release-exceptions-with-documentation-as-a-fast-follower/ (accessed 2026-10-31).
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