Use code fixes when the issue is part of the application’s trust model and should not persist, but use compensating controls when delivery pressure makes immediate remediation unrealistic. The right choice depends on whether the control is meant to remove the flaw or contain exposure while engineering catches up. Good governance makes that trade-off explicit.
When a code fix is the right answer
Use a code fix when the issue is part of the system’s intended trust model and will remain a recurring source of exposure if you leave it in place. That usually means the defect affects authorisation logic, validation, privilege boundaries, secret handling, or another control that the application depends on for safe behaviour.
A code fix removes the flaw at the source, so it is the right long-term answer when the problem is deterministic and repeatable. It also avoids building a parallel control path that operators must remember to maintain, monitor, and eventually retire.
In practice, code fixes are strongest when the issue is well understood, testable, and likely to reappear across environments or releases. If the weakness sits in a reusable component, a library, or shared workflow, fixing code tends to reduce risk more reliably than wrapping the problem in compensating controls.
When compensating controls are the better short-term choice
Compensating controls make sense when the immediate remediation cost, release risk, or operational dependency makes a code change impractical right now. They contain exposure while engineering work is queued, but they do not remove the underlying defect, so they should be treated as temporary and explicitly time-bounded.
This option is most defensible when the control can reduce blast radius in a meaningful way, for example by limiting access, tightening approval paths, increasing monitoring, or segmenting the affected process. The key question is whether the workaround measurably narrows abuse potential rather than just creating the appearance of action.
Compensating controls are also useful when you need to buy time for safe change management, test coverage, regression analysis, or dependency coordination. In that case the control should be documented as a risk decision, not as a substitute for engineering ownership.
How to decide without creating governance drift
The decision turns on whether the issue should be eliminated or contained. If the defect represents an unacceptable part of the application’s design, fix the code as the end state. If the defect is real but immediate removal would create more operational harm than temporary exposure, apply a compensating control and schedule remediation with an owner and deadline.
That trade-off should be visible in change records, risk acceptance, and backlog prioritisation. Good governance distinguishes between a permanent control and a temporary containment measure, because the organisation’s risk posture changes materially depending on which one is actually in force.
For structured control decisions, the same logic is reflected in Segregation of Duties (SoD) Guide, where compensating controls are used to manage conflicts when a clean separation is not yet achievable.
External control frameworks reinforce the same principle: ISO/IEC 27001:2022 Information Security Management and NIST Cybersecurity Framework 2.0 both support explicit governance over risk treatment, while CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls provide control discipline for containment, access restriction, and monitoring.
Risk and Threat Considerations
The main risk is treating a temporary workaround as a permanent security control. When that happens, the compensating control often outlives its justification, coverage weakens over time, and the original flaw continues to expose the application to misuse, privilege abuse, or unexpected paths around the intended design.
Failure mechanism: The organisation defers the code change, relies on manual or procedural containment, and later loses visibility into whether the workaround still matches the original risk. Over time, attackers or internal users can exploit the gap between the real flaw and the assumed protection.
Impact: Residual exposure remains in production, the control may be bypassed or misapplied, and the business inherits both the original defect and the operational burden of maintaining a temporary measure indefinitely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control decisions frame whether to remove or contain exposure. |
| Recommendation — Define whether the defect needs a permanent access-control fix or a temporary compensating measure. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The question is a risk-treatment choice between fixing and compensating controls. |
| PR.AA-05 — Access Permissions and Credentials are Managed | Compensating controls often narrow permissions while a code fix is pending. | |
| Recommendation — Document whether risk is being treated by remediation or by temporary containment. Restrict permissions and exposure paths until the underlying flaw is remediated. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Temporary controls should be tracked as deliberate configuration state, not drift. |
| Recommendation — Baseline the temporary control and track its planned removal. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Safe containment depends on controlled, auditable configuration changes. |
| Recommendation — Harden the affected asset set while the code fix is being delivered. | ||
Practitioner Guidance
What to prioritise: If the issue changes the application’s security model, prioritise a code fix and use compensating controls only to reduce exposure until release. If the issue is edge-case, time-limited, or dependent on external constraints, make the workaround explicit, owned, and expiring.
What to verify: Confirm that any compensating control actually reduces abuse potential in the affected path, not just in theory. Require an owner, review date, and removal plan, because temporary controls fail most often when no one tracks when they should disappear.
Common mistake: Teams often accept a workaround because it is faster, then forget that the workaround becomes part of the operating model. The better test is whether the control can be safely operated and reliably retired without hidden dependency on tribal knowledge.
Practitioner takeaway: Choose the option that best matches the control’s purpose: remove the flaw when the design is wrong, contain the exposure when immediate removal is genuinely impractical, and never let a temporary containment path become an unowned permanent exception.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- Why does risk analysis help organisations decide which security issues to fix first?
- When should organisations block a pull request instead of letting developers fix issues later?
- How do organisations operationalise NHI ownership at scale?