ISO 27701 A.2.5: Sharing Transfer and Disclosure (Remaining)

Quick Reference (60 Seconds)

If you only read one thing: the A.2.5 family (remaining) is where the processor moves from "we follow the controller's instructions" to "we have a defensible processor-side transfer-and-disclosure operation". The five controls in this guide ask a single operational question, if a controller-customer, the Data Protection Board of India, a GDPR supervisory authority, or a court asked the processor, today, to produce the list of destinations it transfers the controller's personal data to (A.2.5.3), the per-flow transfer mechanism with the SCC reference, the TIA reference and the controller-authorisation reference (A.2.5.2), the per-event log of every disclosure the processor has executed on the controller's behalf in the last twelve months (A.2.5.4), the cross-border sub-processor engagements with the chain-transfer re-assessment linked (A.2.5.2 read with A.2.5.7), and the per-event log of every legally-binding disclosure request it has received with the controller-routing record and the legality assessment (A.2.5.6), could it? An A.2.5.2 / .3 / .4 / .5 / .6-conformant processor is one in which the destination register is documented and reconciles to the customer DPA's permitted-destinations list and to the DPDP §16 negative list; every cross-border flow has the controller's documented instruction plus a valid transfer mechanism (the SCCs executed, the adequacy decision current, the BCRs in place) plus a current TIA where Schrems II applies; the disclosure log covers every category, processor, sub-processor, joint-controller, third-party recipient, law-enforcement request, regulator direction, court order, with the lawful basis, the contract reference and the disclosure date; the sub-processor transfer record (A.2.5.2 read with A.2.5.7) links every cross-border sub-processor to its chain-transfer re-assessment and its controller-authorisation; the law-compulsion-request procedure routes every request to the controller within 24 hours of intake (unless the law prohibits), runs the multi-factor legality assessment in parallel, and logs the request and the response. Not a customer DPA that says "the processor shall transfer only on the controller's instructions and keep records"; five registers that prove it. The certification auditor picks a recent disclosure, a new sub-processor abroad, a recent support escalation to a foreign vendor, a recent regulator direction, and walks the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record (A.2.5.2 read with A.2.5.7), the legality assessment and the controller-routing record. The Data Protection Board of India will, after a complaint or an incident, ask whether the processor screened the destination, executed the mechanism, logged the disclosure, traced the chain transfer and routed the law-compulsion request to the controller. Get A.2.5.2 / .3 / .4 / .5 / .6 wrong, no destination register, no mechanism register, no disclosure log, no sub-processor transfer record, no law-compulsion-request procedure, 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

The paraphrased family-level requirement

ISO/IEC 27701:2025 controls A.2.5.2, A.2.5.3, A.2.5.4, A.2.5.5 and A.2.5.6 ask PII processors to inform the controller-customer, in a timely manner, of the basis on which it transfers that customer's personal data between jurisdictions, and to give advance notice of any intended change, within an agreed time frame, so the customer can object or terminate (A.2.5.2); to maintain a documented list of the destinations to which the processor will transfer (A.2.5.3) bounded by the controller's instructions, the DPDP cross-border regime and the sector rules; to keep records of every disclosure of personal data to a third party, including the disclosures to sub-processors and the disclosures made under legal compulsion (A.2.5.4); to notify the controller-customer of any legally binding request it receives for the disclosure of that customer's personal data, within the agreed time frame and by the agreed procedure (A.2.5.5); and to handle every legally-binding disclosure request that lands with the processor through a documented procedure that routes the request to the controller before compliance, logs the request and the response, and applies the multi-factor legality test (A.2.5.6).

The five controls operate as a coherent cluster inside theme A.2.5. A.2.5.2 is the mechanism layer, it answers the question "by what authority and under what transfer tool does the processor move the controller's data across borders?". A.2.5.3 is the spatial layer, it answers "to where?". A.2.5.4 is the event layer, it answers "what was disclosed, to whom, when, on what basis?". A.2.5.5 is the notification layer, it answers "when a legally binding request for this customer's data arrived, was the customer told, within the agreed time frame and by the agreed procedure?" The chain-transfer question, "for the sub-processor chain, what is the transfer-related disclosure for each cross-border engagement?". A.2.5.6 is the compulsion layer, it answers "when the law compels disclosure, what does the processor do?". The five together produce the processor's disclosure footprint on behalf of the controller: a controller-walkable, auditor-testable, regulator-presentable map of where the controller's personal data has gone under the processor's control, on what basis, and against which records.

The five controls sit upstream of the A.2.5.7 / A.2.5.8 / A.2.5.9 sub-processor chain (the Singahi flagship processor guide). A.2.5.7 governs the static disclosure of the sub-processor list; A.2.5.8 governs the engagement gate; A.2.5.9 governs the change notification. A.2.5.5 (in this guide) is the slice of the chain governance that captures the transfer-disclosure for each cross-border sub-processor, the bridge between this guide's transfer-and-disclosure discipline and the chain governance of A.2.5.7 to A.2.5.9.

The lineage, 2019 to 2025

The five controls have clean ancestors in the 2019 edition. Under 27701:2019, the processor-side sharing-transfer-disclosure provisions lived scattered across clause 8.5 (sharing, transfer and disclosure) and clause 7 (the privacy-by-design extension clause). The 2025 consolidation regroups them inside theme A.2.5 of Table A.2 as controls A.2.5.2 to A.2.5.6 (the ".1" position is reserved for the objective statement, which is why the controls start at .2, the same pattern runs through A.2.2, A.2.3, A.2.4). The renumbering is mechanical; no substantive requirement has been deleted or added.

The 2025 edition's contribution is structural and normative. Annex B at B.2.5.2, B.2.5.3, B.2.5.4, B.2.5.5 and B.2.5.6 is now normative (it was informative Annex F in the 2019 edition). The B.2.5.2 guidance explains how the processor should structure the transfer-mechanism verification, the SCC execution, the adequacy check, the BCR reliance, the supplementary measures, the controller-instruction cross-reference. The B.2.5.3 guidance explains how the processor should structure the destination register, the customer-permitted-destinations overlay, the DPDP §16 screen, the sector-overlay screen, the next-review cadence. The B.2.5.4 guidance explains how the processor should structure the disclosure-event log, the reconciliation to the processor ROPA (A.2.2.7) and the retention of the log. The B.2.5.5 guidance explains how the processor should structure the sub-processor transfer record and link it to the chain-transfer re-assessment. The B.2.5.6 guidance explains how the processor should structure the law-compulsion-request procedure, the controller-routing discipline, the multi-factor legality assessment, the challenge procedure, the log entry, the gag-order handling. Auditors now test against B.2.5.x explicitly; an A.2.5.x audit that does not also walk through the B.2.5.x guidance is incomplete. The pre-Schrems-II, pre-DPDP framing of "follow the controller's instructions and keep a transfer list" is no longer sufficient; the auditor wants the destination register with the screen evidence, the per-flow mechanism with the SCC and the TIA references, the per-event disclosure log with the recipient and the basis, the sub-processor transfer record (A.2.5.2 read with A.2.5.7) cross-linked to the chain, and the law-compulsion-request procedure attached.

A.2.5.2 in detail, the basis for PII transfer between jurisdictions

ISO/IEC 27701:2025 control A.2.5.2 asks PII processors to transfer the controller-customer's personal data to another jurisdiction only on the controller's documented instruction and under a recognised transfer mechanism, the European Commission's adequacy decision (Article 45 GDPR where EU personal data is involved); the appropriate safeguards of Article 46 GDPR (the Standard Contractual Clauses of Implementing Decision (EU) 2021/914; the Binding Corporate Rules; the codes of conduct and certifications); the derogations of Article 49 GDPR (for occasional, non-systematic transfers); the DPDP Act section 16 permission (for India-anchored flows); or the equivalent mechanism under the applicable law.

Six load-bearing ideas sit inside this control. First, the processor transfers only on the controller's documented instruction. The customer DPA's transfer schedule is the source of the documented instruction; an instruction outside the DPA's schedule (a verbal direction; an email from the controller's operations team; a product-manager-level agreement) is not a "documented instruction" for A.2.5.2 purposes. The processor's instruction-decision log (under A.2.2.5) cross-references each transfer instruction to the DPA's transfer schedule and to the customer's written authorisation. The interlock between A.2.5.2 and A.2.2.5 (infringing instruction) is direct: a controller's instruction to transfer outside the documented mechanism is a textbook A.2.2.5 infringement and a textbook A.2.5.2 infringement.

Second, the processor must independently verify the transfer mechanism the controller names. The controller's instruction names a mechanism (SCCs; adequacy; BCRs; a DPDP-permitted route); the processor's verification confirms the mechanism is current and operational. The marquee verification failures: the controller's DPA cites SCCs that the processor has not yet executed (a paperwork gap; the processor is exposed because the actual contract is missing); the controller's DPA cites the EU-US Privacy Shield (invalidated by Schrems II in July 2020, the processor must challenge the instruction and propose the EU-US Data Privacy Framework or SCCs); the controller's DPA cites the pre-2021 SCCs (superseded on 27 December 2022, the processor must migrate to the modular SCCs of Decision 2021/914); the controller names an adequacy decision that has been suspended or repealed (the processor must re-screen and propose an alternative). The processor's transfer-mechanism register (toolkit doc 09) is the operational evidence of the verification.

Third, where SCCs are the mechanism, the processor executes the appropriate module. The 2021 modular SCCs have four modules: Module 1 controller-to-controller; Module 2 controller-to-processor; Module 3 processor-to-processor; Module 4 processor-to-controller. The processor's role in the chain determines the module: a controller-to-processor transfer uses Module 2 (with the controller as data exporter and the processor as data importer); a processor-to-sub-processor transfer across borders uses Module 3 (with the processor as data exporter and the sub-processor as data importer); a processor-to-controller transfer (the return of data to the controller in a different jurisdiction) uses Module 4. The processor must execute the correct module for each flow; the transfer-mechanism register records the module reference.

Fourth, where the destination lacks adequacy and SCCs are the mechanism, the Schrems II transfer-impact assessment is part of A.2.5.2. Case C-311/18 (Schrems II) requires the data exporter to verify, case-by-case, that the SCCs can be complied with in the destination, the destination's surveillance law (in the EU context, the US FISA 702 / Executive Order 12333 considerations; in other contexts, the equivalent surveillance regime); the destination's rights of redress for the principals; the supplementary measures (technical: encryption with keys held outside the destination, pseudonymisation, split processing; contractual: transparency-about-government-access commitments, challenge-of-unlawful-access commitments; organisational: the internal governance). The EDPB Recommendations 01/2020 on supplementary measures is the operational methodology. The processor's TIA per cross-border flow is documented in the transfer-mechanism register (toolkit doc 09 Part B).

Fifth, the DPDP section 16 permission is the Indian statutory mechanism. Section 16 of the DPDP Act permits transfer outside India except to countries or bodies the Central Government notifies as restricted, the "negative list" model. The processor's transfer of an Indian controller's data outside India is statutorily permitted under section 16 if the destination is not on the negative list. But the section 16 permission is a floor, the controller's instructions may be more restrictive (the controller's DPA may exclude destinations that section 16 permits), the sector rules may be more restrictive (the RBI payment-data localisation directive prohibits any payment-data transfer outside India regardless of the section 16 permission), and the processor's risk appetite may be more restrictive. The processor's destination register (A.2.5.3) operationalises the layered screen.

Sixth, the processor must keep the transfer-mechanism evidence current. A transfer mechanism that was valid at DPA signing may lapse, the SCCs may be superseded; the adequacy decision may be suspended; the destination's surveillance law may degrade; the controller's instructions may change. The processor's transfer-mechanism register has a next-review date per flow; the review confirms the mechanism is still valid; the lapsed mechanism triggers the re-screen and the re-execution (or the re-routing of the flow).

A.2.5.3 in detail, the destination-country register

ISO/IEC 27701:2025 control A.2.5.3 asks PII processors to maintain a current, documented list of the countries and international organisations to which the controller's personal data can be transferred, together with the basis on which the transfer is permitted and the conditions that apply.

Four load-bearing ideas sit inside this control. First, the processor's destination register is the processor's own, not a copy of the controller's list. The controller's permitted-destinations list (the A.1.5.3 artefact on the controller side) is one input; the processor's register is the synthesis of every applicable bound, the controller-customer's permitted-destinations list, the DPDP §16 negative-list screen, the sector-overlay screens (RBI payment-data localisation; SEBI KYC; IRDAI policyholder-data; CERT-In log localisation), the GDPR Chapter V cascade where EU personal data is processed, the processor's own risk appetite. The processor serves multiple controller-customers across multiple jurisdictions; the destination register is the least-permissive intersection of every bound that applies to each customer's data.

Second, the register is allow-list-shaped. Each destination entry is documented with the basis on which the transfer is permitted and the conditions that apply. The basis is the transfer mechanism (the SCCs; the adequacy; the BCRs; the DPDP permission; the derogation); the conditions are the supplementary measures (the encryption pattern; the contractual clauses), the principal-cohort restrictions, the data-category restrictions, the retention overlay. A destination entry without the basis and the conditions is a phone-book entry, not a register entry.

Third, the register is current. The processor refreshes the register on a documented cadence (typically quarterly) and on every legal-change event: a Central-Government notification adding a country to the DPDP restricted list; a European Commission adequacy decision being issued, suspended or repealed; a new sector-regulator locality rule; a new TIA finding on a destination; a new controller-customer DPA with a different permitted-destinations list. A register that has not been refreshed for two years is a finding, regardless of the legal-change events; the burden of staying current is on the processor.

Fourth, the register reconciles to live operations. The processor's destination register must reconcile to (a) the processor's transfer-mechanism register (A.2.5.2), (b) the processor's disclosure log (A.2.5.4), (c) the sub-processor transfer record (A.2.5.2 read with A.2.5.7), (d) the processor ROPA (A.2.2.7), (e) the sub-processor register (A.2.5.7), and (f) the live pipeline telemetry. A destination that appears in the pipeline telemetry but not in the register is the canonical A.2.5.3 finding, the processor is transferring to a destination it has not assessed.

A.2.5.4 in detail, the records-of-disclosure log

