Accountability sits with the teams that approved the business process, the owners of the unsanctioned tool, and the identity governance function that failed to detect the gap. If access was never inventoried, no one can prove it was properly governed. That makes ownership and evidence retention essential.
Why This Matters for Security Teams
Shadow IT changes the accountability question because risk is created outside the normal intake, approval, and review paths. When a business unit adopts an unsanctioned app, the access model often expands through service accounts, API keys, and delegated permissions that never enter the identity governance workflow. That leaves security teams with exposure but no clean owner, which is exactly where auditability breaks down.
This is not a minor process issue. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and only 5.7% have full visibility into their service accounts, according to Ultimate Guide to NHIs. Once a shadow tool is connected to production data or SaaS workflows, the access risk becomes shared across procurement, app ownership, security, and identity governance. Current guidance from NIST Cybersecurity Framework 2.0 still puts clear ownership and asset visibility at the centre of risk management. In practice, many security teams discover the ownership gap only after access sprawl, leaked secrets, or an incident review has already exposed it.
How It Works in Practice
Accountability should follow the path of decision and control, not just the path of technical ownership. The team that approved the business process owns the business risk, the tool owner owns the configuration and lifecycle of access, and identity governance owns the control failures if inventory, review, or revocation did not catch the exposure. That model is consistent with the governance emphasis in the OWASP Non-Human Identity Top 10, especially where unmanaged credentials and overprivileged non-human identities create hidden attack paths.
In practice, the answer depends on whether the shadow app was merely unapproved or actively unmanaged. If the organisation knew about the tool and failed to register its access path, the control gap sits with governance. If a department bypassed intake entirely, business leadership still carries accountability for introducing the risk, even if IT had no prior visibility. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that identity exposure is rarely isolated to one control failure; it usually involves weak inventory, weak secret handling, and weak offboarding at the same time.
- Inventory every app that can create tokens, service accounts, or delegated access.
- Assign a named business owner and a named technical owner for each tool.
- Record what data the tool can reach, which identities it uses, and when access must expire.
- Require evidence of review for every exception, not just verbal approval.
- Revoke or rotate credentials when a tool is abandoned, replaced, or found to be unsanctioned.
These controls tend to break down when shadow IT is embedded in line-of-business automation, because the app is treated as a productivity dependency long before anyone documents who is accountable for its access.
Common Variations and Edge Cases
Tighter access governance often increases operational friction, requiring organisations to balance speed for the business against proof of control. That tradeoff becomes sharper when the shadow tool is low-code, SaaS-based, or attached to a third-party integration that multiple teams depend on.
There is no universal standard for this yet, but current guidance suggests a simple rule: if a team can create credentials, connect to production data, or impersonate a user, it cannot be “unowned” just because it sits outside the central IT catalog. In mixed environments, accountability may be shared, but evidence must still be singular and testable. That means the owner of the process must be identifiable, the owner of the tool must maintain access records, and security must be able to prove review, revocation, and exception handling. For broader identity governance context, NHIMG’s Top 10 NHI Issues and the control priorities in Ultimate Guide to NHIs help anchor that ownership model.
Edge cases also matter. A contractor-managed SaaS app may be contractually owned by procurement but operationally controlled by a department. A shadow workflow inside a sanctioned platform may inherit platform trust while still bypassing data access review. In both cases, the risk is not merely that the tool is unofficial, but that nobody can show who approved the access path or when it was last reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Shadow IT becomes risky when assets and owners are not inventoried. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Unmanaged service accounts and keys are the core shadow-IT access risk. |
| NIST AI RMF | GOVERN | Accountability for unapproved tools depends on clear governance and oversight. |
Maintain a complete inventory of apps, identities, and owners before access is granted.
Related resources from NHI Mgmt Group
- Why do shadow IT apps create identity risk even when users still have valid SSO access?
- Who is accountable if an MSP onboarding workflow creates excessive access?
- Who should be accountable when automated provisioning creates unauthorised access?
- Why do shadow IT and SaaS sprawl create access risk for MSPs?
