Accountability should sit with both the business owner and the security function, but the business cannot own risk in isolation. Security teams need standards for approval, monitoring, and decommissioning, while business leaders should justify the need for each tool and its data access. Shared accountability is the only workable model when adoption happens outside central procurement.
Why Shared Accountability Matters When Teams Self-Adopt SaaS
When business teams can buy and connect apps without central procurement, accountability becomes a governance problem as much as a technical one. The core issue is not just who approved the app, but who owns the ongoing risk created by data sharing, delegated access, and lifecycle drift. Security teams need to define the guardrails, while business leaders need to defend the business purpose and accept the operational impact of the choice. For a practical identity and access perspective, the OWASP Non-Human Identity Top 10 is useful because third-party integrations often rely on tokens, service accounts, and API credentials that outlive the original approval.
In practice, many security teams encounter excessive integration risk only after a low-friction app has already accumulated broad access and no one can prove who is responsible for removing it.
How Accountability Should Be Split Across Business and Security
The accountability model works best when it separates decision rights from control ownership. Business owners should be accountable for the justification: why the tool is needed, what data it will touch, and whether the benefit is worth the exposure. Security should be accountable for the control plane: approval criteria, integration standards, monitoring, and retirement rules. That split matters because third-party integrations often bypass normal procurement review, but they still create the same exposure to overbroad permissions, data replication, and hidden persistence.
In practice, the security function should not be expected to discover every app after the fact. It needs a policy that defines which integrations are permitted, what evidence is required before approval, and which signals trigger review or revocation. Business teams should not be allowed to treat approval as a one-time event, because the risk changes when scopes expand, the vendor changes its terms, or the integration owner leaves.
- Business leaders own the request, the use case, and the business benefit.
- Security owns the standards for access, review, monitoring, and removal.
- Both sides share accountability when the app handles sensitive data or privileged workflows.
NIST SP 800-53 Rev 5 is relevant here because it treats access control, authorisation, and continuous oversight as institutional controls rather than one-off approvals. Where teams cannot explain who can revoke access, the accountability model has already failed. The point of shared accountability is to make the risk visible before integration sprawl turns into shadow access that nobody actively governs.
This guidance breaks down when organisations let local convenience override any minimum standard for data access or offboarding.
Where the Model Breaks Down in Real Organisations
Tighter autonomy for business teams often speeds adoption, but it also increases the chance that governance becomes fragmented, so organisations have to balance agility against control consistency.
The hardest edge case is not the app itself but the ownership of its ongoing state. A tool may be approved by one manager, connected by another, and used by a third team after a re-org. In that scenario, accountability can no longer rest on the person who first signed up for it. Guidance versus consensus is not settled on whether every integration needs identical controls, but it is broadly accepted that higher-risk data and broader scopes require stricter review than low-risk productivity apps.
Another common failure mode is assuming that procurement ownership equals security ownership. It does not. Procurement may validate commercial terms, but it rarely governs token scope, admin consent, or deprovisioning triggers. The same problem appears when a platform vendor offers an easy marketplace install: adoption friction drops, but control evidence often becomes thinner. Teams should treat that ease of adoption as a signal to tighten review, not relax it.
Where a third-party app can create or reuse non-human credentials, the accountability question becomes even sharper, because the security of the integration depends on how well those credentials are inventoried, constrained, and removed. If no named owner can answer those questions, the organisation is relying on hope rather than governance.
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 |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Third-party integrations create account and access paths that need ownership and revocation. |
| Recommendation — Enforce approval and revocation rules for every externally adopted integration. | ||
| NIST CSF 2.0 | GV.OV-01 — Oversight | Shared accountability depends on defined oversight for externally adopted apps and their risk. |
| PR.AA-01 — Identity Management, Authentication, and Access Control | Third-party integrations often rely on delegated access and non-human credentials. | |
| Recommendation — Assign governance oversight for app adoption, review, and decommissioning. Constrain integration access to the minimum scope and revoke stale credentials quickly. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Self-adopted apps often create unmanaged service accounts, tokens, and API keys. |
| NHI-03 — Privilege Minimisation | Business-led app adoption often over-grants access beyond the actual use case. | |
| Recommendation — Inventory every integration credential and assign a named owner for lifecycle control. Reduce each integration to the smallest permission set required for the business need. | ||
Practitioner Guidance
What to prioritise: Assign one business owner and one security owner for every integration, then make that ownership explicit in the approval record. If the app can touch customer, financial, or internal sensitive data, require an exception review rather than relying on informal sign-off.
What to verify: Confirm that the integration has a documented purpose, a defined data scope, and a revocation path. Security teams should be able to verify who can disable access, who is notified when ownership changes, and what event triggers a re-review.
Common mistake: Treating “approved once” as “safe indefinitely.” Third-party integrations drift as scopes expand, vendors change, and business owners move on, so accountability must include an ongoing review obligation, not just initial approval.
Practitioner takeaway: The safest model is not centralised control of every app, but centralised control of the rules and evidence that prove each app still deserves its access.
Related resources from NHI Mgmt Group
- How should security teams govern third-party apps that employees adopt without a formal security review?
- How should security teams make NHI best practices usable across the business?
- How should security teams govern third-party OAuth access for SaaS integrations?
- What do security teams get wrong about secrets in third-party code and integrations?
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
