Accountability sits with the organisation that owns the inventory, access reviews, and decommissioning process. If an unused app remains connected to sensitive data, teams should treat it as a control failure in SaaS governance, not an isolated user mistake. Clear ownership, continuous discovery, and documented removal steps are necessary to prevent lingering access.
Who Owns Lingering SaaS Access to Health Data?
When a SaaS application keeps access to sensitive health data after it is no longer used, accountability is organisational rather than accidental. The owner of the application inventory, access review process, and decommissioning workflow is responsible for making sure the connection is removed, revoked, and verified. The practical question is not who clicked the wrong button, but who had the duty to detect the orphaned access path and close it.
For health data, that distinction matters because lingering access can outlive the business need that justified it. If a tool is retired, repurposed, or quietly abandoned, the exposed data relationship can remain active unless someone owns lifecycle control end to end. For a broader governance view of orphaned non-human access, see the OWASP Non-Human Identity Top 10. In practice, many security teams discover this only after a SaaS renewal, contract review, or incident review exposes that the data connection was never formally removed.
What the Accountability Chain Looks Like in Practice
Accountability usually spans more than one team, but it should not become ambiguous. Security may define the control expectation, application owners may confirm business need, IAM or platform teams may execute revocation, and governance or privacy teams may require evidence that the data path was closed. What matters is that one function is clearly answerable for the full lifecycle, including discovery, review, removal, and verification. If ownership is split across too many teams, the most common failure is that everyone assumes someone else closed the loop.
In a SaaS environment, lingering access often persists because inventory is incomplete, access reviews focus on active users rather than connected apps, or decommissioning is treated as a procurement task instead of a security task. The safer model is to treat every external integration as a controlled entitlement with an owner, an expiry condition, and a retirement record. That record should show when the application stopped being used, who approved removal, what was disconnected, and how the team verified that the data access path no longer functioned.
- Keep a current inventory of apps connected to sensitive health data.
- Require named ownership for review and removal decisions.
- Verify revocation, not just request it.
- Track retirement as part of the access lifecycle, not as an afterthought.
Where this guidance breaks down is when the organisation cannot prove which systems still hold the connection, because then accountability exists on paper but not in control evidence.
When Lingering Access Becomes a Governance or Security Problem
Tighter access control often increases operational overhead, so organisations have to balance administrative effort against the risk of leaving dormant SaaS connections in place. The issue becomes material when the app can still read, sync, export, or cache sensitive health data after it has ceased to serve a business purpose. At that point, the concern is no longer just poor housekeeping. It becomes a control weakness that can affect confidentiality, auditability, and compliance expectations.
There are also edge cases. A vendor-managed connector may look inactive in the business workflow while still retaining API access, and a temporary pilot tool may be forgotten after the pilot ends. Industry practice is clear that these should be retired quickly, but the exact division of duty between procurement, security, and business owners is not always standardised, so organisations should document it explicitly rather than assume consensus. If an app is genuinely no longer used, the correct test is whether the organisation can show that data access was removed and the removal was checked, not whether the app still happens to be installed somewhere.
The most reliable governance pattern is to tie access ownership to an explicit end-of-use decision, because that is the point at which orphaned access becomes foreseeable rather than surprising.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Lingering SaaS access is an orphaned non-human access lifecycle problem. |
| NHI-02 — Secrets and Credential Management | Unused apps may retain tokens, keys, or delegated credentials after retirement. | |
| NHI-05 — Lifecycle and Decommissioning | The core issue is failure to retire access when the app is no longer used. | |
| Recommendation — Assign ownership and maintain an inventory of every SaaS-to-data access path. Revoke unused credentials and verify the SaaS app can no longer authenticate. Remove the app’s access during decommissioning and retain proof of revocation. | ||
| CIS Controls v8 | 5 — Account Management | Persistent app access reflects weak control over active entitlements and removal. |
| 6 — Access Control Management | The question centers on who controls and revokes access to sensitive data. | |
| Recommendation — Review and remove inactive app entitlements before they remain overexposed. Enforce least-privilege access and promptly revoke unnecessary data permissions. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Lingering SaaS access is an access-control failure affecting sensitive health data. |
| GV.RM — Risk Management Strategy | Accountability depends on governance for lifecycle risk and control ownership. | |
| ID.IM — Improvements | Recurring orphaned access indicates a need to improve discovery and decommissioning controls. | |
| Recommendation — Limit and revoke access paths that no longer support a business need. Assign risk ownership for SaaS lifecycle decisions that affect sensitive data exposure. Use recurring review findings to improve decommissioning and access-removal controls. | ||
Practitioner Guidance
What to prioritise: Treat the retirement of the app and the revocation of its data access as one control event. If those two actions are owned separately, define which team signs off that the connection is gone and which team keeps the evidence.
What to verify: Confirm that “unused” means more than no one logging in. A practitioner should verify active tokens, API grants, service accounts, sync jobs, cached exports, and any delegated access still tied to the SaaS app.
Common mistake: Assuming procurement closure, contract termination, or user offboarding automatically removes access. Those events may end usage, but they do not prove revocation.
Practitioner takeaway: The accountability risk is usually not the missing technical action itself, but the missing ownership boundary that lets an old SaaS connection survive long after the business case has ended.
Related resources from NHI Mgmt Group
- Who is accountable when a leaver still has SaaS access after offboarding?
- Who is accountable when former employees still have SaaS access after offboarding?
- Who is accountable when SaaS access persists after a tool is no longer needed?
- Who is accountable when a mobile app passes audit but still leaks sensitive data at runtime?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
