Teams should prioritise new code first when the codebase already contains many bugs, vulnerabilities, or code smells. That approach avoids turning quality improvement into an endless remediation project. By keeping newly written code clean, organisations stop adding fresh debt while gradually improving the parts of the system they actively touch.
Why new code usually gets fixed first in a quality programme
When a codebase already has accumulated defects, the highest-leverage move is to stop creating more. New code is where the team still has the most control over design, testing, and review discipline, so quality work there compounds quickly. If every release adds fresh problems, legacy cleanup becomes a treadmill instead of a reduction strategy.
The practical reason is simple: newly written code is still changing, still owned, and still easier to shape than old code with uncertain dependencies. Fixing the active path also protects the parts users and operators are most likely to hit next, while reducing the chance that future work is built on top of a shaky foundation.
When legacy code should move ahead of new code
Legacy code can still deserve priority when it creates disproportionate operational or security exposure, especially if it sits on a critical path, handles sensitive data, or blocks the safe delivery of new work. A narrow, high-impact legacy fix can be justified when the defect is severe enough that leaving it in place would distort the whole quality programme.
The key distinction is between “old” and “high risk.” Old code that is stable, low change, and rarely touched may be a better candidate for deferred remediation than new code that is generating repeated defects. By contrast, legacy components with recurring incidents, brittle integrations, or repeated manual work often need a targeted intervention rather than a blanket deferment.
How to set the priority rule without creating a permanent backlog trap
The most defensible rule is to prioritise by current change activity and business exposure, not by age alone. If a defect is in code that the team is actively modifying, fix it as part of the current change stream. If the issue is in dormant code and does not materially affect reliability, security, or delivery speed, queue it behind the quality work that prevents new defects from entering the system.
That rule only works if teams keep a visible distinction between prevention and remediation. Prevention means better tests, reviews, and standards on new work. Remediation means deliberate, limited cleanup of legacy hotspots. When those two are blended, organisations either over-invest in low-value cleanup or let new defects accumulate faster than the programme can absorb them.
Risk and Threat Considerations
Deferring all legacy work can leave known weaknesses in place, but prioritising legacy indiscriminately can also drain capacity from the code that is still evolving. The real risk is uncontrolled defect accumulation: either the old estate becomes an accepted hazard, or the team spends so much time repairing history that current delivery quality keeps degrading.
Failure mechanism: Teams often let “technical debt” become an open-ended label, which turns quality work into a never-ending queue of old fixes and leaves no capacity to stop new defects from being introduced.
Impact: The programme loses momentum, defect density stays high, and the most active parts of the system continue to accrete risk even while older issues are being triaged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-6 — Access Control Management | Priority-setting for code quality often hinges on limiting exposure in active systems. |
| Recommendation — Focus remediation on the code paths that most affect active risk and exposure. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The question is about choosing a remediation strategy that balances new work and legacy risk. |
| Recommendation — Set a remediation strategy that prioritises the highest-current-risk code paths first. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | New-code-first prioritisation is a change-control decision about where quality effort is applied. |
| Recommendation — Apply change control to ensure quality fixes are prioritised where active change creates the most risk. | ||
Practitioner Guidance
What to prioritise: Treat new code as the default focus whenever the system is already carrying a meaningful defect load. Reserve legacy remediation for defects that are high severity, high exposure, or blocking safe change.
Decision rule: If a fix can be made in the same change set that introduced the new code, take it now. If the issue is older but materially affects a critical flow, escalate it as a targeted remediation item rather than folding it into broad cleanup work.
What to verify: Make sure the programme measures new defect arrival rate, not just backlog burn-down. If new defects are still rising, legacy work is not yet the main optimisation target.
Practitioner takeaway: Quality programmes fail when they confuse “important” with “old.” The best order is usually to stop the flow of new defects first, then use focused legacy work to remove the oldest high-impact risks.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- When should teams prioritise identity data cleanup over new IAM features?
- When should organisations prioritise code signing certificate renewal controls over new signing tooling?
- When should teams prioritise DAST over more source-code scanning?
