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

The processor remains accountable to the controller for the sub-processor’s activities. Under GDPR, a processor may outsource only with prior written authorisation from the controller, and the same data protection obligations must flow down contractually. If that chain is broken, accountability does not disappear. It stays with the processor, while the controller still retains oversight duties.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while GDPR, ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	Art. 28 — Processor	The question turns on processor authorisation and sub-processor accountability under GDPR processing rules.
Recommendation — Require prior written authorisation and equivalent sub-processor obligations before any downstream processing begins.
ISO/IEC 27001:2022	A.5.19 — Information security in supplier relationships	Unauthorised sub-processing is a supplier-governance failure involving outsourced processing risk.
Recommendation — Control supplier access and subcontracting through approved terms, monitoring, and review.
NIST SP 800-53 Rev 5	SR-5 — Acquisition Strategies, Tools, and Methods	Outsourcing decisions must preserve control over external service relationships and requirements flow-down.
Recommendation — Specify security and privacy requirements for outsourced processing and verify they flow to subcontractors.
SOC 2 (AICPA)	CC9.2 — Vendor and Third-Party Risk Management	The scenario concerns third-party processing oversight and contractual control of downstream providers.
Recommendation — Review third-party authorisation and monitor subcontractors for compliance with committed controls.