Who is accountable when third-party SaaS mishandles company data?

Why This Matters for Security Teams

Third-party SaaS changes the operating model, but it does not change the accountability model. When company data is uploaded, synced, indexed, backed up, or shared through a vendor platform, the customer still has to answer for classification, retention, access, residency, and incident response. That is why NHI Mgmt Group treats SaaS exposure as an identity and governance problem, not just a procurement issue.

The practical risk is that vendor controls often look stronger than they are. A contract may promise deletion, yet backups, replicas, analytics pipelines, subcontractors, and support tooling can keep data alive far longer than expected. The same pattern shows up in real incidents such as the Snowflake breach and the Salesloft OAuth token breach, where third-party access paths became the path to customer data. OWASP’s OWASP Non-Human Identity Top 10 is explicit that machine identities and vendor-issued credentials must be governed as attack surfaces, not trusted by default.

NHI Mgmt Group research shows that 92% of organisations expose NHIs to third parties, which makes this a common supply-chain exposure, not an edge case. In practice, many security teams learn the boundary of vendor accountability only after data has already moved into a backup, export, or support workflow that nobody on the customer side fully mapped.

How It Works in Practice

Accountability starts with deciding who owns the data flow, not who runs the SaaS. The customer should define the data purpose, approve the data types shared, and set the retention and deletion requirements before integration begins. The vendor then becomes a processor or service operator with specific obligations. That distinction matters because operational tasks can be delegated, but oversight cannot.

Security teams should map the full SaaS path: user-uploaded records, API ingests, delegated admin access, service accounts, tokens, backups, logs, support exports, and subcontractor touchpoints. For each path, the organisation should know who can access it, where it is stored, how long it persists, and how it is removed. This is especially important when the SaaS relies on non-human identities such as API keys, OAuth tokens, or service accounts. The Ultimate Guide to NHI highlights how long-lived secrets and excessive privileges create persistence that contracts alone cannot solve.

Practically, a mature control set includes:

• data processing agreements that name residency, breach notice, backup deletion, and subcontractor approval terms
• least-privilege SaaS access with time-bound tokens and revocation on role change or termination
• vendor inventory that records which datasets, secrets, and integrations each SaaS can reach
• evidence of deletion, not just a policy promise, including backup and replica handling
• regular review of logs, exports, and support workflows that may carry sensitive data outside the primary tenant

This aligns with current guidance from NIST’s AI Risk Management Framework on governance and with the operational expectations in the 52 NHI Breaches Analysis, where credential and access failures repeatedly outlast the initial compromise. These controls tend to break down when SaaS admins rely on shared tenant settings and cannot prove what happened to exported data after it left the primary application.

Common Variations and Edge Cases

Tighter SaaS governance often increases procurement friction and operational overhead, requiring organisations to balance speed of adoption against evidence of control. That tradeoff is real, especially when business teams buy tools first and ask security later. There is no universal standard for this yet, but current guidance suggests the customer should treat high-risk SaaS as a shared-responsibility environment with explicit proof requirements.

Edge cases usually appear when the vendor acts as a data processor, a subprocessor chain is involved, or the service supports customer-managed keys, delegated administration, or embedded AI features. In those situations, accountability is still anchored to the customer’s data decisions, but the evidence burden expands. Security teams should verify where the vendor can send data, whether training uses customer content, and whether support personnel can access production records. If the SaaS uses machine-to-machine integrations, the NHI problem becomes central again because tokens, certificates, and service accounts may persist long after a human owner has changed roles.

For that reason, third-party risk reviews should not stop at privacy terms. They should test operational realities such as export controls, backup deletion windows, incident notification timing, and revocation mechanics for non-human identities. NHI Mgmt Group research repeatedly shows that exposed third-party NHIs and weak offboarding create durable risk even after a vendor incident is “closed.”

Related resources from NHI Mgmt Group

• Who is accountable when a third-party verification provider mishandles identity data?
• What breaks when third-party SaaS access is never reviewed?
• When should organisations treat third-party SaaS access as privileged access?
• Who is accountable when unsanctioned SaaS stores sensitive business data?