Who is accountable for unapproved software discovered during an audit?

How accountability should be assigned for unapproved software

Unapproved software is usually a governance and ownership problem before it is a technical one. The right accountability model separates who introduced the application, who operates or administers it, and who owns the inventory and control process. That split matters because remediation decisions, exception handling, and retirement actions fail when responsibility is assumed rather than explicitly assigned.

Business accountability belongs to the team that needed the software and asked for it, because that group can explain the use case, accept or reject the business need, and fund a replacement if required. Technical accountability belongs to the system or application owner, because that role can assess exposure, verify where the software runs, and execute removal, isolation, or hardening. Governance accountability belongs to the inventory or control function, which should track the finding to closure and prevent it from becoming a recurring exception.

In practice, the audit finding should map to named owners, not to a generic department. If the software was installed by a project team, shadow IT group, or an outsourced function, the same principle applies: the sponsoring business unit owns the justification, the technical custodian owns the environment, and the governance function owns the record of decision and follow-up.

Why audits fail when ownership is unclear

Audit findings become repetitive when no single party can answer three questions: why the software exists, who can change or remove it, and who is tracking the exception. That gap turns a one-time discovery into a standing exposure, because the organisation keeps the software but never completes the decision cycle. Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful here because it frames auditability, ownership, and inventory discipline as control issues, not just documentation tasks.

Unclear accountability also creates control drift. Software can remain installed after the original need disappears, after vendor support lapses, or after a project changes hands. At that point, the finding is not just “unauthorised software,” it is unresolved authority over whether the software should stay, be replaced, or be retired.

Where the software touches regulated data, privileged access, or production systems, the accountability problem becomes more serious. A team may be willing to keep the tool, but another team may inherit the risk, so the audit trail must show who accepted that exposure and on what basis.

What the accountable owner must be able to decide

Accountability is only useful if it connects to a decision. The business owner should be able to confirm whether the software still supports an approved activity. The technical owner should be able to confirm what the software accesses, what dependencies it has, and whether it can be removed safely. The governance function should be able to confirm whether the software is recorded, reviewed, exceptioned, or escalated.

The strongest operating model is a simple decision chain: validate business need, verify technical risk, then record disposition. That disposition is usually one of three outcomes, remove it, approve it with controls, or grant a time-bound exception while a replacement or retirement plan is completed. SOC 2 Trust Services Criteria (AICPA) is a useful external reference because it reinforces the need for control ownership, monitoring, and evidence that exceptions are managed rather than left open-ended.

What matters most is that the accountable party can produce evidence of decision-making. If no one can explain who approved the software, who reviewed it, and when it will be revisited, then the organisation does not have accountability, it has a blind spot.

Practitioner Guidance

What to verify: Confirm that every unapproved application has three named owners in the record: business sponsor, technical custodian, and governance owner. If any one is missing, treat the finding as unresolved rather than closed.

Decision rule: If the software is required for a live business process, keep the business owner on the hook for justification and the technical owner on the hook for containment or remediation. If it is not required, move directly to retirement and do not let the item sit in an indefinite exception queue.

What practitioners underestimate: The main failure is not discovery, it is orphaning. Once ownership is fuzzy, the audit finding survives personnel changes, project closure, and tool sprawl, which is why clear disposition dates matter as much as the original finding.

Practitioner takeaway: Unapproved software should never be “owned by audit”; it should be owned by the business that wanted it, the technical function that operates it, and the governance function that keeps the decision visible until closure.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Who is accountable when endpoint compliance fails during an audit?
• Who is accountable when identity governance evidence is incomplete during an audit?