Who is accountable when a processor uses a sub-processor without proper authorisation?

What Accountability Means When a Processor Outsources Without Permission

The accountability question is usually sharper than the contractual breach question. A processor that uses a sub-processor without proper authorisation has stepped outside the controller-approved processing chain, but that does not transfer responsibility away from the processor. The controller still has oversight duties, yet the processor remains the party answerable for the unauthorised downstream processing relationship.

In practice, the key issue is not whether the sub-processor is visible in the stack, but whether the processor preserved the controller’s authorisation conditions and the same data protection obligations in the subcontracting chain. Where those conditions are missing, the processor cannot treat the sub-processor’s conduct as someone else’s problem.

Why Prior Authorisation and Flow-Down Obligations Matter

Under GDPR-style processor governance, authorisation is not a formality. It is the control that keeps delegated processing within the controller’s risk appetite and makes sure the processor does not quietly expand the processing network without approval. A processor that skips this step breaks the trust boundary the controller relied on when appointing it.

The contractual flow-down is equally important because it is what preserves enforceability. If the sub-processor is not bound to equivalent obligations, the controller may lose practical assurance over security, confidentiality, deletion, assistance, and incident handling. That is why this topic aligns closely with IAM and IGA Basics and Ultimate Guide to NHIs, Regulatory and Audit Perspectives, because both stress governed delegation, oversight, and auditability in access chains.

For the same reason, modern authorisation models matter here. The controller is effectively deciding who may act on the data, through which chain, and under what constraints. Authorisation Models Guide is useful because it frames permission decisions as a control problem, not just a contract clause.

How Liability and Oversight Split Between Controller and Processor

Accountability does not vanish because the processor failed to ask permission. The processor remains accountable for its own compliance failure, and for the sub-processor’s activities insofar as they were introduced into the processing chain by the processor. The controller still retains oversight duties, including setting the rules for outsourcing and verifying that the processor can demonstrate compliance.

This is also why lifecycle discipline matters. If the subcontracting relationship is not inventoried, reviewed, and monitored, the controller may not know where data flows, while the processor may not know which obligations are now being breached. The result is a governance gap, not a transfer of blame. NHI Lifecycle Management Guide covers that governance pattern well, especially the need for visibility, ownership, and controlled offboarding in delegated access chains.

Where the processor has also introduced unnecessary privilege or broad access to the sub-processor, the issue becomes more than a paperwork failure. It becomes an access governance problem with a larger blast radius. That is the same control logic discussed in Top 10 NHI Issues and in Ultimate Guide to NHIs, Key Challenges and Risks, where over-privilege and unmanaged delegation increase exposure.

What Practitioners Should Check First

First, verify whether prior written authorisation existed for the exact sub-processing arrangement, not a generic vendor approval. Then confirm that the contract chain included equivalent security and privacy obligations, retention rules, incident reporting, and deletion requirements. If either condition is missing, treat the arrangement as a governance failure requiring immediate review.

Second, determine whether the unauthorised sub-processor actually handled personal data, had production access, or could influence processing outcomes. That distinction matters because pure administrative non-compliance and substantive data exposure are not the same operational problem. If the sub-processor had access to sensitive production systems or data, the response should prioritise containment and assurance before negotiating contractual fixes.

Practitioner takeaway: Do not let an unauthorised sub-processor become a shared responsibility fog. The processor remains the accountable party for introducing the downstream processor, while the controller’s oversight duty is to detect, challenge, and control that delegation path.

Related resources from NHI Mgmt Group

• Who is accountable when a contractor uses a shadow SaaS app without MFA?
• Who is accountable when a high-risk relationship is approved without proper EDD?
• Who is accountable when seized digital assets are moved without authorisation?
• Who is accountable when payment page scripts are altered without authorisation?