Developers should be accountable for the quality of new code they write, because they control those changes directly. Management should be accountable for decisions about old code, since those choices involve business risk, prioritisation, and resourcing across the portfolio. That split avoids blame shifting and makes ownership align with practical control over the work.
How accountability should split between new code and old code
Accountability should follow control over the work. New code is best owned by the developers writing it, because they choose the design, implementation, tests, and trade-offs that determine its quality. Old code is different: the main decision is not how to author it, but whether to keep, fix, replace, or accept it. That makes the accountability for legacy code a management responsibility tied to business priority and risk tolerance.
This split matters because “quality” means something different in each context. For new code, quality is primarily about correctness, maintainability, testability, and adherence to standards at the point of creation. For old code, quality is often bounded by accumulated technical debt, operational constraints, and the cost of change. A single ownership model for both usually creates confusion, especially when teams use blame instead of decision rights.
The practical test is simple: if the team can directly change the code, it should be accountable for the code’s quality. If the team must decide what to invest in, defer, or retire, accountability sits with the people controlling prioritisation and resources. That keeps accountability aligned with action, not with hindsight.
Why old code needs management accountability
Legacy code usually carries hidden trade-offs that no individual developer can resolve alone. It may be expensive to refactor, risky to change, or deeply coupled to other systems. In those cases, the right question is rarely “why is this code still messy?” and more often “what level of risk are we willing to carry, and what work will we fund to reduce it?” That is a management decision, not a developer blame exercise.
Management accountability also helps prevent organisational drift. If nobody owns the decision to leave old code in place, technical debt becomes an invisible tax that accumulates until it affects reliability, security, and delivery speed. Good management ownership means making those trade-offs explicit, documenting the rationale, and setting a horizon for remediation or retirement.
That does not mean developers are exempt from commenting on legacy problems. They should still surface defects, explain constraints, and estimate the impact of change. But they should not be made personally accountable for strategic decisions about code they did not author and cannot safely rewrite without support.
Why new code should stay with the engineers who wrote it
New code quality belongs to the people who introduced the change because they are the ones with the best context on intent, edge cases, and implementation details. They are also the only people who can reasonably be expected to defend design choices, add tests, and fix defects discovered shortly after release. If accountability is moved away from the author too early, the organisation loses the strongest feedback loop in engineering.
This does not mean every defect becomes a personal failure. Complex systems fail for many reasons, including unclear requirements, weak review processes, or missing guardrails. But the authoring team still owns the initial quality bar: readable code, adequate coverage, safe deployment, and quick correction when something slips through. That ownership encourages better engineering habits without turning every issue into a blame event.
The healthiest model is one in which engineers own the quality of the code they create, while the organisation provides the standards, tooling, and review processes that make that ownership realistic. Accountability without authority is unfair, and authority without accountability is ineffective.
What this split changes in practice
Once the ownership line is clear, teams can stop arguing about who “caused” the problem and start deciding who can best resolve it. New-code defects should flow into the development team’s normal quality process. Old-code issues should be handled as portfolio decisions: remediate, isolate, tolerate, or retire, depending on risk and value.
That distinction also improves reporting. Metrics for new code should focus on build quality, escaped defects, review discipline, and test coverage trends. Metrics for old code should focus on risk exposure, change failure rate, operational fragility, and backlog burn-down against agreed priorities. If the same metric is used for both, the organisation usually ends up measuring the wrong thing.
The most useful governance habit is to make ownership visible in the decision record. When a legacy issue remains unresolved, the record should show who accepted the risk, why it was accepted, and when it will be revisited. That prevents ambiguity later when the same issue reappears in a different form.
Risk and Threat Considerations
When accountability is blurred, organisations tend to underinvest in legacy remediation and over-assign blame after defects appear. That creates two risks at once: old-code risk becomes normalised, and new-code quality is treated as a moral issue instead of an engineering one.
Failure mechanism: Legacy defects persist because no one is empowered to fund change, while developers are judged on outcomes they did not control. Over time, the organisation accumulates technical debt, operational fragility, and avoidable exposure to failure.
Impact: The result is slower delivery, more production incidents, weaker security posture, and poorer decision-making about where engineering effort should go. Clear accountability reduces both blame shifting and the probability that important remediation is perpetually deferred.
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 governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Legacy code decisions are risk acceptance and prioritisation decisions. |
| GV.RR-01 — Roles, Responsibilities, and Authorities | The question is fundamentally about assigning accountability to the right decision-maker. | |
| Recommendation — Define who accepts residual risk for legacy code and how remediation is prioritised. Assign code-quality ownership to engineers and legacy-risk ownership to managers. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | New code quality depends on controlled, reviewable baselines and change discipline. |
| Recommendation — Establish controlled baselines for new code and review changes before release. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | New-code quality is driven by secure, well-managed software delivery practices. |
| Recommendation — Embed review, testing, and defect management into the software delivery process. | ||
Practitioner Guidance
Decision rule: Assign quality accountability to the team that directly controls the code change, and assign legacy-code risk acceptance to the management layer that controls prioritisation and funding.
What to verify: For new code, verify that the owning team can explain tests, review standards, and release criteria. For old code, verify that there is a named decision owner for remediation, exception acceptance, or retirement.
Common mistake: Treating all code quality problems as developer failures. That approach usually hides portfolio debt, delays remediation, and makes it harder to distinguish execution issues from resourcing decisions.
Practitioner takeaway: Accountability should mirror control: engineers own the quality of what they create, while management owns the risk decisions for what the organisation chooses to keep.
Related resources from NHI Mgmt Group
- Why do AI agents create new AppSec risk even when code quality improves?
- What breaks when teams do not define new code boundaries before enforcing quality gates?
- How should teams implement quality gates for new code without blocking every release?
- What is the difference between cleaning up old code and enforcing Clean as You Code on new code?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