ISO/IEC 27701:2025 control A.2.5.4 asks PII processors to keep records of disclosures of personal data to third parties, what was disclosed, when, to whom, on what basis, with which contract reference, covering which principal cohort and which data categories. The disclosure log covers every category of disclosure: the processor's disclosures to its sub-processors; the processor's disclosures to its own processors (the second-tier chain); joint-controller disclosures (where the processor's customer is a joint controller with another entity); third-party-recipient disclosures (a downstream analytics vendor; a verification service); and the legally-binding disclosures under A.2.5.6 (law-enforcement requests; regulator directions; court orders, recorded in the same disclosure log with the legality-assessment reference).

Four load-bearing ideas sit inside this control. First, the disclosure log is event-shaped (or recurring-category-shaped). Each disclosure event is a record (an ad-hoc disclosure to a foreign vendor on a support escalation; a one-off processor-to-processor transfer for a migration). For steady-state flows (the daily sync to a sub-processor; the weekly feed to a verification service), the recurring flow is the record, with the recurring-category entry covering the period and the volume. The recurring-category shape is acceptable only where the processor can produce, on demand, the event-level evidence for any period within the recurring category.

Second, the disclosure log is distinct from the disclosure register (the recipient list). The recipient list is the system-of-record for the recipients; the disclosure log is the event log. The two cross-reference; the auditor tests reconciliation. A recipient list without a disclosure log is a policy without execution evidence; a disclosure log without a recipient list is execution evidence without policy.

Third, the disclosure log feeds the controller's Article 15 / DPDP §11 recipient-list response. Under GDPR Article 15(1)(c), the data subject is entitled to "the recipients or categories of recipients of the personal data"; under DPDP §11, the principal is entitled to "the identities of the Data Fiduciaries and Consent Managers with whom the personal data has been shared". The controller's response is built from the controller's own disclosure log plus the processor's disclosure log, the processor must, on the controller's request, produce the recipients of the controller's data that the processor has disclosed. The processor's disclosure log is therefore the operational engine for the controller's Article 15 / §11 compliance. A processor that cannot produce the recipient list from its disclosure log within the controller's SLA fails both A.2.5.4 and A.2.3.2 (comply with obligations to PII principals).

Fourth, the disclosure log is tamper-evident and reconciled. The log must be protected against falsification and unauthorised modification (A.3.14); the entries must be added in append-only mode; the log must reconcile to the underlying pipeline telemetry (the actual API calls, the actual SFTP events, the actual cross-border traffic) on a documented cadence (typically monthly). A disclosure log that lives in a spreadsheet on a shared drive, with no version control and no reconciliation, is the canonical A.2.5.4 anti-pattern.

A.2.5.5 in detail, the sub-processor transfer-disclosure record

ISO/IEC 27701:2025 control A.2.5.5 asks PII processors to keep, for every cross-border sub-processor engagement, the transfer-disclosure record, the transfer mechanism used, the destination, the chain-transfer re-assessment (TIA) reference, the controller's authorisation reference, the flow-down contract reference, the data categories accessed, the principal cohort, the engagement start date and the current status. The control sits at the intersection of A.2.5.4 (the broader disclosure log) and A.2.5.7 to A.2.5.9 (the sub-processor chain governance), it is the transfer-disclosure slice of the chain governance, the bridge that makes the chain transfer auditable end-to-end.

Four load-bearing ideas sit inside this control. First, the sub-processor transfer record is a slice of the disclosure log, with the transfer-specific dimensions added. Every cross-border sub-processor engagement is a disclosure (the sub-processor is a third-party recipient of the controller's data), it is in the A.2.5.4 disclosure log. The sub-processor transfer record adds the transfer-specific dimensions: the destination's surveillance regime assessment; the transfer mechanism (the SCC module, typically Module 3 processor-to-processor); the chain-transfer re-assessment (TIA) reference; the supplementary measures; the controller's authorisation (general or specific) reference; the flow-down contract's cross-border clauses. The A.2.5.5 record is therefore the deep-dive on the cross-border slice of the sub-processor chain; it is not a separate register.

Second, the chain-transfer re-assessment (the Schrems II TIA) is the load-bearing evidence. Every cross-border sub-processor engagement triggers the chain-transfer re-assessment under Schrems II (Case C-311/18), the destination's surveillance law, the rights of redress, the supplementary measures. The A.2.5.5 record links the engagement to its TIA; the TIA's findings (the supplementary measures needed; the re-routing decision where the destination's regime cannot be mitigated) drive the engagement decision. A cross-border sub-processor without a current TIA is the canonical A.2.5.5 finding, and the canonical A.2.5.8 finding (engagement without due diligence) and the canonical A.2.5.2 finding (transfer without a valid mechanism).

Third, the controller-authorisation reference is the legal anchor. The cross-border sub-processor engagement is authorised by the controller, either generally (the controller's DPA pre-approves a class of sub-processors, with the change-notification duty and the objection right under A.2.5.9) or specifically (the controller approves each named sub-processor individually). The sub-processor transfer record cites the authorisation basis (general or specific) and the controller's reference (the DPA clause; the specific-authorisation document; the change-notification record). The interlock with A.2.5.7 / A.2.5.8 / A.2.5.9 is direct, the A.2.5.5 record is the transfer-disclosure slice of the chain governance those controls operate.

Fourth, the A.2.5.5 record drives the controller's transfer-disclosure obligation. The controller's Article 15 / §11 recipient-list response includes the cross-border sub-processors; the controller's Article 19 / DPDP §8(7) downstream-rights-propagation duty runs to the cross-border sub-processors; the controller's records-of-transfer log (A.1.5.4) captures the cross-border sub-processor flows. The processor's sub-processor transfer record is the operational input to the controller's transfer-and-disclosure discipline; the processor must produce the sub-processor transfer record on the controller's request within the SLA.

A.2.5.6 in detail, the legally-binding PII disclosures

ISO/IEC 27701:2025 control A.2.5.6 asks PII processors to handle every legally-binding disclosure request, a law-enforcement request, a regulator direction or a court order that lands with the processor for the controller's personal data, through a documented procedure that routes the request to the controller before compliance (unless the law prohibits notification, as in a gag order), logs the request and the response, and applies the multi-factor legality test.

Five load-bearing ideas sit inside this control. First, the processor's primary duty is to route, not to comply. The processor holds the controller's personal data on the controller's behalf; a legally-binding request for that data is, in the first instance, a request to the controller. The processor's duty is to route the request to the controller, within 24 hours of intake by default, so the controller can run the legality assessment and decide the response. The processor's own legality assessment runs in parallel (the processor must satisfy itself that the request is validly directed at the processor and that the controller's response, when given, is consistent with the processor's own obligations), but the controller's assessment is the primary decision.

Second, the routing duty has one carve-out: the gag order. Where the legal instrument that brings the request prohibits the processor from notifying the controller (or anyone) of the request's existence, the processor cannot route. The processor's procedure must handle the gag-order case: the log entry records the request with the gag-order reference; the processor's Legal counsel reviews the gag-order's scope and duration; the processor calendars the gag-order's expiry; on expiry, the processor assesses the notification. The processor may challenge an overbroad gag-order through the competent court (the Puttaswamy proportionality backdrop).

Third, the multi-factor legality test applies. The test, adapted from the controller-side A.1.5.5 test for the processor's perspective, covers: (i) jurisdiction (does the requesting authority have jurisdiction over the processor and the controller's data the processor holds?); (ii) legal basis (is the legal basis cited valid, section 91 / 92 CrPC; section 69 / 69A / 69B IT Act; section 18 DPDP Act; a competent court order?); (iii) scope (are the data categories, the principal cohort and the period proportionate to the legitimate aim?); (iv) necessity (could a less intrusive means, aggregated data, a narrower cohort, a shorter period, a sample, achieve the aim?); (v) challenge decision (comply; engage to narrow; challenge in court; escalate to the regulator). The processor's Legal counsel runs the test; the test is documented per request in the law-compulsion-request log.

Fourth, the controller's instructions govern the response. The controller may instruct the processor to comply, to comply partially (with the narrowed scope the controller negotiated with the requesting authority), to challenge the request, or to escalate. The processor follows the controller's instructions within the bounds of the processor's own legal obligations, a controller's instruction to comply with an invalid request is a textbook A.2.2.5 infringing instruction (the processor must refuse); a controller's instruction to ignore a valid request is also a textbook A.2.2.5 infringement (the processor must comply with the law regardless of the controller's instruction).

Fifth, the disclosure is logged. The disclosure event, the personal data disclosed, the recipient, the date, the legal basis, the scope, the form (raw; aggregated; pseudonymised), the controller-routing record, the legality assessment, the challenge decision, is logged in the A.2.5.4 disclosure log (with the legality-assessment reference under A.2.5.6). The log is the operational evidence the auditor and the regulator will want to see after the fact; a law-compulsion-request log with zero entries over a multi-year period is the "impossible zero" finding (no operation of scale receives zero legal-compulsion requests).

The Indian statutory anchors

In India, the five controls are statutorily anchored in the DPDP Act 2023, the DPDP Rules 2025, the adjacent sector and procedural instruments, and the constitutional jurisprudence. Seven load-bearing hooks.

DPDP Act 2023 section 16, cross-border negative-list. The load-bearing A.2.5.3 anchor. The controller (and through the controller's instructions, the processor) may transfer personal data outside India except to countries or bodies the Central Government notifies as restricted. The processor's destination register operationalises the screen: each destination is screened against the current restricted list, with the screen result, the version, the date and the next-screen date. The register is the processor's evidence that the screen was run; the controller's instruction does not discharge the processor's independent verification duty.

DPDP Act 2023 section 2(1)(k), the Data Processor definition. The processor is a processor only while processing "on behalf of" the Data Fiduciary. The processor's transfers and disclosures must be within the controller's instructions; transfers and disclosures outside the instructions break the "on behalf of" character and expose the processor to being treated as a controller for those processing activities (the Article 28(10) status-drift analogue).

DPDP Act 2023 section 8(6), breach notification. A misdirected disclosure (the recipient column of the disclosure log not matching the lawful recipient), an unauthorised transfer (the destination not on the register), or a chain incident (a sub-processor's breach) is a personal-data breach triggering the 72-hour clock to the Board under DPDP Rules 2025 Rule 7. The processor's disclosure log is the source of the breach detection; the breach-notification procedure (the dual-clock pattern under CERT-In six hours + DPDP seventy-two hours) feeds from the disclosure log.

DPDP Act 2023 section 8(7), erasure and downstream propagation. When a principal withdraws consent (and no other lawful basis applies) or exercises the right to erasure, the controller must propagate the erasure downstream to every recipient, including every recipient the processor has disclosed to. The processor's disclosure log is the propagation source; the processor's flow-down contract requires the recipients to confirm the erasure.

DPDP Act 2023 section 18, Data Protection Board powers. The Board may, in the course of adjudicating a complaint or conducting an inquiry, direct the processor (or the controller) to produce information or documents. The Board-direction disclosure is a category of legally-binding disclosure under A.2.5.6; the disclosure log records the direction, the scope, the response and the date.

Code of Criminal Procedure, 1973, section 91 and section 92; Information Technology Act, 2000, section 69, section 69A, section 69B. The load-bearing Indian law-compulsion-request and government-direction provisions. A disclosure made under any of these is a legally-binding disclosure under A.2.5.6; the processor's law-compulsion-request procedure records the request, the authority, the legal basis, the scope, the proportionality assessment, the controller-routing record, the challenge decision, the disclosure form and the date.

Sector rules, RBI Storage of Payment System Data (6 April 2018); RBI Digital Lending Guidelines (2 September 2022); RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025) and its NBFC version; SEBI KRA Master Circular (May 2024) and CSCRF (20 August 2024); IRDAI Information and Cyber Security Guidelines (24 April 2023); CERT-In Directions (28 April 2022). The sector rules layer additional restrictions on the processor (through the controller-customer's DPAs and through the regulator's direct jurisdiction over the processor in some cases). The destination-country register's sector-overlay screens operationalise these restrictions; the law-compulsion-request procedure handles the regulator-direction disclosures under the sector rules.

Demarcations: transfer vs disclosure; voluntary vs legally-binding; processor vs controller; what is NOT required

Four demarcations matter for the A.2.5.2 / .3 / .4 / .5 / .6 family.

Transfer vs disclosure. A transfer is the movement of personal data across a national border. A disclosure is the sharing of personal data with a third party. Every cross-border transfer is a disclosure (the recipient is a third party); not every disclosure is a transfer (a domestic sub-processor engagement is a disclosure without a transfer). A.2.5.2 (basis for transfer) and A.2.5.3 (destination list) address the cross-border slice; A.2.5.4 (records of disclosure) covers the broader category. The sub-processor transfer record (A.2.5.2 read with A.2.5.7) is the cross-border slice of the sub-processor chain. A.2.5.5 (notification of PII disclosure requests) sits on the law-compulsion path with A.2.5.6. A.2.5.6 (legally-binding disclosures) is the legal-compulsion slice (cross-border or domestic).

Voluntary vs legally-binding. Voluntary disclosures are the disclosures the processor makes on the controller's instructions (sub-processor engagement under a flow-down contract; joint-controller sharing under the customer DPA; third-party-recipient sharing under a contract). Legally-binding disclosures are the disclosures the processor makes because a legal instrument requires it (law-enforcement requests under CrPC §91 / IT Act §69; regulator directions under DPDP §18; court orders). Both are in scope under A.2.5.4; both must be logged. The legally-binding disclosures carry additional dimensions (the routing-to-controller discipline under A.2.5.6; the legality assessment; the challenge procedure).

Processor vs controller. The A.2.5.2-to-A.2.5.6 controls are the processor-side mirrors of the controller-side A.1.5.2-to-A.1.5.5 controls. The processor's records (the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request log) feed the controller's records, the controller's Article 15 / §11 response, the controller's Article 19 / §8(7) propagation, the controller's transfer-discipline evidence, through the customer DPA's reporting clauses. The processor does not maintain the controller's records; the processor maintains its own records and produces them to the controller on request.

What the family does NOT require. It does not require a specific destination-list format (the format is the processor's documented decision; the audit tests that the format covers the required dimensions). It does not require event-level logging for every recurring disclosure (the recurring-category shape is acceptable where event-level evidence can be produced on demand). It does not require the processor to take the controller's legality-assessment decision on legally-binding disclosures (the controller decides; the processor supports and routes). It does not require the processor to refuse every law-compulsion request (the processor may comply with valid requests after the controller's instructions and the processor's own legality assessment). It does not require real-time public reporting of disclosures (the disclosure log is internal; sector-regulator reporting is governed by the sector rule, RBI, SEBI, IRDAI, CERT-In each have their own reporting cadence). It does not require a specific retention period for the logs (the period is the processor's documented decision; DPDP Rules may prescribe a floor; the audit tests that a period is documented, automated and evidenced, Section 10 risk assessment).

What auditors actually check

The certification auditor's A.2.5.2 / .3 / .4 / .5 / .6 examination has eight predictable moves (the 28-question checklist is in Section 11). First, open the Processor Sharing, Transfer and Disclosure Policy, does it exist, is it signed off, does it commit to the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request procedure. Second, ask for the destination register and walk three to five entries, for each, the DPDP §16 screen, the sector-overlay screens, the customer-permitted-destinations overlay, the GDPR cascade (where applicable), the TIA reference (where applicable) and the next-review date. Third, ask for the transfer-mechanism register and walk three to five flows, for each, the controller-instruction reference, the mechanism (the SCC module / adequacy / BCRs), the supplementary measures, the flow-down contract reference, the next-review date. Fourth, ask for the disclosure log and walk three to five entries covering each category (sub-processor; joint-controller; third-party recipient; law-enforcement; regulator direction; court order). Fifth, ask for the sub-processor transfer record (A.2.5.2 read with A.2.5.7) and walk two cross-border sub-processor engagements, the chain-transfer re-assessment, the controller-authorisation, the flow-down contract. Sixth, ask for the law-compulsion-request procedure and walk a recent request (or a tabletop scenario if no recent request), the intake, the controller-routing, the legality assessment, the challenge decision, the disclosure form, the log entry. Seventh, ask for a recent controller request for the recipient list (Article 15 / §11) and verify that the processor's response was produced from the disclosure log within the SLA. Eighth, test the integrity controls, the registers and logs are tamper-evident under A.3.14, A.3.25, A.3.26; the privileged-access pattern under A.3.9 / ISO/IEC 27002:2022 control 5.18 covers the law-compulsion-request responders.

Why This Control Family Matters

The processor as the controller's operational arm

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 five controls in this guide are the evidence controls that turn the customer DPA's transfer-and-disclosure clauses into a defensible operation. A processor that has a perfect customer DPA but no destination register, no transfer-mechanism register, no disclosure log, no sub-processor transfer record, no law-compulsion-request procedure cannot answer the regulator's most basic questions about what it did with the controller's data: where did it go, when, to whom, on what basis, under what authority?

This is why the A.2.5.2 / .3 / .4 / .5 / .6 cluster is the second-most-audited slice of theme A.2.5 (after A.2.5.7 / .5.8 / .5.9). The early GDPR enforcement on transfers, the supervisory-authority decisions on analytics transfers (the Google Analytics decisions across EU DPAs in 2022), turned on whether the controller could evidence, for each transfer, the basis, the supplementary measures and the destination's surveillance regime. In the processor-customer context, the controller's ability to evidence its transfer-and-disclosure discipline depends on the processor's records, the processor that cannot produce its transfer-mechanism register or its disclosure log exposes its controller-customer to the controller's own supervisory authority. In India, the DPDP Act's section 11 right to access (the recipient list), the section 8(6) breach-notification duty, the section 18 Board-direction power, and the sector-regulator reporting cadences together make the A.2.5.2 / .3 / .4 / .5 / .6 cluster the operational heart of the processor's compliance posture.

The Indian regulatory weight

In India, the cluster has a regulatory weight that goes beyond the ISO standard itself. Five layers of weight.

The DPDP section 2(1)(k) layer, the "on behalf of" test. The processor's transfers and disclosures are bounded by the controller's instructions. A transfer outside the instructions, a disclosure outside the customer DPA's authorisation, a legally-binding disclosure without the controller-routing discipline, each breaks the "on behalf of" character. The processor that acts outside the controller's instructions becomes a controller for those processing activities (the Article 28(10) status-drift analogue); the consequences include the loss of the indemnity protection in the customer DPA and the exposure to the controller's penalty exposure.

The DPDP section 16 layer, the cross-border statutory bound. The negative-list model is permission-by-default with notified-restricted destinations. The processor's destination-country register operationalises the screen. The processor's evidence that it ran the screen, for each destination, with the current restricted-list version, on the documented cadence, is the regulator-facing artefact. The DPBI, once operational, will request the destination register after a complaint or an incident; the absence of the register is itself an aggravating factor in the penalty determination.

The sector-localisation layer. The DPDP negative-list model is the general cross-border regime, but the sector regulators layer additional restrictions that bind the processor through its controller-customer's DPAs and through the regulator's direct jurisdiction. The RBI Storage of Payment System Data directive (6 April 2018) is the marquee, payment-data storage in India only; the processor that processes payment-system data for a bank customer must store it in India only, and the destination-country register's payment-data entry is "India-only" with no permitted destination outside India. The RBI Digital Lending Guidelines (2 September 2022) add the digital-lending layer. The SEBI KYC (May 2024) and CSCRF (20 August 2024) add the capital-markets layer. The IRDAI Information and Cyber Security Guidelines (24 April 2023) add the insurance layer. CERT-In (28 April 2022) adds the 180-day log-localisation layer. For a regulated Indian controller's processor, the sector-overlay screens are the load-bearing A.2.5.3 mechanism, they override the DPDP general permission.

The Board-direction and law-compulsion-request layer. Under DPDP Act 2023 section 18 (Board powers), the Data Protection Board may direct the processor to produce information (the Board's jurisdiction over the processor is direct in some circumstances and indirect through the controller in others). Under the Code of Criminal Procedure, 1973, section 91, a court or a police officer may issue a summons to produce documents. Under the Information Technology Act, 2000, section 69 / 69A / 69B, the government may issue directions for interception, blocking or monitoring. Each of these is a legally-binding disclosure under A.2.5.6; each must be routed to the controller and logged with the legality assessment. The Indian growing-company processor segment frequently mishandles these requests, the request lands with an untrained employee (the support desk; the junior operations executive; the CEO's assistant); the request is complied with without the controller-routing and the legality assessment; the request is not logged. The A.2.5.6 audit tests the procedure and the log.

The SDF layer (DPDP section 10). Where the controller-customer is a Significant Data Fiduciary under section 10, the cross-border and disclosure dimensions become DPIP triggers for the controller. The processor must support the SDF's DPIP with the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record; the cross-border dimension must be supported on the section 10 cadence; the algorithmic-fairness review (where the cross-border flow or the disclosure involves AI / inference) applies. The processor's A.2.5.2 / .3 / .4 / .5 / .6 operation is therefore the densest in the 27701 universe for an SDF's processor.

The constitutional layer, Puttaswamy and the law-compulsion-request proportionality test

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, striking down section 57 of the Aadhaar Act as unconstitutional.

The A.2.5.6 legality assessment for law-enforcement and government-direction disclosures is, in operational terms, the processor's (and through the processor's routing, the controller's) internal proportionality test. The processor asks, of the request: does the requesting authority have jurisdiction? Is the legal basis valid? Is the scope proportionate to the legitimate aim? Is the request necessary? Should the controller challenge the request? The Puttaswamy proportionality test is the doctrinal foundation for the multi-factor legality test the processor (and the controller) runs before disclosure. A processor that runs the test seriously is a processor that runs the Puttaswamy test seriously on its disclosure operations.

The cost of non-compliance

The cost of an A.2.5.2 / .3 / .4 / .5 / .6 family failure breaks down into four bands.

Direct DPDP / sector-regulator exposure (through the controller). For the controller-customer, the exposure is direct, the section 8(5) failure exposure (up to ₹250 crore) applies where the safeguards were not informed by the records discipline; the section 8(6) failure exposure (up to ₹200 crore) applies where the breach-notification was undermined by the records gap; the section 10 SDF failure exposure (up to ₹150 crore) applies where the SDF's DPIP could not draw on the processor's records. For the processor, the exposure is indirect but real: the controller's indemnity claim against the processor; the sector regulators' direct jurisdiction over the processor (the RBI can investigate the processor directly under the outsourcing rules; the supervisory action can include the cancellation of the controller's authorisation to engage the processor, which is for a processor whose business depends on the controller a commercial death sentence); the reputational damage of being named in the regulator's order.

Indirect regulatory consequences (GDPR-applicable flows). For processors processing EU personal data on behalf of EU controller-customers, the GDPR Article 83 penalty exposure applies, up to €10 million or 2 percent of global annual turnover for the Article 28 / Article 30 / Article 32 violations (the records-of-transfer and disclosure-log gaps cascade into the Article 30(2) ROPA gap and the Article 28(3) DPA-content gap). Indian processors with substantial EU-customer exposure face the same cascade.

Commercial cost. The Indian processor market, SaaS vendors, BPO / ITeS providers, analytics vendors, cloud-service resellers, payment processors, 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.2-to-A.2.5.6-style transfer-and-disclosure clauses in their standard DPAs, audit the processor's destination register and disclosure log during vendor diligence, and require the law-compulsion-request procedure as a procurement requirement. The processor that cannot demonstrate a current destination register, a current transfer-mechanism register, a current disclosure log, a current sub-processor transfer record and a current law-compulsion-request 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 misdirected disclosure or an unauthorised transfer that traces back to the processor's records gap) compounds the procurement loss.

Recoverable; entirely avoidable.

The board-level question

The board-level question for the family is not "do we have a transfer clause in our DPA?", most processors can point to the boilerplate. The question is "for every cross-border flow we execute on behalf of our controller-customers, can we produce (a) the destination register entry with the screens, (b) the transfer-mechanism register entry with the SCC reference, the TIA reference and the controller-authorisation, (c) the disclosure log entry with the recipient, the basis and the contract, (d) the sub-processor transfer record (for cross-border sub-processor engagements) with the chain-transfer re-assessment linked, and (e) the law-compulsion-request log entry (for legally-binding disclosures) with the controller-routing record and the legality assessment?" If the honest answer is "partially" or "no", the processor has an A.2.5.2 / .3 / .4 / .5 / .6 gap regardless of what its DPA says.

Scope and Applicability

Who the family applies to

Control family A.2.5 (remaining) sits in Table A.2 of the 2025 Annex A, the PII processor control set. It binds every organisation that acts as a processor (DPDP: Data Processor; GDPR: processor) for at least one controller-customer and that engages in any of the five in-scope activities: transferring the controller's personal data across borders (A.2.5.2); maintaining a list of permitted destinations (A.2.5.3); disclosing the controller's personal data to third parties (A.2.5.4); engaging cross-border sub-processors (A.2.5.5); or handling law-compulsion requests for the controller's data (A.2.5.6). Controllers (Table A.1) are bound by their own mirror set, A.1.5.2 to A.1.5.5, which depend on the processor's records under this guide.

The family applies regardless of organisation size. A twenty-person SaaS startup providing analytics services to five controller-customers and using a single cloud region outside India, a thousand-person BPO serving twenty banking customers and processing data across three cross-border destinations, and a global cloud provider serving thousands of controller-customers across multiple jurisdictions are all bound. The maturity expectations scale with the volume, complexity and risk of the transfers and disclosures, see Section 22 (Maturity Model).

When the family applies, the trigger analysis

A.2.5.2 / .3 / .4 / .5 / .6 apply throughout the lifecycle of every transfer and every disclosure. Unlike A.2.2.5 (which activates on each instruction), the five controls are always-on, every cross-border flow produces a transfer-mechanism-register entry; every disclosure produces a disclosure-log entry; every cross-border sub-processor engagement produces an A.2.5.5 record; every law-compulsion request produces an A.2.5.6 log entry. The activities that trigger the family fall into eight categories.

1. New controller-customer onboarding, the customer DPA's transfer schedule is the foundational instruction; the destination register's customer-permitted-destinations overlay is built from the DPA; the transfer-mechanism register's flows are populated; the disclosure log's processor-customer entry is created. Every new customer onboarding is a trigger event.
2. New cross-border flow, a new cloud-region deployment; a new sub-processor abroad; a new analytics pipeline that processes data outside India; a new reporting flow to a foreign regulator. The destination register entry is created before the flow begins; the transfer-mechanism register entry is created with the SCC reference, the TIA reference, the controller-authorisation.
3. New sub-processor engagement (cross-border), a new sub-processor abroad triggers the A.2.5.5 record (the chain-transfer re-assessment, the controller-authorisation, the flow-down). The A.2.5.7 / .5.8 / .5.9 controls also fire (the disclosure, the engagement, the change notification); A.2.5.5 is the transfer-disclosure slice.
4. New sub-processor engagement (domestic), a domestic sub-processor triggers the A.2.5.4 disclosure-log entry but not the A.2.5.5 record (no cross-border dimension). The A.2.5.7 / .5.8 / .5.9 controls fire.
5. Law-compulsion request, a section 91 CrPC summons; a section 69 / 69A / 69B IT Act direction; a section 18 DPDP Board direction; a court order. The A.2.5.6 procedure fires, the controller-routing, the legality assessment, the challenge decision, the disclosure form, the log entry.
6. Regulator-direction disclosure, a RBI direction (where the processor is within the RBI's direct jurisdiction); a SEBI information request (through a SEBI-regulated controller-customer); an IRDAI query; a DPBI direction. The A.2.5.6 procedure fires.
7. Material change to an existing flow or disclosure, a destination change; a recipient change; a data-category change; a purpose change. The change triggers a register refresh and a re-screen.
8. Material change to the legal regime, a Central-Government notification adding a country to the DPDP restricted list; a European Commission adequacy decision being issued, suspended or repealed; a new sector-regulator locality rule; a new TIA finding on a destination. The change triggers a register refresh and a re-screen of every affected flow.

The transfer-and-disclosure categories the processor must capture

The processor's destination register, transfer-mechanism register, disclosure log and A.2.5.5 record must capture every transfer and every disclosure across eight categories:

1. Cross-border flows to the controller's group entities, a multinational controller-customer's affiliate in another country that receives data from the processor under the customer DPA.
2. Cross-border flows to the processor's sub-processors, the sub-processor abroad that processes on the processor's behalf (covered in detail in the A.2.5.5 record and the A.2.5.7 / .5.8 / .5.9 controls).
3. Cross-border flows to third-party recipients, a downstream analytics vendor abroad; a verification service abroad; a clinical-research partner abroad (joint-controller or third-party).
4. Domestic flows to sub-processors, the sub-processor in the same country as the processor (no cross-border dimension; in the disclosure log; not in the transfer-mechanism register).
5. Domestic flows to third-party recipients, a downstream analytics vendor in the same country (in the disclosure log; not in the transfer-mechanism register).
6. Law-enforcement-request disclosures, CrPC §91 / §92 summons; IT Act §69 / 69A / 69B directions; other Indian law-enforcement-request instruments; foreign law-enforcement requests through MLAT / court-order routes (in the disclosure log; in the law-compulsion-request log under A.2.5.6).
7. Regulator-direction disclosures, DPDP §18 Board directions; RBI directions; SEBI information requests; IRDAI queries; CERT-In directions (in the disclosure log; in the law-compulsion-request log under A.2.5.6).
8. Court-order disclosures, civil, criminal, regulatory or administrative proceedings (in the disclosure log; in the law-compulsion-request log under A.2.5.6).

The processor's intake procedure (toolkit doc 02) routes each transfer-and-disclosure event to the right register or log.

What is in scope for the destination register

The destination register captures every destination to which the processor transfers the controller-customer's personal data. The destinations include:

• Cloud regions, the cloud provider's regions (the Mumbai region; the Singapore region; the Frankfurt region; the Northern Virginia region). Each region is a separate destination, even though the cloud provider is the same.
• Sub-processor locations, the geography where the sub-processor processes the data (a US-based AI-model vendor's inference region; a Netherlands-based clinical-research partner's hosting region; a Singapore-based support-tooling vendor's data-centre region).
• Controller-customer's group locations, the multinational controller-customer's affiliate locations that receive data.
• International organisations, the multilateral development banks, the UN-system bodies, the international-standard-setting bodies that may receive data in the course of regulated business (the international-organisation entries are distinct from the countries in which they are headquartered).
• Reporting destinations, the foreign regulators, the foreign tax authorities, the foreign courts to which data may be reported under legal compulsion.

What is out of scope

The following are out of scope of the family:

• Transfers of truly anonymised data, data that has been irreversibly anonymised (per ISO/IEC 20889 or the equivalent standard) is no longer personal data and is outside the scope of A.2.5.2 / .3 / .4 / .5 / .6. Pseudonymised data is still personal data and is in scope.
• Transfers within the processor's own infrastructure that do not cross a border, the data flowing within the Mumbai region of a cloud provider is not a cross-border transfer. (Note: the data flowing from the Mumbai region to the Singapore region of the same cloud provider for disaster-recovery purposes is a cross-border transfer and is in scope.)
• Disclosures to the controller itself, the processor's return of data to the controller (under the A.2.4.3 control) is not a third-party disclosure under A.2.5.4. (Note: where the return crosses a border, the controller in another jurisdiction, the return is a cross-border transfer and is in scope of A.2.5.2 and A.2.5.3.)
• Disclosures the processor's personnel make in the ordinary course of their work, the processor's own employees accessing the data within the authorised access controls are not "third-party disclosures". (Note: a processor's personnel disclosing data outside the authorised access controls is a personal-data breach, not a third-party disclosure under A.2.5.4; the breach-notification procedure under A.3 incident controls and DPDP §8(6) applies.)

Applicability by industry (preview, Section 21 has detail)

• BFSI processors (serving banks/NBFCs/insurers), RBI's outsourcing Directions (2025) and the IRDAI ICT-outsourcing clauses prescribe specific destination-locality and sub-processor-side transfer-disclosure content. The most prescriptive Indian sectoral processor regime; the destination register's sector-overlay screen for payment-data, KYC-data and policyholder-data is load-bearing.
• Healthcare processors (serving hospitals/insurers/telemedicine), sensitive health data; the destination register must reflect the heightened sensitivity; the cross-border dimension (telemedicine platforms routing consultations across borders for second-opinion services) is the marquee A.2.5.2 challenge.
• IT-ITeS and SaaS processors, multi-jurisdiction customer portfolios; the destination register must accommodate DPDP, GDPR, US-state, Brazil LGPD, China PIPL simultaneously; the AI-model vendor's cross-border dimension is the marquee A.2.5.5 challenge.
• E-commerce enabler processors (logistics, payments, recommendation engines), typically joint-controller or processor relationships with multiple e-commerce platforms; the payment-rail sub-processor's destination is the marquee A.2.5.3 / .5.5 challenge (the RBI payment-data localisation overlay).
• Edtech processors, DPDP §9 dominates where the controller-customer is an edtech serving minors; the destination register must reflect the verifiable-parental-consent overlay and the no-behavioural-monitoring and no-targeted-advertising prohibitions on any cross-border flow involving children's data.
• Manufacturing (IIoT/Industry 4.0 processors), typically processor relationships with OEM customers; the data may include operator-identification, shift-rotation, safety-incident records; the destination register's employee-data overlay is the marquee A.2.5.3 challenge for multinational OEMs.

Key Definitions and Terminology

Relationship to Other Clauses and Frameworks

The sibling-control network inside Annex A.2

The A.2.5 family (remaining) does not stand alone, it sits inside a tight sibling network, and the audit will trace the network end-to-end.

A.2.2.2, Customer agreement. The DPA's transfer schedule and disclosure schedule are the contractual foundation for A.2.5.2 / .3 / .4. The customer DPA specifies the controller's permitted-destinations list, the authorised transfer mechanisms, the sub-processor engagement regime, the law-compulsion-request routing clause, the breach-handoff clause, the audit-and-inspection rights. A.2.5.2 verifies that the DPA's transfer schedule is operational; A.2.5.3 produces the destination register bounded by the DPA's permitted-destinations list; A.2.5.4 produces the disclosure log the DPA's reporting clauses reference.

A.2.2.5, Infringing instruction. A controller's instruction to transfer outside the documented mechanism, or to disclose without the legality assessment, is a textbook A.2.2.5 infringement. The interlock with A.2.5.2 and A.2.5.6 is direct, the processor's refusal of an infringing instruction routes through the same instruction-decision log.

A.2.2.7, Records related to processing. The processor's ROPA references the five registers, the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request log. The ROPA is the audit's primary walk-through document; the five registers reconcile to it.

A.2.3.2, Comply with obligations to PII principals. The processor's support for the controller's principal-side rights depends on the disclosure log. The recipient-list response under Article 15 / DPDP §11 is built from the disclosure log; the downstream-rights propagation under Article 19 / DPDP §8(7) is operated from the disclosure log. The interlock is operational, A.2.3.2 cannot be satisfied without A.2.5.4.

A.2.4.4, PII transmission controls. The technical transmission discipline, the encryption in transit, the secure-transmission protocols, the integrity controls, that every cross-border flow operates within. The technical foundation of A.2.5.2; without it, the transfer mechanism's supplementary measures are not implemented.

A.2.5.7 / A.2.5.8 / A.2.5.9, Sub-processor chain. The A.2.5.5 sub-processor transfer record cross-links directly. The A.2.5.7 disclosure (the published sub-processor list) shows the cross-border sub-processors; the A.2.5.5 record shows their transfer-disclosure slice. The two interlock, the chain governance (A.2.5.7 / .5.8 / .5.9) operates the engagement discipline; the A.2.5.5 record captures the transfer-discipline slice.

A.3, Security controls. The integrity of the five registers and the disclosure log. The A.3 controls (especially A.3.10 supplier agreements; A.3.14 protection against falsification; A.3.25 logging; A.3.26 cryptography) protect the A.2.5 stack's evidence base. The secure-transmission channel for legally-binding disclosures is the A.3 / ISO/IEC 27002:2022 control 8.18 (privileged access) interlock.

Clause 8.1, Operational planning and control. The PIMS-level framework within which the A.2.5 stack sits. The processor's overall control of its processes, the criteria for control, the implementation, these Clause 8.1 disciplines flow into the A.2.5 family's operational discipline.

Clause 9.1 / 9.3, Monitoring, measurement, analysis, evaluation; management review. The KPI reporting on the A.2.5 stack (Section 12) feeds the Clause 9.1 monitoring and the Clause 9.3 management review. Trends in destination-register currency, transfer-mechanism currency, disclosure-log completeness, sub-processor transfer-record coverage, law-compulsion-request clock attainment are the A.2.5 KPI set.

Clause 7.5, Documented information. The five registers are documented information under Clause 7.5, version-controlled, access-controlled, retention-managed, retrievable.

The controller-side mirror (Annex A.1)

The A.2.5 family has a clean mirror in Annex A.1, the controller-side transfer-and-disclosure controls. The mirror points:

• A.1.5.2, Identify basis for PII transfer. The controller-side mirror of A.2.5.2. The controller documents the transfer basis (the mechanism the controller has authorised); the processor's A.2.5.2 verifies the mechanism and executes the flow.
• A.1.5.3, Countries to which PII can be transferred. The controller-side mirror of A.2.5.3. The controller's destination list is one input to the processor's destination register; the processor's register is bounded by the controller's list and by every other applicable bound.
• A.1.5.4, Records of transfer. The controller-side mirror of A.2.5.4 (for the transfer slice). The controller's records-of-transfer log captures the controller's cross-border flows (including the flows the controller has instructed the processor to execute); the processor's disclosure log captures the processor's execution of those flows.
• A.1.5.5, Records of PII disclosure. The controller-side mirror of A.2.5.4 (for the broader disclosure slice) and A.2.5.6. The controller's disclosure log captures every disclosure, including the legally-binding disclosures; the processor's disclosure log and law-compulsion-request log feed the controller's records.
• A.1.2.7, Contracts with PII processors. The controller-side mirror of the customer DPA's transfer-and-disclosure schedules. The controller's duty to put in place a written DPA that addresses the transfer-and-disclosure dimensions; the processor's customer DPA is the same artefact, viewed from the processor side.

The cross-framework map (preview, Section 16 has detail)

The lineage from ISO/IEC 27018:2019

ISO/IEC 27018:2019, the code of practice for protection of PII in public clouds acting as PII processor, is the most directly relevant ISO sibling for the A.2.5 family. The 27018 clauses that map most cleanly:

• Clause 9, Sub-contractors. The cloud PII processor's sub-processor discipline (the A.2.5.7 / .5.8 / .5.9 controls operate inside this; the A.2.5.5 record captures the cross-border sub-processor's transfer-disclosure slice).
• Clause 10, Cross-border transfer. The cloud PII processor's transfer-discipline framework, the documented basis, the appropriate safeguards, the disclosure to the cloud customer (the controller).
• Clause 11, Data return and destruction. The cloud PII processor's end-of-engagement handling (the A.2.4.3 control).

A.2.5 of 27701:2025 is the management-system-level counterpart of 27018:2019's clause-level processor code of practice. A cloud processor that implements 27701:2025 implements 27018:2019's substantive content through the management-system lens.

The lineage from GDPR Article 28 + Chapter V

GDPR Article 28 is the most-litigated processor regime in the world. Article 28(3)(a) requires the processor to process personal data only on the controller's documented instructions, the legal foundation for the A.2.5.2 verification. Article 28(3)(b) requires the processor not to transfer personal data to a third country without the controller's specific or general written authorisation (the A.2.5.5 controller-authorisation reference). Article 28(3)(h) requires the processor to make available to the controller all information necessary to demonstrate compliance, the legal foundation for the A.2.5.4 disclosure log and the A.2.5.2 transfer-mechanism register. Article 28(4) requires the processor to impose equivalent terms on its sub-processors (the flow-down contract reference). Article 29 provides that persons acting under the processor's authority may process personal data only on the processor's instructions, the processor-internal authorisation regime. Chapter V (Articles 44 to 49) governs transfers to third countries, Article 45 adequacy; Article 46 appropriate safeguards (SCCs, BCRs); Article 47 BCRs; Article 48 law-enforcement/judgment transfers (which intersects A.2.5.6); Article 49 derogations. A processor that processes EU personal data must layer these on top of the DPDP anchors, taking the stricter of the two where they diverge. The A.2.5 family is the 27701 operationalisation of this converged posture.

The Schrems II lineage

The CJEU's judgment in Case C-311/18, Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (Schrems II, 16 July 2020), invalidated the EU-US Privacy Shield and upheld the SCCs subject to a case-by-case verification duty, the TIA. The EDPB Recommendations 01/2020 on supplementary measures operationalise the TIA methodology. The modernised SCCs (Implementing Decision (EU) 2021/914 of 4 June 2021) replaced the pre-2021 SCCs and added the processor-to-processor module. The EU-US Data Privacy Framework adequacy decision (10 July 2023) restored an adequacy route for certified US organisations. For an Indian processor, the Schrems II duty applies wherever the processor transfers EU personal data on behalf of an EU controller-customer to a destination outside the EU, the TIA is part of A.2.5.2; the supplementary measures are part of the transfer-mechanism register; the chain-transfer re-assessment is part of A.2.5.5 for the cross-border sub-processor engagements.

Detailed Implementation Guidance, Control by Control

This section walks through each of the five controls with a consistent five-part structure: (a) the paraphrased requirement; (b) what it means in practice; (c) the DPDP and GDPR mapping; (d) the implementation discipline; (e) the audit evidence the certification auditor will expect. The five controls together form the transfer-and-disclosure scaffolding framed in Section 2.

A.2.5.2, Basis for PII transfer between jurisdictions

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.5.2 asks PII processors to transfer the controller-customer's personal data to another jurisdiction only on the controller's documented instruction and under a recognised transfer mechanism, the European Commission's adequacy decision (Article 45 GDPR where EU personal data is involved); the appropriate safeguards of Article 46 GDPR (the SCCs of Implementing Decision 2021/914; the BCRs; the codes of conduct and certifications); the derogations of Article 49 GDPR (for occasional transfers); the DPDP Act section 16 permission (for India-anchored flows); or the equivalent mechanism under the applicable law.

(b) What it means in practice. Every cross-border transfer the processor executes must have two layers of authority: the controller's documented instruction (the customer DPA's transfer schedule plus any specific written authorisation) and a valid transfer mechanism (the SCCs executed; the adequacy decision current; the BCRs in place). The two layers interlock but are not the same, the controller's instruction is the legal authority under the contract; the transfer mechanism is the statutory authority under the applicable data-protection law. A processor with a controller's instruction but no transfer mechanism has a contract without a legal basis; a processor with a transfer mechanism but no controller's instruction has a legal basis without authority.

The marquee A.2.5.2 failure patterns are: (i) the processor that executes a cross-border flow on the controller's verbal direction or on an email from the controller's operations team, without verifying that the customer DPA's transfer schedule authorises the flow; (ii) the processor that has the customer DPA's transfer schedule but has never executed the SCCs the schedule references (a paperwork gap; the processor is exposed because the actual contract is missing); (iii) the processor that executed the pre-2021 SCCs and has not migrated to the modular SCCs of Decision 2021/914 (the pre-2021 SCCs were superseded on 27 December 2022); (iv) the processor that relies on an adequacy decision that has been suspended or repealed; (v) the processor that has not run a TIA for any of its cross-border flows to non-adequate destinations (the Schrems II duty).

(c) DPDP and GDPR mapping. DPDP Act 2023 section 2(1)(k) (the processor's "on behalf of" status depends on the documented instruction); section 8 (the fiduciary's obligations flow through the documented instruction); section 16 (the cross-border negative list, the Indian statutory mechanism); section 8(5) (security safeguards, including the transfer's security); section 8(6) (breach, a transfer that becomes a breach triggers the 72-hour clock); section 33 + Schedule (penalties). GDPR Article 28(3)(a) and (b) (the documented instructions; the controller's authorisation for cross-border transfers); Article 28(3)(h) (records of processing); Article 30(2) (processor ROPA, the transfers content); Article 32 (security of processing, including in transit); Article 33(2) (breach handoff); Chapter V (Articles 44 to 49, the transfer mechanisms). UK GDPR + DPA 2018 (same as EU GDPR; the IDTA / UK Addendum references). ISO/IEC 27018:2019 clause 10 (cross-border in public clouds). ISO/IEC 27002:2022 controls 5.34 (PII), 8.15 (logging), 8.18 (privileged access). NIST Privacy Framework v1.0 Control-P (data-processing management). SOC 2 Privacy TSC P6.0 (Disclosure) and Common Criteria CC9.2.

(d) The implementation discipline. Six sub-disciplines drive conformant transfer-basis management:

• Transfer-Mechanism Register. A register of every cross-border flow the processor executes on behalf of every controller-customer, with the per-flow fields: the customer; the flow identifier; the source jurisdiction; the destination; the data categories; the principal cohort; the controller-instruction reference (the DPA's transfer-schedule clause; any specific written authorisation); the transfer mechanism (the SCC module; the adequacy decision reference; the BCR reference; the DPDP permission); the SCC execution reference (where SCCs apply); the TIA reference and date; the supplementary measures; the flow-down contract reference; the start date; the next-review date. The register is the A.2.5.2 artefact and the audit's primary walk-through document.
• Per-customer transfer inventory. Each active customer's transfer flows are inventoried at onboarding and updated through the change-control process. The per-customer inventory reconciles with the customer DPA's transfer schedule; an instruction outside the schedule is a textbook A.2.2.5 infringement and a textbook A.2.5.2 infringement.
• Transfer-mechanism verification. For each cross-border flow, the processor verifies that the mechanism named in the controller's instruction is current and operational. The verification covers: the SCCs have been executed by both parties; the SCC module is correct (Module 2 controller-to-processor for the customer-to-processor leg; Module 3 processor-to-processor for the processor-to-sub-processor leg; Module 4 processor-to-controller for the return leg); the SCC version is current (the 2021 modular SCCs of Implementing Decision 2021/914; not the pre-2021 SCCs); the adequacy decision is current (if the controller's instruction names an adequacy decision, the processor verifies it has not been suspended or repealed); the BCRs are in place and current (if relied on); the DPDP permission applies (for India-anchored flows; the destination is not on the §16 restricted list).
• Schrems II TIA. For each cross-border flow that relies on Article 46 appropriate safeguards to a non-adequate destination, the TIA is conducted and documented. The TIA covers: the destination's surveillance law (in the EU context, the US FISA 702 / Executive Order 12333 considerations; in other contexts, the equivalent surveillance regime); the destination's rights of redress for the principals; the supplementary measures (technical: encryption with keys held outside the destination, pseudonymisation, split processing; contractual: transparency-about-government-access commitments, challenge-of-unlawful-access commitments; organisational: the internal governance). The TIA is reviewed annually, on destination-country legal-change event, on flow-change event, and on incident event.
• SCC execution discipline. The processor executes the appropriate SCC module for each flow; the executed SCC is filed in the transfer-mechanism register; the SCC version is tracked (the 2021 modular SCCs); the migration from pre-2021 SCCs is documented (for flows that pre-date the 2021 SCCs). For cross-border sub-processor engagements, the processor-to-processor module (Module 3) is executed between the processor and the sub-processor; the flow-down contract incorporates the SCCs.
• Change-of-mechanism discipline. When a transfer mechanism becomes invalid (the SCCs are superseded; the adequacy decision is suspended; the destination's regime degrades such that the TIA cannot be satisfied with the current supplementary measures), the processor's procedure routes the change through the customer-communication cycle (a side-letter; an amended DPA; a re-executed SCC; a re-routing of the flow). The change is logged in the transfer-mechanism register with the change date and the new mechanism.

(e) Audit evidence. (i) The Processor Sharing, Transfer and Disclosure Policy (toolkit doc 01) covering A.2.5.2; (ii) the Transfer-Mechanism Register (toolkit doc 09); (iii) sample walks of three to five flows showing the controller-instruction reference, the transfer mechanism, the SCC execution, the TIA reference, the supplementary measures, the flow-down contract reference; (iv) the SCC execution evidence (signed SCCs for each applicable flow); (v) the TIA reports for the cross-border flows to non-adequate destinations; (vi) the change-of-mechanism records (where applicable); (vii) the per-customer DPA register showing the transfer-schedule references reconciled with the transfer-mechanism register.

A.2.5.3, Countries and international organisations to which PII can be transferred

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.5.3 asks PII processors to maintain a current, documented list of the countries and international organisations to which the controller's personal data can be transferred, together with the basis on which the transfer is permitted and the conditions that apply.

(b) What it means in practice. The destination-country register is the processor's own, not a copy of the controller's permitted-destinations list. The processor's register is bounded by the most restrictive of: the controller-customer's permitted-destinations list; the DPDP section 16 negative list; the sector-overlay screens; the GDPR Chapter V cascade where EU personal data is processed; the processor's own risk appetite. A processor serving multiple controller-customers across multiple jurisdictions operates a least-permissive intersection, for each destination, the register applies the most restrictive of every applicable bound.

The marquee A.2.5.3 failure patterns are: (i) the processor that has no destination register (the processor relies on the controller's instruction without independent verification); (ii) the processor that has a destination register but it is a copy of one customer's permitted-destinations list (the register is not the least-permissive intersection; the processor may be permitting a destination for a customer whose DPA excludes it); (iii) the processor that has not run the sector-overlay screens (the payment-data entry permits a flow outside India in violation of the RBI directive; the ICT-log entry permits a flow outside the 180-day CERT-In localisation window); (iv) the processor that has not refreshed the register since the original DPDP notification (the negative-list version is stale; new sector rules are not reflected); (v) the processor that has international organisations merged into country entries (the international organisation should be a distinct entry).

(c) DPDP and GDPR mapping. DPDP Act 2023 section 16 (the negative-list model, the load-bearing Indian anchor); section 8(5) (safeguards); section 8(6) (breach); section 10 (SDF, the destination register is a DPIP input for SDF customers); section 33 + Schedule. GDPR Chapter V (Arts 44 to 49, the cascade); Article 30(1)(e) (ROPA, third-country recipients). UK GDPR + DPA 2018 (same as EU GDPR; the IDTA / UK Addendum). ISO/IEC 27018:2019 clause 10 (cross-border in public clouds). ISO/IEC 27002:2022 control 5.34 (PII). NIST Privacy Framework v1.0 Control-P (data-processing management). SOC 2 Privacy TSC P6.0 (Disclosure).

(d) The implementation discipline. Six sub-disciplines:

• Destination-Country Assessment Register. A register with the per-destination fields: the destination (country or international organisation); the legal regime summary (the destination's data-protection law, surveillance law, rights of redress); the DPDP §16 negative-list screen result with the version, date and next-screen date; the sector-overlay screens (RBI payment-data; SEBI KYC; IRDAI policyholder-data; CERT-In ICT logs); the customer-permitted-destinations overlay (which customers' DPAs permit the destination; which exclude it); the GDPR cascade result (Article 45 adequacy; Article 46 SCCs / BCRs; Article 49 derogations); the transfer mechanism (the SCCs; the adequacy decision; the BCRs); the TIA reference; the supplementary measures; the sign-off authority (DPO; executive; board); the next-review date; the status (active; suspended; retired).
• Destination-onboarding workflow. A new destination is onboarded through a documented workflow: the DPDP §16 screen; the sector-overlay screens; the customer-permitted-destinations overlay; the GDPR cascade (where EU data is involved); the TIA (where SCCs apply); the supplementary-measures design; the sign-off at the appropriate authority level; the register entry. The workflow is gated, a flow to a destination not yet onboarded is blocked.
• Negative-list screening per destination. Each destination is screened against the current Central-Government restricted list; the screen is documented with the date, the version and the next-screen date; the screen is refreshed on the quarterly cadence and on every Central-Government-notification event. A destination that becomes restricted after a flow has commenced triggers the suspension procedure (typically within 30 days of the notification).
• Sector-overlay screens. For each sector-regulated flow, the applicable sector overlay is applied after the DPDP negative-list screen. The overlays: RBI Storage of Payment System Data (payment-data India-only); RBI Digital Lending (borrower-data localisation); SEBI KRA (KYC-data handling); SEBI CSCRF (data-locality for SEBI-regulated entities); IRDAI Information and Cyber Security Guidelines (policyholder-data locality); CERT-In Directions (180-day ICT-log localisation).
• Customer-permitted-destinations overlay. Each customer's DPA's transfer schedule specifies the destinations that customer permits. The destination register's overlay records, per destination, which customers' DPAs permit it and which exclude it. A destination permitted by customer A's DPA but excluded by customer B's DPA is operated with customer-specific routing (B's data does not flow to the destination; A's data does).
• Refresh cadence. The register is refreshed on the quarterly cadence and on every legal-change event. The refresh covers: the negative-list re-screen; the sector-overlay re-screen; the cascade re-verification (where applicable); the TIA refresh (where applicable); the customer-permitted-destinations update (where a customer's DPA has been amended); the next-review date update.

(e) Audit evidence. (i) The Destination-Country Assessment Register (toolkit doc 03); (ii) sample walks of three to five destinations showing the DPDP §16 screen, the sector-overlay screens, the customer-permitted-destinations overlay, the GDPR cascade, the TIA reference, the next-review date; (iii) the onboarding workflow evidence for a recent destination addition; (iv) the negative-list screening evidence with the version history; (v) the sector-overlay evidence for each sector-regulated flow; (vi) the customer-permitted-destinations overlay reconciled with the per-customer DPA register.

A.2.5.4, Records of PII disclosures to third parties

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.5.4 asks PII processors to keep records of disclosures of personal data to third parties, what was disclosed, when, to whom, on what basis, with which contract reference, covering which principal cohort and which data categories, covering every disclosure category (sub-processor disclosures; joint-controller disclosures; third-party-recipient disclosures; law-enforcement-request disclosures; regulator-direction disclosures; court-order disclosures).

(b) What it means in practice. The disclosure log is the processor's evidence base for every disclosure it has executed on the controller's behalf. The controller's Article 15 / DPDP §11 recipient-list response depends on the processor's disclosure log; the controller's Article 19 / DPDP §8(7) downstream-rights propagation depends on the processor's disclosure log; the controller's breach-notification under section 8(6) (where a misdirected disclosure becomes a breach) draws on the processor's disclosure log for the breach-detection evidence. The disclosure log is therefore the operational engine for both the processor's own compliance and the controller's compliance.

The marquee A.2.5.4 failure patterns are: (i) the disclosure log that covers sub-processor disclosures but omits the law-enforcement-request disclosures, the regulator-direction disclosures and the court-order disclosures (the "voluntary-only" disclosure log); (ii) the disclosure log that is a spreadsheet on a shared drive with no event-level pipeline feed, no reconciliation, no integrity controls and no version control (the canonical A.2.5.4 anti-pattern); (iii) the disclosure log that has gaps (events not captured; recurring categories not aggregated; reconciliation fails); (iv) the disclosure log that does not reconcile with the transfer-mechanism register (for cross-border disclosures) or with the recipient list (the disclosure register); (v) the disclosure log that is not tamper-evident (no append-only store; no hash-chain; no access logging); (vi) the disclosure log that does not produce the recipient-list response within the controller's SLA (the manual-assembly anti-pattern, the DPO emails the engineering team to ask who has been shared with).

(c) DPDP and GDPR mapping. DPDP Act 2023 section 2(1)(k) (the processor's disclosure records are part of the "on behalf of" character); section 8 (records implied, the fiduciary's records flow through); section 8(6) (breach, the disclosure log is the breach-detection source); section 8(7) (erasure, the disclosure log drives the downstream propagation); section 10 (SDF, the disclosure log supports the controller's DPIP); section 11 (access, the recipient list); section 18 (Board powers, the regulator-facing artefact); section 33 + Schedule. GDPR Article 28(3)(h) (records of processing); Article 30(2) (processor ROPA, recipients content); Article 15(1)(c) (recipients in the access response); Article 19 (propagation to recipients); Article 33(2) (breach handoff). UK GDPR + DPA 2018 (same as EU GDPR). ISO/IEC 27018:2019 clause 9 (disclosure to third parties). ISO/IEC 27002:2022 controls 5.34 (PII), 8.15 (logging). NIST Privacy Framework v1.0 Identify-P (data-mapping) + Communicate-P (reporting). SOC 2 Privacy TSC P5.0 (Access), P6.0 (Disclosure), P8.0 (Monitoring).

(d) The implementation discipline. Six sub-disciplines:

• Disclosure-log schema. A schema with the per-entry fields: the disclosure identifier; the disclosure date and time; the customer (the controller on whose behalf the disclosure is made); the recipient (name; corporate identifier; jurisdiction; relationship, sub-processor / joint-controller / third-party / law-enforcement / regulator / court); the lawful basis (the customer DPA clause; the legal instrument for legally-binding disclosures); the contract reference (the DPA; the sub-processor flow-down; the joint-controller agreement); the principal cohort (named individuals; account-number ranges; principal-category definitions); the data categories disclosed; the cross-border flag (and the destination where applicable); the transfer-mechanism reference (for cross-border disclosures); the legality-assessment reference (for legally-binding disclosures); the disclosure form (raw; aggregated; pseudonymised; sample); the controller-routing record (for legally-binding disclosures); the integrity metadata (the hash; the modifier; the timestamp).
• Event-emission pipeline. The disclosure log is fed by an event-emission pipeline that emits a structured event per cross-border flow, per sub-processor disclosure, per joint-controller feed, automatically from the source systems. Manual entry is the fallback for disclosures the pipeline does not capture (legally-binding disclosures; ad-hoc disclosures); the manual entry is reviewed by the DPO before being committed to the log.
• Recurring-category aggregation. For steady-state flows, the recurring-category entry covers the period and the volume, with the aggregation rules documented and the on-demand event-level evidence available. The recurring-category shape is acceptable only where the controller can produce, on demand, the event-level evidence for any period within the recurring category.
• Reconciliation cadence. Monthly reconciliation of the disclosure log to the underlying pipeline telemetry, to the transfer-mechanism register (for cross-border disclosures), to the recipient list (the disclosure register), and to the processor ROPA (A.2.2.7). Drift (a disclosure in the telemetry that is not in the log; a disclosure in the log that is not in the telemetry) is the canonical A.2.5.4 finding; the reconciliation closes the loop.
• Recipient-list response workflow. The processor's response to the controller's request for the recipient list (under Article 15 / DPDP §11) is auto-produced from the disclosure log. The workflow queries the disclosure log for the customer's cohort, produces the recipient list, and serves it to the controller within the SLA (typically hours, not days). The workflow is the operational unlock for the controller's Article 15 / §11 compliance.
• Downstream-rights-propagation workflow. The processor's support for the controller's Article 19 / DPDP §8(7) propagation is operated from the disclosure log. The workflow queries the disclosure log for the principal's recipients, propagates the right-action (rectification; erasure; restriction) downstream, and tracks the recipient confirmations. The propagation closes the audit loop.

(e) Audit evidence. (i) The disclosure log (toolkit doc 10); (ii) sample walks of three to five entries covering each category (sub-processor; joint-controller; third-party recipient; law-enforcement; regulator direction; court order); (iii) the event-emission pipeline specification and the pipeline's event-level entries; (iv) the recurring-category-aggregation rules with the on-demand event-level evidence; (v) the monthly reconciliation report; (vi) the recipient-list response workflow with the SLA evidence; (vii) the downstream-rights-propagation workflow with the recipient-confirmation SLA.

A.2.5.5, Sub-processor-related transfer disclosure

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.5.5 asks PII processors to keep, for every cross-border sub-processor engagement, the transfer-disclosure record, the transfer mechanism used, the destination, the chain-transfer re-assessment (TIA) reference, the controller's authorisation reference, the flow-down contract reference, the data categories accessed, the principal cohort, the engagement start date and the current status. The control is the transfer-disclosure slice of the chain governance (A.2.5.7 / .5.8 / .5.9) and the bridge that makes the chain transfer auditable end-to-end.

(b) What it means in practice. Every cross-border sub-processor engagement is both a disclosure (in the A.2.5.4 disclosure log) and a transfer (in the A.2.5.2 transfer-mechanism register). The A.2.5.5 record is the deep-dive on the cross-border slice, it pulls the engagement into a single artefact that links the chain governance (the A.2.5.7 register; the A.2.5.8 engagement record; the A.2.5.9 change notification), the transfer discipline (the SCC module; the TIA; the supplementary measures), and the disclosure discipline (the recipient; the basis; the contract). The A.2.5.5 record is the operational evidence the controller needs to support the controller's own transfer-disclosure discipline, the controller's Article 15 / §11 response, the controller's Article 19 / §8(7) propagation, the controller's transfer-register entry (A.1.5.4), the controller's disclosure-log entry (A.1.5.5).

The marquee A.2.5.5 failure patterns are: (i) the cross-border sub-processor engagement without a chain-transfer re-assessment (the Schrems II TIA is missing, the canonical A.2.5.5 finding, and the canonical A.2.5.8 finding, and the canonical A.2.5.2 finding); (ii) the chain-transfer re-assessment that is stale (the destination's surveillance law has degraded since the TIA was conducted; the TIA is older than the annual cadence without a refresh); (iii) the A.2.5.5 record without the controller-authorisation reference (the engagement is documented, but the controller's authorisation basis is not cited, the engagement may be unauthorised); (iv) the A.2.5.5 record without the flow-down contract reference (the engagement is documented, but the flow-down contract's cross-border clauses are not cited, the supplementary measures may not be contractually binding on the sub-processor); (v) the sub-processor transfer record that is not linked to the A.2.5.7 sub-processor register (the chain governance and the transfer discipline are in separate artefacts, the auditor cannot trace the chain end-to-end).

(c) DPDP and GDPR mapping. DPDP Act 2023 section 2(1)(k) (the sub-processor is a processor of the processor, itself acting on behalf of the fiduciary); section 8 (the chain flow-through); section 8(5) (the sub-processor's safeguards); section 8(6) (the chain breach-handoff); section 16 (the negative-list screen for the cross-border sub-processor's destination); section 33 + Schedule. GDPR Article 28(3)(a) (the documented-instruction transfer to the sub-processor); Article 28(3)(f) (the controller's authorisation for the sub-processor); Article 28(4) (the flow-down); Article 28(9) (the processor's written record of sub-processors); Chapter V (the transfer mechanisms); the modernised SCCs of Implementing Decision 2021/914 (the processor-to-processor module at Clause 9). UK GDPR + DPA 2018 (same as EU GDPR). ISO/IEC 27018:2019 clause 9 (sub-contractors in public clouds); clause 10 (cross-border). ISO/IEC 27002:2022 controls 5.19 to 5.23 (supplier relationships) and 5.34. NIST Privacy Framework v1.0 Control-P (data-use agreements). SOC 2 Privacy TSC P6.0 (Disclosure) and Common Criteria CC9.2.

(d) The implementation discipline. Six sub-disciplines:

• Sub-processor Transfer Record schema. A schema with the per-engagement fields: the sub-processor identifier; the engagement identifier; the customer(s) for whom the engagement operates; the destination (the country where the sub-processor processes the data); the data categories accessed; the principal cohort; the role or service; the controller-authorisation basis (general or specific) with the DPA-clause reference and the specific-authorisation document if applicable; the transfer mechanism (the SCC module, typically Module 3 processor-to-processor; the adequacy decision; the BCRs; the DPDP permission); the SCC execution reference (where SCCs apply); the chain-transfer re-assessment (TIA) reference and date; the supplementary measures; the flow-down contract reference (with the cross-border clauses cited); the engagement start date; the current status; the next-review date; the link to the A.2.5.7 register entry.
• Chain-transfer re-assessment (TIA). For every cross-border sub-processor engagement, the TIA is conducted following the EDPB Recommendations 01/2020 six-step methodology. The TIA covers: the destination's surveillance law; the destination's rights of redress; the supplementary measures (technical, contractual, organisational). The TIA is reviewed annually, on destination-country legal-change event, on engagement-change event (a scope change; a data-category change; a sub-processor ownership change), and on incident event.
• Controller-authorisation evidence. For each engagement, the controller-authorisation basis is documented. For general-authorisation regimes, the customer DPA's sub-processor schedule is cited and the change-notification record (under A.2.5.9) is referenced. For specific-authorisation regimes, the controller's signed authorisation is filed. For the BFSI overlay (the RBI Master Direction's prior-written-permission rule), the bank-customer's specific authorisation is filed.
• Flow-down contract evidence. The flow-down contract with the sub-processor is on file, with the cross-border clauses cited (the SCCs incorporated by reference; the supplementary-measures clauses; the breach-notification duty with the chain-handoff timeline; the audit rights; the data-return-or-destruction clauses; the cross-border sub-sub-processor regime). The flow-down is the A.2.5.8 artefact; the A.2.5.5 record references it.
• Customer-specific data routing. Where the engagement is permitted for some customers' data but not others (the customer-permitted-destinations overlay of A.2.5.3 excludes the destination for some customers), the technical architecture enforces customer-specific data routing. The customer-specific routing is documented in the A.2.5.5 record; the engineering team's access-control matrix and the data-pipeline configuration are the technical evidence.
• Periodic refresh. The A.2.5.5 record is refreshed on the quarterly cadence and on every engagement-change event. The refresh covers: the TIA refresh; the SCC version check; the supplementary-measures verification; the controller-authorisation renewal (where applicable); the customer-specific-routing re-test; the link to the A.2.5.7 register entry.

(e) Audit evidence. (i) The Sub-processor Transfer Record (toolkit doc 10 Part B); (ii) sample walks of two cross-border sub-processor engagements showing the destination, the transfer mechanism, the TIA reference, the controller-authorisation, the flow-down contract reference; (iii) the chain-transfer re-assessment reports; (iv) the controller-authorisation evidence (the DPA's sub-processor schedule; the specific-authorisation documents); (v) the flow-down contracts with the cross-border clauses cited; (vi) the customer-specific data-routing evidence; (vii) the link to the A.2.5.7 register.

A.2.5.6, Legally binding PII disclosures

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.5.6 asks PII processors to handle every legally-binding disclosure request, a law-enforcement request, a regulator direction or a court order that lands with the processor for the controller's personal data, through a documented procedure that routes the request to the controller before compliance (unless the law prohibits notification, as in a gag order), logs the request and the response, and applies the multi-factor legality test.

(b) What it means in practice. The processor holds the controller's personal data on the controller's behalf; a legally-binding request for that data is, in the first instance, a request to the controller. The processor's duty is to route, not to comply, the controller decides the response; the processor supports the decision with the technical extraction and the secure-transmission channel; the processor logs the request and the response. The processor's own legality assessment runs in parallel (the processor must satisfy itself that the request is validly directed at the processor and that the controller's response is consistent with the processor's own obligations), but the controller's assessment is the primary decision.

The marquee A.2.5.6 failure patterns are: (i) the processor that complies with a law-compulsion request without routing it to the controller (the textbook A.2.5.6 infringement, the processor has exceeded the controller's instructions and incurred Article 28(10) status-drift risk); (ii) the processor that routes the request but does not run its own legality assessment (the processor relies entirely on the controller's assessment; the processor's own obligations are not satisfied); (iii) the processor that complies with a foreign law-enforcement request directly (without the MLAT / court-order route), a textbook GDPR Article 48 infringement and a textbook A.2.5.6 infringement; (iv) the processor that does not log the request (the law-compulsion-request log has gaps; the impossible-zero finding); (v) the processor that does not handle the gag-order case (the processor's procedure does not contemplate the gag-order carve-out; the processor either routes the request in violation of the gag-order or complies without the controller-routing record); (vi) the processor that does not challenge an overbroad request (the blanket-comply anti-pattern, the processor waives the proportionality test that Puttaswamy requires).

(c) DPDP and GDPR mapping. DPDP Act 2023 section 18 (the Board's power to direct the processor to produce information); section 8 (the fiduciary's obligations that the processor supports); section 8(6) (breach, a misdirected legally-binding disclosure is a breach); section 33 + Schedule. Code of Criminal Procedure, 1973 sections 91 and 92 (the summons-to-produce provisions). Information Technology Act, 2000 sections 69, 69A and 69B (the interception / blocking / monitoring directions). GDPR Article 28(3)(a) (the documented-instructions clause, a legally-binding disclosure outside the documented instructions is a textbook infringement); Article 28(3)(h) (records of processing, the law-compulsion-request log); Article 28(10) (controller-status drift, the processor that complies without the controller's instructions drifts to controller status); Article 48 (transfers/judgments of third-country courts/admin, disclosure to a foreign authority without an MLAT / court-order route is prohibited). UK GDPR + DPA 2018 (same as EU GDPR). ISO/IEC 27018:2019 clause 9 (disclosure to third parties, the law-enforcement-request handling). ISO/IEC 27002:2022 controls 5.34 (PII), 8.15 (logging), 8.18 (privileged access for the law-compulsion-request responders). NIST Privacy Framework v1.0 Communicate-P (reporting, authorisation). SOC 2 Privacy TSC P6.0 (Disclosure) and P8.0 (Monitoring).

(d) The implementation discipline. Six sub-disciplines:

• Law-Compulsion-Request Procedure. A documented procedure (toolkit doc 08) covering: the intake (the routing of every law-compulsion request to a dedicated intake channel; the prohibition on the receiver's direct response); the controller-routing discipline (the notification of the controller within 24 hours of intake, except where the law prohibits); the multi-factor legality assessment (jurisdiction; legal basis; scope; proportionality; necessity; challenge decision); the response execution (the technical extraction; the secure-transmission channel; the disclosure form); the log entry; the annual tabletop exercise. The procedure is signed off by the DPO and the Legal counsel; it is communicated to every staff member who could receive a law-compulsion request.
• Law-Compulsion-Request Response Team. A team with documented roles: the Team Lead (typically the DPO or the Legal counsel); the Legal counsel (the legality-assessment runner); the Engineering Lead (the technical extraction); the Security Lead (the secure-transmission channel and the integrity); the Customer Success Lead (the controller-facing communication); the Executive Sponsor (the high-residual-risk sign-off). The team is trained annually; the tabletop exercise runs three to five scenarios per year.
• Multi-factor legality assessment. The test, documented per request, covering: (i) jurisdiction (does the requesting authority have jurisdiction?); (ii) legal basis (is the legal basis cited valid, CrPC §91 / §92; IT Act §69 / 69A / 69B; DPDP §18; a competent court order?); (iii) scope (are the data categories, the principal cohort and the period proportionate?); (iv) necessity (could a less intrusive means, aggregated data, a narrower cohort, a shorter period, a sample, achieve the aim?); (v) challenge decision (comply; engage to narrow; challenge in court; escalate to the regulator). The test is run by the processor's Legal counsel in parallel with the controller's assessment.
• Controller-routing discipline. Every law-compulsion request is routed to the controller within 24 hours of intake (or within the customer DPA's specified timeline, if shorter), except where the law prohibits notification (the gag-order case). The routing record is filed in the law-compulsion-request log with the date and time of routing, the controller's designated notice contact, the controller's response instructions, and the controller's response timeline.
• Gag-order handling. Where the legal instrument prohibits the processor from notifying the controller, the processor's procedure handles the gag-order case: the log entry records the request with the gag-order reference; the processor's Legal counsel reviews the gag-order's scope and duration; the processor calendars the gag-order's expiry; on expiry, the processor assesses the notification to the controller. The processor may challenge an overbroad gag-order through the competent court.
• Log discipline and the impossible-zero check. The law-compulsion-request log records every request, every assessment, every controller-routing record, every challenge decision, every disclosure event. The log is reconciled with the disclosure log (A.2.5.4) on the monthly cadence. A law-compulsion-request log with zero entries over a multi-year period is the "impossible zero" finding, the auditor infers that requests have arrived but have not been logged.

(e) Audit evidence. (i) The Law-Compulsion-Request Procedure (toolkit doc 08); (ii) the Law-Compulsion-Request Response Team charter and the training records; (iii) the multi-factor legality assessment template and a sample of completed assessments (where any requests were handled in the last 12 months); (iv) the controller-routing records; (v) the law-compulsion-request log reconciled with the disclosure log; (vi) the annual tabletop exercise report; (vii) the gag-order handling records (where applicable).

The end-to-end walk, bringing the five controls together

The certification auditor's end-to-end A.2.5 walk picks a recent cross-border flow and traces it through the full stack. A representative walk for an Indian SaaS analytics processor's transfer of an EU controller-customer's data to a US-based AI-model sub-processor:

1. Destination register entry (A.2.5.3). The destination "United States" is on the register with the DPDP §16 screen result (not restricted; screen date and version documented), the sector-overlay screens (not applicable, the customer is not BFSI / SEBI / IRDAI / payment-data), the customer-permitted-destinations overlay (the EU customer's DPA permits the United States subject to the SCCs and the supplementary measures), the GDPR cascade (Article 46 SCCs, the EU customer's data is EU personal data; the cascade stops at SCCs), the TIA reference (the Schrems II TIA for the US destination), the next-review date (within 12 months).
2. Transfer-mechanism register entry (A.2.5.2). The flow is logged with the controller-instruction reference (the customer DPA's transfer-schedule clause authorising the AI-model vendor), the transfer mechanism (the SCCs, Module 3 processor-to-processor, executed between the processor and the AI-model vendor), the SCC execution reference (the signed SCCs), the TIA reference and date, the supplementary measures (encryption-at-rest with CMK held by the processor in India; pseudonymisation with the mapping held in India; contractual transparency-about-government-access and challenge-of-unlawful-access clauses), the flow-down contract reference, the start date, the next-review date.
3. Disclosure-log entry (A.2.5.4). The disclosure event is logged with the customer, the recipient (the AI-model vendor), the lawful basis (the customer DPA's transfer-schedule clause), the contract reference (the flow-down), the principal cohort (the EU customer's end-users whose data is sent for inference), the data categories (the prompts, the context, the outputs, pseudonymised before transmission), the cross-border flag (true), the destination (United States), the transfer-mechanism reference (the SCC Module 3 execution), the disclosure form (pseudonymised raw data; encrypted in transit), the integrity metadata.
4. Sub-processor transfer record (A.2.5.5). The AI-model vendor engagement is recorded with the destination (United States), the transfer mechanism (SCC Module 3), the chain-transfer re-assessment reference (the TIA report), the controller-authorisation (the customer DPA's general-authorisation clause with the change-notification record under A.2.5.9 cited), the flow-down contract reference (with the cross-border clauses cited, the SCC incorporation; the supplementary-measures clauses; the breach-notification duty), the data categories (pseudonymised prompts, context, outputs), the principal cohort (the EU customer's end-users), the engagement start date, the current status, the link to the A.2.5.7 register entry.
5. Law-compulsion-request log (A.2.5.6). No law-compulsion request has been received for this flow; the log reflects the absence (the documented absence, not the impossible-zero). The procedure is in place; the Law-Compulsion-Request Response Team is trained; the tabletop exercise has covered a US-government-request scenario.

The walk closes with the audit evidence: the destination register entry, the transfer-mechanism register entry, the disclosure-log entry, the sub-processor transfer record, the law-compulsion-request log. A processor that can produce this walk for any cross-border flow is operating at A.2.5 L4 or L5. A processor that cannot produce this walk for any cross-border flow is operating at L1 or L2.

Tools, Technologies, and Solutions

The tool landscape

The A.2.5 family is operationally supported by six classes of tool. The choice is a risk-treatment decision (Section 10), not a one-size-fits-all prescription.

Privacy management platforms (PMPs). Software products that manage the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request log, the sub-processor register (A.2.5.7), the ROPA (A.2.2.7). The A.2.5-relevant slice is the transfer-and-disclosure module and the law-compulsion-request module. Generic category terms, "enterprise privacy management platform", "privacy operations platform", "third-party risk management platform", are the right vocabulary; this guide does not name vendors.

Data discovery and pipeline-mapping tools. Products that scan the processor's data estate and map the data flows, the ingestion pipelines, the storage layers, the analytics warehouse, the AI/ML feature store, the sub-processor outbound feeds, the cross-border transfer flows. The output drives the destination-register population (A.2.5.3), the transfer-mechanism-register population (A.2.5.2), the disclosure-log event emission (A.2.5.4), and the sub-processor transfer-record population (A.2.5.5). The continuous-monitoring slice (the detection of new flows, new sub-processors, new destinations) is the engineering unlock.

Contract lifecycle management (CLM) tools. Products that manage the customer DPA's drafting, negotiation, execution, renewal and change control. The CLM integrates with the PMP (the customer-DPA register references the CLM's executed DPAs; the transfer-mechanism register references the DPA's transfer schedule) and with the e-signature platform.

Tamper-evident logging infrastructure. The disclosure log, the transfer-mechanism register, and the law-compulsion-request log must be tamper-evident under A.3.14, A.3.25 and A.3.26. The infrastructure choices: a WORM-compliant cloud store; a hash-chained append-only log (a blockchain-style ledger or an equivalent); a database with strict access controls, audit logging and immutable storage. The integrity infrastructure is the security-side foundation; the choice depends on the processor's risk profile and regulatory obligations.

Secure-transmission channels for legally-binding disclosures. The law-compulsion-request response execution requires a secure-transmission channel, encrypted in transit; access-controlled; audit-logged. The channel is the A.3 / ISO/IEC 27002:2022 control 8.18 (privileged access) interlock; the design depends on the requesting authorities' channels (some accept a secure-portal upload; some require a physical delivery; some require a specific encryption protocol).

GRC platforms with vendor-risk modules. Products that integrate the destination register, the sub-processor register (A.2.5.7), the disclosure log, the law-compulsion-request log, the risk-assessment records, the audit-evidence records, the KPI dashboard. The GRC platform is the conformant pattern for mid-market and enterprise processors; for growing-company processors, a focused PMP implementation may suffice.

The build-vs-buy decision framework

The build-vs-buy decision depends on the processor's scale, complexity, regulatory profile and in-house engineering capacity. The framework:

• Growing processors (50 to 250 staff; 5 to 25 customers; 3 to 10 destinations). Buy (PMP) for the disclosure log and the sub-processor register; build (lightweight) for the destination register and the transfer-mechanism register (the volumes are tractable; a structured document or a spreadsheet with integrity controls may suffice at this scale). The law-compulsion-request procedure is a process artefact, not a tooling artefact.
• Mid-market processors (250 to 2,000; 25 to 200 customers; 10 to 30 destinations). Buy (PMP) for the full transfer-and-disclosure module; integrate the PMP with the data discovery tool for the event-emission pipeline; integrate with the CLM for the customer-DPA register. The destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request log are managed in the PMP.
• Enterprise processors or SDF-class fiduciary's processors. Build (in-house platform) for the transfer-and-discipline, integrating the PMP, the data discovery tool, the CLM, the tamper-evident logging infrastructure and the secure-transmission channel. The build is justified by the scale, the multi-jurisdiction complexity, and the SDF-customer's DPIP integration requirements.

The India-specific tooling landscape

The India-specific tooling landscape is maturing rapidly. The marquee India-specific dimensions:

• DPDP-native privacy platforms. A growing tier of privacy platforms are DPDP-native, built around the DPDP Act's constructs (Data Fiduciary, Data Principal, Consent Manager, SDF, DPBI) rather than adapted from a GDPR-first template. The DPDP-native platforms are particularly relevant for the law-compulsion-request procedure (the Indian-specific instruments, CrPC, IT Act, sector regulators, are built into the workflow).
• Consent Manager integration. The DPDP Act's Consent Manager construct (section 2(1)(g)) is operationally unlike a generic consent-management platform. For processors supporting controllers that use a Consent Manager, the integration with the Consent Manager's APIs (for the consent-status check before processing; for the withdrawal-propagation) is an India-specific tooling dimension.
• Sector-regulator reporting integration. The sector regulators (RBI, SEBI, IRDAI, CERT-In) each have their own reporting cadences and portals. The processor's tooling should integrate the sector-regulator reporting (the CERT-In 6-hour incident report; the SEBI quarterly CSCRF reporting; the IRDAI annual ICT-returns) into the disclosure-log workflow.
• India-region hosting for the registers and logs. The CERT-In Directions' 180-day log-localisation requirement and the RBI payment-data localisation directive impose India-region hosting for certain categories of register and log. The processor's tooling must accommodate the India-region hosting for the in-slice registers and logs.

Cost ranges (illustrative, India market)

The cost ranges for the tooling (illustrative, India market, mid-2026):

The cost ranges are illustrative; the actual cost depends on the processor's scale, complexity, regulatory profile and in-house capacity. Singahi does not quote tooling prices, these are market references, not Singahi pricing.

Policy and Procedure Templates

The Singahi toolkit (this guide's companion artefact set) provides the seventeen ready-to-customize documents that operationalise the five controls. The policy and procedure templates are the foundational artefacts:

• Policy (doc 01). The Processor Sharing, Transfer and Disclosure Policy, the processor's commitments to the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request procedure, the controller-routing discipline, the integrity controls.
• Lifecycle Procedure (doc 02). The eight-stage procedure (intake → instruction-verify → screen → mechanism-execute → log → reconcile → retain → erase) with acceptance criteria, owners, KPIs and cadence.
• Destination-Country Assessment Register (doc 03). The A.2.5.3 master artefact, the register schema, the onboarding workflow, the DPDP §16 negative-list tracker, the sector-overlay screens, the customer-permitted-destinations overlay, the GDPR cascade documentation, the sign-off authority matrix, the reconciliation report, the change history.
• Transfer-Mechanism Register (doc 09). The A.2.5.2 master artefact, the register schema, the per-flow fields, the SCC execution tracker, the TIA reference library, the supplementary-measures checklist, the change-of-mechanism log.
• Disclosure Log and Sub-processor Transfer Record (doc 10). The A.2.5.4 + A.2.5.5 master artefact, the disclosure-log schema, the event-emission pipeline specification, the recurring-category-aggregation rules, the reconciliation report, the integrity controls, the sub-processor transfer-record slice (the A.2.5.5 fields per cross-border engagement), the recipient-list response template, the downstream-rights-propagation template, the processor-side DPA clause library for transfer and disclosure.
• Law-Compulsion-Request Procedure (doc 08). The A.2.5.6 master artefact, the multi-factor legality test; the intake workflow; the controller-routing discipline; the assessment template; the challenge procedure; the response execution; the log entry; the gag-order handling; the tabletop-exercise template.

Each of the seventeen toolkit documents is control-specific (transfer-and-disclosure themed) rather than a generic PIMS boilerplate. The full toolkit contents are listed in Section 19.

Risk Assessment and Treatment

The A.2.5.2 / .3 / .4 / .5 / .6 family is itself a risk-treatment control, it reduces the transfer-and-disclosure risk by producing the evidence base that lets the processor detect, respond to and evidence the transfers and disclosures it executes on the controller's behalf. But the family's operation carries its own risks, which the processor must assess and treat under clause 6.1.2 / 8.2 of the PIMS.

The risk register entries

The A.2.5.2 / .3 / .4 / .5 / .6 risk register typically includes the following fourteen entries, each scored on the likelihood × impact grid and treated through one or more of the family's sub-disciplines.

1. Off-register destination risk, a cross-border flow executes to a destination not on the Destination-Country Assessment Register (the canonical A.2.5.3 finding). Treatment: the onboarding workflow; the monthly reconciliation; the pipeline-level block on off-register destinations.
2. Lapsed-entry risk, a destination's next-review date has passed without a re-screen. Treatment: the quarterly refresh cadence; the legal-change-event refresh; the dashboard alert on the next-review date.
3. Negative-list violation risk, a Central-Government notification adds a country to the restricted list and the processor does not suspend the affected flows within the prescribed period. Treatment: the legal-change-event refresh within 30 days; the suspension procedure; the alternative-arrangement assessment.
4. Transfer-mechanism gap risk, a flow executes without a current transfer mechanism (the SCCs not executed; the pre-2021 SCCs not migrated; the adequacy decision suspended; the TIA missing or stale). Treatment: the transfer-mechanism verification; the SCC execution discipline; the Schrems II TIA; the change-of-mechanism discipline.
5. Disclosure-log gap risk, the log has gaps (events not captured; recurring categories not aggregated; reconciliation fails). Treatment: the event-emission pipeline; the recurring-category-aggregation rules; the monthly reconciliation; the integrity audit.
6. Sub-processor transfer-record gap risk, a cross-border sub-processor engagement is not in the A.2.5.5 record (the engagement was not routed through the engagement procedure). Treatment: the procurement-controlled engagement workflow; the engineering-team training on the intake discipline; the quarterly reconciliation with the A.2.5.7 register.
7. Controller-routing failure risk, a law-compulsion request is complied with without routing to the controller (the textbook A.2.5.6 infringement). Treatment: the Law-Compulsion-Request Procedure; the intake-form routing; the Law-Compulsion-Request Response Team; the annual tabletop exercise.
8. Gag-order risk, a law-compulsion request or a regulator direction prohibits the processor from notifying the controller. Treatment: the gag-order procedure; the log entry with the gag-order reference; the challenge procedure (where the gag-order is overbroad); the calendar-the-expiry discipline.
9. Foreign-law-enforcement direct-compliance risk, a foreign law-enforcement request is complied with directly (without the MLAT / court-order route), in violation of GDPR Article 48 and the equivalent Indian rule. Treatment: the Law-Compulsion-Request Procedure's jurisdiction test; the Legal counsel's review; the MLAT-route enforcement.
10. Impossible-zero risk, the law-compulsion-request log has zero entries over a multi-year period, despite the processor having substantial customer-volume. Treatment: the documented procedure; the annual tabletop; the staff-wide intake-form routing; the impossible-zero check at the internal audit.
11. Recipient-list response SLA failure risk, the controller's Article 15 / §11 request is not served within the SLA; the recipient list is incomplete or wrong. Treatment: the recipient-list response workflow with the disclosure-log query; the SLA monitoring; the recipient-cohort query completeness test.
12. Downstream-rights-propagation failure risk, the controller's rectification / erasure / restriction is not propagated to the recipients; the recipients do not confirm. Treatment: the propagation workflow with the disclosure-log source; the recipient-confirmation SLA; the escalation on the recipient non-confirmation.
13. Integrity-compromise risk, the registers and logs are modified without authorisation; the hash-chain is broken; the access log is incomplete. Treatment: the append-only store; the hash-chaining; the access-logged modifications; the tamper-evident store; the periodic integrity audit.
14. Chain-breach amplification risk, a sub-processor's breach triggers the controller's section 8(6) breach-notification duty (the 72-hour clock via DPDP Rules Rule 7); the processor's records discipline is the breach-detection source. Treatment: the event-emission pipeline's failure-detection pattern; the breach-notification procedure (the dual-clock pattern under CERT-In six hours + DPDP seventy-two hours); the disclosure log as the breach-detection source.

The risk-treatment plan

The risk-treatment plan assigns each risk to an owner, a treatment, a target residual risk and a review cadence. The plan is reviewed at the Clause 9.3 management review. The high-impact risks (off-register destination; transfer-mechanism gap; controller-routing failure; foreign-law-enforcement direct-compliance; integrity compromise) are typically treated to low residual risk; the medium-impact risks (lapsed entry; negative-list violation; disclosure-log gap; sub-processor transfer-record gap; gag-order; impossible-zero; recipient-list SLA failure; downstream-rights-propagation failure; chain-breach amplification) are typically treated to medium-low residual risk.

The DPIA integration

Where the controller-customer is an SDF (DPDP section 10) or where the processing activity triggers a DPIA (A.1.2.6; GDPR Article 35, large-scale; sensitive data; cross-border to non-equivalent jurisdictions; profiling with significant effects), the A.2.5 risk register entries are part of the controller's DPIA, supported by the processor's records. The processor's transfer-mechanism register, the TIA, the disclosure log, the sub-processor transfer record, the law-compulsion-request log are inputs to the DPIA's transfer-and-disclosure dimension. The DPIA's recommendations feed back into the processor's registers (a TIA-driven decision to suspend a destination; a disclosure-log-driven decision to redesign the recipient-list response process).

Audit and Compliance Checklist

The certification auditor's A.2.5.2 / .3 / .4 / .5 / .6 examination follows the eight predictable moves in Section 2.10 and the per-control evidence walks in Sections 7.1 to 7.5. The 28-question checklist below (organised by control, then by the eight moves) is the auditor's examination map. Each question lists the expected evidence and the red-flag pattern.

The policy and governance questions

1. Does the processor have a documented Processor Sharing, Transfer and Disclosure Policy? Expected evidence: the policy document (toolkit doc 01) signed off by top management; the version control; the annual review record. Red flag: no policy; a policy that is silent on A.2.5.2 / .3 / .4 / .5 / .6; a policy older than twelve months without a review.
2. Are the five controls' owners documented in the RACI matrix? Expected evidence: the RACI (toolkit doc 13); the role definitions (toolkit doc 16). Red flag: no RACI; the DPO is the named owner of every dimension (a single-point-of-failure pattern); the Law-Compulsion-Request Response Team is not defined.
3. Is the Law-Compulsion-Request Response Team convened and trained? Expected evidence: the team charter; the training records (toolkit doc 07); the annual tabletop exercise (toolkit doc 08). Red flag: no team; no training; no tabletop.
4. Are the five controls' KPIs in the management-review reporting pack? Expected evidence: the dashboard (toolkit doc 11); the management-review minutes (Clause 9.3) showing the KPI trend analysis. Red flag: no KPIs; KPIs reported but not actioned.

The A.2.5.2 transfer-mechanism register questions

5. Does the Transfer-Mechanism Register exist with the per-flow fields? Expected evidence: the register (toolkit doc 09). Red flag: no register; a register with fewer fields; a register that is a spreadsheet on a shared drive.
6. Is every cross-border flow's controller-instruction reference documented? Expected evidence: the customer DPA's transfer-schedule clause cited per flow; any specific written authorisations filed. Red flag: flows without the controller-instruction reference; flows with the reference but the referenced DPA clause does not authorise the flow.
7. Is every flow's transfer mechanism current and operational? Expected evidence: the SCC execution reference (the signed SCCs); the SCC version (the 2021 modular SCCs); the adequacy decision reference (current; not suspended); the BCR reference; the DPDP permission. Red flag: flows with the pre-2021 SCCs not migrated; flows with the EU-US Privacy Shield cited (invalidated by Schrems II); flows with no SCCs executed despite the customer DPA's schedule referencing them.
8. For flows relying on Article 46 SCCs to non-adequate destinations, is the Schrems II TIA documented per flow? Expected evidence: the TIA reference per flow (toolkit doc 09 Part B). Red flag: no TIA; a TIA older than the annual cadence; a TIA that does not identify the supplementary measures.
9. Are the supplementary measures operationalised where the TIA identifies a gap? Expected evidence: the supplementary-measures checklist per measure with the implementation status and the verification evidence. Red flag: no supplementary measures; supplementary measures documented but not operationalised.
10. Is the Transfer-Mechanism Register reconciled to the Destination-Country Assessment Register, the Disclosure Log, the Sub-processor Transfer Record, the processor ROPA and the pipeline telemetry? Expected evidence: the monthly reconciliation report. Red flag: no reconciliation; a flow in the telemetry but not in the register; a flow in the register with no live operations for twelve months without an archive decision.

The A.2.5.3 destination-country register questions

11. Does the Destination-Country Assessment Register exist? Expected evidence: the register (toolkit doc 03) with the per-destination schema. Red flag: no register; a register that is a list of countries without the screen results.
12. Is every destination screened against the current DPDP §16 restricted list? Expected evidence: the negative-list tracker with the screen date, the restricted-list version, the result and the next-screen date per destination. Red flag: no screen; a screen older than the quarterly cadence without a legal-change-event refresh; a screen against an outdated restricted-list version.
13. Is every sector-regulated destination screened against the applicable sector overlay? Expected evidence: the sector-overlay screen result per destination (payment-data; digital-lending; KYC; policyholder; ICT logs). Red flag: no sector-overlay screen; a sector-overlay screen that allows a prohibited flow (payment-data outside India).
14. Is the customer-permitted-destinations overlay documented per destination? Expected evidence: the overlay showing which customers' DPAs permit the destination and which exclude it. Red flag: no overlay; an overlay that does not reconcile with the per-customer DPA register.
15. For EU-applicable flows, is the GDPR cascade documented per destination? Expected evidence: the cascade result per destination (Article 45 adequacy; Article 46 SCCs / BCRs; Article 49 derogations). Red flag: no cascade documentation; a cascade that stops at derogations for steady-state flows (derogations are occasional only).
16. Is the Destination-Country Assessment Register reconciled to the Transfer-Mechanism Register, the Disclosure Log, the Sub-processor Transfer Record, the processor ROPA and the pipeline telemetry? Expected evidence: the monthly reconciliation report. Red flag: no reconciliation; a destination in the telemetry but not in the register.

The A.2.5.4 disclosure-log questions

17. Does the Disclosure Log exist with the per-entry fields? Expected evidence: the log (toolkit doc 10 Part A). Red flag: no log; a log with fewer fields; a log that covers only sub-processor disclosures (without the law-enforcement-request, regulator-direction and court-order categories).
18. Is the event-emission pipeline operational? Expected evidence: the pipeline specification (toolkit doc 10 Part C); the pipeline's event-level entries. Red flag: manual entry; manual entry without reconciliation; a pipeline that emits some events but not all.
19. Are the recurring-category entries documented with the aggregation rules and the on-demand event-level evidence? Expected evidence: the aggregation rules; a sample on-demand event-level pull. Red flag: recurring-category entries without the on-demand event-level evidence; aggregation rules that lose event-level detail.
20. Is the Disclosure Log reconciled to the Transfer-Mechanism Register (for cross-border disclosures), the Destination Register, the processor ROPA and the pipeline telemetry? Expected evidence: the monthly reconciliation report. Red flag: no reconciliation; reconciliation that does not tie the volumes; reconciliation that does not surface the gaps.
21. Is the recipient-list response workflow producing the controller's Article 15 / DPDP §11 recipient list from the disclosure log within the SLA? Expected evidence: the workflow with the disclosure-log query; the response samples with the SLA evidence. Red flag: manual recipient-list assembly; a recipient list that does not include all the categories (the law-enforcement-request category is frequently omitted); an SLA violation.
22. Is the downstream-rights-propagation (Article 19 / DPDP §8(7)) operational? Expected evidence: the propagation workflow with the disclosure-log source; the recipient confirmations. Red flag: no propagation; propagation without the recipient confirmations; propagation that does not close the audit loop.
23. Is the Disclosure Log tamper-evident? Expected evidence: the integrity-controls documentation; the append-only store; the hash-chain; the access-logged modifications; the tamper-evident store; the periodic integrity audit. Red flag: a spreadsheet without integrity controls; a log with in-place modifications.

The A.2.5.5 sub-processor transfer-record questions

24. Does the Sub-processor Transfer Record exist with the per-engagement fields? Expected evidence: the record (toolkit doc 10 Part B). Red flag: no record; a record with fewer fields; a record not linked to the A.2.5.7 sub-processor register.
25. For every cross-border sub-processor engagement, is the chain-transfer re-assessment (TIA) documented and current? Expected evidence: the TIA per engagement; the TIA's annual refresh evidence. Red flag: no TIA; a TIA older than the annual cadence; a TIA that does not identify the supplementary measures.
26. Is every cross-border sub-processor engagement's controller-authorisation documented? Expected evidence: the authorisation basis (general or specific) with the DPA-clause reference or the specific-authorisation document. Red flag: no authorisation; a general-authorisation cited but the engagement is for a customer whose DPA does not include the general-authorisation clause.

The A.2.5.6 law-compulsion-request questions

27. Does the Law-Compulsion-Request Procedure exist with the multi-factor legality assessment, the controller-routing discipline, the challenge procedure, the response execution, the log entry and the gag-order handling? Expected evidence: the procedure (toolkit doc 08). Red flag: no procedure; a procedure that lacks the controller-routing discipline (the textbook A.2.5.6 infringement); a procedure that lacks the legality assessment.
28. Is the law-compulsion-request log populated and reconciled with the Disclosure Log? Expected evidence: the log entries (where any requests were handled in the last 12 months); the reconciliation report. Red flag: the impossible zero (no entries over a multi-year period for a processor with substantial customer-volume); entries that are not in the Disclosure Log; entries without the controller-routing record.

The integrity and end-to-end questions

(Additional integrity and end-to-end questions are embedded in the per-control questions above, questions 10, 16, 19, 23, 28 cover the reconciliation and integrity dimensions. The auditor's end-to-end walk (Section 7.6) traces a recent cross-border flow through the five registers as the capstone examination move.)

Metrics and KPIs

The Singahi A.2.5.2 / .3 / .4 / .5 / .6 KPI set (toolkit doc 11), fourteen KPIs with formulas, targets, frequencies and owners. The KPIs are organised into five groups: destination-register KPIs; transfer-mechanism-register KPIs; disclosure-log KPIs; sub-processor-transfer-record KPIs; law-compulsion-request KPIs.

Destination-register KPIs (3 KPIs)

Transfer-mechanism-register KPIs (3 KPIs)

Disclosure-log KPIs (4 KPIs)

Sub-processor transfer-record KPIs (2 KPIs)

Law-compulsion-request KPIs (2 KPIs)

The dashboard layout

The Singahi dashboard (toolkit doc 11) organises the fourteen KPIs into a single view: the destination-register panel (KPIs 1 to 3); the transfer-mechanism-register panel (KPIs 4 to 6); the disclosure-log panel (KPIs 7 to 10); the sub-processor-transfer-record panel (KPIs 11 to 12); the law-compulsion-request panel (KPIs 13 to 14). The dashboard shows the current value, the target, the trend (12-month) and the action-on-breach (the documented response when a KPI breaches the target). The dashboard is reviewed at the management review (Clause 9.3) on the quarterly cadence; the action-on-breach feeds the Clause 10.2 nonconformity-and-corrective-action workflow.

The KPI maturity arc

The KPIs mature with the processor's maturity (Section 22). At L1, no KPIs are reported. At L2, the structural KPIs (off-register destination count; lapsed-entry count; transfer-mechanism coverage) are reported manually. At L3, the pipeline-fed KPIs (reconciliation rate; emission latency; recipient-list clock attainment; propagation attainment) are reported automatically. At L4, the integrity KPIs and the sub-processor-transfer-record KPIs are reported with predictive analytics. At L5, the KPIs are integrated into the broader privacy-engineering practice, with cross-KPI correlation and anomaly detection.

Common Pitfalls and Audit Failures

The A.2.5.2 / .3 / .4 / .5 / .6 family has a distinct set of pitfalls, eighteen patterns that recur across Indian growing companies, growing firms and enterprises. The certification auditor and the regulator both recognise these patterns; the processor that has them is on the wrong side of the finding.

The "controller-told-us-to-send-it" anti-pattern (A.2.5.2)

The processor executes a cross-border flow on the controller's instruction without verifying the transfer mechanism the controller names. The processor's defence, "the controller told us to send it", fails the A.2.5.2 verification duty. The conformant pattern is the transfer-mechanism register with the per-flow mechanism, the SCC execution, the TIA reference.

The "SCCs-signed-once" anti-pattern (A.2.5.2)

The processor executed the SCCs at DPA signing (sometimes the pre-2021 SCCs) and has not refreshed them since. The SCCs are stale; the modular SCCs of Implementing Decision 2021/914 have not been adopted; the Schrems II TIA has not been run. The conformant pattern is the SCC version tracking and the migration discipline.

The "Privacy Shield reliance" anti-pattern (A.2.5.2)

The processor's customer DPA cites the EU-US Privacy Shield for the US-destination flows. The Privacy Shield was invalidated by Schrems II in July 2020. The conformant pattern is the migration to the EU-US Data Privacy Framework adequacy decision (10 July 2023) for certified US organisations or to the modular SCCs.

The "destination list copied from the controller" anti-pattern (A.2.5.3)

The processor's destination register is a copy of one controller-customer's permitted-destinations list. The register is not the least-permissive intersection of every applicable bound; the processor may be permitting a destination for a customer whose DPA excludes it. The conformant pattern is the customer-permitted-destinations overlay per destination, reconciled with the per-customer DPA register.

The "negative-list blind spot" anti-pattern (A.2.5.3)

The processor has a destination register but the DPDP §16 negative-list screen is missing or stale. The screen is the load-bearing Indian anchor for A.2.5.3; the absence of the screen, or the screen against an outdated restricted-list version, is the canonical Indian A.2.5.3 finding. The conformant pattern is the quarterly screen and the legal-change-event refresh.

The "sector-overlay miss" anti-pattern (A.2.5.3)

The processor's destination register permits a payment-data flow outside India (the RBI Storage of Payment System Data directive prohibits); or a digital-lending-data flow outside India (the RBI Digital Lending Guidelines restrict); or a KYC-data flow outside the permitted use cases (the SEBI KRA Master Circular restricts); or a policyholder-data flow outside India (the IRDAI guidelines restrict); or the ICT logs outside the 180-day localisation (the CERT-In Directions require). The conformant pattern is the sector-overlay screen per sector rule.

The "voluntary-only disclosure log" anti-pattern (A.2.5.4)

The processor's disclosure log covers the sub-processor disclosures and the third-party-recipient disclosures, but is silent on the law-enforcement-request disclosures, the regulator-direction disclosures and the court-order disclosures. The "voluntary-only" disclosure log is the canonical A.2.5.4 finding, the processor has cherry-picked the easy categories and omitted the hard ones. The conformant pattern covers every category.

The "Spreadsheet-of-Disclosures" anti-pattern (A.2.5.4)

The disclosure log is a spreadsheet on a shared drive, maintained manually by the DPO, with no event-level pipeline feed, no reconciliation, no integrity controls and no version control. The spreadsheet is the canonical A.2.5.4 anti-pattern, it is the processor's claim without the evidence. The conformant pattern is the pipeline-fed, append-only, hash-chained, reconciled log.

The "manual recipient-list assembly" anti-pattern (A.2.5.4)

When the controller exercises the Article 15 / §11 right to access and asks the processor for the recipient list, the DPO emails the engineering team and asks "who have we shared this customer's data with?"; the team manually assembles the list from memory and from disparate sources; the response is served late and incomplete. The conformant pattern is the recipient-list response workflow with the disclosure-log query.

The "sub-processor transfer record missing" anti-pattern (A.2.5.5)

A cross-border sub-processor engagement is in the A.2.5.7 register but not in the A.2.5.5 record. The chain-transfer re-assessment is missing or stale; the controller-authorisation is not cited; the flow-down contract's cross-border clauses are not referenced. The conformant pattern is the A.2.5.5 record per cross-border engagement, linked to the A.2.5.7 register.

The "chain-transfer re-assessment as a one-off" anti-pattern (A.2.5.5)

The processor ran the chain-transfer re-assessment (TIA) at the engagement's start but has not refreshed it. The destination's surveillance law has degraded; the TIA is older than the annual cadence; the supplementary measures have not been verified. The conformant pattern is the annual TIA refresh and the destination-country legal-change-event refresh.

The "comply-without-routing" anti-pattern (A.2.5.6)

The processor complies with a law-compulsion request without routing it to the controller. The textbook A.2.5.6 infringement; the textbook Article 28(10) status-drift trigger. The conformant pattern is the controller-routing discipline (within 24 hours of intake, except where prohibited).

The "blanket-comply" anti-pattern (A.2.5.6)

The processor's law-compulsion-request procedure is to comply with every request, without the multi-factor legality assessment. The blanket-comply pattern is the canonical A.2.5.6 finding, the processor has effectively waived the proportionality test that Puttaswamy requires. The conformant pattern is the multi-factor legality test documented per request.

The "foreign-law-enforcement direct-compliance" anti-pattern (A.2.5.6)

The processor complies with a foreign law-enforcement request directly, without the MLAT / court-order route. The textbook GDPR Article 48 infringement and the textbook A.2.5.6 infringement. The conformant pattern is the jurisdiction test in the multi-factor legality assessment.

The "impossible zero" anti-pattern (A.2.5.6)

The processor's law-compulsion-request log has zero entries over a multi-year period, despite the processor having substantial customer-volume. The impossible zero is the canonical A.2.5.6 finding, the requests have arrived but have not been logged (or have not been routed through the procedure). The conformant pattern is the documented procedure with the log-entry requirement, the trained Response Team and the annual tabletop.

The "gag-order blind spot" anti-pattern (A.2.5.6)

The processor's procedure does not contemplate the gag-order case. The processor either routes the request in violation of the gag-order (a legal violation) or complies without the controller-routing record (an A.2.5.6 infringement). The conformant pattern is the gag-order handling procedure with the log entry, the calendar-the-expiry discipline and the challenge procedure for overbroad gag-orders.

The "single-point-of-failure" anti-pattern (governance)

The DPO is the named owner of every dimension of the five controls, the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request procedure. The single-point-of-failure pattern is the canonical governance finding. The conformant pattern is the RACI with the role distribution.

The "DPA boilerplate without the operational evidence" anti-pattern (the capstone)

The processor's customer DPA has the transfer-and-disclosure clauses (the permitted destinations, the authorised mechanisms, the disclosure-authorisation, the law-compulsion-request routing). The processor treats the DPA clauses as the controls. There is no destination register, no transfer-mechanism register, no disclosure log, no sub-processor transfer record, no law-compulsion-request log. The conformant pattern is the operational evidence behind the clauses.

Illustrative Scenario 1: Failure, Kaveri Cloud Analytics and the Off-Register Singapore Pipeline (Illustrative)

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative scenario. Names, figures and events are illustrative composites, drawn from the patterns in the Singahi research base. Any resemblance to a specific company is coincidental. The case is presented for the operating lessons, not as a factual account.

The company and the context

Kaveri Cloud Analytics (a neutral name; not a real company) is a Bengaluru-based B2B customer-analytics SaaS processor founded in 2019. By 2025, Kaveri had grown to approximately 280 employees and served 46 controller-customers, 22 India-based (across retail, edtech, healthcare and manufacturing), 14 EU-based, 7 US-based, and 3 across Southeast Asia and the Middle East. The platform ingests the controller-customers' first-party customer data (transaction events, profile data, behavioural events) and produces segmentation, churn-prediction and personalisation outputs.

The processing involved a Mumbai-region primary deployment, a Singapore-region disaster-recovery (DR) deployment, a US-based AI-model vendor for the personalisation feature, and a Netherlands-based customer-success analytics partner. The privacy function was led by a DPO hired in 2024 reporting to the Chief Technology Officer; the Legal counsel was half-time; the Data Engineering Lead ran the pipeline.

The incident

In April 2026, an enterprise EU controller-customer's vendor-diligence team asked Kaveri to produce, within ten working days, the following: the destination-country assessment register; the transfer-mechanism register; the disclosure log for the customer's data; the sub-processor transfer record for the cross-border sub-processors; and the law-compulsion-request log. The DPO attempted to assemble the records manually. The assembly surfaced the gaps:

• No destination-country register. The DPO had a list of destinations in a slide deck from the 2024 board presentation ("Mumbai primary; Singapore DR; US ML vendor; Netherlands partner"). The list was not a register; there were no DPDP §16 screens, no sector-overlay screens, no customer-permitted-destinations overlay, no GDPR cascade, no TIAs. The Singapore DR entry was indistinguishable from the US ML vendor entry; the Netherlands partner entry was indistinguishable from the customer-success analytics partner's other flows.
• No transfer-mechanism register. The customer DPA's transfer schedule cited SCCs for the EU customers' data; the SCCs had been signed in 2022 using the pre-2021 SCC templates; the migration to the 2021 modular SCCs had not been done. No Schrems II TIA had been conducted for any of the EU-applicable flows. The US ML vendor's flow relied on a generic Data Processing Addendum the vendor had provided; no SCC Module 3 (processor-to-processor) had been executed between Kaveri and the US vendor.
• No disclosure log. The disclosures to the sub-processors were documented in the customer DPAs, but no per-event log existed. Two law-enforcement requests over the preceding twelve months (a section 91 CrPC summons from a state police force investigating a fraud ring that had used one of Kaveri's controller-customer's platforms; a section 69B IT Act direction from a central investigative agency) had been handled by the Chief Operating Officer directly, without the DPO's knowledge, without the controller-routing discipline, and without a documented legality assessment. The regulator-direction disclosure (an SEBI information request through a SEBI-regulated controller-customer in late 2025) had been responded to from the platform directly, without a log entry.
• No sub-processor transfer record (A.2.5.5). The US ML vendor's cross-border engagement was not in any A.2.5.5-style record. The chain-transfer re-assessment was missing; the controller-authorisation basis was not documented; the flow-down contract's cross-border clauses were not cited.
• No law-compulsion-request log. The two section 91 / section 69B requests and the SEBI information request had not been logged.

The consequences

The vendor-diligence team flagged the gaps and paused the contract renewal. The immediate consequences were:

• A referral to the controller-customer's supervisory authority, the EU controller-customer's DPO, on learning that the Schrems II TIA had not been conducted for the EU-applicable flows, filed a complaint with the national supervisory authority; the authority coordinated with the Data Protection Board of India on the cross-border dimension.
• A referral to the DPBI for the section 91 / section 69B handling, the absence of the controller-routing discipline and the legality assessment on the law-enforcement requests; the absence of the disclosure-log entries.
• A freeze on the US ML vendor's flow for the EU controller-customer's data, the customer's instructions were to suspend the cross-border flow until the SCC Module 3 was executed and the TIA was conducted.

The DPBI's interim inquiry, completed in late 2026, focused on the cross-border records discipline. The penalty exposure for the controller-customer (under whose instructions Kaveri processed) was in the section 33 + Schedule band for the section 8(5) safeguards failure (the absence of the cross-border records discipline was treated as a safeguards failure); the indemnity claim against Kaveri was in the range of INR 8 to 22 crore (covering the principal notifications, the crisis communications, the legal defence, the contract-renewal loss).

The lessons

Six lessons for Indian growing-company processors.

1. The destination-country register is the gate, not a list. A list of destinations is the L1 anti-pattern. The conformant register has the per-destination schema with the screens and the overlays.
2. The transfer-mechanism register is the verification, not the controller's instruction. The controller's instruction is the legal authority; the transfer-mechanism register is the operational evidence that the authority was verified.
3. The disclosure log must cover every category. The voluntary-only disclosure log is the canonical A.2.5.4 finding. The legally-binding categories are non-negotiable.
4. The sub-processor transfer record is the chain-transfer evidence. The A.2.5.5 record is the operational evidence for the cross-border sub-processor; without it, the chain transfer is unauditable.
5. The law-compulsion-request procedure is the routing, not the compliance. The processor's primary duty is to route; the controller's duty is to decide.
6. The vendor-diligence questionnaire is the early signal. The DPDP Act's full enforceability and the 27701:2025 certification are the later signals. Processors that build the five registers ahead of the regulatory window capture the commercial differentiation; processors that retrofit in 2027 and 2028 are on the defensive.

The remediation

Kaveri's remediation programme ran from mid-2026 to mid-2027. The Singahi destination-country register, transfer-mechanism register, disclosure log, sub-processor transfer record and law-compulsion-request log templates were adopted; the SCCs were migrated to the 2021 modular SCCs; the TIA was conducted for the EU-applicable flows; the Law-Compulsion-Request Response Team was convened; the controller-routing discipline was drilled. The EU controller-customer's contract renewal resumed in early 2027 after the Stage 1 verification of the new discipline.

Illustrative Scenario 2: Success, Avani Health BPO Builds the Five-Register Processor Discipline (Illustrative, with ROI)

Illustrative scenario. Names, figures and events are illustrative composites, drawn from the patterns in the Singahi research base. Any resemblance to a specific company is coincidental. The case is presented for the operating lessons, not as a factual account.

The company and the context

Avani Health BPO (a neutral name; not a real company) is a Chennai-based B2B healthcare-BPO processor founded in 2018. By 2025, Avani had grown to approximately 460 employees and served 28 controller-customers, 18 India-based hospital chains, 6 GCC-based hospital groups, 3 UK-based clinical-research organisations, and 1 US-based telemedicine provider. The processing involved cross-border flows to the GCC customers (a UAE hosting region; a Saudi Arabia reporting destination), to the UK clinical-research organisations (a UK hosting region), to the US telemedicine provider (a US hosting region), and to a US-based AI-diagnostics vendor for an inference sub-processor engagement. The privacy function was led by a DPO (hired in 2024) reporting to the Chief Operating Officer, supported by a half-time Legal counsel, a Data Engineering Lead, and a Vendor Management Lead.

The trigger

In late 2025, Avani's largest Indian hospital-client (a tertiary-care chain that was a Significant Data Fiduciary under DPDP section 10) issued an annual vendor-diligence questionnaire that asked, for the first time, for: the destination-country assessment register; the transfer-mechanism register; the disclosure log; the sub-processor transfer record for the cross-border sub-processors; and the law-compulsion-request log. The DPO, asked to respond within ten working days, recognised that the answer was "partially" and that the partial answer would not satisfy the SDF-customer's diligence. The DPO also recognised that the DPDP Act's full enforceability (estimated May 2027) and the upcoming ISO/IEC 27701:2025 certification audit (planned for Q2 2027) would require the same discipline.

The build

The DPO convened a cross-functional team (DPO, Legal, Data Engineering Lead, Vendor Management Lead, Cloud Lead, Security Lead) and adopted the Singahi five-register templates. The build ran from January to August 2026 in four phases.

Phase 1 (January to February 2026), Inventory. The team inventoried every cross-border flow (22 flows across seven destinations: the UAE hosting region; the Saudi Arabia reporting destination; the UK hosting region; the US hosting region; the US AI-diagnostics vendor; the cloud DR regions in Singapore and the Netherlands; the support-vendor flows to the Philippines). The team inventoried every disclosure category (the GCC customers as the processor disclosures; the UK clinical-research organisations as the joint-controller disclosures; the US AI-diagnostics vendor as the sub-processor disclosure; the law-compulsion-request category, four requests over the preceding twelve months; the regulator-direction category, one IRDAI query in 2025 and one DPBI correspondence).

Phase 2 (March to April 2026), Destination register and transfer-mechanism register. The team ran the DPDP §16 negative-list screen on every destination (none were on the restricted list at the time; the Saudi Arabia reporting destination was flagged for monitoring given the evolving Saudi PDPL enforcement). The team ran the sector-overlay screens (the healthcare-data overlay; the IRDAI policyholder-data locality where insurance-data was involved; the RBI payment-data localisation for the small subset of payment-data flows). The team ran the GDPR cascade for the EU/UK-applicable flows (the UK clinical-research organisations, Article 46 SCCs, Module 1 controller-to-controller for the joint-controller disclosures, Module 2 controller-to-processor for the customer-to-Avani leg; the GCC customers, no GDPR application). The team ran the Schrems II TIA on the US AI-diagnostics vendor (the TIA identified the supplementary measures: encryption-at-rest with CMK held outside the US; pseudonymisation with the mapping held in India; contractual transparency-about-government-access and challenge-of-unlawful-access clauses; the split-processing architecture for the most sensitive inferences). The team migrated the SCCs from the pre-2021 versions to the 2021 modular SCCs across the EU/UK customer portfolio.

Phase 3 (May to June 2026), Disclosure log and sub-processor transfer record. The Data Engineering team built the event-emission pipeline that emitted a structured event per cross-border flow, per sub-processor disclosure, per joint-controller feed. The pipeline fed the disclosure log automatically. The DPO entered the legally-binding disclosures (the four law-compulsion requests and the two regulator-direction disclosures) retroactively from the email archive; the Law-Compulsion-Request Response Team was convened; the Law-Compulsion-Request Procedure was drafted, signed off and trained. The sub-processor transfer record (A.2.5.2 read with A.2.5.7) was populated for the cross-border sub-processors (the US AI-diagnostics vendor; the Philippines support vendor; the Singapore DR provider); each engagement was linked to its chain-transfer re-assessment, its flow-down contract reference, and its A.2.5.7 register entry.

Phase 4 (July to August 2026), Recipient-list response and downstream-rights propagation. The team built the recipient-list response workflow with the disclosure-log query for the controller-customer's Article 15 / §11 access requests. The first test run produced the recipient list for a sample patient cohort in 95 seconds; the previous manual-assembly pattern had taken 3 to 5 hours per request and had missed the law-enforcement disclosures. The team built the downstream-rights-propagation workflow; the first test run propagated a correction request to the four recipients of the patient's data within 24 hours, with the recipient confirmations tracked.

The results

By August 2026, the five registers were operational. The measurable outcomes:

• Recipient-list response clock attainment improved from approximately 55 percent (manual assembly) to 100 percent (auto-response from the disclosure log).
• Pipeline-to-log reconciliation rate for the disclosure log reached 99.4 percent (the 0.6 percent gap was the recurring reconciliation fix-up, addressed through the September 2026 sprint).
• Off-register destination count reached zero (the 22 flows were reconciled to the seven destinations; no off-register flows).
• Transfer-mechanism coverage reached 100 percent (every cross-border flow had a current, operational transfer mechanism; the SCC migration completed; the TIA programme completed).
• Sub-processor transfer-record coverage reached 100 percent (every cross-border sub-processor engagement was in the A.2.5.5 record with the TIA, the controller-authorisation, the flow-down contract).
• Law-compulsion-request controller-routing clock attainment reached 100 percent (the four retroactively entered requests and the one subsequent request all had the controller-routing record within 24 hours of intake).

The ROI

The measurable returns:

• The largest Indian SDF hospital-client renewed the contract at approximately INR 18 crore per year (the vendor-diligence questionnaire was satisfied in full; the SDF-customer's section 10 DPIP drew positively on Avani's five registers).
• The ISO/IEC 27701:2025 certification Stage 1 audit (Q1 2027) reported zero A.2.5.2 / .3 / .4 / .5 / .6 majors and one minor (the recurring reconciliation fix-up, addressed before Stage 2).
• The DPDP Act's full enforceability (estimated May 2027) found Avani operationally conformant on the five controls; the regulatory-risk exposure was reduced to near-zero on the transfer-and-disclosure dimensions.
• The privacy function's reputation within Avani shifted from a compliance cost centre to a commercial-differentiation function; the DPO was promoted to Chief Privacy Officer reporting to the CEO; the team expanded by two headcount in 2027.

The cumulative return over the 2026 to 2028 window was approximately INR 45 to 55 crore in retained and new contract value, plus the avoided regulatory-risk exposure (the DPDP penalty exposure for the section 8(5) safeguards failure, on the patient-cohort volume, was estimated at INR 50 to 150 crore).

The lessons

Six lessons for Indian growing-company processors.

1. The vendor-diligence questionnaire is the early signal. The SDF-customer's questionnaire was the trigger; the DPDP full enforceability and the 27701:2025 certification were the later signals.
2. The destination-country register is the procurement-differentiator. The GCC hospital-clients' procurement teams asked for the register; Avani's register closed the procurement.
3. The disclosure log is the Article 15 / §11 unlock. The auto-response from the disclosure log turned a 3-to-5-hour manual task into a 95-second auto-task.
4. The sub-processor transfer record is the chain-transfer unlock. The A.2.5.5 record made the cross-border sub-processor chain auditable end-to-end; the SDF-customer's DPIP drew positively on the chain-transfer evidence.
5. The law-compulsion-request procedure is the Puttaswamy operationalisation. The multi-factor legality test is the processor's (and through the routing, the controller's) internal proportionality test. The annual tabletop exercise is the training that keeps the test alive.
6. The five registers are the privacy function's commercial story. The shift from cost-centre to commercial-differentiation is the processor's reputational return on the privacy investment.

Multi-Framework Mapping

The A.2.5.2 / .3 / .4 / .5 / .6 family maps onto the major privacy and security frameworks as below. Where a cell has a clause / article / section number, it is a direct cross-reference. Where a cell has a name only, it is a methodological analogue.

The control-by-control crosswalk

The Indian statutory-anchoring summary

The A.2.5.2 / .3 / .4 / .5 / .6 family maps onto the DPDP Act in six dense clusters. Cluster 1, transfer-basis discipline (A.2.5.2): anchored in section 2(1)(k) (the processor's "on behalf of" status depends on the documented instruction); section 16 (the negative list); section 8(5) safeguards; section 33 + Schedule. Cluster 2, destination-list discipline (A.2.5.3): anchored in section 16 negative-list; section 8(5) safeguards; section 10 SDF DPIP. Cluster 3, disclosure-log discipline (A.2.5.4): anchored in section 8(6) breach (the log is the breach-detection source); section 8(7) erasure (the downstream propagation); section 11 access (the recipient list); section 18 Board powers. Cluster 4, sub-processor transfer-record discipline (A.2.5.2 read with A.2.5.7): anchored in section 2(1)(k) (the sub-processor extension); section 8 (the chain flow-through); section 16 (the chain-transfer screen). Cluster 5, law-compulsion-request discipline (A.2.5.6): anchored in section 18 Board powers; CrPC sections 91, 92; IT Act sections 69, 69A, 69B; Puttaswamy (2017) 10 SCC 1 (the proportionality backdrop). Cluster 6, sector-overlay discipline (A.2.5.2 and A.2.5.3): anchored in RBI Storage of Payment System Data 2018; RBI Digital Lending 2022; SEBI KRA 2024; SEBI CSCRF 2024; IRDAI 2023; CERT-In Directions 2022. A processor that implements the A.2.5.2 / .3 / .4 / .5 / .6 family has implemented the operational core of the DPDP Act's processor-side transfer-and-disclosure discipline.

The sector-regulator overlay (India-specific)

The cross-border overlay

Where the controller-customer is in a different jurisdiction from the processor, the transfer 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 (Module 2 controller-to-processor); the India-US leg is governed by the SCCs (Module 3 processor-to-processor); the Schrems II TIA at both legs; the DPDP section 16 negative-list screening for the controller's India-principal data (if any); 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 PIPL Article 55 PIA is the Chinese chain-transfer evidence. The processor's transfer-mechanism register 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.2, A.2.5.3, A.2.5.4, A.2.5.5 and A.2.5.6.

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, Legal Lead, Engineering Lead, Cloud / Infrastructure Lead, Information Security Lead, Vendor Management Lead, Customer Success Lead, Internal Audit). The team adopts the Singahi five-register templates.
• Day 6 to 15, Register stand-up. The team stands up the destination register, the transfer-mechanism register and the disclosure log on the chosen tool (spreadsheet acceptable first cycle if integrity, access control and reconciliation are documented; PMP or in-house build for the steady state). The team loads the existing flows, the cross-border flows 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 transfers, the flows the registers 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 disclosure-update communication to the affected controller-customers.

The 90-day milestone, transfer-mechanism register and disclosure-log maturity

• Day 31 to 50, Template adoption. The team adopts the Singahi Processor Sharing, Transfer and Disclosure Policy (toolkit doc 01), the Lifecycle Procedure (toolkit doc 02), the Destination-Country Assessment Register (toolkit doc 03), the Transfer-Mechanism Register (toolkit doc 09), the Disclosure Log and Sub-processor Transfer Record (toolkit doc 10), calibrated to the processor's transfer-and-disclosure profile.
• Day 51 to 70, SCC and TIA programme. The team runs the SCC inventory, which flows use the pre-2021 SCCs (the migration plan); which flows have no SCCs (the execution plan); which flows rely on the EU-US Privacy Shield (the migration to the Data Privacy Framework or the SCCs). The team runs the TIA programme for the cross-border flows to non-adequate destinations; the supplementary measures are documented per flow.
• Day 71 to 90, Event-emission pipeline. The Data Engineering team builds the event-emission pipeline that emits the disclosure-log entries automatically from the source systems. The first test run produces the recipient-list response within the SLA.

The 180-day milestone, sub-processor transfer record and law-compulsion-request procedure

• Day 91 to 120, Sub-processor transfer record (A.2.5.5). The team stands up the A.2.5.5 record for the cross-border sub-processors; the chain-transfer re-assessment runs for each engagement; the controller-authorisation and the flow-down contract references are populated.
• Day 121 to 150, Law-Compulsion-Request Procedure. The team drafts the Law-Compulsion-Request Procedure (toolkit doc 08); the Response Team is convened; the multi-factor legality-assessment template is adopted; the first tabletop exercise runs three scenarios.
• Day 151 to 180, Integration. The team builds the integration with the processor ROPA (A.2.2.7), the sub-processor register (A.2.5.7), 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, Continuous monitoring. The team stands up the continuous-monitoring feed (the SDK and marketplace scanning; the cross-border landscape monitoring for legal-change events).
• Month 8, Internal audit. The team runs the internal audit (Clause 9.2) covering the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request log.
• 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, Certification Stage 1. The certification Stage 1 documentation review. The team closes the findings before the Stage 2.
• Month 11, Certification Stage 2. The Stage 2 operational-effectiveness test. The auditor walks a sample of cross-border flows through the five registers; a sample of disclosure-log entries; a sample of sub-processor transfer records; a sample of law-compulsion-request records (or the tabletop).
• Month 12, Drill and refresh. The annual Law-Compulsion-Request Response Team drill; the annual TIA refresh; the annual destination-register refresh; the annual customer-communication cycle.

The ongoing cadence (post-certification)

• Weekly, Register activity review (DPO); new-flow intake review (Engineering); shadow-transfer discovery follow-up.
• Monthly, KPI dashboard review (DPO); reconciliation across the five registers; disclosure-log reconciliation with the pipeline telemetry; law-compulsion-request log review (where any requests in the period).
• Quarterly, Destination-register refresh; transfer-mechanism-register refresh; sub-processor-transfer-record refresh; risk-tier re-assessment.
• Semi-annually, Law-Compulsion-Request Response Team tabletop exercise; the disclosure-log integrity audit.
• Annually, Internal audit of A.2.5.2 / .3 / .4 / .5 / .6; the full TIA refresh for cross-border flows; the full destination-register refresh; the Processor Sharing, Transfer and Disclosure Policy review; the customer-communication cycle.
• Event-driven, Destination-country legal-change event (the register refresh and the suspension procedure); sector-rule change (the overlay refresh); customer DPA amendment (the permitted-destinations overlay update); sub-processor ownership change (the chain-transfer re-assessment); sub-processor breach (the chain breach-handoff); law-compulsion request (the procedure fires).

FAQ

Q1. Our customer DPA already has a transfer-and-disclosure schedule that says we will transfer only on the controller's instructions and keep records. Is that enough for A.2.5.2 and A.2.5.4?

No. The two controls are operational, not contractual. The DPA's transfer schedule is the legal authority; the transfer-mechanism register (A.2.5.2) is the operational evidence that the authority was verified; the disclosure log (A.2.5.4) is the operational evidence that the disclosures were logged. The certification auditor and the regulator will look behind the schedule to the operational evidence.

Q2. Our customer DPA cites SCCs that we signed in 2021. Have we satisfied A.2.5.2?

It depends on which SCCs. If the 2021 signing used the pre-2021 SCCs (Decision 2001/497/EC, 2004/915/EC, 2010/87/EU), they were superseded on 27 December 2022 and must be migrated to the modular SCCs of Implementing Decision (EU) 2021/914. If the 2021 signing used the modular SCCs, the version is current. The TIA must be conducted for flows to non-adequate destinations. The transfer-mechanism register is the evidence.

Q3. Our customer DPA's transfer schedule authorises transfers to "all destinations with appropriate safeguards". Is that enough for A.2.5.3?

No. A.2.5.3 is the processor's destination register, not a copy of the controller's permitted-destinations list. The processor's register must capture the destinations the processor actually transfers to, with the DPDP §16 screen, the sector-overlay screens, the customer-permitted-destinations overlay, the GDPR cascade (where applicable) and the TIA reference (where applicable). The customer DPA's general statement is the contractual authority; the register is the operational evidence.

Q4. We have a destination in the United States and we rely on the EU-US Data Privacy Framework adequacy decision. Do we still need a TIA?

For transfers to US organisations that are certified under the EU-US Data Privacy Framework (DPF), the TIA is generally not required (the DPF is an adequacy decision, like any other Article 45 adequacy). For transfers to US organisations that are not DPF-certified, the SCCs (Module 2 or Module 3) plus the Schrems II TIA are required. The transfer-mechanism register documents which route applies per flow.

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

The chain-transfer re-assessment under Schrems II. The EU-India leg uses SCC Module 2 (controller-to-processor) between the customer and us. The India-US leg uses SCC Module 3 (processor-to-processor) between us and the sub-processor. The TIA covers both legs; the supplementary measures (the encryption with keys we hold; the split processing; the contractual challenge commitments) are documented. The A.2.5.5 record captures the engagement; the A.2.5.7 / .5.8 / .5.9 controls operate the chain governance.

Q6. A section 91 CrPC summons arrives at our office addressed to our CEO. What do we do?

Operate the Law-Compulsion-Request Procedure (toolkit doc 08). The intake, route the summons to the dedicated intake channel; do not respond directly. The controller-routing, notify the controller-customer whose data is sought within 24 hours of intake (unless the summons prohibits notification, which a CrPC §91 summons typically does not). The multi-factor legality assessment, the Legal counsel runs the test (jurisdiction; legal basis; scope; proportionality; necessity; challenge decision). The response execution, the Engineering Lead executes the technical extraction; the Security Lead operates the secure-transmission channel. The log entry, every step is logged.

Q7. A foreign law-enforcement agency sends us a direct request for a controller-customer's data. What do we do?

Do not comply directly. The request must be routed through the MLAT / mutual-legal-assistance-treaty process or through an Indian court order. The processor's compliance with a foreign request directly would violate GDPR Article 48 (where EU personal data is involved) and the equivalent Indian rule. The Law-Compulsion-Request Procedure's jurisdiction test flags the request; the Legal counsel engages with the requesting authority's legal representative to route through the MLAT / court-order process; the controller is notified.

Q8. A law-enforcement request comes with a gag order that prohibits us from notifying the controller-customer. What do we do?

Operate the gag-order handling procedure (toolkit doc 08 Section 6). The log entry records the request with the gag-order reference. The Legal counsel reviews the gag-order's scope and duration. The processor calendars the gag-order's expiry. On expiry, the processor assesses the notification to the controller. The processor may challenge an overbroad gag-order through the competent court.

Q9. Our customer exercises the Article 15 / DPDP §11 right of access and asks us for the recipient list. The clock is the controller's, not ours. What is our SLA?

The customer DPA's breach-and-rights schedule specifies the SLA (typically hours, not days, the controller needs to compile its own response within the Article 12(3) one-month clock / the DPDP Rules' §11 clock). The recipient-list response workflow produces the list from the disclosure log; the engineering unlock is the auto-query. A processor that cannot produce the recipient list within the SLA exposes the controller to the controller's own Article 15 / §11 violation.

Q10. Our engineering team started routing a customer's data to a new cloud region last quarter without going through the destination-onboarding workflow. What do we do?

Register the destination retrospectively; run the DPDP §16 screen and the sector-overlay screens; assess the transfer-mechanism position (the customer DPA's transfer schedule may or may not authorise the destination); communicate the disclosure update to the affected controller-customer; embed the destination-onboarding workflow in the engineering team's intake process so it does not recur. The shadow-transfer is the highest-frequency A.2.5.2 / .3 finding; the quarterly reconciliation workshop is the discipline that surfaces them.

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

Yes. The SDF's enhanced duties (DPIP support, independent-audit cooperation, algorithmic-fairness-review support) propagate through the customer DPA. The processor's five registers must support the SDF's DPIP, the destination register and the transfer-mechanism register are DPIP inputs; the disclosure log and the law-compulsion-request log support the SDF's section 10 audit; the sub-processor transfer record supports the algorithmic-fairness review where the cross-border sub-processor is an AI vendor.

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

Both sides. The customer (controller) has the controller-side discipline (the controller authorises the transfers and the disclosures; the controller's records depend on the processor's records) under A.1.5.2 to A.1.5.5. The processor has the A.2.5.2 to A.2.5.6 controls, the operational gate through which every transfer and disclosure passes. The two sides are sequential: the controller sets the regime through the DPA; the processor operates the regime through the five controls.

Q13. We use a general-authorisation regime for our sub-processor engagements. Does that mean we do not need the A.2.5.5 record?

No. The general-authorisation regime waives the per-engagement controller approval; it does not waive the A.2.5.5 record. The A.2.5.5 record captures the transfer-disclosure slice for every cross-border sub-processor engagement, the destination, the transfer mechanism, the TIA reference, the controller-authorisation basis (general, with the DPA-clause reference cited and the change-notification record under A.2.5.9), the flow-down contract reference. The record is the operational evidence behind the general-authorisation clause.

Q14. Our sector-regulator (RBI / SEBI / IRDAI) asks us for information about our controller-customer's data. Are we bound to comply directly or to route through the controller?

It depends on the regulator's jurisdiction over the processor. Where the regulator has direct jurisdiction (the processor is within the RBI's outsourcing jurisdiction; the processor is within the SEBI's CSCRF scope; the processor is within the IRDAI's ICT-outsourcing scope), the regulator may direct the processor directly, the Law-Compulsion-Request Procedure's jurisdiction test confirms this. Where the regulator's jurisdiction runs through the controller-customer (the regulator regulates the customer, not the processor), the request is typically routed through the customer. The Law-Compulsion-Request Procedure handles both cases; the controller-routing discipline applies in either case (the controller is notified, even where the direction is to the processor directly).

Q15. Our sub-processor suffered a breach. The breach-notification clock runs from the controller-customer's awareness. What is our handoff timeline?

The chain handoff. The sub-processor's flow-down breach clause requires it to notify the processor without undue delay (typically 24 to 48 hours). The processor's customer DPA's breach clause requires the processor to notify the controller (typically 48 to 72 hours from the processor's awareness). The controller notifies the Board and the affected principals under section 8(6) 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; the disclosure log is the breach-detection source.

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 transfer-and-disclosure 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 further outsourcing without prior written permission, must allow RBI inspection, and must include data-locality clauses. RBI NBFC Managing Risks in Outsourcing Directions, 2025, equivalent NBFC duties. SEBI CSCRF (20 August 2024), third-party and outsourcing expectations; data-locality expectations. IRDAI Information and Cyber Security Guidelines (24 April 2023), ICT-outsourcing data-protection clauses. RBI Storage of Payment System Data (6 April 2018), payment-data localisation.

Family emphasis for BFSI processors. The destination register's sector-overlay screens for payment-data (India-only), KYC-data (the KRA permitted use cases), policyholder-data (India-only by default), and ICT logs (180-day CERT-In localisation) are the load-bearing A.2.5.3 mechanism. The specific-authorisation regime (the bank's prior written permission) governs the sub-processor transfer record (A.2.5.2 read with A.2.5.7)'s controller-authorisation field for the BFSI customers. The law-compulsion-request procedure must handle the RBI / SEBI / IRDAI directions that may land directly with the processor (the direct-jurisdiction case).

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.

Family 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, and the A.2.5.5 record for these engagements is the densest slice of the family's operation. The cross-border dimension (the telemedicine platforms that route consultations across borders for second-opinion services; the clinical-research partnerships with foreign institutions) is the marquee A.2.5.2 challenge. The law-compulsion-request procedure must handle the patient-data sensitivity on law-enforcement requests (the proportionality test is sharper for health data).

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 transfer-and-disclosure estate is correspondingly diverse, from infrastructure clouds to SDK vendors to AI-model providers.

Family emphasis for IT-ITeS and SaaS processors. The multi-jurisdiction transfer regime (the destination register, the transfer-mechanism register, the disclosure log, the sub-processor transfer record, the law-compulsion-request log must each accommodate the multi-jurisdiction reality); the AI-model sub-processor tier (the marquee A.2.5.5 challenge, the Article 28(10) drift question at the sub-processor layer; the Schrems II TIA for the US-AI-model engagements); the customer-portal recipient-list response (the auto-response from the disclosure log is the operational unlock for the customer-portfolio scale); 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.

Family emphasis for e-commerce and retail processors. The payment-rail sub-processor category (the RBI payment-data localisation overlay, the destination-country register's payment-data entry is "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).

Family emphasis for edtech processors. The children's-data overlay (DPDP section 9) makes every cross-border sub-processor involving a child's data a high-risk engagement. The destination-country register must reflect the verifiable-parental-consent overlay and the no-behavioural-monitoring and no-targeted-advertising prohibitions on any cross-border flow involving children's data. The sub-processor transfer record must flag children's-data sub-processors as Tier B (approved-with-conditions) or Tier C (declined) by default. 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.

Family 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 destination-country register 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.

Family emphasis for government processors. The exemption analysis under section 17 (does the government's processing qualify for an exemption? does the processor inherit the exemption?); the localisation expectations for government data (the data-residency considerations that may require the destination register to be "India-only" for government-controller customers); the joint-controller analysis with the public-sector technology partners; the legal-process handling for government-instructed data sharing (the A.2.5.6 procedure for government-direction disclosures).

Maturity Model

Figure · Tiers

Maturity levels for sharing transfer and disclosure (remaining)

Level 1, Initial / Ad-hoc

Characteristics. No destination-country register; no transfer-mechanism register; no disclosure log; no sub-processor transfer record; no law-compulsion-request procedure. The processor relies on the controller's instruction without independent verification. The cross-border flows are tracked in the engineering team's wiki; the disclosures live in the customer-support inboxes. The law-compulsion requests are handled by the CEO directly. The most common audit nonconformity pattern in Indian growing-company processors.

Typical artefacts. A customer DPA template with transfer-and-disclosure clauses inherited from a standard template. A list of destinations in a slide deck. No other transfer-and-disclosure artefacts.

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

The investment covers the register stand-up, the reconciliation workshop, the SCC inventory, the disclosure-log stand-up, the law-compulsion-request procedure drafting.

Level 2, Repeatable / Defined

Characteristics. A documented Processor Sharing, Transfer and Disclosure Policy. A current Destination-Country Assessment Register reconciled with the customer DPA's permitted-destinations lists. A current Transfer-Mechanism Register reconciled with the customer DPAs' transfer schedules. A current Disclosure Log fed by the event-emission pipeline. The first Sub-processor Transfer Record populated for the cross-border sub-processors. The Law-Compulsion-Request Procedure drafted; the Response Team convened; the first tabletop exercise run.

Typical artefacts. The Policy; the Lifecycle Procedure; the Destination-Country Register; the Transfer-Mechanism Register; the Disclosure Log; the Sub-processor Transfer Record; the Law-Compulsion-Request Procedure; the first tabletop exercise report.

The investment covers the SCC migration to the 2021 modular SCCs, the TIA programme, the recipient-list response workflow, the downstream-rights-propagation workflow, the KPI maturity.

Level 3, Managed / Measured

Characteristics. The SCC migration completed across the customer portfolio. The TIA programme completed for the cross-border flows to non-adequate destinations. The recipient-list response workflow producing the recipient list from the disclosure log within the SLA. The downstream-rights-propagation workflow tracking the recipient confirmations. The full Sub-processor Transfer Record reconciled with the A.2.5.7 sub-processor register. The Law-Compulsion-Request Procedure drilled with multiple scenarios; the first real requests handled through the procedure. The fourteen KPIs reporting; the first management-review pack produced. The first internal-audit report on the family.

Typical artefacts. The migrated SCCs; the TIA reports; the recipient-list response workflow; the downstream-rights-propagation workflow; the KPI dashboard; the first internal-audit report on the family.

The investment covers the multi-jurisdiction transfer capability, the automated register with continuous reconciliation, the customer-portfolio risk analysis, the continuous-monitoring tooling.

Level 4, Quantitatively Managed

Characteristics. The automated registers with continuous reconciliation (the SDK and marketplace scanning; the cross-border landscape monitoring; the engineering-integrations feed). The multi-jurisdiction transfer regime (DPDP plus GDPR plus US-state plus PIPL plus sector rules) operational. The customer-portfolio risk analysis driving the management review. The Law-Compulsion-Request Response Team drilled semi-annually with multiple scenarios. The KPI targets consistently met; the management-review pack driving Clause 10.1 improvement.

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

Level 5, Optimising

Characteristics. The transfer-and-disclosure programme is continuously improved; the five registers are the system-of-record for the broader vendor-relationship-management practice. The TIA methodology is at the frontier (the team contributes to the sector's methodology; publishes anonymised lessons). The Law-Compulsion-Request Response Team drills run quarterly with multiple scenarios. The programme produces predictive analytics (transfer-risk forecasting; sub-processor chain-transfer risk modelling; law-compulsion-request pattern analysis). The processor's transfer-and-disclosure 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-scenario drill reports; the industry-benchmarking evidence.

Maturity-model quick-reference

Emerging Trends

The AI-model sub-processor as the marquee A.2.5.5 challenge

The AI-model vendor is the marquee new sub-processor category of the 2025 to 2027 window. Processors that offer AI-driven services on top of customer data routinely engage AI-model vendors (the model providers, the inference-service providers, the fine-tuning platforms). The A.2.5.5 challenge: the AI-model vendor typically processes the customer's personal data (the prompts, the context, the outputs may contain personal data); the chain-transfer risk is sharp (many AI-model vendors are in jurisdictions with surveillance laws that trigger Schrems II supplementary measures); the Article 28(10) drift question (does the AI-model vendor use the customer's data for its own model-training?) is the marquee compliance question. Processors that build the A.2.5.5 discipline for the AI-model tier 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. The disclosure log is the breach-detection source; the family's integrity discipline is the breach-evidence discipline.

The continuous-monitoring convergence

The continuous-monitoring tools (the security-rating services; the TPRM platforms with continuous posture assessment; the SDK and marketplace scanners; the cross-border landscape monitoring tools) are converging into an integrated capability. The processor's destination register, transfer-mechanism register, disclosure log, sub-processor transfer record are increasingly fed by continuous feeds. The convergence reduces the shadow-transfer risk and the stale-register risk.

The multi-jurisdiction transfer regime

The multi-jurisdiction transfer 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 transfer-and-disclosure duties. A single cross-border flow may trigger multiple regimes, the transfer-mechanism register must address each. The convergence is not perfect (the US-state model differs in the processor's obligations; PIPL adds the CAC security-assessment overlay for cross-border transfers), but a processor that builds to the DPDP-plus-GDPR core will be substantially conformant with the wider landscape with per-jurisdiction configuration.

The processor-side law-compulsion-request transparency reporting

The processor-side law-compulsion-request transparency reporting is an emerging trend borrowed from the large-technology-company practice. The processor's annual transparency report (the aggregate count of law-compulsion requests received; the categories of requests; the aggregate principal cohorts; the challenge decisions) is becoming a customer-diligence differentiator in the enterprise-procurement segment. The processor that publishes the transparency report (in aggregate; subject to the gag-order constraints) signals a mature Law-Compulsion-Request Procedure.

The recipient-list response as the customer-portal feature

The recipient-list response (the processor's support for the controller's Article 15 / §11 access response) is increasingly being offered as a customer-portal feature, the controller signs in, queries the processor's disclosure log for the cohort, and receives the recipient list in real time. The customer-portal feature is the operational expression of the family's disclosure-log discipline; the enterprise customers increasingly ask about the feature in their vendor-diligence questionnaires.

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

The A.2.5.2-to-A.2.5.6 dimensions of DPDP, GDPR Article 28 / Chapter V, 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 9 and section 26) are converging on a similar operational core: a current destination register; a current transfer-mechanism register; a current disclosure log; a current sub-processor transfer record; a documented law-compulsion-request procedure. The converged architecture is the Singahi recommended pattern.

The Schrems II chain-transfer re-assessment as the operational standard

The chain-transfer re-assessment is increasingly being recognised as the operational expression of the Schrems II duty. The EDPB 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 processor-side ethical-AI dimension in the transfer

The processor-side ethical-AI dimension intersects A.2.5.5 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 sub-processor transfer record 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-fairness review under DPDP section 10 SDF.

The integration of the family with the broader privacy-engineering practice

The five registers are increasingly integrated with the broader privacy-engineering practice, the data catalogue, the data-lineage tooling, the privacy-enhancing-technologies (PETs) deployment, the AI/ML governance platform. The integration reduces the friction between the privacy office and the engineering teams; the registers become the system-of-record for the engineering teams' privacy decisions, not a separate compliance artefact. Processors that design the integration from day one avoid the fragmentation that the pre-remediation state typically exhibits.

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; 8.15 logging; 8.18 privileged access).
• ISO/IEC 27018:2019, Code of practice for protection of PII in public clouds acting as PII processor (clauses 9, 10, 11).
• 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.
• 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 to 14 November 2025; phased commencement). Source: meity.gov.in.
• Information Technology Act, 2000 (Act No. 21 of 2000), sections 43A, 69, 69A, 69B 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.
• Code of Criminal Procedure, 1973, sections 91 and 92 (the summons-to-produce provisions).
• 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.
• 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(3)(a) and (b) the documented-instruction and the cross-border authorisation; Article 28(3)(f) the sub-processor authorisation; Article 28(3)(h) records; Article 28(4) the flow-down; Article 28(9) the written record of sub-processors; Article 28(10) status drift); Article 29 processor not to engage another processor except on the controller's instructions; Article 30(2) processor ROPA; Article 32 security; Article 33(2) processor-to-controller breach notification; Article 48 third-country court/admin judgments; Chapter V (Arts 44 to 49) transfers.
• Commission Implementing Decision (EU) 2021/914 of 4 June 2021, modernised Standard Contractual Clauses (Module 2 controller-to-processor; Module 3 processor-to-processor; Module 4 processor-to-controller).
• Commission Implementing Decision (EU) 2016/1250 of 12 July 2016 (the EU-US Privacy Shield, invalidated by Schrems II in July 2020, historic reference only).
• 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.).
• Virginia Consumer Data Protection Act (Va. Code § 59.1-575 et seq.).
• Colorado Privacy Act (C.R.S. § 6-1-1301).
• Connecticut Data Privacy Act (Public Act 22-15).
• Brazil, LGPD (Lei nº 13.709/2018), effective 18 September 2020. Article 33 international transfer; Article 39 operator duties.
• China, PIPL, effective 1 November 2021. Article 21 entrusted processing; Article 38 cross-border mechanisms (the CAC security assessment, the CAC standard contract, the certification); Article 39 separate consent for cross-border; Article 55 PIA.
• Singapore, PDPA 2012 (No. 26 of 2012) as amended; section 9 protection obligation; section 26 transfer limitation.
• Canada, PIPEDA (S.C. 2000, c. 5); Principle 4.1.3.
• Australia, Privacy Act 1988; Australian Privacy Principles (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.
• 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; P5.0 (Access), P6.0 (Disclosure and notification) and P8.0 (Monitoring) are the load-bearing mappings for A.2.5.4 and A.2.5.6; the Common Criteria CC9.2 (vendor oversight) is the load-bearing mapping for A.2.5.2 and A.2.5.5.
• 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); 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; ICO International Transfers guidance (the IDTA / UK Addendum).

Certification-scheme and practitioner references (generic)

• IAF (International Accreditation Forum).
• 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.