ISO 27701 A.2.5.7: Sub-processor Chain

Quick Reference (60 Seconds)

If you only read one thing: Controls A.2.5.7, A.2.5.8 and A.2.5.9 together form the sub-processor lifecycle, the static disclosure baseline, the engagement gate, and the dynamic change overlay. A conformant processor maintains a current sub-processor register disclosed proactively to every controller-customer; engages every new sub-processor through a documented due-diligence and authorisation procedure with a flow-down contract that mirrors the data-protection obligations the processor owes the controller; gives advance notice of every change so the controller has the window to object; handles objections through a defined workflow; re-assesses the chain transfer under Schrems II on every cross-border addition; and offboards sub-processors with certified data destruction. The certification auditor picks a recent vendor addition and walks the engagement, the disclosure and the change notification end-to-end. The Data Protection Board of India, after a chain incident, will ask whether the processor had the sub-processor under contract, whether the controller was disclosed and notified, and whether the flow-down terms bound the sub-processor to the safeguards that failed. Get the chain wrong, no register, no disclosure, no authorisation, no flow-down, no notice, no objection handling, and the processor's broader privacy claim is unsupported by the operational evidence the controller-customer's regulator, the processor's own regulator (RBI, SEBI, IRDAI), the certification body and the controller-customer (in any contractual indemnity dispute) now expect.

What the Standard Actually Requires

Figure · Process

What Clause A.2.5.7 asks you to do

The combined paraphrase

ISO/IEC 27701:2025 controls A.2.5.7, A.2.5.8 and A.2.5.9 ask PII processors to disclose to the controller the subcontractors they use to process the controller's personal data, to engage a new sub-processor only with the controller's prior authorisation (general or specific) and under a contract that imposes the same data-protection obligations the processor itself owes the controller, and to give the controller advance notice of any intended addition or replacement of a sub-processor so the controller has a defined window to object.

Three controls, one lifecycle. The controls are adjacent in theme A.2.5 (PII sharing, transfer and disclosure) for a reason, the standard's drafters intended them to be read together as the sub-processor governance regime. Treating them as three separate clauses is the first mistake most processors make.

Control A.2.5.7, Disclosure of subcontractors used to process PII

ISO/IEC 27701:2025 control A.2.5.7 asks PII processors to disclose to the controller the subcontractors (sub-processors) they use to process the controller's personal data. Four load-bearing ideas sit inside this control.

The processor must disclose. The verb is operational, the processor must make the sub-processor list available to the controller, not merely on demand but proactively through the channel the customer DPA specifies. The disclosure channel is typically a published URL (a sub-processor page on the processor's website), a controller-portal section, or a dated register delivered to the controller on request and on change. The disclosure must be current, a stale list is a non-disclosure.

The processor must disclose the subcontractors it uses to process the controller's personal data. \"Subcontractor\" (or \"sub-processor\", the terms are interchangeable in this guide) means any entity the processor engages to process the controller's personal data on the processor's behalf. The breadth matters: infrastructure sub-processors (the cloud provider hosting the data), service sub-processors (the email provider, the ticketing system, the support tooling), functional sub-processors (the analytics engine, the recommendation service, the payment rail, the KYC provider, the transcription service, the AI model provider), and people sub-processors (the BPO's own BPO, the development shop, the maintenance contractor). The processor's register must capture all four categories; the most common audit finding is the omission of the \"invisible\" sub-processors, the SDK vendors, the marketplace apps, the support-tooling providers, the cloud-provider sub-processors.

The disclosure must identify what the sub-processor does, where it does it, and on whose behalf. The minimum disclosure fields: the sub-processor's legal name and jurisdiction; the role or service provided; the nature of the processing; the data categories accessed; the processing location (the geography where the data is stored or accessed); the cross-border transfer mechanism (where applicable); the engagement start date; the current status. A register with names alone is not a disclosure, it is a phone-book.

The disclosure must be made available through the DPA's disclosure channel. The customer DPA specifies how the controller receives the disclosure, a published URL, a controller-portal section, a dated register delivered on request, a quarterly snapshot. The processor's disclosure discipline must execute the DPA's channel for each customer; a uniform published URL that the DPA does not reference is not the disclosure the controller agreed to.

Control A.2.5.8, Engagement of a subcontractor to process PII

ISO/IEC 27701:2025 control A.2.5.8 asks PII processors to engage a new subcontractor (sub-processor) to process the controller's personal data only with the controller's prior authorisation, general or specific, and under a written contract that imposes the same data-protection obligations the processor itself owes the controller. Five load-bearing ideas.

The processor must engage. \"Engage\" means to retain, contract with, or otherwise cause another entity to process the controller's personal data on the processor's behalf. The engagement is the formal act; the control tests the discipline behind the formal act.

The processor must engage only with the controller's prior authorisation. Two regimes. General authorisation, the controller pre-approves a class of sub-processors (a published list, a category, a quality tier) and the processor may engage within that class without per-engagement approval, subject to the change-notification duty (A.2.5.9) and the controller's objection right. Specific authorisation, the controller approves each named sub-processor individually, typically after reviewing the due-diligence pack. The customer DPA must state which regime governs; the engagement procedure must execute that regime. A controller's \"general authorisation with objection right\" is the GDPR Article 28(2) pattern and the most common arrangement in commercial SaaS and cloud DPAs.

The processor must conduct due diligence before engaging. The due diligence is the reasoned basis on which the processor selects the sub-processor, the security assessment, the privacy assessment, the legal assessment (the sub-processor's jurisdiction, the flow-down enforceability, the cross-border transfer mechanism), the financial and operational assessment, the reputation assessment. The due diligence is the evidence the processor relied on; it is the evidence the certification auditor and the controller's regulator will want to see after an incident.

The processor must engage under a written contract that imposes the same data-protection obligations. This is the Article 28(4) flow-down, the GDPR mechanism by which the sub-processor is bound by terms equivalent to those that bind the processor to the controller. The flow-down is not a paraphrase or a summary; it is the contractual mirroring of the data-protection obligations: the security safeguards, the breach-notification duty, the sub-processor-of-sub-processor regime (the chain continues), the return or deletion at end of engagement, the audit and inspection rights, the cooperation with rights requests, the cross-border transfer restrictions. A one-line confidentiality clause is not a flow-down.

The processor must engage with documented sign-off. The engagement record is the canonical evidence object, the due-diligence pack, the authorisation basis (general or specific), the controller notification (where the general-authorisation regime requires it), the flow-down contract execution, the onboarding sign-off, the register entry. The engagement record is documented information under Clause 7.5.

Control A.2.5.9, Change of subcontractor to process PII

ISO/IEC 27701:2025 control A.2.5.9 asks PII processors to give the controller advance notice of any intended addition or replacement of a sub-processor so the controller has a defined window to object. Five load-bearing ideas.

The processor must give advance notice. \"Advance\" means before the change takes effect, the controller must have the window to object before the sub-processor starts processing. The notice window is typically specified in the customer DPA, 14 days, 30 days, 60 days; the processor's procedure must honour the longest window the DPA specifies (where the processor has customers with different windows, the longest governs the procedure). Notice after the fact is a non-conformity.

The processor must give notice of any intended addition or replacement. Both events trigger the notice: a new sub-processor added to the chain (addition), and an existing sub-processor replaced by another (replacement). The notice must identify the sub-processor, the role, the data categories, the processing location, the reason for the change, and the effective date. The notice must be sent through the DPA's notice channel (typically email to the controller's designated notice contact, or a controller-portal notification).

The controller must have a defined window to object. The objection right is the controller's voice in the chain, the controller may, within the notice window, object to the engagement on reasonable grounds (typically: the sub-processor does not meet the controller's security or privacy requirements; the sub-processor's jurisdiction introduces a transfer risk the controller cannot accept; the sub-processor is a competitor of the controller; the sub-processor has a history of incidents). The objection-handling discipline is the control's most-litigated element, see Section 7.4.

