Who is accountable when a service provider cannot demonstrate adequate controls over customer data?

The service provider is accountable for operating and proving the controls it claims to have in place. Customers remain responsible for their own vendor due diligence and risk decisions, but they should expect clear evidence for security, availability, confidentiality, and privacy. If the provider cannot demonstrate control effectiveness, that becomes a governance and procurement risk.

Why This Matters for Security Teams

Accountability is not optional when a service provider handles customer data. If the provider cannot show that security, availability, confidentiality, and privacy controls are operating effectively, the issue moves beyond a technical gap and becomes a governance failure. Customers can outsource processing, but they cannot outsource the need for evidence, especially where procurement, privacy, and incident response decisions depend on it.

This is why due diligence has to be evidence-led, not trust-led. The NIST SP 800-53 Rev 5 Security and Privacy Controls model is helpful here because it frames controls as something that can be assessed, tested, and monitored over time rather than assumed. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that weak control evidence often reflects weak operational visibility, not just weak policy wording.

In practice, many security teams discover the absence of control proof only after a contract dispute, audit finding, or data incident has already exposed the gap.

How It Works in Practice

The provider is accountable for operating the controls it claims and for producing evidence that those controls are working. That evidence usually includes policy documents, control test results, audit reports, logging coverage, incident handling records, and proof of access restrictions. Customers remain accountable for their own risk acceptance, but they should not accept vague assurances where the provider cannot demonstrate control effectiveness.

Good practice is to ask for evidence mapped to a recognised control baseline, then test whether the evidence matches the service actually being delivered. For example, a provider that claims strong identity controls should be able to show NIST control families for access enforcement, logging, configuration management, and incident response. Where customer data is exposed through APIs, integrations, or service accounts, the same expectation applies to non-human identities: proof of rotation, scope limitation, and revocation. NHIMG’s Ultimate Guide to NHIs is useful here because it ties control failures to the operational realities of secrets sprawl, overprivilege, and poor lifecycle management.

• Require control evidence before onboarding, not after the first review cycle.
• Map provider claims to specific security and privacy controls.
• Verify that monitoring, logging, and incident reporting are contractually defined.
• Check that third-party and subcontractor access is covered in the same evidence set.

This matters because breach patterns often start with ungoverned credentials and weak provider visibility, as seen in incidents such as the JetBrains GitHub plugin token exposure and the Vercel Context.ai OAuth Supply Chain Breach. These controls tend to break down when the provider’s delivery model changes faster than its control testing and customer notification process.

Common Variations and Edge Cases

Tighter contractual control requirements often increase procurement friction, requiring organisations to balance faster onboarding against stronger assurance. That tradeoff becomes more visible in shared responsibility models, managed services, and cloud platforms where some controls sit with the provider and others remain with the customer.

There is no universal standard for every scenario, but current guidance suggests the accountability question should follow two tests: who operates the control, and who must prove it to the customer or regulator. If the provider subcontracts processing, accountability does not disappear. It extends to the downstream service chain, which means due diligence must include subcontractor coverage, data residency, access paths, and incident notification terms. For customer data governed by privacy obligations, proof of control effectiveness should also cover retention, deletion, and lawful processing boundaries.

A common failure mode is assuming a certification or attestation is enough on its own. It is helpful, but it is not the same as operational evidence tied to the specific service, tenant, and data flow in question. The strongest programs treat provider accountability as a living assurance process, not a one-time procurement checkbox. When providers cannot demonstrate control maturity, the risk is not theoretical: it usually shows up in exposed secrets, mis-scoped access, or delayed incident detection.

Related resources from NHI Mgmt Group

• Who is accountable when Essential Eight maturity evidence cannot stand up to an audit or customer review?
• Who is accountable when a service account breach exposes customer data?
• Who is accountable when a customer account is taken over despite controls?
• Who is accountable when an organisation cannot prove control over AI data flows during ISO 42001 certification?