Who should be accountable for unsupported business applications?

Why This Matters for Security Teams

Unsupported business applications are not just a technical debt problem. They create a governance gap where no one is clearly responsible for risk acceptance, remediation planning, or business justification. That gap becomes dangerous when the application supports customer workflows, contains sensitive data, or depends on hard-coded secrets and fragile integrations. Security can identify exposure, but only the business can decide whether continuity is worth the risk and cost of mitigation. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for defined accountability, risk treatment, and lifecycle oversight rather than informal tolerance. For teams managing identity-heavy systems, the broader NHI lifecycle issues described in Ultimate Guide to NHIs show how unmanaged ownership often correlates with stale credentials, missing offboarding, and weak visibility. In practice, many security teams encounter unsupported software only after a failed audit, a vendor shutdown, or a production incident has already forced the question of ownership.

How It Works in Practice

Operational accountability should follow business ownership, not infrastructure custody. The business owner is responsible for deciding whether the application is retired, replaced, isolated, or temporarily accepted with documented risk. IT operations can maintain uptime, and security can define minimum safeguards, but neither should inherit the authority to justify indefinite use on the business’s behalf. A workable process usually includes:

• a named executive or application owner with budget authority
• an inventory entry that records supported status, dependencies, and data classification
• a remediation or retirement deadline with measurable milestones
• a formal risk acceptance decision when support cannot be restored immediately
• compensating controls such as segmentation, tighter access control, logging, and backup validation

This is especially important when unsupported applications expose secrets, service accounts, or API keys. NHIMG’s research notes that only 20% of organisations have formal offboarding and revocation processes for NHIs, and the Ultimate Guide to NHIs highlights how weak lifecycle governance amplifies risk across the estate. Aligning this with NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate ownership into control responsibilities, evidence, and review cadence. These controls tend to break down when the application is embedded in a revenue-critical process and no single business unit wants to own the cost or disruption of replacement.

Common Variations and Edge Cases

Tighter accountability often increases short-term friction, requiring organisations to balance operational continuity against governance discipline. The main edge case is when an application is unsupported by the vendor but still essential and difficult to replace. In that situation, current guidance suggests the business owner should still own the risk, while technical teams document compensating controls and a sunset plan. There is no universal standard for this yet, but best practice is evolving toward explicit risk acceptance rather than silent exception handling. Another common case is outsourced or SaaS-adjacent tooling, where the business thinks procurement or IT owns the decision. That confusion should be resolved early, because a vendor relationship does not remove internal accountability for data use, access paths, or retention obligations. For identity-rich applications, unsupported status can also hide NHI issues such as stale service accounts and unreclaimed tokens, which are called out in the Ultimate Guide to NHIs. If the system touches regulated data or critical operations, the owner should be required to show both a remediation path and a fallback exit plan before the exception is renewed.

Related resources from NHI Mgmt Group

• Who is accountable when an unsupported system causes an incident?
• Who is accountable when business associates access ePHI without strong MFA?
• How should security teams make NHI best practices usable across the business?
• What is the difference between protecting applications and protecting access?