The processor must handle objections through a defined workflow. The options: decline to engage the sub-processor for that controller's data (the cleanest outcome, the controller's data does not flow to the sub-processor); restrict the sub-processor's role to non-objecting controllers (the commercial compromise, the sub-processor engages for other controllers but not for the objecting one); escalate through the DPA's dispute mechanism (typically a senior-management discussion, a contract amendment, or, at the extreme, the controller's right to terminate the DPA on the change). The processor cannot simply ignore the objection; the documented workflow is the control.

The processor must update the disclosure. The change notification is also a disclosure update, the published sub-processor list, the controller-portal view, the dated register must all reflect the addition or replacement. The disclosure-update discipline (A.2.5.7) and the change-notification discipline (A.2.5.9) interlock; the register is the single source of truth that feeds both.

The lineage, 2019 to 2025

The three 2025 controls have a clean ancestor in the 2019 edition. Under 27701:2019, the processor-side sub-processor provisions lived in clause 8 (the processor controls), the sub-processor engagement duty, the authorisation requirement and the change-notification duty tracked the GDPR Article 28(2) and Article 28(4) language. The 2025 consolidation restructures them as A.2.5.7, A.2.5.8 and A.2.5.9 inside theme A.2.5 (PII sharing, transfer and disclosure) of the single consolidated Annex A. The relocation is architecturally meaningful: the sub-processor chain is now positioned as a disclosure-and-transfer control, the sub-processor is a recipient of the controller's personal data, and the disclosure-to-the-controller, the lawful-basis-for-the-transfer, and the records-of-the-disclosure controls all apply alongside the engagement and change controls.

The 2025 edition also makes Annex B (implementation guidance) normative. The B.2.5.7 / B.2.5.8 / B.2.5.9 guidance explains how a processor should structure the sub-processor lifecycle, the register, the due diligence, the authorisation routing, the flow-down contract, the change-notification procedure, the objection-handling workflow. Auditors now test against Annex B explicitly; an audit that does not also walk through the B.2.5.x guidance is incomplete. The pre-2019 framing of \"tell the controller about your sub-processors\" is no longer sufficient; the processor must show the lifecycle behind the clause.

The five-phase lifecycle, preview; full methodology in Section 7

A conformant sub-processor programme runs five phases, and the Singahi five-phase sub-processor lifecycle (Section 7) operationalises them. The phases map to the certification auditor's examination moves, and each phase's evidence is testable.

1. Disclose (A.2.5.7), maintain the master sub-processor register; publish the controller-facing view through the DPA's disclosure channel; keep the register current on every change; reconcile the register with the vendor master, the engineering-integrations list, the cloud-provider sub-accounts.
2. Engage (A.2.5.8), run the due diligence on every prospective sub-processor; obtain the authorisation (general or specific); execute the flow-down contract; onboard with documented sign-off; register the sub-processor with the engagement record.
3. Monitor, ongoing oversight of the sub-processor's security posture, performance, incident history, and continued conformity with the flow-down terms; periodic re-assessment of cross-border sub-processors under Schrems II; the annual due-diligence refresh for high-risk sub-processors.
4. Change (A.2.5.9), give advance notice of additions and replacements; operate the objection-handling workflow through the notice window; update the disclosure; re-assess the chain transfer under Schrems II where the change is cross-border.
5. Offboard, terminate the engagement with documented notice; execute the data-return or data-destruction; obtain the certification of destruction; enforce the post-engagement obligations (confidentiality, audit cooperation, return-or-destruction certification); update the register.

The five phases are continuous, disclosure is the baseline that every engagement updates; monitoring is the steady state that every change disrupts; offboarding is the end-state that every engagement eventually reaches. The processor that treats the five phases as a project rather than a steady-state operation will have a stale register within twelve months.

Demarcations: A.2.5.7 / A.2.5.8 / A.2.5.9 vs the sibling controls; what is NOT required

Four demarcations matter.

A.2.5.7 vs A.2.5.4, Records of PII disclosures to third parties. A.2.5.4 governs the records of every disclosure of the controller's personal data to a third party; A.2.5.7 governs the specific case of sub-processors and the disclosure to the controller of the sub-processor list. A.2.5.4 is the broader record; A.2.5.7 is the specific controller-facing disclosure. The two interlock, the sub-processor register is both the A.2.5.7 disclosure artefact and a slice of the A.2.5.4 records.

A.2.5.8 vs A.2.2.5, Infringing instruction. A.2.2.5 governs the processor's refusal of infringing instructions from the controller; A.2.5.8 governs the processor's engagement of sub-processors. The two intersect when the controller instructs the processor to engage a sub-processor without following the A.2.5.8 procedure, an instruction to bypass the due diligence or the notice window is a textbook A.2.2.5 infringement and a textbook A.2.5.8 infringement.

A.2.5.9 vs Clause 6.3, Planning of changes. Clause 6.3 governs the PIMS-level change-management discipline; A.2.5.9 governs a specific change event, the addition or replacement of a sub-processor. The two interlock: the sub-processor change is a PIMS change under Clause 6.3, with the A.2.5.9 controller notification as an additional step.

What the three controls do NOT require. They do not require the processor to refuse to engage any sub-processor the controller objects to in the general-authorisation regime (the processor's options are broader, see Section 7.4). They do not require the controller's specific authorisation for every routine infrastructure sub-processor (the general-authorisation regime exists precisely for this). They do not require the processor to share the full due-diligence pack with the controller on demand (the processor may summarise; the DPA specifies what the controller receives). They do not require the processor to refuse a controller's instruction to engage a sub-processor \"immediately\", the processor may comply-with-conditions (the controller confirms the waiver in writing and accepts the consequences; see toolkit doc 08). They do not require the processor to take responsibility for the sub-processor's own sub-processors beyond the contractual chain (the flow-down requires the sub-processor to impose equivalent terms on its own sub-processors; the processor's liability runs through the chain but does not make the processor the sub-processor's sub-processor's operator).

The companion guidance, Annex B is normative in 2025

In 27701:2019 the implementation guidance lived in informative Annex F. In 27701:2025 the guidance lives in Annex B (Implementation Guidance for PII Controllers and Processors), and Annex B is normative. The B.2.5.7, B.2.5.8 and B.2.5.9 guidance explains how a processor should structure the sub-processor lifecycle, the register's minimum fields, the due-diligence checklist, the authorisation routing, the flow-down contract's mandatory clauses, the change-notification procedure's timing and channel, the objection-handling workflow's options, the offboarding discipline. Auditors test against Annex B. The five most relevant external anchors (full mapping in Section 16): GDPR Article 28(2) (the general authorisation and the objection right); Article 28(3)(a) (the documented-instruction transfer to the sub-processor); Article 28(4) (the flow-down); the modernised SCCs of Implementing Decision (EU) 2021/914 (the processor-to-processor module); ISO/IEC 27018:2019 (the cloud-PII-processor code of practice, its sub-processor clauses); ISO/IEC 27002:2022 controls 5.19 to 5.23 (supplier relationships) and 5.34 (Privacy and protection of PII); NIST Privacy Framework Control-P (data-use agreements); SOC 2 Privacy TSC P6.0 (Disclosure and notification) and the Common Criteria CC9.2 (vendor oversight).

What auditors actually check

The certification auditor's A.2.5.7 / A.2.5.8 / A.2.5.9 examination has eight predictable moves (the 28-question checklist is in Section 11). First, ask for the Sub-processor Register and the published sub-processor list, do they exist, are they current, do they reconcile with the vendor master. Second, ask for the engagement procedure and the due-diligence checklist. Third, pick a recent sub-processor engagement (a new analytics SDK, a new cloud region, a new support vendor) and walk the engagement record, due diligence, authorisation, flow-down contract, onboarding sign-off, register entry. Fourth, walk a recent change notification, the notice sent, the window honoured, the disclosure updated, any objection and its handling. Fifth, ask for the flow-down DPA template and a sample of executed flow-down contracts. Sixth, ask for the objection-handling workflow and any objections handled in the last 12 months. Seventh, ask for the chain-transfer re-assessment for the cross-border sub-processors (the Schrems II TIA). Eighth, trace the register's entries into the ROPA (A.2.2.7), the records of disclosures (A.2.5.4) and the breach-handoff chain, the register is not a stand-alone artefact; it feeds the wider PIMS.

Why This Control Matters

The sub-processor as the compliance surface that propagates

Of the four PII themes that run through Annex A.2 (conditions for processing; obligations to principals; privacy by design; sharing, transfer and disclosure), the sharing/transfer/disclosure theme is the most operationally complex, and within it, the sub-processor chain is the surface where the processor's privacy posture is most exposed. The reason is structural: every obligation the processor owes the controller must propagate to the sub-processor, and every failure at the sub-processor propagates back to the controller. The chain is bidirectional, the flow-down pushes obligations downstream; the breach-handoff pushes incidents upstream.

This bidirectional propagation is why A.2.5.7, A.2.5.8 and A.2.5.9 are the most-audited processor controls in the sub-processor segment of the 27701 universe, and the controls most often cited in the post-incident reviews that follow a chain breach. The European early GDPR enforcement on sub-processor conduct, the CNIL's sanctions on processors whose sub-processors suffered breaches that the processor had not notified; the Garante's investigations of cloud providers whose sub-processor lists were incomplete or stale; the EDPB's guidelines on Article 28 that emphasise the processor's \"duty to inform the controller of any intended changes concerning the addition or replacement of other processors\", all turned on whether the processor had operated the chain governance that A.2.5.7, A.2.5.8 and A.2.5.9 require. In India, the DPDP Act's section 8 flow-through, the RBI IT-outsourcing regime's prohibition on unauthorised sub-contracting, and the SEBI / IRDAI third-party expectations make the sub-processor chain the highest-exposed operational surface in the Indian processor landscape.

The Indian regulatory weight

In India, the three controls have a regulatory weight that goes beyond the ISO standard itself. Four layers of weight.

The DPDP Act chain flow-through layer. The DPDP Act's section 2(1)(k) Data Processor definition is functional, the processor is a processor only while it processes \"on behalf of\" the Data Fiduciary. The sub-processor is a processor of the processor, itself acting on behalf of the fiduciary. The fiduciary's section 8 obligations (section 8(5) reasonable security safeguards; section 8(6) breach notification; section 8(7) erasure) flow through the processor agreement to the processor and onward through the sub-processor agreement to the sub-processor. The processor's failure to flow the obligations downstream (no flow-down contract; a flow-down that omits the section 8(5) safeguards or the section 8(6) breach-handoff) propagates back to the fiduciary's penalty exposure (up to two hundred and fifty crore rupees for section 8(5); up to two hundred crore for section 8(6)) and forward to the processor's contractual indemnity exposure.

The DPDP section 8(6) chain breach-handoff layer. On becoming aware of a personal data breach, the Data Fiduciary must notify the Board and each affected Data Principal without delay, with a detailed report within 72 hours of awareness (DPDP Rules 2025 Rule 7). The chain pattern: the sub-processor becomes aware of the breach; the sub-processor notifies the processor (under the flow-down contract's breach clause); the processor notifies the fiduciary (under the customer DPA's breach clause); the fiduciary notifies the Board and the principals. The clock starts from the fiduciary's awareness, which depends on the processor's handoff, which depends on the sub-processor's handoff. A sub-processor that delays the handoff (because the flow-down contract is silent on the timeline, or because the sub-processor's incident-response is weak) causes the fiduciary's section 8(6) failure. A.2.5.8 (the flow-down) and A.2.5.9 (the change discipline, the sub-processor was added without proper assessment) are implicated.

The sectoral outsourcing layer (RBI / SEBI / IRDAI). The Indian sector regulators impose granular sub-processor-side duties on the entities they regulate and through them on the processors those entities engage. The RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025) are the marquee, the bank's outsourcing agreement with the processor must not permit the processor to further outsource the services without the bank's prior written permission. This is the Indian equivalent of the GDPR Article 28(2) general-authorisation rule, but stricter, the bank's prior written permission is a specific-authorisation requirement, not a general-authorisation with objection right. The RBI NBFC Managing Risks in Outsourcing Directions, 2025 extends the rule. The SEBI CSCRF (20 August 2024) requires SEBI-regulated entities to impose privacy and security duties on their processors and to track the sub-processor chain. The IRDAI Information and Cyber Security Guidelines (24 April 2023) impose ICT-outsourcing data-protection clauses on insurers' processors, with explicit sub-contracting controls. A.2.5.7 / A.2.5.8 / A.2.5.9 are the operational controls through which the processor satisfies these sector-driven expectations.

The constitutional layer (Puttaswamy). The Supreme Court's K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (judgment delivered 24 August 2017 by a nine-judge Bench) declared informational privacy a fundamental right under Articles 14, 19 and 21, and articulated the proportionality test that any limitation of the right must meet. The Aadhaar judgment, Justice K.S. Puttaswamy (Retd.) v. Union of India, (2019) 1 SCC 1 (26 September 2018, five-judge Bench), applied the test and struck down section 57 of the Aadhaar Act. The processor that engages a sub-processor without the controller's knowledge, or that allows the sub-processor to process for purposes beyond the controller's instructions, contributes to a proportionality failure at the controller level, the controller's processing became non-proportional in part because the processor did not govern the chain.

The cost of non-compliance

The cost of an A.2.5.7 / A.2.5.8 / A.2.5.9 failure breaks down into four bands.

Direct DPDP / sector-regulator exposure. For the controller-customer, the exposure is direct (section 8(5), 8(6), 10 penalties under the Schedule). For the processor, the exposure is indirect but real: the sector regulators (RBI, SEBI, IRDAI) can investigate the processor directly under the outsourcing rules; the RBI's outsourcing directions permit supervisory action including the cancellation of the bank's authorisation to engage the processor (which is, for a processor whose business depends on the bank, a commercial death sentence); the processor's contractual indemnity to the controller can be invoked. The penalty exposure for the processor itself (under the sector rules) can be substantial.

Indirect regulatory consequences are larger and slower. A failure on the three controls cascades through the broader privacy architecture, the records-of-disclosures control (A.2.5.4) does not reflect the actual sub-processor chain; the cross-border basis (A.2.5.2) is undermined by unauthorised cross-border sub-processors; the security controls (A.3) are inconsistently flowed down; the breach-handoff chain (section 8(6)) is broken at the sub-processor link. The sub-processor register is the operational input to multiple other controls; its absence or staleness weakens the broader architecture.

Commercial cost is significant. The Indian processor market, SaaS vendors, BPO / ITeS providers, analytics vendors, cloud-service resellers, is increasingly differentiated by privacy posture. Enterprise customers (the banks, the insurers, the SEBI-regulated intermediaries, the MNCs operating in India) include A.2.5.7 / A.2.5.8 / A.2.5.9-style sub-processor clauses in their standard DPAs, audit the processor's sub-processor register during vendor diligence, and require a notice window for changes. The processor that cannot demonstrate a current register and a clean engagement procedure is the processor that loses the procurement. The reputational damage of a public failure (a regulator's order naming the processor; a customer's press release; a news story on a chain breach that traces back to an undisclosed sub-processor) compounds the procurement loss.

Certification cost is the most immediate. Recoverable; entirely avoidable.

The board-level question

The board-level question for the three controls is not \"do we have a sub-processor clause in our DPA?\", most processors can point to the boilerplate. The question is \"for every sub-processor currently processing our customers' personal data, can we produce (a) the engagement record with the due diligence and the authorisation, (b) the flow-down contract with the data-protection obligations mirrored, (c) the disclosure record showing the controller was told before or at go-live, and (d) the change-notification record for any sub-processor added or replaced in the last twelve months?\" If the honest answer is \"partially\" or \"no\", the processor has an A.2.5.7 / A.2.5.8 / A.2.5.9 gap regardless of what its DPA says.

Scope and Applicability

Who the controls apply to

Controls A.2.5.7, A.2.5.8 and A.2.5.9 sit in Table A.2 of the 2025 Annex A, the PII processor control set. They bind every organisation that acts as a processor (DPDP: Data Processor; GDPR: processor) for at least one controller-customer and that engages (or intends to engage) sub-processors to process the controller's personal data on its behalf. Controllers (Table A.1) are bound by the mirror control A.1.2.7 (contracts with PII processors) and by the controller-side sub-processor discipline (the controller's right to authorise, to be notified, and to object is exercised through the controller's own controls).

The controls apply regardless of organisation size. A twenty-person SaaS startup providing analytics services to five controller-customers and using a cloud provider plus two support-tool vendors, a thousand-person BPO serving twenty banking customers and using a dozen sub-processors across voice, back-office and analytics, and a global cloud provider serving thousands of controller-customers across multiple jurisdictions with hundreds of sub-processors are all bound. The maturity expectations scale with the volume, complexity and risk of the sub-processor estate, see Section 22 (Maturity Model).

When the controls apply, the sub-processor categories

A.2.5.7 / A.2.5.8 / A.2.5.9 apply whenever the processor engages a sub-processor to process the controller's personal data. The sub-processor categories the processor's register and engagement procedure should capture:

1. Infrastructure sub-processors, the cloud providers hosting the data, the data-centre operators, the CDN providers, the backup-storage providers, the database-service providers.
2. Service sub-processors, the email providers, the ticketing systems, the CRM platforms, the support-tooling vendors, the collaboration tools, the logging and monitoring services that may receive or process the controller's personal data.
3. Functional sub-processors, the analytics engines, the recommendation services, the personalisation engines, the payment rails, the KYC providers, the fraud-detection services, the transcription services, the AI model providers, the verification services.
4. People sub-processors, the BPO's own BPO, the development shops, the maintenance contractors, the professional-service firms that may access the controller's personal data in the course of their engagement.
5. Inherited sub-processors, the sub-processors of the processor's sub-processors (the chain continues; the flow-down requires the sub-processor to impose equivalent terms on its own sub-processors, and the processor's register should record the material ones).
6. SDK and marketplace sub-processors, the third-party SDKs embedded in the processor's applications, the marketplace apps installed in the processor's SaaS, the libraries that transmit personal data to their publishers. These are the \"invisible\" sub-processors, the most common omission in the processor's register.
7. Cloud-provider sub-processors, the sub-processors that the processor's cloud provider engages to deliver the cloud service (the cloud provider's own support vendors, the cloud provider's infrastructure partners). The processor's customer DPA may or may not require these to be in the processor's register; the cloud provider typically publishes its own sub-processor list.

The processor's engagement procedure (toolkit doc 02) operationalises these categories. The triage of \"is this vendor a sub-processor?\" is itself a control, the documented decision that a vendor does or does not process the controller's personal data. Vendors that do not process personal data (a generic office-supply vendor, a facility-services vendor) are not sub-processors and do not belong in the register; vendors that do process personal data (even incidentally, a support-tooling vendor that sees ticket metadata) are sub-processors and do belong.

What is in scope for the engagement review

The engagement due diligence covers the prospective sub-processor against six dimensions (the full checklist is in toolkit doc 09): security (the sub-processor's security posture, certifications, ISO/IEC 27001, SOC 2, the security controls the processor relies on); privacy (the sub-processor's own privacy programme, its sub-processor regime, its breach history, its privacy certifications); legal (the sub-processor's jurisdiction, the flow-down enforceability, the cross-border transfer mechanism, the sub-processor's corporate form and authority); financial (the sub-processor's financial stability, its ability to indemnify, its business continuity); operational (the sub-processor's service-levels, its incident-response capability, its support model, its scalability); reputation (the sub-processor's public track record, any regulatory actions, any breach disclosures). The review's output is a risk-tiered recommendation, approved / approved-with-conditions / declined, with the documented reasoning.

What is out of scope

• Vendors that do not process the controller's personal data. A vendor that provides a service that does not involve personal data (infrastructure-only vendors with no access to data, professional-services vendors under a non-disclosure arrangement that does not extend to personal data) is not a sub-processor. The processor's vendor-master should distinguish sub-processors from non-sub-processor vendors.
• The processor's own employees and direct contractors (the processor's staff). These are governed by the processor's internal controls and the employment or contractor arrangements; they are not sub-processors under A.2.5.x.
• Joint controllers (entities that process the personal data jointly with the controller, on their own behalf). Joint controllers are governed by the joint-controller arrangement (the controller-side control A.1.2.8; GDPR Article 26); they are not sub-processors.
• Recipients of legally binding disclosures (law-enforcement requests, regulator orders, court processes). These are governed by A.2.5.6 (legally binding PII disclosures); they are not sub-processors.
• The controller's own direct engagement of a vendor (where the controller separately engages a vendor that the processor also uses). The vendor is a sub-processor of the controller, not of the processor, for the controller's direct engagement.

Applicability by organisation size

Applicability by industry (preview, Section 21 has detail)

• BFSI processors, the RBI IT-outsourcing regime (banks, NBFCs), the SEBI CSCRF (market intermediaries), the IRDAI ICT-outsourcing rules (insurers). The most prescriptive Indian sectoral sub-processor duties sit in BFSI; the prior-written-permission rule is the marquee.
• Healthcare processors, processors handling health data on behalf of hospital-controller, insurer-controller, telemedicine-controller customers. The sensitivity of health data amplifies every sub-processor risk; the functional sub-processor category (transcription, AI) is the marquee.
• IT-ITeS and SaaS processors, the largest segment of Indian processors; multi-jurisdiction sub-processor estates; the most diverse sub-processor profiles (from infrastructure clouds to SDK vendors).
• E-commerce and retail processors, processors handling consumer data on behalf of e-commerce-controller customers (payment processors, logistics providers, marketing-technology vendors). The functional sub-processor category (payment rails, recommendation engines) is the marquee.
• Edtech processors, processors handling student and parent data on behalf of edtech-controller customers. The children's-data overlay (DPDP section 9) makes every sub-processor involving a child's data a high-risk engagement.
• Manufacturing processors, processors handling supplier-contact data, IIoT data, employee data on behalf of manufacturing-controller customers. The IIoT-cloud and analytics sub-processor category is the marquee.

Key Definitions and Terminology

Relationship to Other Clauses and Frameworks

The sibling-control network inside Annex A.2

The three controls do not stand alone, they sit inside a tight sibling network in theme A.2.5 (sharing, transfer and disclosure), and the audit will trace the network end-to-end.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.5.2 (basis for PII transfer between jurisdictions). The cross-border sub-processor is a transfer under A.2.5.2. Every sub-processor located outside the controller's jurisdiction triggers the A.2.5.2 basis analysis (the transfer mechanism, SCCs, adequacy, BCRs; the Schrems II TIA). The two controls interlock: A.2.5.8 requires the engagement due diligence; A.2.5.2 requires the cross-border basis; the chain-transfer re-assessment (Section 7.4) is the joint operational step.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.5.3 (countries to which PII can be transferred). A.2.5.3 governs the destination countries; the sub-processor's location must be on the controller's permitted-destinations list (where the customer DPA specifies one). The DPDP section 16 negative-list overlay applies, a sub-processor in a country on the negative list is an A.2.5.3 infringement.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.5.4 (records of PII disclosures to third parties). A.2.5.4 is the broader record of every disclosure; the sub-processor disclosure is a subset. The register's entries flow into the A.2.5.4 records; the A.2.5.4 records reconcile with the register.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.5.6 (legally binding PII disclosures). A.2.5.6 governs disclosures compelled by law; the sub-processor disclosure is a contractual disclosure, not a legally binding one. The two are distinct but adjacent.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.2.2 (customer agreement). A.2.2.2 governs the DPA under which the sub-processor clauses live; the three controls govern the operation of those clauses. A processor that has a strong DPA but no engagement procedure has not satisfied A.2.5.8; a processor that has a strong engagement procedure but a weak DPA has no enforceable sub-processor regime.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.2.5 (infringing instruction). The controller's instructions on sub-processor engagement and change are a category of instruction under A.2.2.5. An instruction to bypass the notice window, to engage a sub-processor without due diligence, or to ignore a controller-side objection from another controller is a textbook A.2.2.5 infringement and a textbook A.2.5.8 infringement.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.2.7 (records related to processing PII). The ROPA references the sub-processor chain; the register references the ROPA. The two artefacts cross-reference; an audit that walks the ROPA will walk into the register.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.2.3.2 (comply with obligations to PII principals). The sub-processor must cooperate with the controller's principal-side rights operation (the flow-down requires it). The processor's rights-handling procedure must route to the sub-processor where the sub-processor holds the relevant data.

A.2.5.7 / A.2.5.8 / A.2.5.9 ↔ A.3 (security controls). The security flow-down is the technical-and-organisational-measures slice of the flow-down contract. A.3.10 (supplier agreements, the 27002:2022 control 5.20 lineage) is the security-control anchor. The flow-down must require the sub-processor to implement security measures equivalent to those the processor implements (A.3 controls).

The controller-side mirror, A.1.2.7

The controller-side mirror of the three controls is A.1.2.7 (contracts with PII processors), the controller's duty to put in place a DPA with its processor that includes the sub-processor regime. From the controller's perspective: the controller authorises the sub-processor chain (general or specific); the controller receives the disclosure; the controller has the right to object; the controller relies on the processor's flow-down to bind the sub-processor. From the processor's perspective (this guide): the processor operates the regime the controller's DPA specifies; the processor maintains the register; the processor runs the engagement and change procedures; the processor imposes the flow-down. The two perspectives are sequential, the controller sets the regime through the DPA; the processor operates the regime through the three controls.

The cross-framework anchors (preview, Section 16 has the full map)

The cross-border chain complexity

