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.
Why This Matters for Security Teams
The accountable party is rarely the SaaS vendor. It is the organisation that approved the integration, failed to track it, or never completed offboarding. When a SaaS app still retains access to sensitive health data after it is no longer used, the issue is usually broken identity governance, not just forgotten software. That creates exposure across compliance, privacy, incident response, and audit readiness.
This is especially important in environments where non-human identities outnumber human identities by 25x to 50x, as noted in the Ultimate Guide to NHIs by NHI Mgmt Group. If ownership is unclear, deprovisioning stalls and stale access persists long after business need ends. The OWASP Non-Human Identity Top 10 treats over-permissioned and unmanaged machine access as a recurring risk, which maps directly to abandoned SaaS integrations holding health data.
In practice, many security teams discover lingering access only after a data review, offboarding event, or incident has already exposed the gap.
How It Works in Practice
Accountability should follow control ownership. If a SaaS app connects to sensitive health data, the business owner, application owner, IAM team, and data steward all have defined duties, but one function must be explicitly responsible for the full lifecycle: approval, review, monitoring, and removal. Current guidance from NIST SP 800-53 Rev. 5 Security and Privacy Controls supports this through access enforcement, account management, and audit logging expectations.
Operationally, teams should map every SaaS integration to a named owner, an expiry or review date, and a documented revocation path. The Ultimate Guide to NHIs – Key Challenges and Risks highlights how poor visibility and stale credentials turn routine tooling into persistent exposure. For health data, the practical sequence is:
- Discover all connected SaaS apps, including shadow IT and delegated integrations.
- Confirm which datasets each app can reach and whether that access is still justified.
- Assign a single accountable owner for decommissioning, not just usage review.
- Revoke tokens, keys, OAuth grants, and API access, then verify the removal.
- Retain evidence for audit and incident response.
Teams should also align this with access recertification and offboarding so that unused apps do not survive beyond their business purpose. These controls tend to break down in federated SaaS environments where app ownership is distributed across departments and no one has end-to-end authority to revoke access.
Common Variations and Edge Cases
Tighter revocation control often increases operational overhead, requiring organisations to balance fast removal against business continuity and support burden. That tradeoff matters most when a SaaS app is shared across teams, embedded in a workflow, or connected through delegated admin rights.
There is no universal standard for this yet, but current guidance suggests treating abandoned SaaS access to sensitive health data as a lifecycle failure with shared accountability and a clear primary owner. If a third party administers the app, the organisation still remains accountable for the data exposure risk, while the vendor is accountable for contractually defined service behaviour. The key distinction is that outsourcing the tool does not outsource the obligation to remove access.
Edge cases also arise when the app is inactive but the credentials remain valid, when the integration is forgotten during employee turnover, or when a business unit reuses an old approval without fresh review. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why stale access persists. In those cases, the safer default is to assume access remains active until verified otherwise, then document the revocation and owner reassignment trail.
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 and CSA MAESTRO 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Stale SaaS access is often caused by missing lifecycle rotation and revocation. |
| NIST CSF 2.0 | PR.AC-1 | Covers identity and access governance for lingering SaaS permissions. |
| NIST AI RMF | Accountability and governance are central when systems retain unwanted access. | |
| CSA MAESTRO | Shared responsibility matters when SaaS apps and integrations outlive business need. |
Document ownership, review cadence, and removal authority for every SaaS integration.
Related resources from NHI Mgmt Group
- What breaks when organisations try to secure SaaS access with MFA after the app inventory is already fragmented?
- 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?
