Accountability should sit with business and technology leadership together, because security is a business responsibility when technology is central to operations. The article says leaders must invest in modern security capabilities rather than treating legacy risk as purely technical. That means ownership for remediation, architecture change, and funding should be explicit, especially where outdated systems increase exposure across the enterprise.
Who should own the security debt created by aging critical systems?
When technical debt creates a security gap in critical infrastructure, accountability cannot sit with IT alone. The real owner is shared business and technology leadership, because the risk affects service continuity, safety, compliance and financial exposure. That shared accountability must be explicit, funded and tied to remediation decisions, not treated as an optional engineering cleanup.
Why accountability has to sit above the technology team
Technical debt becomes a security issue when outdated platforms, unsupported components or deferred patching increase exposure faster than the organisation can absorb it. In critical infrastructure, that is not just a maintenance problem. It changes the organisation’s risk posture, because legacy systems can widen the blast radius of outages, slow containment and leave security teams with fewer viable controls.
The right accountability model reflects that reality: technology leaders own the technical remediation plan, while business leaders own the risk acceptance decision, capital prioritisation and operating model changes needed to reduce exposure. If leadership treats legacy risk as a purely technical backlog, the organisation usually ends up with chronic underinvestment and a predictable gap between what is known and what is fixed.
For critical environments, this is especially important because availability and security are tightly coupled. A deferred upgrade can be a resilience issue first and a security issue second, but the consequence is the same, a system that is harder to defend, harder to recover and more likely to fail under pressure.
What explicit accountability looks like in practice
Accountability should be assigned to the business owner of the service and the technology owner of the platform, with clear executive sponsorship where the risk is material. That pairing forces decisions about remediation timing, compensating controls, funding and acceptable exposure to be made at the level where trade-offs can actually be approved.
Good ownership also means the organisation can answer three questions without ambiguity: who approves continued operation on the legacy stack, who funds the replacement or hardening work, and who is accountable if the exposure is accepted beyond the agreed period. Without those answers, technical debt stays invisible inside routine operations until an incident exposes it.
Where legacy systems support essential operations, the accountability model should also capture dependency risk across suppliers, integrators and control environments. A single outdated platform may appear local, but in practice it can carry authentication, access, monitoring or recovery assumptions that affect many downstream systems and teams.
For broader guidance on defensive posture in critical environments, CISA Industrial Control Systems resources are useful for understanding how operational technology security and resilience intersect. CISA also publishes cyber threat advisories that help leadership connect legacy exposure to current attack patterns.
When legacy debt becomes a governance problem, not just a technical one
The governance failure usually appears when organisations know a system is exposed but still lack a decision path for retiring, isolating or compensating for it. At that point, the real issue is not only technical weakness, it is the absence of explicit risk ownership, budget authority and escalation discipline.
That is why accountability should be written into service ownership, remediation milestones and exception handling. If a critical platform cannot be modernised immediately, leadership must still decide whether to segment it, restrict access, increase monitoring or accept the risk with a documented end date. Anything less turns “temporary” technical debt into permanent security exposure.
For infrastructure leaders, the strongest signal of maturity is not that all legacy systems disappear quickly. It is that every material exception has an owner, a funding path, and a dated decision for remediation or retirement, with no ambiguity about who carries the risk in the meantime.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Oversight of cybersecurity risk | Legacy security debt in critical infrastructure needs executive oversight and explicit risk ownership. |
| GV.RM-01 — Risk management strategy | The question is about who owns acceptance and reduction of material technical security risk. | |
| Recommendation — Assign executive oversight for legacy risk and track remediation decisions to closure. Include technical debt exposure in the organisation’s formal risk strategy and funding decisions. | ||
| NIST SP 800-53 Rev 5 | PM-4 — Plan of Action and Milestones Process | Deferred remediation of legacy gaps needs owned milestones, dates and accountability. |
| RA-3 — Risk Assessment | Critical infrastructure legacy exposure should be assessed for impact, likelihood and control gaps. | |
| Recommendation — Use a managed remediation plan with accountable owners and dated corrective actions. Assess legacy-system risk before accepting continued operation or delay. | ||
| ISO/IEC 27001:2022 | A.5.4 — Management responsibilities | This topic requires clear management ownership for security decisions and remediation funding. |
| Recommendation — Define management responsibility for security remediation and exception approval. | ||
Practitioner Guidance
What to prioritise: Start with the systems whose failure would affect safety, continuity or regulated services, then rank legacy exposures by blast radius rather than by age alone. A well-worn system with tight isolation is usually less urgent than a moderately old one that still has broad access or weak monitoring.
Decision rule: If a legacy component can still authenticate, route, control or recover critical services, treat it as an executive risk item, not an IT backlog item. If the organisation cannot commit to remediation, require a time-bounded exception with compensating controls and named ownership.
What to verify: Verify that the accountable business owner, technology owner and approver of risk acceptance are all named in the same remediation record. Also verify that the legacy asset inventory includes dependencies, support status and the specific control gap created by the debt.
Practitioner takeaway: The key mistake is assuming security debt can be delegated downward while the consequences remain strategic. In critical infrastructure, accountability must follow the risk, and the risk sits at the point where business continuity and technology design intersect.
Related resources from NHI Mgmt Group
- Who is accountable for closing the browser security gap between identity controls, SecOps, and incident response teams?
- Who is accountable for identity security in critical infrastructure resilience programs?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