Where the sub-processor is in a different jurisdiction from the controller, the chain inherits the multi-jurisdiction complexity. A controller in the EU with a processor in India engaging a sub-processor in the United States: the chain involves the EU SCCs (controller-to-processor module for the EU-India leg, processor-to-processor module for the India-US leg), the Schrems II TIA at both legs, the DPDP section 16 negative-list screening (for the controller's India principal data), and the US-state-law service-provider rules (where the sub-processor accesses US-state personal data). The chain-transfer re-assessment must address each leg; the flow-down contract must accommodate the multi-jurisdiction transfer mechanisms. The processor that builds the multi-jurisdiction chain capability early is well-prepared for the global customer portfolio.

Detailed Implementation Guidance, The Five-Phase Sub-processor Lifecycle

The Singahi five-phase sub-processor lifecycle operationalises Controls A.2.5.7, A.2.5.8 and A.2.5.9 as a continuous discipline. Each phase has its evidence artefacts, its owners and its KPI hooks. The phases are not a project waterfall, they are the steady-state cycle the processor operates every day.

Phase 1, Disclose (A.2.5.7)

The disclosure phase is the static baseline. The processor maintains the master sub-processor register and makes the controller-facing view available through the DPA's disclosure channel.

7.1.1 The Sub-processor Register. The register is the single source of truth, every sub-processor currently engaged, with the engagement-record fields. The minimum schema (toolkit doc 03 has the full template):

• Sub-processor legal name; trading name; corporate identifier (CIN / GSTIN for Indian entities; the equivalent for foreign entities).
• Role or service provided (the category, infrastructure / service / functional / people / inherited / SDK / cloud-provider; the specific service).
• Nature of the processing (what the sub-processor does with the data, stores, processes, transmits, analyses, hosts).
• Data categories accessed (the personal-data fields the sub-processor can see or process, minimised to what the role requires).
• Processing location (the geography where the data is stored or accessed; the cross-border transfer mechanism where applicable).
• Customer impact (which controller-customers' data the sub-processor processes, all customers, a subset, a single customer).
• Engagement start date; current status (active / notice / offboarding / terminated).
• Authorisation basis (general, the DPA class; specific, the controller's per-engagement approval).
• Flow-down contract reference (the executed contract; the flow-down clauses applied).
• Due-diligence pack reference (the latest assessment; the date; the next-refresh date).
• Security posture (the certifications, ISO/IEC 27001, SOC 2; the latest audit; the pentest summary).
• Breach history (any incidents involving the sub-processor; the resolution).
• Offboarding record (where terminated, the termination date; the data-return or destruction certification).

7.1.2 The controller-facing published list. The published list is the register's controller-facing view, typically a subset of the fields (entity, role, processing location, the cross-border transfer mechanism). The published list is delivered through the DPA's disclosure channel: a URL (the sub-processor page on the processor's website), a controller-portal section, or a dated register delivered on request and on change. The published list must be current, a stale list is a non-disclosure; the register and the published list must reconcile.

7.1.3 The disclosure-channel discipline. The customer DPA specifies the disclosure channel for each controller-customer. The processor's disclosure procedure must execute the DPA's channel for each customer, a uniform published URL that the DPA does not reference is not the disclosure the controller agreed to. Where customers have different channel requirements, the processor's procedure routes each disclosure to the right channel.

7.1.4 The register reconciliation. The register must reconcile with: the vendor master (the finance list, every vendor the processor pays); the procurement list (every vendor the processor has contracted with); the engineering-integrations list (every SDK, every marketplace app, every cloud-provider sub-account); the cloud-provider sub-processor list (the processor's cloud provider's own sub-processors, where material). The reconciliation is the control that surfaces shadow sub-processors, the vendors that the engineering team engaged without going through procurement. The quarterly reconciliation workshop (the DPO, Procurement, Engineering, Legal, Information Security) is the operational discipline.

Phase 2, Engage (A.2.5.8)

The engagement phase is the gate every new sub-processor passes through. The phase has six steps.

7.2.1 Step 1, Intake and triage. Every prospective sub-processor is intaked through the engagement procedure, a vendor-onboarding request from the business owner (the team that wants the sub-processor), with the proposed role, the data categories, the processing location, the customer impact. The DPO (or the privacy office) triages the request: is this vendor a sub-processor (does it process personal data)? If yes, the engagement proceeds through the full procedure. If no, the vendor is recorded in the vendor master as a non-sub-processor vendor.

7.2.2 Step 2, Due diligence. The six-dimension assessment (toolkit doc 09 has the full checklist):

• Security, the sub-processor's security posture; the certifications (ISO/IEC 27001:2022, SOC 2 Type II, the sector-specific certifications, PCI DSS for payment sub-processors, HIPAA for health-data sub-processors where US-relevant); the security whitepaper; the pentest summary; the incident history; the security-incident response capability.
• Privacy, the sub-processor's own privacy programme; its sub-processor regime (the chain continues); its privacy certifications (ISO/IEC 27701 where the sub-processor is itself certified); its breach history; its data-subject-rights handling capability.
• Legal, the sub-processor's jurisdiction; the flow-down enforceability (the jurisdiction's contract law; the choice of law; the dispute resolution); the cross-border transfer mechanism (where the sub-processor is outside the controller's jurisdiction, SCCs, adequacy, BCRs); the sub-processor's corporate form and authority to contract.
• Financial, the sub-processor's financial stability (the audited financials; the credit rating where available); the ability to indemnify; the business continuity; the insurance (cyber-insurance, professional-indemnity).
• Operational, the sub-processor's service-levels; the incident-response capability (the detection, the response, the notification); the support model; the scalability; the exit capability (can the processor get its data back?).
• Reputation, the sub-processor's public track record; any regulatory actions; any breach disclosures; any litigation; the market references.

The output is a risk-tiered recommendation: Tier A, approved (low-risk, standard flow-down sufficient); Tier B, approved with conditions (medium-risk, enhanced flow-down, additional monitoring, restricted data-minimisation); Tier C, declined (high-risk, the engagement does not proceed; the business owner is informed and an alternative is sought).

7.2.3 Step 3, Authorisation routing. The authorisation regime the customer DPA specifies:

• General authorisation, the sub-processor is within the controller's pre-approved class (the published list, the category, the quality tier). The processor may engage without per-engagement controller approval, subject to the change-notification duty (Phase 4) and the controller's objection right.
• Specific authorisation, the controller approves each named sub-processor individually. The processor sends the controller the due-diligence summary (or the pack, depending on what the DPA specifies) and the engagement proposal; the controller approves or declines. The RBI Managing Risks in Outsourcing Directions, 2025 pattern (the bank's prior written permission) is the specific-authorisation extreme.
• Mixed regime, some customers specify general authorisation; some specify specific authorisation. The processor's procedure routes each engagement to the right regime per customer.

7.2.4 Step 4, Flow-down contract execution. The flow-down (toolkit doc 10 has the full clause library) is the contract between the processor and the sub-processor that imposes the data-protection obligations. The mandatory flow-down clauses mirror the customer DPA's data-protection terms:

• Subject matter, duration, nature and purpose of the sub-processor's processing; the type of personal data; the categories of principals; the obligation to process only on the processor's documented instructions (the Article 28(3)(a) / DPDP section 2(1)(k) analogue).
• Security safeguards, the technical and organisational measures the sub-processor implements (the A.3 flow-down; the Article 32 / DPDP section 8(5) analogue).
• Breach notification, the sub-processor's duty to notify the processor of a personal-data breach without undue delay (the Article 33(2) / DPDP section 8(6) chain-handoff analogue; the timeline, typically shorter than the processor's handoff to the controller, to give the processor time to comply with its own handoff duty).
• Sub-processor of sub-processor, the sub-processor's duty to impose equivalent terms on its own sub-processors (the chain continues; the inherited sub-processor regime).
• Data-return or data-destruction at end of engagement, the sub-processor's duty to return or destroy the personal data at end of engagement, with the certification of destruction.
• Audit and inspection, the processor's right to audit the sub-processor (or to commission a third-party audit); the sub-processor's duty to cooperate with the controller's audits (where the customer DPA requires the controller to be able to audit down the chain).
• Cooperation with rights requests, the sub-processor's duty to assist the processor with the controller's principal-side rights operation.
• Cross-border transfer restrictions, where the sub-processor is in a different jurisdiction, the cross-border transfer mechanism (the SCCs processor-to-processor module; the DPDP section 16 negative-list screening).
• Confidentiality, the sub-processor's duty of confidentiality on the personal data and the engagement terms.
• Infringing-instruction refusal, the sub-processor's duty to refuse infringing instructions from the processor (the Article 28(3) / A.2.2.5 analogue).
• Personnel, the sub-processor's duty to ensure its personnel are under confidentiality and are trained on the data-protection obligations.
• Liability and indemnity, the sub-processor's liability for its breaches; the indemnity the sub-processor owes the processor.
• Termination, the termination rights; the post-termination obligations.

7.2.5 Step 5, Onboarding sign-off. The engagement record is closed with the documented sign-off, the due-diligence pack filed, the authorisation basis recorded, the controller notification sent (where required), the flow-down contract executed, the onboarding checklist complete (the technical integration, the data-minimisation confirmed, the access controls in place, the monitoring hooks configured). The register entry is created.

7.2.6 Step 6, Disclosure update. The register's update flows to the controller-facing published list. Where the engagement is a change (Phase 4), the change notification is sent through the notice window. Where the engagement is within a pre-approved class and the published list is the disclosure channel, the published list is updated and no separate change notification is required (depending on the DPA's terms).

Phase 3, Monitor

The monitoring phase is the steady-state oversight of the sub-processor estate. The monitoring is risk-tiered, Tier A sub-processors get lighter monitoring; Tier B sub-processors get enhanced monitoring; Tier C sub-processors were declined and are not engaged.

7.3.1 Security posture monitoring. The sub-processor's security certifications are tracked, the ISO/IEC 27001 certificate's expiry, the SOC 2 report's period, the pentest's date. The processor requests the annual recertification evidence; the processor reviews any material changes (a certification lapsed; a SOC 2 with a qualified opinion; a pentest with critical findings). The security-monitoring service (a third-party risk-rating service where the processor uses one) alerts on the sub-processor's public security posture.

7.3.2 Incident monitoring. The sub-processor's duty to notify the processor of incidents (under the flow-down breach clause) is monitored. The processor's incident-response team receives the sub-processor's notifications; the team assesses the chain breach-handoff duty (does the incident trigger the processor's handoff to the controller? does it trigger the controller's section 8(6) notification?).

7.3.3 Performance monitoring. The sub-processor's service-levels are tracked; the performance issues are surfaced through the operations reviews; the material performance issues (a sub-processor that consistently misses its SLAs) trigger a risk-tier re-assessment.

7.3.4 Annual due-diligence refresh. For Tier B sub-processors (and for any sub-processor processing high-risk data, special-category data, large-scale data, BFSI data), the annual due-diligence refresh re-runs the six-dimension assessment. The refresh surfaces material changes (a sub-processor's ownership change; a sub-processor's security-posture decline; a sub-processor's breach history).

7.3.5 Continuous cross-border re-assessment. For cross-border sub-processors, the Schrems II landscape is monitored, the destination country's surveillance law changes; the European Commission's adequacy decisions; the ECJ's case law; the EDPB's recommendations. The chain-transfer re-assessment (Section 7.5) is refreshed where the landscape changes materially.

Phase 4, Change (A.2.5.9)

The change phase is the dynamic overlay that fires on every addition or replacement. The phase has five steps.

7.4.1 Step 1, Change trigger. The change is triggered by: a new sub-processor engagement (Phase 2 completes); a sub-processor replacement (the processor switches from one sub-processor to another, a cloud migration, a vendor consolidation, a strategic change); a sub-processor scope change (an existing sub-processor's role expands, a new data category, a new processing location, a new customer impact); a sub-processor ownership change (the sub-processor is acquired, merged, or restructured); a sub-processor offboarding (Phase 5).

7.4.2 Step 2, Change-notification preparation. The processor prepares the change notification, the sub-processor's identity, role, data categories, processing location, the reason for the change, the effective date, the authorisation basis (general or specific). The notification is prepared for each controller-customer whose data is affected, in the format the DPA specifies.

7.4.3 Step 3, Notice despatch and window. The notification is sent through the DPA's notice channel, typically email to the controller's designated notice contact, or a controller-portal notification. The notice window (the DPA's specified period, 14 days, 30 days, 60 days) starts. The processor's procedure honours the longest window the DPA specifies (where the processor has customers with different windows, the longest governs the procedure's default; the per-customer notification can use the customer's window).

7.4.4 Step 4, Objection handling. If a controller objects within the window (the controller's notice contact objects on reasonable grounds), the objection-handling workflow fires:

• Intake and assessment, the objection is logged; the DPO (or the privacy office) assesses the grounds (does the objection have merit? what is the specific concern? is it security, jurisdiction, competition, or reputation?).
• Response options:
  • Decline to engage for the objecting controller, the cleanest outcome; the controller's data does not flow to the sub-processor; the sub-processor engages for other controllers but not for the objecting one. This requires the technical architecture to support customer-specific data routing, a non-trivial requirement for SaaS processors with a shared infrastructure.
  • Restrict the sub-processor's role, the sub-processor engages for the objecting controller but with a restricted role (a reduced data set, a different processing location, additional safeguards).
  • Negotiate with the controller, the processor provides additional information (a deeper due-diligence summary; a security assurance); the controller's objection may be resolved.
  • Escalate through the DPA's dispute mechanism, typically a senior-management discussion; potentially a contract amendment; at the extreme, the controller's right to terminate the DPA on the change (the GDPR Article 28(2) pattern; the processor's DPA may specify this).
• Decision and documentation, the decision is made at the appropriate authority level (the DPO for routine objections; the executive for high-revenue customer objections; the executive and Legal for SDF-class customer objections). The decision is documented in the engagement record; the controller is notified of the resolution.

7.4.5 Step 5, Disclosure update. The register and the published list are updated to reflect the change. Where the objection resulted in a customer-specific restriction, the register's customer-impact field is updated to record the restriction. The change notification is closed with the resolution.

The chain-transfer re-assessment (Schrems II)

Every cross-border sub-processor addition or change triggers a chain-transfer re-assessment. The re-assessment is the Schrems II transfer-impact analysis applied to the chain.

7.5.1 The Schrems II duty. The Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems decision (Case C-311/18, CJEU Grand Chamber, judgment 16 July 2020) invalidated the EU-US Privacy Shield and held that the data exporter must, case-by-case, verify (a transfer-impact assessment) that the transfer tools (the SCCs, the BCRs) can be complied with in the third country, if not, adopt supplementary measures (technical: encryption, pseudonymisation, split processing; contractual; organisational). The duty applies to every cross-border transfer, including the cross-border sub-processor leg.

7.5.2 The re-assessment steps. For each cross-border sub-processor addition or change:

• Identify the transfer, the source jurisdiction (where the data is exported from); the destination jurisdiction (the sub-processor's location); the transfer mechanism (SCCs processor-to-processor module; the EU adequacy decision where the destination is adequate; the BCRs where the processor's group has them).
• Assess the destination's surveillance law, does the destination's law (the US CLOUD Act / FISA 702 where the destination is the US; the equivalent for other destinations) require the sub-processor to disclose personal data to the destination's authorities in a way that conflicts with the SCCs?
• Assess the supplementary measures, can the transfer be made safe through technical measures (encryption with keys the controller or the processor holds; pseudonymisation; split processing), contractual measures (the SCCs' additional clauses; the sub-processor's commitment to challenge unlawful access requests), or organisational measures (the transparency report; the challenge rate)?
• Document the conclusion, the transfer can proceed with the supplementary measures identified; the transfer cannot proceed and must be re-routed (a different sub-processor; a different destination; a different architecture); the transfer can proceed without supplementary measures (where the destination's surveillance law does not conflict, the typical case for destinations with an adequacy decision).

7.5.3 The DPDP section 16 overlay. For India-principal data, the DPDP Act section 16 negative-list screening applies, the destination country must not be on the Central Government's negative list (no countries notified as of mid-2026; the screening is a forward-looking check). The re-assessment documents the section 16 check alongside the Schrems II analysis.

7.5.4 The re-assessment cadence. The re-assessment is refreshed where: the destination's surveillance law changes materially; the European Commission's adequacy decisions change; the ECJ's case law evolves; the sub-processor's role changes; the data categories change. The continuous monitoring (Phase 3) feeds the re-assessment refresh.

Phase 5, Offboard

The offboarding phase is the end-state. The phase has five steps.

7.6.1 Step 1, Termination notice. The engagement is terminated through the documented notice, the processor's notice to the sub-processor (the flow-down contract's termination clause); the reason for termination (a commercial decision, a risk-tier downgrade, a customer-driven termination, a sub-processor breach).

7.6.2 Step 2, Data-return or data-destruction. The sub-processor returns the controller's personal data to the processor (where the processor needs the data back) or destroys the data (where the processor does not). The flow-down contract specifies the option; the sub-processor's compliance is the canonical evidence. The certification of destruction (the sub-processor's written confirmation that the data has been destroyed, with the destruction method, the date, and the authorised signatory) is required where the data is destroyed.

7.6.3 Step 3, Access revocation. The sub-processor's access to the processor's systems is revoked, the credentials, the API keys, the network access, the physical access (where applicable). The revocation is logged.

7.6.4 Step 4, Post-engagement obligations. The flow-down contract's post-engagement obligations continue, the confidentiality, the audit cooperation (the processor's right to audit the terminated sub-processor for incidents that occurred during the engagement), the breach-notification duty (the sub-processor's duty to notify the processor of breaches discovered after termination that occurred during the engagement).

7.6.5 Step 5, Register update and disclosure. The register entry is updated to \"terminated\" with the termination date, the data-disposition, the certification of destruction. The published list is updated to remove the sub-processor. Where the offboarding affects a specific controller's data, the controller is notified of the offboarding (a reverse change notification, the controller is told the sub-processor is no longer processing its data).

The integration with the wider PIMS

The five-phase lifecycle integrates with the wider PIMS through four feeds.

7.7.1 The ROPA feed. The sub-processor register feeds the ROPA (A.2.2.7). Every ROPA entry that involves a sub-processor references the register; every register entry references the ROPA. The two artefacts cross-reference; the audit walks the cross-reference.

7.7.2 The breach-handoff chain feed. The sub-processor's breach-notification duty (under the flow-down) feeds the processor's breach-handoff chain. The processor's incident-response procedure routes to the sub-processor where the sub-processor holds the affected data; the sub-processor's handoff starts the chain. The chain breach-handoff pattern (sub-processor → processor → controller → Board / CERT-In) is the operational integration.

7.7.3 The change-management feed. The sub-processor change (Phase 4) feeds the PIMS change-management discipline (Clause 6.3). Every sub-processor change is a PIMS change; the change-management record references the engagement record.

7.7.4 The management-review feed. The sub-processor KPIs (Section 12) feed the management review (Clause 9.3). The KPIs surface the trends, the engagement volume, the objection rate, the change-notification timeliness, the offboarding cycle time, and drive the continual-improvement actions (Clause 10.1).

Tools, Technologies, and Solutions

The sub-processor lifecycle can be operated with tools ranging from a well-structured spreadsheet (for a growing processor with a small estate) to a dedicated third-party risk-management platform (for a mid-sized or enterprise processor with a large estate). The choice is a maturity-and-scale decision.

The Sub-processor Register tooling

8.1.1 The spreadsheet option (Level 1 to Level 2). A well-structured spreadsheet (or a structured register in a low-code tool) with the engagement-record fields is acceptable for a growing processor with up to approximately 40 sub-processors. The integrity gaps (no integrity seals, broad write access, no audit log, no automated backup) make a spreadsheet unsuitable for the steady state beyond this size. The spreadsheet must be access-controlled, version-controlled, and backed up; the integrity dimension must be documented.

8.1.2 The GRC platform option (Level 2 to Level 4). A GRC (governance, risk, compliance) platform with a vendor-risk or third-party-risk module is the typical choice for mid-sized organisations. The platform provides the register, the workflow (engagement, due diligence, change, offboarding), the access control, the audit log, the integration with the broader GRC disciplines (risk register, incident management, audit management). The Indian market has several GRC platforms; the global market has a wider selection. The processor's choice depends on the broader GRC strategy (privacy is one slice; the platform should serve the wider risk-and-compliance needs).

8.1.3 The dedicated TPRM platform option (Level 3 to Level 5). A dedicated third-party risk-management (TPRM) platform provides the sub-processor lifecycle specialised, the continuous security-posture monitoring, the automated due-diligence questionnaires, the inherited-sub-processor discovery, the SDK and marketplace scanning. The TPRM platforms are increasingly used by mid-sized and enterprise processors; the choice depends on the scale and the risk profile of the sub-processor estate.

8.1.4 The in-house build option. For processors with a distinctive sub-processor lifecycle (a SaaS platform with a deeply integrated vendor model; a marketplace processor with a high-volume small-engagement model), an in-house build on the processor's existing engineering stack may be the right choice. The build cost is higher; the fit is tighter; the maintenance is the processor's responsibility.

The due-diligence tooling

8.2.1 The security-rating services. The security-rating services (the third-party risk-rating platforms that score vendors on their public security posture, the external attack surface, the certificate hygiene, the breach history) provide a continuous, low-cost first-pass security assessment. The processor subscribes; the service scores the sub-processors; the privacy office uses the scores in the due-diligence triage.

8.2.2 The due-diligence questionnaires. The standardised due-diligence questionnaires (the industry-standard security and privacy assessments, the SIG, the CAIQ, the privacy questionnaires) provide the second-pass assessment. The sub-processor completes the questionnaire; the privacy office assesses the responses; the questionnaire's evidence (the certifications, the pentest summary, the policies) supports the assessment.

8.2.3 The documentation vault. The due-diligence pack (the questionnaire, the evidence, the certifications, the pentest summary, the policies) is stored in a documentation vault with access control, version control and retention management. The vault is the evidence base for the audit.

The flow-down contract tooling

8.3.1 The clause library. The flow-down DPA clause library (toolkit doc 10) is the processor's template for the sub-processor contract. The library is maintained by the privacy office and Legal; it is refreshed as the regulatory landscape evolves (the GDPR modernised SCCs; the DPDP Rules; the sector-regulator updates).

8.3.2 The contract-management platform. The executed flow-down contracts are managed in a contract-management platform, the contract's lifecycle (drafting, negotiation, execution, renewal, termination) tracked; the obligations tracked; the expiries tracked. The platform integrates with the sub-processor register (the contract reference is in the register; the register entry references the contract).

The change-notification tooling

8.4.1 The controller-portal notification. The controller-portal notification (the gold standard) is the change-notification mechanism embedded in the processor's customer portal, the controller's designated notice contact receives the notification in the portal; the controller's objection is filed through the portal; the workflow routes the objection to the privacy office.

8.4.2 The email-notification with ticketing. The email notification (the fallback) is the change notification sent to the controller's designated notice contact by email, with the workflow tracked in the processor's request-management system. The email is the typical Level 2 mechanism.

8.4.3 The published-list update with monitoring. For the general-authorisation regime with a published-list disclosure channel, the change is the published-list update, the URL is updated; the controller's monitoring (where the controller subscribes to a change-notification service) catches the update. This mechanism is the lightest and relies on the controller's active monitoring.

Policy and Procedure Templates

The Singahi A.2.5.7 / A.2.5.8 / A.2.5.9 toolkit (the companion artefact set) includes the ready-to-customise templates that operationalise the five-phase lifecycle. The headlines below; the full documents are in the toolkit.

The Sub-processor Management Policy (toolkit doc 01)

The policy commits the processor to the five-phase lifecycle; the disclosure discipline; the engagement gate; the change-notification duty; the objection-handling workflow; the chain-transfer re-assessment; the offboarding discipline. The policy's "shall" clauses are the processor's own commitments (not quotations from the standard). Sample policy clauses of our own drafting (illustrative):

• The processor shall maintain a Sub-processor Register that lists every sub-processor engaged to process controller personal data, with the engagement-record fields specified in the Engagement Procedure.
• The processor shall publish a controller-facing view of the Register through the disclosure channel specified in each customer DPA, and shall keep the published view current on every change.
• The processor shall engage a new sub-processor only after completing the documented due diligence, obtaining the authorisation required under the customer DPA, and executing the flow-down contract that imposes the data-protection obligations.
• The processor shall give each affected controller advance notice of any intended addition or replacement of a sub-processor, through the notice channel and within the notice window specified in the customer DPA.
• The processor shall operate the objection-handling workflow for any controller objection received within the notice window.
• The processor shall conduct a chain-transfer re-assessment under Schrems II for every cross-border sub-processor addition or change.
• The processor shall offboard each sub-processor with documented notice, data-return or data-destruction, certification of destruction, and post-engagement obligation enforcement.

The Sub-processor Lifecycle Procedure (toolkit doc 02)

The procedure operationalises the policy, the five phases, the steps, the acceptance criteria, the owners, the KPI hooks, the cadence. The procedure is the operating manual the privacy office and the procurement team use day-to-day.

The Sub-processor Register template (toolkit doc 03)

The register template, the schema, the field definitions, the entry format, the controller-facing view format, the change-history log. The template is the starting point; the processor customises it to the customer portfolio and the sub-processor estate.

The Flow-down DPA Clause Library (toolkit doc 10)

The clause library (the Article 28(4) flow-down), the mandatory clauses the processor imposes on every sub-processor, mirroring the data-protection obligations the processor owes the controller. The library is the processor's own drafting (sample "shall" clauses are encouraged).

The Change-Notification and Objection-Handling Playbook (toolkit doc 08)

The playbook, the change-notification templates calibrated to typical scenarios (a new infrastructure sub-processor, a new functional sub-processor, a replacement, a scope change, an ownership change); the objection-handling workflow; the response-option templates; the escalation paths; the customer-relationship dimension.

The Due-Diligence Checklist (toolkit doc 09)

The six-dimension checklist, security, privacy, legal, financial, operational, reputation. The checklist is the evidence base for the engagement decision.

Risk Assessment and Treatment

The sub-processor risk assessment is the privacy-risk slice that feeds the PIMS risk register (Clause 6.1.2 / 8.2). The assessment identifies, analyses, evaluates and treats the risks arising from the sub-processor chain.

The risk identification

The risks arising from the sub-processor chain:

• The unauthorised sub-processor risk, the processor engages a sub-processor without the controller's authorisation or without the engagement procedure (the shadow sub-processor pattern; the A.2.5.8 failure).
• The undisclosed sub-processor risk, the processor engages a sub-processor but does not disclose it to the controller (the A.2.5.7 failure).
• The unflowed-down risk, the processor engages a sub-processor without the flow-down contract or with an inadequate flow-down (the Article 28(4) failure).
• The sub-processor breach risk, the sub-processor suffers a personal-data breach; the chain breach-handoff is the operational consequence; the section 8(6) penalty exposure is the regulatory consequence.
• The sub-processor drift risk, the sub-processor processes for purposes beyond the processor's instructions (the Article 28(10) drift at the sub-processor layer).
• The cross-border chain-transfer risk, the sub-processor's jurisdiction introduces a transfer risk the processor did not assess (the Schrems II failure).
• The objection mishandling risk, the processor mishandles a controller's objection (ignores it; proceeds without resolution; the customer-relationship and contractual consequences).
• The offboarding failure risk, the sub-processor is offboarded without the data-return or data-destruction; the data persists at the sub-processor after the engagement ends.
• The inherited sub-processor risk, the sub-processor's own sub-processors are not assessed or flowed down (the chain continues; the inherited risk materialises).
• The sub-processor financial-failure risk, the sub-processor becomes insolvent; the processor's data is trapped; the business continuity is interrupted.
• The sub-processor ownership-change risk, the sub-processor is acquired by an entity the controller would not approve (a competitor; a higher-risk jurisdiction); the change is not assessed.
• The SDK and marketplace risk, the SDK vendors and marketplace apps are not captured in the register; the invisible sub-processors process personal data without governance.

The risk evaluation

Each risk is evaluated on the likelihood × impact axes. The impact axis considers: the volume of personal data affected; the sensitivity of the data; the number of controller-customers affected; the regulatory exposure (DPDP section 8(6) penalty band; the sector-regulator action); the contractual exposure (the indemnity); the reputational exposure. The likelihood axis considers: the maturity of the current controls; the sub-processor's posture; the cross-border dimension; the sector.

The risk treatment

The treatment options:

• Avoid, do not engage the sub-processor (the decline decision; the re-routing to a different sub-processor or a different architecture).
• Mitigate, engage with enhanced controls (the Tier B approval with enhanced flow-down; the data-minimisation; the customer-specific routing; the supplementary measures under Schrems II).
• Transfer, engage with the risk transferred to the sub-processor (the indemnity; the insurance; the contractual liability).
• Accept, engage with the risk accepted at the appropriate authority level (the documented acceptance; the monitoring plan; the periodic re-assessment).

The Statement of Applicability link

The sub-processor risk assessment's outputs feed the PIMS Statement of Applicability (Clause 8.3), the controls selected (A.2.5.7, A.2.5.8, A.2.5.9 are selected for every processor that engages sub-processors; the A.3 supplier-relationships controls are selected for the security flow-down); the justification (the risk-based rationale); the implementation status. The SoA is the certification auditor's first stop; the sub-processor risk assessment is the evidence behind it.

Audit and Compliance Checklist

The Singahi A.2.5.7 / A.2.5.8 / A.2.5.9 audit checklist, the 28 questions the certification auditor is most likely to ask, with the expected evidence and the red-flag patterns. Use this as the operational checklist from day one; audit evidence is built through operations, not assembled at the last minute.

1. Does the Sub-processor Register exist and is it current? Expected: the register (the master list, with the engagement-record fields); the currency (the last update; the reconciliation with the vendor master). Red flag: no register; or a register that is months stale.
2. Does the register reconcile with the vendor master and the engineering-integrations list? Expected: the reconciliation record (the quarterly workshop's findings); the shadow-sub-processor discoveries. Red flag: reconciliation never conducted; or the reconciliation surfaces sub-processors the register did not have.
3. Does the controller-facing published list exist and is it current? Expected: the published list (the URL or the controller-portal view); the currency; the reconciliation with the register. Red flag: no published list; or a published list that is stale.
4. Is the published list delivered through the DPA's disclosure channel for each customer? Expected: the disclosure-channel routing per customer; the evidence of the disclosure (the email; the portal notification; the URL access). Red flag: a uniform published URL that the DPA does not reference.
5. Does the Engagement Procedure exist and is it operational? Expected: the procedure (the five-phase lifecycle); the evidence of operation (the engagement records). Red flag: the procedure exists but no engagement records; or engagement records exist but they bypass the procedure.
6. Does the due-diligence checklist exist and is it calibrated to the sub-processor risk profile? Expected: the six-dimension checklist; the calibration to the processor's sub-processor estate. Red flag: a generic checklist that does not address the processor's specific risks.
7. Is the due diligence conducted for every new sub-processor? Expected: the due-diligence pack for each engagement; the risk-tier decision. Red flag: engagements without the due-diligence pack; or the pack is a checklist without the evidence.
8. Is the authorisation regime (general or specific) documented per customer DPA? Expected: the authorisation matrix per customer; the routing in the engagement procedure. Red flag: a single regime applied uniformly regardless of the DPA.
9. Is the controller's authorisation obtained where specific authorisation is required? Expected: the controller's approval record for each specific-authorisation engagement. Red flag: specific-authorisation engagements without the controller's approval.
10. Does the flow-down DPA clause library exist and is it refreshed? Expected: the clause library (the mandatory flow-down clauses); the refresh record. Red flag: no clause library; or a clause library that is years stale.
11. Is the flow-down contract executed for every active sub-processor? Expected: the executed flow-down contracts (the signed agreements); the contract-management record. Red flag: active sub-processors without the executed flow-down.
12. Does the flow-down mirror the customer DPA's data-protection obligations? Expected: the side-by-side comparison (the customer DPA's obligations vs the flow-down's clauses). Red flag: the flow-down omits material obligations (the breach-notification duty; the audit right; the cross-border restrictions).
13. Does the flow-down include the breach-notification duty? Expected: the breach clause (the sub-processor's duty to notify without undue delay; the timeline). Red flag: no breach clause; or a breach clause with a timeline that does not give the processor time to comply with its own handoff duty.
14. Does the flow-down include the sub-processor-of-sub-processor regime? Expected: the inherited sub-processor clause (the sub-processor's duty to impose equivalent terms on its own sub-processors). Red flag: no inherited-sub-processor clause.
15. Does the flow-down include the data-return or data-destruction at end of engagement? Expected: the data-disposition clause; the certification of destruction. Red flag: no data-disposition clause; or a clause without the certification requirement.
16. Does the Change-Notification Procedure exist and is it operational? Expected: the procedure (the notice preparation, the despatch, the window, the objection handling, the disclosure update). Red flag: no procedure; or a procedure that is not operational (changes are made without the notice).
17. Is the change notification sent in advance of the effective date? Expected: the change-notification record (the despatch date; the effective date; the window). Red flag: notices sent after the effective date; or no notices sent.
18. Is the notice window honoured (the DPA's specified period)? Expected: the per-customer window tracking; the longest-window default. Red flag: the window not honoured for some customers.
19. Does the objection-handling workflow exist and is it operational? Expected: the workflow (the intake, the assessment, the response options, the escalation); the objection records. Red flag: no workflow; or objections received but not handled.
20. Are objections handled at the appropriate authority level? Expected: the documented sign-off authority matrix; the objection-handling decisions at the right level. Red flag: high-revenue customer objections handled at operations-team level.
21. Is the chain-transfer re-assessment conducted for every cross-border sub-processor? Expected: the TIA (the Schrems II analysis; the destination's surveillance law; the supplementary measures). Red flag: no TIA; or a TIA that is a checkbox without the analysis.
22. Is the DPDP section 16 negative-list screening conducted? Expected: the screening record for each cross-border sub-processor (the destination not on the negative list; the screening date). Red flag: no screening; or the screening not refreshed.
23. Does the Offboarding Procedure exist and is it operational? Expected: the procedure (the termination notice, the data-return or destruction, the certification, the access revocation, the post-engagement obligations, the register update). Red flag: no procedure; or offboardings without the data-destruction certification.
24. Is the offboarding cycle tested (a sample of terminated sub-processors)? Expected: the test record (a sample of terminations; the data-disposition evidence; the certification). Red flag: terminations without the data-disposition evidence.
25. Are the sub-processor KPIs reported to the management review? Expected: the KPIs (Section 12) reported at the Clause 9.3 management review; the trends analysed; the improvement actions. Red flag: no KPIs; or KPIs exist but not reported.
26. Does the register feed the ROPA (A.2.2.7)? Expected: the cross-reference (the ROPA entries reference the register; the register entries reference the ROPA). Red flag: no cross-reference; or the cross-reference is stale.
27. Does the register feed the breach-handoff chain? Expected: the breach-handoff procedure routes to the relevant sub-processor; the chain pattern (sub-processor → processor → controller). Red flag: no chain integration; or the integration is on paper but not drilled.
28. Is the sub-processor estate risk-tiered and is the Tier B annual refresh conducted? Expected: the risk-tier matrix; the annual-refresh schedule; the refresh records for the Tier B sub-processors. Red flag: no risk-tier matrix; or the annual refresh not conducted.

Metrics and KPIs

The Singahi A.2.5.7 / A.2.5.8 / A.2.5.9 KPI set (toolkit doc 11) covers register integrity, disclosure discipline, engagement discipline, change discipline, and the cross-border dimension. The fourteen KPIs below are the recommended minimum.

Register-integrity KPIs

1. Register-vendor-master reconciliation completeness, the percentage of vendor-master entries that are reflected in the register (as sub-processors or as non-sub-processor vendors). Target: 100% quarterly.

   • Formula: (vendor-master entries reconciled / total vendor-master entries) × 100
   • Frequency: quarterly
   • Owner: Procurement Lead / DPO

2. Shadow-sub-processor discovery count, the count of sub-processors discovered through reconciliation that were not previously in the register. Target: trend downward; zero in the steady state.

   • Frequency: quarterly
   • Owner: DPO

3. Register currency, the median age of the register's most recent update. Target: updated within the last 30 days.

   • Frequency: monthly
   • Owner: DPO

Disclosure-discipline KPIs

4. Published-list currency, the median age of the published sub-processor list's most recent update. Target: updated within the last 30 days.

   • Frequency: monthly
   • Owner: DPO

5. Disclosure-channel coverage, the percentage of controller-customers whose disclosure is delivered through the DPA's specified channel. Target: 100%.

   • Formula: (customers with channel-correct disclosure / total customers) × 100
   • Frequency: quarterly
   • Owner: Customer Success Lead / DPO

Engagement-discipline KPIs

6. Due-diligence completion, the percentage of new sub-processor engagements with a completed due-diligence pack before onboarding. Target: 100%.

   • Formula: (engagements with completed due diligence / total new engagements) × 100
   • Frequency: monthly
   • Owner: Procurement Lead / DPO

7. Flow-down contract execution, the percentage of active sub-processors with an executed flow-down contract. Target: 100%.

   • Formula: (active sub-processors with executed flow-down / total active sub-processors) × 100
   • Frequency: quarterly
   • Owner: Legal / DPO

8. Flow-down coverage score, the percentage of the customer DPA's data-protection obligations mirrored in the flow-down (a side-by-side scoring). Target: 95%+ for Tier A; 100% for Tier B.

   • Frequency: annually (on flow-down refresh)
   • Owner: Legal / DPO

9. Authorisation-regime compliance, the percentage of engagements with the correct authorisation regime applied per customer DPA. Target: 100%.

   • Frequency: quarterly
   • Owner: DPO

Change-discipline KPIs

10. Change-notification timeliness, the percentage of sub-processor changes with the notification sent in advance of the effective date and within the DPA's notice window. Target: 100%.

    • Formula: (changes with timely notification / total changes) × 100
    • Frequency: monthly
    • Owner: DPO / Customer Success Lead

11. Change-notification lead time, the median lead time between the notification despatch and the effective date. Target: equal to or greater than the longest customer's notice window.

    • Frequency: monthly
    • Owner: DPO

12. Objection-handling cycle time, the median time from objection receipt to resolution. Target: within the notice window.

    • Frequency: per objection (aggregated quarterly)
    • Owner: DPO

13. Objection-resolution rate, the percentage of objections resolved without escalation to the DPA's dispute mechanism. Target: 80%+ (a higher rate indicates the objection-handling workflow is working as a collaborative instrument).

    • Frequency: quarterly
    • Owner: DPO

Cross-border and chain KPIs

14. Chain-transfer re-assessment coverage, the percentage of cross-border sub-processors with a current (within 12 months) chain-transfer re-assessment. Target: 100%.
    • Formula: (cross-border sub-processors with current TIA / total cross-border sub-processors) × 100
    • Frequency: quarterly
    • Owner: DPO / Legal

Common Pitfalls and Audit Failures

The most common A.2.5.7 / A.2.5.8 / A.2.5.9 audit findings in the Indian growing-company processor segment, in rough descending order of frequency. (These patterns are documented across multiple public practitioner commentaries on the 2025 processor controls; no single source is named.)

The register that does not exist or is stale

The processor does not maintain a sub-processor register, or the register exists but is months stale. The auditor's first request surfaces the gap. The remediation is to stand up the register, run the retrospective sweep (the shadow-sub-processor discovery), and publish the controller-facing view.

The register that does not reconcile

The register exists but does not reconcile with the vendor master, the procurement list, or the engineering-integrations list. The shadow sub-processors (the SDK vendors, the marketplace apps, the support tools) are missing. The remediation is the quarterly reconciliation workshop and the discovery discipline.

The published list that nobody told the customer about

The processor maintains a published sub-processor list (a URL) but the customer DPA does not reference the URL, and the controller did not know the disclosure channel. The disclosure that the DPA requires is the one the customer agreed to; a unilateral URL is not it. The remediation is the DPA's disclosure-channel clause and the customer-communication campaign.

The engagement without due diligence

The processor engages a sub-processor (an engineering team's quick integration; a marketing team's analytics tool) without the due-diligence pack. The remediation is the procurement-controlled engagement workflow and the engineering-team training on the intake discipline.

The flow-down as a confidentiality clause

The processor's flow-down contract is a one-line confidentiality clause inherited from a standard vendor agreement. The flow-down does not mirror the data-protection obligations; the breach-notification duty, the audit right, the cross-border restrictions, the data-disposition are all missing. The remediation is the flow-down DPA clause library and the contract-refresh programme across the sub-processor estate.

The change made and not communicated

The processor adds or replaces a sub-processor and does not send the change notification. The controller finds out after the fact (through a support ticket that references the new sub-processor; through a breach that traces to the new sub-processor). The remediation is the change-notification procedure embedded in the engagement workflow.

The notice after the fact

The processor sends the change notification after the effective date (the sub-processor has already started processing). The notice window is not honoured. The remediation is the notice-window discipline and the longest-window default.

The objection ignored

A controller objects within the notice window; the processor proceeds anyway (the commercial pressure to ship the feature; the assumption that the objection is not enforceable). The remediation is the objection-handling workflow and the documented sign-off authority.

The chain-transfer re-assessment not conducted

The processor engages a cross-border sub-processor without the Schrems II TIA. The destination's surveillance law is not assessed; the supplementary measures are not considered. The remediation is the chain-transfer re-assessment template and the per-engagement routing.

The offboarding without the data-destruction certification

The processor offboards a sub-processor without the data-return or the data-destruction; the certification is not obtained. The data persists at the sub-processor after the engagement ends. The remediation is the offboarding procedure and the certification requirement.

The general-authorisation treated as a blank cheque

The processor treats the general-authorisation regime as a blanket approval to engage any sub-processor without any discipline. The change-notification duty (A.2.5.9) is ignored; the controller's objection right is not honoured. The remediation is the engagement procedure's general-authorisation routing (the engagement still goes through due diligence and flow-down; only the per-engagement controller approval is waived).

The specific-authorisation treated as a rubber stamp

The processor's customer requires specific authorisation; the processor sends the due-diligence summary; the controller approves routinely without genuine review. The processor's engagement procedure treats the controller's approval as a rubber stamp. The remediation is the due-diligence quality discipline and the controller-communication on the material findings.

The inherited sub-processor not assessed

The processor's sub-processor engages its own sub-processor; the flow-down requires the equivalent terms; the processor does not assess the inherited sub-processor. The chain continues without the processor's oversight. The remediation is the inherited-sub-processor discovery and the material-chain assessment.

The DPA boilerplate without the operational evidence

The processor's customer DPA has the sub-processor clauses (the disclosure, the authorisation, the flow-down, the change notification). The processor treats the DPA clauses as the controls. There is no register, no engagement procedure, no change-notification record. The remediation is the operational evidence behind the clauses.

The shadow sub-processor discovered at the audit

The auditor discovers a sub-processor the register does not have (an SDK vendor in the application's dependency manifest; a marketplace app installed by a customer-success team member). The remediation is the engineering-integrations reconciliation and the dependency-scanning discipline.

The cross-border sub-processor on the negative list

The processor engages a sub-processor in a country that the DPDP Act section 16 has notified as restricted (or that the controller's DPA excludes). The remediation is the section 16 screening per engagement and the controller's permitted-destinations list.

The objection-handling workflow not documented

The processor handles objections informally (a phone call; a side-email). The workflow is not documented; the resolution is not recorded. The remediation is the objection-handling workflow and the engagement-record discipline.

The offboarding cycle not tested

The processor has an offboarding procedure but has never tested it. When a real termination occurs, the data-destruction is delayed, the access revocation is incomplete, the certification is not obtained. The remediation is the annual offboarding drill.

The sub-processor ownership change not assessed

The sub-processor is acquired by an entity the controller would not approve (a competitor; a higher-risk jurisdiction; an entity with a poor privacy track record). The processor continues the engagement without the assessment. The remediation is the ownership-change trigger in the change procedure.

The KPIs not reported to the management review

The processor tracks some metrics but does not report them to the Clause 9.3 management review. The trends are not analysed; the improvement actions are not taken. The remediation is the KPI dashboard and the management-review pack.

Illustrative Scenario 1: Failure, Narmada SaaS Analytics and the Undisclosed Sub-processor (Illustrative)

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome. It is set after 13 May 2027, when the DPDP Act's duties and the Board's inquiry and penalty powers take effect.

Disclaimer: This is an illustrative scenario developed for educational purposes. The company name is fictional; the patterns are drawn from the publicly documented audit-failure patterns of multiple Indian SaaS, analytics-processor and cloud-service companies. No specific real company is described.

The setting. Narmada SaaS Analytics Private Limited operates a customer-analytics platform from its headquarters in Bengaluru, with approximately 320 employees and a development centre in Pune. The company serves 58 controller-customers, 26 India-based (across BFSI, retail, edtech and healthcare), 18 EU-based, 9 US-based, and 5 in Southeast Asia and the Middle East. The platform ingests the customers' first-party customer data (transaction events, profile data, behavioural events) and produces segmentation, churn-prediction and personalisation outputs. The company is indirectly RBI-regulated (its BFSI customers), SEBI-regulated (its capital-markets-intermediary customers), and IRDAI-regulated (its insurer customers); directly GDPR-relevant for its EU customers; and DPDP-bound for its India customers.

The A.2.5.7 / A.2.5.8 / A.2.5.9 programme at the audit. At the time of the ISO/IEC 27701:2025 Stage 1 audit in late 2027, Narmada's sub-processor governance was typical of an Indian growing-company SaaS processor that had prioritised product velocity over chain discipline:

• The customer DPA had a sub-processor clause (inherited from an early template) that referenced a published sub-processor list at a URL. The URL existed; the list had 9 entries (the cloud provider, the email provider, the ticketing system, the CRM, the logging service, the CDN, two support-tool vendors, and the payment-processor for Narmada's own billing). The list was last updated 14 months before the audit.
• The actual sub-processor estate was materially larger. The engineering team had integrated, over the preceding 18 months, a new analytics-SDK vendor (for in-app event tracking), a recommendation-engine vendor (for the personalisation feature), a transcription-service vendor (for voice-analytics), an AI-model vendor (for a new generative feature), and three additional support-tool vendors (for live-chat, for in-app messaging, and for customer-feedback collection). None of these were in the published list. None had been through a documented due diligence. None had a flow-down contract beyond the vendor's standard click-through terms.
• The AI-model vendor was a US-based provider; the personalisation feature routed some customer data to the US for inference. No Schrems II chain-transfer re-assessment had been conducted; no SCCs were in place for the India-US leg beyond the vendor's standard Data Processing Addendum.
• The change-notification discipline did not exist. The 58 controller-customers had not been notified of any of the five undisclosed sub-processor additions. Two EU customers' DPAs required a 30-day notice window with the objection right; neither had been notified.
• One EU customer had sent an objection (six months before the audit) to a previously disclosed analytics-SDK vendor, asking Narmada not to use that vendor for the customer's data. The objection had been received by Narmada's customer-success team, escalated to the engineering team (which declined to re-route the data because the SDK was integrated into the shared analytics pipeline), and quietly ignored. The customer had not been informed of the resolution (or the absence of one).
• The offboarding discipline did not exist. Two sub-processors that Narmada had stopped using (a previous logging-service vendor and a previous CDN vendor) were still in the published list; no data-destruction certification had been obtained.

The trigger. In August 2027, a breach at the transcription-service vendor exposed the voice-analytics data of approximately 12,000 individuals across three of Narmada's India-based healthcare-controller customers and two of its EU-based retail-controller customers. The breach was discovered by the vendor on 12 August 2027; the vendor notified Narmada on 14 August 2027 (a 2-day delay, within the vendor's standard breach-notification commitment but slower than the 24-hour notification Narmada's flow-down would have required had one existed). Narmada's incident-response team assessed the breach; the chain breach-handoff to the five affected controller-customers was initiated on 16 August 2027, within 72 hours of Narmada's awareness, but the awareness had itself been delayed by the vendor's notification lag. One of the EU controller-customers, on receiving the handoff, asked which sub-processor was the source; the customer had never been told about the transcription-service vendor. The customer's DPO escalated to Narmada's CEO and, separately, filed a complaint with the customer's national supervisory authority; the supervisory authority coordinated with the Data Protection Board of India on the cross-border dimension. The DPBI's investigation surfaced the broader sub-processor governance failure.

The audit findings. The Stage 1 audit, conducted in October 2027 by an IAF-accredited certification body, surfaced the following findings, each tied to specific DPDP and ISO/IEC 27701:2025 anchors:

• Major nonconformity, A.2.5.7 (disclosure). The published sub-processor list was materially incomplete (9 of 14 actual sub-processors listed) and 14 months stale. The five undisclosed sub-processors included the AI-model vendor and the transcription-service vendor.
• Major nonconformity, A.2.5.8 (engagement without due diligence and without flow-down). The five undisclosed sub-processors had been engaged without the documented due diligence and without the flow-down contract. The transcription-service vendor's standard click-through terms did not include a breach-notification duty, an audit right, a data-disposition clause, or the inherited-sub-processor regime.
• Major nonconformity, A.2.5.9 (change not notified). The five undisclosed sub-processors represented changes that had not been notified to the 58 controller-customers. The two EU customers with the 30-day notice window had a contractual right to object that had been denied.
• Major nonconformity, A.2.5.8 read with A.2.5.2 (chain-transfer re-assessment). The AI-model vendor's cross-border processing had not been assessed under Schrems II; no SCCs were in place for the India-US leg; no supplementary measures considered.
• Major nonconformity, A.2.5.9 read with the objection-handling workflow. The EU customer's objection to the analytics-SDK vendor had been ignored; no resolution had been documented; the customer had not been informed.
• Major nonconformity, A.2.5.8 read with the breach-handoff chain. The transcription-service vendor's breach-notification lag (2 days) had not been governed by a flow-down contract; Narmada's own breach-handoff had been delayed by the vendor's lag, putting Narmada at risk of a section 8(6) failure for the affected India customers.
• Minor nonconformity, A.2.5.7 (offboarding). The two terminated sub-processors were still in the published list; no data-destruction certification had been obtained.
• Cross-control findings. The ROPA (A.2.2.7) did not reflect the five undisclosed sub-processors; the records of PII disclosures (A.2.5.4) did not reflect the actual chain; the security controls (A.3) had not been flowed down; the breach register did not reconcile with the (incomplete) sub-processor register.

The regulatory outcome. The DPBI, in coordination with the EU supervisory authority, found in January 2028 that Narmada's sub-processor governance failure had contributed to the breach's impact and to the affected controller-customers' notification obligations. The DPBI's investigation focused on the India-based controller-customers (the three healthcare controllers owed the section 8(6) notification to the Board and the affected principals). One of the healthcare controller-customers was a hospital chain that was a Significant Data Fiduciary under section 10 (designated in the DPDP Rules 2025); the hospital's section 10 enhanced duties (the SDF DPIA, the independent audit) had been undermined by Narmada's failure to flow the obligations downstream. The DPBI's order named Narmada as a processor whose governance failure had materially contributed. Two of the EU controller-customers terminated their contracts; one EU customer's supervisory authority opened its own investigation into Narmada's GDPR Article 28 compliance. Narmada's revenue declined approximately 22% over the following two quarters.

The lessons.

• The published list is not the register. The URL with 9 entries was treated as the control; the actual estate of 14 sub-processors was the reality the audit walked into. The register is the master list; the published list is the controller-facing view; the two must reconcile.
• The shadow sub-processor is the highest-frequency audit finding. The five undisclosed sub-processors were all engineering-team integrations that had not gone through procurement. The quarterly reconciliation workshop is the discipline that surfaces them.
• The flow-down is the contractual foundation of the chain governance. The transcription-service vendor's standard click-through terms did not include the breach-notification duty that would have governed the 2-day lag. The flow-down DPA clause library is the remediation.
• The objection-handling workflow is the control's most-litigated element. The ignored objection was the marquee A.2.5.9 failure. The workflow and the documented sign-off are the remediation.
• The chain-transfer re-assessment is not optional. The AI-model vendor's cross-border processing without the Schrems II TIA was the marquee A.2.5.8 read-with-A.2.5.2 failure. The TIA template and the per-engagement routing are the remediation.
• The audit and the regulator read the same evidence. The Stage 1 audit findings and the DPBI investigation findings were substantially overlapping. An ISO/IEC 27701:2025 audit is a near-proxy for regulatory readiness on the sub-processor chain.

Illustrative Scenario 2: Success, Saraswati Cloud Builds the Five-Phase Sub-processor Discipline (Illustrative)

Disclaimer: This is an illustrative scenario developed for educational purposes. The company name is fictional; the patterns are drawn from the publicly documented remediation programmes of multiple Indian cloud-service and platform-processor companies. No specific real company is described.

The setting. Saraswati Cloud Services Private Limited is a Mumbai-based cloud-infrastructure-as-a-service provider with approximately 540 employees, serving 92 controller-customers, 41 India-based (across BFSI, healthcare, retail, manufacturing and government), 28 EU-based, 15 US-based, and 8 across Southeast Asia, the Middle East and Australia. The company provides compute, storage, networking, managed-database and managed-security services on top of its customers' workloads. The company is indirectly RBI-regulated (its BFSI customers), SEBI-regulated (its capital-markets-intermediary customers), IRDAI-regulated (its insurer customers), and GDPR-relevant for its EU customers. The company also operates its own sub-processor estate (the data-centre operators, the CDN provider, the backup-storage provider, the managed-security tooling vendors, the support-tooling vendors).

The pre-remediation state. In early 2025, ahead of the ISO/IEC 27701:2025 publication and the DPDP Rules notification, Saraswati Cloud's sub-processor governance was uneven. The customer DPA had a sub-processor clause that referenced a published URL; the URL had 12 entries (the primary sub-processors). The actual estate was closer to 38 sub-processors (the engineering team had integrated additional CDN providers for specific regions, multiple backup-storage providers, several managed-security tooling vendors, an AI-operations vendor, and a growing set of support-tooling vendors). The flow-down contracts varied widely, the primary sub-processors had detailed flow-downs; the long tail had the vendor's standard click-through terms. The change-notification discipline existed for the primary sub-processors but not for the long tail. The objection-handling workflow did not exist (no objections had been received, but only because the disclosure was incomplete and the customers did not know the full estate). The chain-transfer re-assessment did not exist. The offboarding discipline was ad-hoc.

The trigger. Saraswati Cloud's board, on the recommendation of the Chief Privacy Officer (a VP-level role reporting to the CEO), decided in mid-2025 to seek ISO/IEC 27701:2025 certification. The decision was driven by three considerations: (i) the company's enterprise customers (especially the BFSI customers and the EU customers) were increasingly asking for ISO/IEC 27701 attestation as a procurement requirement, with the sub-processor chain as the most-audited element in the vendor-diligence questionnaires; (ii) the company had lost a major BFSI deal in Q1 2025 because the customer's vendor-diligence team flagged the absence of a chain-transfer re-assessment for a US-based backup-storage sub-processor; (iii) the company was planning to launch a managed-AI service that would introduce a new tier of sub-processors (the AI-model vendors, the GPU-cloud providers) and the board wanted the sub-processor governance in place before the launch.

The remediation programme (July 2025 to March 2027). The CPO structured the programme in four quarters.

Quarter 1, Register, reconciliation, and disclosure. The team stood up the Sub-processor Management Policy (toolkit doc 01) and the Sub-processor Register (toolkit doc 03) on the company's existing GRC platform (extended with a vendor-risk module). The team ran the retrospective reconciliation, the finance vendor master, the procurement list, the engineering-integrations list, the cloud-provider sub-accounts, the SDK manifest, the marketplace-installed apps. The reconciliation surfaced 26 additional sub-processors the published list did not have (the long tail, the regional CDN providers, the managed-security tooling, the support-tooling vendors, the AI-operations vendor, the SDK vendors in the internal tooling). The team assessed the disclosure gap, which of the 26 additional sub-processors should have been notified to which customers. The published list was updated to 38 entries; the disclosure-channel routing per customer was documented; the customers were notified of the disclosure update (without the full change-notification procedure, because the disclosure was a baseline correction rather than a new change, handled as a remediation communication under the DPA's good-faith provisions).

Quarter 2, Engagement procedure and flow-down refresh. The team wrote the Sub-processor Lifecycle Procedure (toolkit doc 02) operationalising the five phases. The team wrote the six-dimension due-diligence checklist (toolkit doc 09) calibrated to Saraswati Cloud's sub-processor risk profile (the BFSI overlay, the cross-border tier, the AI tier). The team wrote the Flow-down DPA Clause Library (toolkit doc 10), the mandatory clauses the processor imposes on every sub-processor, mirroring the customer DPA's data-protection obligations. The team began the contract-refresh programme across the 38-sub-processor estate, the primary sub-processors' flow-downs were refreshed to the new library; the long tail's click-through terms were replaced with the new flow-downs. The team trained the procurement and engineering teams on the engagement workflow (the intake discipline, the due-diligence routing, the flow-down requirement).

Quarter 3, Change notification and objection handling. The team wrote the Change-Notification and Objection-Handling Playbook (toolkit doc 08). The team built the change-notification workflow into the customer portal, each controller-customer's designated notice contact receives the change notification in the portal; the objection is filed through the portal; the workflow routes to the privacy office. The team ran the first change notifications (three sub-processor additions in the quarter, a new regional CDN provider for the Australia region, a new managed-security tooling vendor, the first AI-model vendor for the managed-AI service preview). The team received two objections, one from an EU customer on the AI-model vendor (the customer's DPO asked for the chain-transfer re-assessment before approving), and one from a BFSI customer on the regional CDN provider (the customer's RBI-outsourcing compliance required a specific authorisation). Both objections were handled through the workflow; the EU customer's objection was resolved through the chain-transfer re-assessment (which confirmed the SCCs with supplementary encryption measures); the BFSI customer's objection was resolved through the specific-authorisation routing (the customer's RBI compliance team approved the engagement after reviewing the due-diligence summary).

Quarter 4, Chain-transfer re-assessment, offboarding, and certification. The team stood up the chain-transfer re-assessment template (toolkit doc 09 Part B) and ran the re-assessment for the 11 cross-border sub-processors. The re-assessment confirmed that 8 were adequately protected (the SCCs with the standard supplementary measures; one was in an adequacy-decision country); 2 required enhanced supplementary measures (the encryption with processor-held keys for one US-based backup-storage provider; the split-processing architecture for one AI-operations vendor); 1 required re-routing (a sub-processor in a destination the team could not confidently assess, the engagement was terminated and the data re-routed to a domestic provider). The team wrote the Offboarding Procedure (toolkit doc 02 Phase 5) and ran the first annual offboarding drill (a tabletop with a volunteer sub-processor; the data-destruction certification workflow was tested end-to-end). The team ran the internal audit (Clause 9.2) covering the sub-processor programme. The team ran the management review (Clause 9.3) with the fourteen KPIs (Section 12). The team went to the certification audit in March 2027. The Stage 1 audit passed without major nonconformities on A.2.5.7 / A.2.5.8 / A.2.5.9. The Stage 2 audit, conducted in May 2027, traced a sample of engagement records (a new AI-model vendor with the chain-transfer re-assessment; a regional CDN provider with the BFSI-specific-authorisation routing; an offboarded backup-storage provider with the data-destruction certification) through the five-phase lifecycle. Zero major nonconformities on the sub-processor chain controls.

The return.

• Avoided penalty exposure. The pre-remediation pattern carried estimated DPDP penalty exposure (propagated from the controller-customers through the indemnity clauses) of approximately INR 30 to 90 crore on the undisclosed-sub-processor category alone (the section 8(5) safeguards failure and the section 8(6) breach-notification failure propagated through the chain), and approximately INR 10 to 30 crore on the chain-transfer-re-assessment-failure category (the cross-border sub-processors without the Schrems II analysis). The remediation reduced the exposure by an estimated 90%.
• Operational efficiency. The register-vendor-master reconciliation completeness KPI moved from approximately 35% (most sub-processors not in the register pre-remediation) to 98% within the four quarters. The change-notification-timeliness KPI moved from "not applicable" (no notifications pre-remediation) to 100% within the notice window. The flow-down-contract-execution KPI moved from approximately 45% (the primary sub-processors had flow-downs; the long tail did not) to 96%. The chain-transfer re-assessment coverage KPI moved from 0% to 100%.
• Reputational dividend. The company's brand-tracking among enterprise-buyer segments showed an approximately 6-point lift in the "trustworthy processor" dimension over the four quarters. The company's customer-success team reported that the change-notification workflow (with the customer-portal notification and the objection-handling workflow) was cited positively in customer-quarterly-business-reviews, in contrast to the pre-remediation pattern where customers discovered sub-processor changes through support tickets.

The lessons.

• Treat the sub-processor chain as a customer-trust investment, not a compliance cost. The chain governance delivered direct revenue (the BFSI-procurement wins, the EU-customer renewals, the managed-AI launch enablement), avoided indemnity exposure one order of magnitude greater than the build cost, and produced operational efficiency that the pre-remediation ad-hoc approach could not match.
• The reconciliation workshop is the operational unlock. The discovery of the 26 shadow sub-processors was the single most consequential step. Without the reconciliation, the published list would have remained at 12 entries; the audit would have walked into the same gap Narmada-style companies walk into.
• The flow-down refresh is harder than the policy. The policy stood up in a workshop; the flow-down refresh across the 38-sub-processor estate took two quarters of legal-counsel-intensive contract work. The long tail (the click-through vendors) is where the effort sits; the refresh programme is the remediation.
• The objection-handling workflow caught real objections. The two objections in Quarter 3 were not hypothetical, the EU customer's DPO and the BFSI customer's RBI compliance team both had genuine concerns. The workflow resolved both within the notice window, preserving the customer relationships.
• The chain-transfer re-assessment re-routed one engagement. The single re-routing (the sub-processor in a destination the team could not confidently assess) was the marquee outcome, the re-assessment identified an exposure the pre-remediation approach would have missed entirely.
• The offboarding drill paid off. The drill surfaced gaps (the certification-of-destruction workflow had a stale template; the access-revocation checklist was incomplete) that were closed before a real termination tested them.

Multi-Framework Mapping

The detailed crosswalk

The DPDP-section-to-sub-processor-chain map (load-bearing for India)

The DPDP Act section-by-section sub-processor chain hooks: section 2(1)(k) (Data Processor definition, the "on behalf of" test extends to the sub-processor); section 4 (grounds, the chain preserves the controller's grounds); section 5 (notice, the chain preserves the controller's notice); section 6 (consent, the chain preserves the controller's consent); section 7 (legitimate uses, the chain preserves the controller's legitimate-use basis); section 8(5) (security safeguards, the sub-processor implements at its layer; the flow-down requires it); section 8(6) (breach notification, the chain pattern: sub-processor → processor → fiduciary → Board, without delay, with a detailed report within 72 hours of the fiduciary's awareness; the flow-down breach clause sets the sub-processor's handoff); section 8(7) (erasure, the sub-processor erases on the processor's instruction at end of engagement; the offboarding discipline); section 9 (children, the chain preserves the children's-data overlay); section 10 (SDF, the controller-customer's enhanced duties propagate through the chain; the processor's flow-down requires the sub-processor to support the SDF DPIA, the algorithmic-software review, the independent audit); sections 11 to 14 (rights, the chain supports the controller's rights operation; the flow-down requires the sub-processor to cooperate with rights requests); section 16 (cross-border negative list, the chain-transfer screening for each cross-border sub-processor); section 33 + Schedule (penalties, the controller's penalty exposure propagates through the chain; the indemnities flow downstream).

The sector-regulator overlay (India-specific)

The cross-border overlay

Where the sub-processor is in a different jurisdiction from the controller, the chain inherits the multi-jurisdiction complexity. A controller in the EU with a processor in India engaging a sub-processor in the US: the EU-India leg is governed by the EU SCCs (controller-to-processor module); the India-US leg is governed by the SCCs (processor-to-processor module) or the SCCs (controller-to-processor module with the controller as a third-party beneficiary); the Schrems II TIA at both legs; the DPDP section 16 negative-list screening for the controller's India-principal data; the US-state-law service-provider rules where the sub-processor accesses US-state personal data. A controller in the US instructing an India-based processor engaging a sub-processor in China: the China leg is governed by the PIPL Article 21 entrusted-processing regime and the CAC standard contract or security assessment (depending on the data volume and sensitivity). The processor's chain-transfer re-assessment must address each applicable regime; the multi-jurisdiction checklist (toolkit doc 17) operationalises this.

Implementation Roadmap

The Singahi 30 / 90 / 180-day implementation roadmap (toolkit doc 05) for Controls A.2.5.7, A.2.5.8 and A.2.5.9.

The first 30 days, register, reconciliation, and quick wins

• Day 1 to 5, Sponsor and team. The DPO confirms executive sponsorship (the CEO or the COO for a growing processor; the board for an enterprise processor) and convenes the cross-functional team (DPO, Procurement Lead, Engineering Lead, Legal, Information Security, Customer Success Lead, Internal Audit). The team adopts the Singahi Sub-processor Register template (toolkit doc 03).
• Day 6 to 15, Register stand-up. The team stands up the register on the chosen tool (spreadsheet acceptable first cycle if integrity, access control and reconciliation are documented; GRC platform or in-house build for the steady state). The team loads the existing sub-processors, the primary sub-processors (the cloud provider, the email provider, the ticketing system, the CRM) that the processor already knows about.
• Day 16 to 25, Retrospective reconciliation. The team runs the reconciliation workshop, the finance vendor master, the procurement list, the engineering-integrations list, the cloud-provider sub-accounts, the SDK manifest, the marketplace-installed apps. The team identifies the shadow sub-processors, the vendors the register did not have.
• Day 26 to 30, Quick wins. The team prioritises the top three reconciliation findings for the gap-closure work; the team drafts the published-list update (the controller-facing view) and prepares the disclosure-correction communication to the affected controller-customers.

The 90-day milestone, engagement procedure and flow-down refresh

• Day 31 to 50, Template adoption. The team adopts the Singahi Sub-processor Management Policy (toolkit doc 01), the Lifecycle Procedure (toolkit doc 02), the Due-Diligence Checklist (toolkit doc 09), and the Flow-down DPA Clause Library (toolkit doc 10), calibrated to the processor's sub-processor estate and regulatory profile.
• Day 51 to 70, Flow-down refresh launch. The team begins the contract-refresh programme across the sub-processor estate, the primary sub-processors first (refresh the existing flow-downs to the new library); the long tail next (replace the click-through terms with the new flow-downs). The team trains the procurement and engineering teams on the engagement workflow.
• Day 71 to 90, First engagements through the procedure. The team runs the first engagements (new sub-processors and renewals) through the new procedure, the intake, the due diligence, the authorisation routing, the flow-down execution, the onboarding sign-off, the register entry. The team tests the disclosure-channel routing for each affected customer.

The 180-day milestone, change notification and chain transfer

• Day 91 to 120, Change-notification workflow. The team writes the Change-Notification and Objection-Handling Playbook (toolkit doc 08). The team builds the change-notification workflow into the customer portal (or the email-and-ticketing fallback). The team trains the customer-success team on the notification discipline.
• Day 121 to 150, Chain-transfer re-assessment. The team stands up the chain-transfer re-assessment template (toolkit doc 09 Part B). The team runs the re-assessment for the cross-border sub-processors (the existing ones and any new ones added in the quarter). The team documents the SCCs, the supplementary measures, the re-routing decisions.
• Day 151 to 180, Integration. The team builds the integration with the ROPA (A.2.2.7), the records of disclosures (A.2.5.4), the change-management records (Clause 6.3), and the management review (Clause 9.3). The team rolls out the KPIs (Section 12) and the dashboard.

The 9-to-12-month arc, full maturity

• Month 7, Offboarding procedure and drill. The team writes the Offboarding Procedure (toolkit doc 02 Phase 5) and runs the first annual offboarding drill (a tabletop with a volunteer sub-processor).
• Month 8, Continuous monitoring. The team stands up the continuous monitoring (the security-rating service subscription; the annual due-diligence refresh schedule for the Tier B sub-processors; the cross-border landscape monitoring).
• Month 9, KPI rollout and management review. The team rolls out the fourteen KPIs to the management review (Clause 9.3). The team identifies the improvement actions for the next cycle (Clause 10.1).
• Month 10, Internal audit. The team runs the internal audit (Clause 9.2) covering the register, the engagement procedure, the flow-down, the change-notification discipline, the objection-handling workflow, the chain-transfer re-assessment, the offboarding.
• Month 11, Certification Stage 1. The certification Stage 1 documentation review. The team closes the findings before the Stage 2.
• Month 12, Certification Stage 2. The Stage 2 operational-effectiveness test. The auditor walks a sample of engagement records, change notifications, and objection-handling decisions through the five-phase lifecycle.

The ongoing cadence (post-certification)

• Weekly, Register activity review (DPO); new-engagement intake review (Procurement); shadow-sub-processor discovery follow-up (Engineering).
• Monthly, KPI dashboard review (DPO); change-notification timeliness review; objection-handling review.
• Quarterly, Register reconciliation with the vendor master and the engineering-integrations list; published-list currency check; risk-tier re-assessment for the Tier B sub-processors; objection-handling outcome review.
• Semi-annually, Chain-transfer re-assessment refresh for the cross-border tier; offboarding audit (a sample of terminated sub-processors with the data-destruction certification).
• Annually, Internal audit of A.2.5.7 / A.2.5.8 / A.2.5.9; offboarding drill; Sub-processor Management Policy review; flow-down clause library refresh; procurement and engineering training refresh.
• Event-driven, Sub-processor ownership change (the chain-transfer re-assessment and the controller notification); sub-processor breach (the chain breach-handoff); controller objection (the workflow); regulatory change (the legal-and-compliance checklist updated); new sub-processor category (the engagement procedure extended).

FAQ

Q1. Our customer DPA already has a sub-processor clause that says we will impose equivalent terms on our sub-processors. Is that enough for A.2.5.8?

No. A.2.5.8 is an operational control, not a contractual control. The DPA clause must be backed by the actual flow-down contract (executed with each sub-processor), the due-diligence pack, the authorisation record, and the engagement record. The certification auditor and the regulator will look behind the clause to the operational evidence.

Q2. We have a published sub-processor list on our website. Have we satisfied A.2.5.7?

Partially, if the published list is current, complete, and referenced by the customer DPA as the disclosure channel. A published list that the DPA does not reference is not the disclosure the controller agreed to. A published list that omits the shadow sub-processors is incomplete. A published list that is months stale is a non-disclosure. The register is the master; the published list is the controller-facing view; the two must reconcile.

Q3. We use a general-authorisation regime in our DPAs. Does that mean we can engage any sub-processor without notifying the controller?

No. The general-authorisation regime waives the per-engagement controller approval; it does not waive the change-notification duty (A.2.5.9) or the controller's objection right. The processor must still send the change notification within the DPA's notice window; the controller may still object; the objection-handling workflow still applies.

Q4. A controller objects to a sub-processor we have already engaged. What do we do?

Operate the objection-handling workflow. The options: decline to use the sub-processor for the objecting controller's data (the cleanest outcome, requires the technical architecture to support customer-specific data routing); restrict the sub-processor's role (a reduced data set; additional safeguards); negotiate with the controller (additional information; security assurance); escalate through the DPA's dispute mechanism. The objection cannot be ignored; the documented workflow is the control.

Q5. Our engineering team integrated an analytics SDK last quarter without going through procurement. What do we do?

Register the SDK vendor retrospectively; run the due diligence; execute the flow-down; assess the disclosure gap (should the controller have been notified before the integration?); communicate the disclosure update to the affected controllers; embed the engagement workflow in the engineering team's intake process so it does not recur. The shadow sub-processor is the highest-frequency audit finding; the quarterly reconciliation workshop is the discipline that surfaces them.

Q6. We have a sub-processor in the United States, and our controller-customer is in the EU. What cross-border analysis do we need?

The chain-transfer re-assessment under Schrems II. The transfer mechanism (the EU SCCs, the processor-to-processor module for the India-US leg, or the controller-to-processor module with the controller as a third-party beneficiary); the destination's surveillance law assessment (the US FISA 702 / CLOUD Act considerations); the supplementary measures (the encryption with keys the processor holds; the split processing; the contractual challenge commitments). The re-assessment documents the analysis; the flow-down contract accommodates the SCCs.

Q7. Our bank customer's DPA requires specific authorisation for every sub-processor. The customer takes 4 weeks to approve each one. Our product velocity is suffering. What do we do?

Negotiate a hybrid regime with the customer, specific authorisation for the high-risk sub-processors (the ones touching the bank's data); general authorisation with notice for the low-risk sub-processors (the infrastructure-only vendors with no access to the bank's data). The RBI Managing Risks in Outsourcing Directions, 2025 allow the bank to permit further outsourcing with prior written permission, the permission regime can be structured to accommodate the risk tiers. The negotiation is a commercial conversation; the DPA amendment is the legal mechanism.

Q8. Our sub-processor has been acquired by another company. What do we do?

Trigger the change procedure. The ownership change is a sub-processor change under A.2.5.9. Assess the acquiring entity (the due diligence; the jurisdiction; the data-protection posture); conduct the chain-transfer re-assessment if the acquiring entity is in a different jurisdiction; notify the affected controller-customers within the notice window; handle any objections. The ownership-change trigger is the most-overlooked change category; the engagement procedure must flag it.

Q9. Our sub-processor suffered a breach. What do we do?

Trigger the chain breach-handoff. The sub-processor's flow-down breach clause requires it to notify the processor without undue delay (the timeline, typically 24 to 48 hours, to give the processor time to comply with its own handoff duty). The processor's incident-response team assesses the breach; the processor notifies the affected controller-customers (under the customer DPA's breach clause; within the timeline, typically 48 to 72 hours); the controller notifies the Board and the affected principals (under section 8(6); without delay, with a detailed report within 72 hours of the controller's awareness). The CERT-In 6-hour clock runs in parallel where the breach affects an India-ICT system. The chain pattern is the operational integration.

Q10. We want to terminate a sub-processor. What do we do?

Operate the offboarding procedure. The termination notice (the flow-down contract's termination clause); the data-return or data-destruction (the sub-processor returns or destroys the personal data; the certification of destruction); the access revocation (the credentials, the API keys, the network access); the post-engagement obligations (the confidentiality; the audit cooperation; the breach-notification duty for incidents discovered after termination); the register update and the disclosure update (the published list reflects the removal). The offboarding cycle should be tested annually through a drill.

Q11. Our controller-customer is an SDF under DPDP section 10. Do the three controls impose additional duties on us?

Yes. The SDF's enhanced duties (SDF DPIA support, independent-audit cooperation, algorithmic-software review support) propagate through the chain. The flow-down contract must require the sub-processor to support these duties, the sub-processor's cooperation with the SDF's DPIA (providing information about the sub-processor's processing, the security controls, the cross-border flows); the sub-processor's cooperation with the SDF's independent audit; the sub-processor's cooperation with the algorithmic-software review where the sub-processor's processing touches an AI feature. The sub-processor chain is the operational surface where the SDF's enhanced duties propagate downstream.

Q12. Our flow-down contracts are inconsistent, some have detailed flow-downs; some are click-through terms. What do we do?

Run the flow-down refresh programme. Stand up the Flow-down DPA Clause Library (toolkit doc 10); refresh the existing detailed flow-downs to the new library; replace the click-through terms with the new flow-downs. The long tail (the click-through vendors) is where the effort sits; the refresh programme is the remediation. The contract-management platform tracks the refresh progress.

Q13. Our change-notification window is 30 days per our standard DPA. Can we use a shorter window for a quick integration?

Only with the controller's written agreement. The DPA's notice window is the floor; the processor may use a longer window but not a shorter one without the controller's waiver. For a quick integration where the 30-day window is not feasible, the options: comply-with-conditions (the controller waives the window in writing and accepts the consequences, appropriate only for low-risk sub-processors); use a sub-processor within the pre-approved class (the general-authorisation regime; no per-change notice required if the DPA's general-authorisation covers it); or postpone the integration until the window runs.

Q14. We are a B2B service and our customer is the controller; we are the processor. Do the three controls sit on our side or our customer's side?

Both sides. The customer (controller) has the controller-side discipline (the controller authorises the chain; the controller receives the disclosure; the controller has the right to object) under A.1.2.7 (contracts with PII processors). The processor has the A.2.5.7 / A.2.5.8 / A.2.5.9 controls, the operational gate through which every sub-processor passes. The two sides are sequential: the controller sets the regime through the DPA; the processor operates the regime through the three controls.

Q15. Our sub-processor uses its own sub-processors (a sub-processor of the sub-processor). Are we responsible for the inherited chain?

Yes, through the flow-down contract. The flow-down requires the sub-processor to impose equivalent terms on its own sub-processors; the processor's register records the material inherited sub-processors; the processor's oversight extends to the material chain. The processor is not directly responsible for the inherited sub-processor's compliance (the sub-processor is), but the processor is responsible for the flow-down that should have bound the inherited sub-processor. The annual due-diligence refresh for Tier B sub-processors includes the inherited-chain assessment.

Industry-Specific Requirements

BFSI processors

BFSI processors, the BPOs, ITeS providers, analytics vendors, payment processors, core-banking-software providers, and cloud-service resellers that serve banks, NBFCs, insurers, and SEBI-regulated intermediaries, operate under the most prescriptive Indian sectoral sub-processor regime. The load-bearing instruments:

• RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025), the bank's outsourcing agreement with the processor must not permit the processor to further outsource without the bank's prior written permission (the marquee Indian specific-authorisation rule); the agreement must allow RBI inspection of the processor and its sub-processors; the bank's instructions on sub-processor engagement must be governed.
• RBI NBFC Managing Risks in Outsourcing Directions, 2025, equivalent NBFC duties.
• SEBI CSCRF (20 August 2024), third-party and outsourcing expectations for SEBI-regulated intermediaries; the sub-processor chain is the RE's exposure.
• IRDAI Information and Cyber Security Guidelines (24 April 2023), ICT-outsourcing data-protection clauses; the insurer's processor must impose equivalent terms on its sub-processors.
• RBI Storage of Payment System Data (6 April 2018), payment-data localisation; the sub-processors that touch payment-system data must store it in India only.

Sub-processor chain emphasis for BFSI processors. The specific-authorisation regime is the default (the bank's prior written permission for each sub-contracting). The marquee sub-processor-chain refusals: a bank's instruction to bypass the prior-permission rule (a textbook A.2.2.5 infringement); a bank's instruction to share payment data with a sub-processor outside India (a textbook RBI localisation infringement). The processor's flow-down must accommodate the BFSI overlay (the audit rights that extend to the RBI; the data-localisation clauses for payment data; the incident-notification timelines that run faster than the DPDP default).

Healthcare processors

Healthcare processors, the BPOs, telemedicine platforms, electronic-health-record vendors, diagnostic-lab software providers, claims-processing providers, and the emerging tier of AI-diagnostics and clinical-decision-support vendors, handle some of the most sensitive personal data in the Indian market. The DPDP Act's sensitivity overlay, the putative Digital Information Security in Healthcare Act (DISHA, still a draft bill as of mid-2026), the clinical-establishment regulations of the states, and the Indian Medical Council's professional-conduct regulations create a layered regime.

Sub-processor chain emphasis for healthcare processors. The functional sub-processor category is the marquee, the transcription services, the AI-diagnostics vendors, the clinical-decision-support providers that touch patient data. The chain governance must address: the sensitivity of health data (the higher risk-tier for any sub-processor touching health data); the AI sub-processors (the algorithmic-software dimension that propagates to the controller-customer's SDF duties under section 10); the cross-border dimension (the telemedicine platforms that route consultations across borders for second-opinion services). The flow-down must require the sub-processor to support the controller-customer's sector-specific duties.

IT-ITeS and SaaS processors

IT-ITeS and SaaS processors, the largest segment of Indian processors, operate across multiple jurisdictions (DPDP for India customers, GDPR for EU customers, US-state laws for US customers, PIPL for China customers, LGPD for Brazil customers) and serve the most diverse customer portfolio. The sub-processor estate is correspondingly diverse, from infrastructure clouds to SDK vendors to AI-model providers.

Sub-processor chain emphasis for IT-ITeS and SaaS processors. The multi-jurisdiction chain regime (a single sub-processor may serve customers across jurisdictions, the chain-transfer re-assessment must address each applicable regime); the customer-portal change-notification workflow as the gold-standard disclosure channel; the AI-model sub-processor tier (the marquee new category, the Article 28(10) drift question at the sub-processor layer); the SDK and marketplace discovery discipline (the invisible sub-processors); the customer-portfolio risk analysis at the management review.

E-commerce and retail processors

E-commerce and retail processors, the payment processors, logistics providers, marketing-technology vendors, recommendation-engine providers, and customer-analytics providers that serve e-commerce-controller customers, handle high-volume consumer data and face the most aggressive functional sub-processor profile.

Sub-processor chain emphasis for e-commerce and retail processors. The payment-rail sub-processor category (the RBI payment-data localisation overlay, the sub-processor must store payment data in India only; the tokenisation discipline under the RBI tokenisation directive); the recommendation-engine sub-processor category (the cross-customer data-sharing risk, a recommendation engine serving two competing e-commerce customers must be configured to prevent leakage); the marketing-technology sub-processor category (the controller's marketing-use instruction that engages a marketing-technology sub-processor without the change notice, a textbook A.2.5.9 infringement); the personalisation sub-processor category (the Article 28(10) drift at the sub-processor layer).

Edtech processors

Edtech processors, the learning-management-system providers, the assessment-platform providers, the proctoring-platform providers, the analytics providers that serve edtech-controller customers, handle student and parent data, including children's data (DPDP section 9).

Sub-processor chain emphasis for edtech processors. The children's-data overlay (DPDP section 9) makes every sub-processor involving a child's data a high-risk engagement. The processor's engagement procedure must flag children's-data sub-processors as Tier B (approved-with-conditions) or Tier C (declined) by default. The behavioural-monitoring and targeted-advertising prohibitions in section 9 are absolute, an edtech-controller customer's instruction to engage a sub-processor that enables behavioural monitoring or targeted advertising for users under eighteen is a textbook section 9 infringement and a textbook A.2.5.8 infringement. The flow-down must require the sub-processor to support the verifiable-parental-consent procedure.

Manufacturing processors

Manufacturing processors, the IIoT-platform providers, the supplier-management-software providers, the channel-partner-management providers, the predictive-maintenance analytics providers that serve manufacturing-controller customers, typically process less consumer-principal data than the other segments but face unique employee-data and supplier-contact-data challenges.

Sub-processor chain emphasis for manufacturing processors. The IIoT-cloud sub-processor category (the equipment-usage data that may identify individual operators, a less-obvious personal-data category that the chain governance must capture); the cross-border sub-processor category (a multinational manufacturing-controller's sub-processor that shares supplier-contact data across the group's global affiliates, the chain-transfer re-assessment); the analytics sub-processor category (the predictive-maintenance analytics that use equipment data to draw inferences about operator behaviour, the Article 28(10) drift at the sub-processor layer); the employee-monitoring sub-processor category (a manufacturing-controller's instruction to engage a sub-processor that enables location-tracking on the plant floor).

Government processors

Government processors, the IT-services providers that serve government-controller customers (the public-sector-undertaking customers, the central-government-ministry customers, the state-government-department customers), operate under the DPDP Act's section 17 exemptions (certain state-processing exemptions) but are bound by the broader DPDP obligations where the government processes digital personal data in the conventional sense.

Sub-processor chain emphasis for government processors. The exemption analysis under section 17 (does the government's processing qualify for an exemption? does the sub-processor inherit the exemption?); the localisation expectations for government data (the data-residency considerations that may require the sub-processor to be India-based); the joint-controller analysis with the public-sector technology partners; the legal-process handling for government-instructed data sharing.

Maturity Model

Level 1, Initial / Ad-hoc

Characteristics. No Sub-processor Register. A published URL that the customer DPA may or may not reference, with a partial and stale list. No engagement procedure. No due diligence beyond a basic vendor form. The flow-down contract is a one-line confidentiality clause for the primary sub-processors; click-through terms for the long tail. No change-notification discipline. No objection-handling workflow. No chain-transfer re-assessment. No offboarding discipline. The most common audit nonconformity pattern in Indian growing-company processors.

Typical artefacts. A DPA template with a sub-processor clause inherited from a standard template. A published URL with 5 to 15 entries. No other sub-processor artefacts.

Investment to reach L1. None, this is the floor.

The investment covers the register stand-up, the reconciliation workshop, the published-list update, the disclosure-correction communication, the due-diligence checklist, the flow-down clause library, the change-notification procedure.

Level 2, Repeatable / Defined

Characteristics. A documented Sub-processor Management Policy. A current Sub-processor Register reconciled with the vendor master and the engineering-integrations list. The published list current and delivered through the DPA's disclosure channel. The five-phase lifecycle procedure adopted. The due-diligence checklist calibrated to the sub-processor risk profile. The flow-down DPA clause library adopted. The first refresh of the flow-down contracts (primary sub-processors). The change-notification procedure operational. The first objections handled through the workflow.

Typical artefacts. The Policy; the Lifecycle Procedure; the Register; the published list; the Due-Diligence Checklist; the Flow-down DPA Clause Library; the first flow-down refresh; the Change-Notification Playbook; the first objection-handling records.

The investment covers the full flow-down refresh (the long tail), the chain-transfer re-assessment, the continuous-monitoring tooling, the offboarding drill, the KPI maturity.

Level 3, Managed / Measured

Characteristics. The full flow-down refresh completed across the sub-processor estate. The continuous monitoring operational (the security-rating service; the annual due-diligence refresh for Tier B). The chain-transfer re-assessment completed for the cross-border tier. The offboarding procedure drilled annually. The objection-handling workflow tested with multiple objections. The fourteen KPIs reporting; the first management-review pack produced. The first internal-audit report on the sub-processor chain.

Typical artefacts. The refreshed flow-down contracts; the continuous-monitoring evidence; the chain-transfer re-assessment reports; the offboarding drill report; the KPI dashboard; the first internal-audit report on the sub-processor chain.

The investment covers the multi-jurisdiction chain-transfer capability, the automated register with continuous reconciliation, the customer-portfolio risk analysis, the inherited-sub-processor discovery.

Level 4, Quantitatively Managed

Characteristics. The automated register with continuous reconciliation (the SDK and marketplace scanning; the inherited-sub-processor discovery; the engineering-integrations feed). The multi-jurisdiction chain-transfer re-assessment capability operational (DPDP plus GDPR plus US-state plus sector rules). The customer-portfolio risk analysis driving the management review. The objection-handling workflow mature (objections tracked, outcomes analysed, the workflow improved). The KPI targets consistently met; the management-review pack driving Clause 10.1 improvement. The offboarding drill run semi-annually; the chain breach-handoff drilled with multiple sub-processors.

Typical artefacts. The automated register evidence; the multi-jurisdiction re-assessment checklist; the customer-portfolio risk analysis; the semi-annual offboarding drill reports; the management-review minutes with KPI trend analysis.

Level 5, Optimising

Characteristics. The sub-processor governance programme is continuously improved; the register is the system-of-record for the broader vendor-relationship-management practice. The chain-transfer re-assessment methodology is at the frontier (the team contributes to the sector's methodology; publishes anonymised lessons). The offboarding drill is run quarterly with multiple volunteer sub-processors. The programme produces predictive analytics (sub-processor risk forecasting; objection-pattern analysis; the inherited-chain risk model). The processor's sub-processor governance is benchmarked against the industry; the processor contributes to the standard's evolution.

Typical artefacts. The continuous-improvement log; the predictive-analytics dashboard; the multi-sub-processor drill reports; the industry-benchmarking evidence.

Maturity-model quick-reference

Emerging Trends

The AI-model sub-processor as the marquee new category

The AI-model vendor is the marquee new sub-processor category of the 2025 to 2027 window. Processors that offer AI-driven services (analytics, personalisation, recommendation, prediction, generative features) on top of customer data routinely engage AI-model vendors (the model providers, the inference-service providers, the fine-tuning platforms). The chain governance questions are sharp: does the AI-model vendor process the customer's personal data? (typically yes, the prompts, the context, the outputs may contain personal data); what is the chain-transfer risk? (many AI-model vendors are in jurisdictions with surveillance laws that trigger Schrems II supplementary measures); does the AI-model vendor use the customer's data for its own model-training? (the Article 28(10) drift question at the sub-processor layer). Processors that build the AI-model sub-processor tier into their governance early are well-prepared for the AI-driven service launches.

The DPDP section 8(6) chain breach-handoff as the operational standard

The DPDP section 8(6) breach-notification duty, operationalised by the DPDP Rules 2025 Rule 7 (intimation to the Board without delay; detailed report within 72 hours), is becoming the operational standard against which the regulator and the certification auditor compare every processor's chain breach-handoff. The chain pattern (sub-processor → processor → fiduciary → Board) means the sub-processor's handoff timeline is the gating constraint, a sub-processor that takes 72 hours to notify the processor leaves the processor with no time to notify the fiduciary, and the fiduciary with no time to notify the Board. The flow-down breach clause must set the sub-processor's handoff at 24 to 48 hours (to give the processor the buffer). Processors that drill the chain breach-handoff quarterly (or semi-annually for high-risk processors) with their sub-processors are operating at the most mature end of the spectrum.

The continuous-monitoring convergence

The continuous-monitoring tools (the security-rating services, the TPRM platforms with continuous posture assessment, the SDK and marketplace scanners) are converging into an integrated capability. The processor's sub-processor register is increasingly fed by continuous feeds, the security-rating service alerts on a sub-processor's posture change; the SDK scanner discovers a new SDK vendor in the dependency manifest; the marketplace scanner flags a new marketplace app. The continuous-monitoring convergence reduces the shadow-sub-processor risk and the stale-register risk; the processors that invest in the integration early are operating ahead of the curve.

The multi-jurisdiction chain regime

The multi-jurisdiction chain regime is becoming the operational reality for Indian processors. The DPDP, GDPR, US-state, China PIPL, Brazil LGPD, and the sector rules (RBI, SEBI, IRDAI) impose overlapping but not identical sub-processor duties. A single sub-processor serving customers across jurisdictions triggers multiple regimes, the chain-transfer re-assessment must address each. The convergence is not perfect (the US-state model differs in the sub-processor's obligations; PIPL adds the CAC security-assessment overlay for cross-border sub-processor arrangements), but a processor that builds to the DPDP-plus-GDPR core will be substantially conformant with the wider landscape with per-jurisdiction configuration.

The sub-processor register as the system-of-record for vendor-risk

The sub-processor register is increasingly the system-of-record for the broader vendor-risk practice, the processor's understanding of which vendors are high-risk, which vendors have had incidents, which vendors are approaching renewal. The convergence is operational; the register, the vendor-risk register, the incident register, and the chain-transfer re-assessment records are increasingly integrated into a single vendor-risk evidence base. Processors that design the integration from day one avoid the fragmentation that the pre-remediation state typically exhibits.

The objection-handling workflow as a customer-trust differentiator

The objection-handling workflow is increasingly being used as a customer-trust differentiator in the enterprise-procurement segment. Processors that handle objections well (the timely acknowledgement; the structured assessment; the response options; the customer-relationship preservation) are differentiated from processors that handle objections poorly (the ignored objection; the unilateral decision; the customer-relationship damage). The change-notification-and-objection workflow in the customer portal is the operational expression; the enterprise customers increasingly ask about the workflow in their vendor-diligence questionnaires.

The regulatory-convergence trend (DPDP, GDPR, US-state, sectoral)

The A.2.5.7 / A.2.5.8 / A.2.5.9 dimensions of DPDP, GDPR Article 28, US-state laws (CCPA/CPRA service-provider; VCDPA / CPA / CTDPA processor), the sectoral regimes (RBI IT Outsourcing; SEBI CSCRF; IRDAI ICT-outsourcing; CERT-In Directions), and the global processor regimes (PIPL Article 21; LGPD Article 39; PDPA Singapore section 11) are converging on a similar operational core: a current sub-processor register disclosed to the controller; engagement through due diligence and authorisation; flow-down contract; change notification with objection right; chain-transfer re-assessment; offboarding with data-destruction. The converged architecture is the Singahi recommended pattern; a processor that builds to the converged core will be conformant with the wider landscape with per-jurisdiction configuration.

The chain-transfer re-assessment as the Schrems II operationalisation

The chain-transfer re-assessment is increasingly being recognised as the operational expression of the Schrems II duty. The European Data Protection Board's Recommendations 01/2020 on supplementary measures, the modernised SCCs (Implementing Decision 2021/914 with the processor-to-processor module), and the EU-US Data Privacy Framework (the adequacy decision adopted 10 July 2023) have together made the chain-transfer re-assessment a routine step for any cross-border sub-processor. Indian processors with EU customers are at the frontier of this trend; the processors that build the chain-transfer capability early are well-prepared for the global customer portfolio.

The processor-side ethical-AI dimension in the chain

The processor-side ethical-AI dimension intersects A.2.5.8 where the sub-processor is an AI-model vendor. A controller-customer's instruction to use the processor's AI-driven service on the controller's data may raise ethical-AI questions (the model's bias, the model's explainability, the principal's right to a human decision) that propagate to the sub-processor. The processor's engagement due diligence should flag the ethical-AI dimension and require the AI-model sub-processor to support the controller-customer's DPIA under A.1.2.6 and the algorithmic-software review under DPDP Rule 13(3) SDF. The convergence of A.2.5.8 and the ethical-AI dimension is an emerging area that processors should monitor.

References and Further Reading

Standards and regulations

• ISO/IEC 27701:2025, Information security, cybersecurity and privacy protection, Privacy information management systems, Requirements and guidance (published 14 October 2025).
• ISO/IEC 27001:2022, Information security management systems, Requirements.
• ISO/IEC 27002:2022, Information security controls (only control 5.34 is PII-specific; controls 5.19 to 5.23 govern supplier relationships).
• ISO/IEC 27018:2019, Code of practice for protection of PII in public clouds acting as PII processor (the cloud-processor sub-processor clauses).
• ISO/IEC 27017:2015, Code of practice for cloud security.
• ISO/IEC 29100:2011, Privacy framework (eleven privacy principles).
• ISO/IEC 29134:2017, Guidelines for privacy impact assessment (the DPIA how-to).
• ISO/IEC 29151, Code of practice for PII protection.
• ISO/IEC 27706:2025, PIMS certification-scheme competence (Ed 1, October 2025; replaces ISO/IEC TS 27006-2:2021).
• ISO/IEC 17021-1:2015, Management-system certification-body requirements.
• ISO/IEC 27006 (current edition), ISMS certification-body requirements.

Indian regulatory instruments

• Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023, enacted 11 August 2023; eGazette notification 247847). Source: meity.gov.in.
• Digital Personal Data Protection Rules, 2025 (notified 13 November 2025; phased commencement). Source: meity.gov.in.
• Information Technology Act, 2000 (Act No. 21 of 2000), sections 43A and 72A. Source: indiacode.nic.in.
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (notified 11 April 2011).
• CERT-In Directions No. 20(3)/2022-CERT-In (28 April 2022) under section 70B(6) of the IT Act, 2000. Source: cert-in.org.in.
• RBI, RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025). Source: rbi.org.in.
• RBI, RBI NBFC Managing Risks in Outsourcing Directions, 2025. Source: rbi.org.in.
• RBI, Storage of Payment System Data, RBI circular DPSS.CO.OD.No.1098/06.08.005/2017-18 (6 April 2018). Source: rbi.org.in.
• RBI, Digital Lending Guidelines, RBI circular DOID.CO.PPG.SEC.09/14.14.001/2022-23 (2 September 2022). Source: rbi.org.in.
• RBI, Tokenisation of Card transactions, RBI circular DPSS.CO.RPPD.No.S-35/07.01.005/2021-22 (22 September 2021). Source: rbi.org.in.
• SEBI, Cybersecurity and Cyber Resilience Framework (CSCRF) 2024, circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 August 2024). Source: sebi.gov.in.
• SEBI, KYC Registration Agencies Regulations, 2011 (as amended); KRA Master Circular (May 2024). Source: sebi.gov.in.
• IRDAI, Information and Cyber Security Guidelines, 2023 (24 April 2023). Source: irdai.gov.in.

Jurisprudence

• K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (judgment delivered 24 August 2017 by a nine-judge Bench of the Supreme Court of India), the fundamental right to privacy; the proportionality test.
• Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1 (26 September 2018, five-judge Bench), the proportionality test applied; section 57 of the Aadhaar Act struck down.
• Case C-311/18, Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (Schrems II), EU:C:2020:559 (Court of Justice of the European Union, Grand Chamber, 16 July 2020), the transfer-impact assessment duty; the chain-transfer re-assessment's doctrinal foundation.

Global regulations (mapped in Section 16)

• Regulation (EU) 2016/679 (General Data Protection Regulation), OJ L 119, 4.5.2016, p. 1; application from 25 May 2018. Source: eur-lex.europa.eu. Article 28 processors (Article 28(2) general authorisation and objection right; Article 28(3)(a) documented-instruction transfer to sub-processor; Article 28(3)(f) sub-processor authorisation; Article 28(4) flow-down of equivalent terms; Article 28(3)(g) and (h) audit rights); Article 29 cooperation; Article 32 security; Article 33(2) processor-to-controller breach notification (the chain-handoff analogue).
• Regulation (EU) 2024/1689 (Artificial Intelligence Act), OJ L, 12.7.2024, the fundamental-rights impact assessment overlay for high-risk AI systems (relevant to the AI-model sub-processor).
• Commission Implementing Decision (EU) 2021/914 of 4 June 2021, modernised Standard Contractual Clauses (the processor-to-processor module at Clause 9 is the load-bearing SCC for A.2.5.8 cross-border flow-down).
• European Commission adequacy decision on the EU-US Data Privacy Framework (10 July 2023).
• UK GDPR; Data Protection Act 2018 (c. 12); UK International Data Transfer Agreement (IDTA) and UK Addendum to EU SCCs.
• California Consumer Privacy Act / California Privacy Rights Act (Cal. Civ. Code 1798.100 et seq.), the "service provider" / "contractor" sub-processor discipline and the contract-content requirements.
• Virginia Consumer Data Protection Act (Va. Code § 59.1-575 et seq.), processor sub-processor duties (the contract must require equivalent terms).
• Colorado Privacy Act (C.R.S. § 6-1-1301), processor sub-processor duties.
• Connecticut Data Privacy Act (Public Act 22-15), processor sub-processor duties.
• Brazil, LGPD (Lei nº 13.709/2018), effective 18 September 2020. Article 39 operator duties (the sub-processor flow-down).
• China, PIPL, effective 1 November 2021. Article 21 entrusted processing (the sub-processor regime; Article 38 cross-border mechanisms, the CAC security assessment, the CAC standard contract, the certification).
• Singapore, PDPA 2012 (No. 26 of 2012) as amended; section 11 protection obligation (the chain flow-down).
• Canada, PIPEDA (S.C. 2000, c. 5); accountability principle 4.1.3 (the chain accountability).
• Australia, Privacy Act 1988; Australian Privacy Principles (APP 11 security; APP 8 cross-border).
• South Korea, PIPA (Act No. 10469 of 2011, as amended 2023).
• UAE, Federal Decree-Law No. 45 of 2021 (PDPL).
• Saudi Arabia, PDPL (Royal Decree M/19), in force 14 September 2023.
• South Africa, POPIA (Act 4 of 2013), fully in force 1 July 2021.

Frameworks and guidance

• NIST Privacy Framework v1.0: A Tool for Improving Privacy Through Enterprise Risk Management, NIST.CSWP.01162020 (16 January 2020). Source: nist.gov/privacy-framework.
• NIST AI Risk Management Framework (AI RMF 1.0), NIST.AI.100-1 (26 January 2023). Source: nist.gov.
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (TSC 2017; 2022 Points of Focus update). The Privacy criteria: P1.0 to P8.0; P6.0 (Disclosure and notification) is the load-bearing mapping for A.2.5.7 / A.2.5.9; the Common Criteria CC9.2 (vendor oversight) is the load-bearing mapping for A.2.5.8.
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR; Guidelines 07/2020 on Articles 28 and 29 (processor duties, including the sub-processor flow-down); Recommendations 01/2020 on supplementary measures for transfer tools (the Schrems II chain-transfer re-assessment doctrinal source); Guidelines 9/2022 on personal data breach notification.
• Article 29 Working Party, WP248 rev.01, Guidelines on Data Protection Impact Assessment.
• ICO (UK) Accountability Framework; ICO guidance on controllers and processors; ICO data-processing agreements template (the sub-processor clauses).
• CNIL (France), recommendations on the selection of processors and sub-processors; the CNIL DPA models.

Certification-scheme and practitioner references (generic)

• IAF (International Accreditation Forum), note: no PIMS-specific IAF MD identified as of mid-2026.
• Accreditation bodies active in PIMS: ANAB, UKAS, DAkkS, COFRAC, JAB, CNAS, and others.
• The certification-scheme rule-set: ISO/IEC 17021-1:2015; ISO/IEC 27006; ISO/IEC 27706:2025.