ISO 27701 A.2.3: Obligations and A.2.4 Privacy by Design (Remaining)

Quick Reference (60 Seconds)

If you only read one thing: the A.2.3 and A.2.4 controls together close the processor's privacy posture. An A.2.3 / A.2.4-conformant processor is one in which every principal request that the controller forwards is handled within the SLA with an end-to-end audit trail; every temporary file that contains the controller's data is inventoried and auto-purged on a documented cadence; every offboarding is executed with the controller's instruction on file, the data returned or destroyed with certificate, and the processor's own copies cryptographically erased; every transmission flow that carries the controller's data is inventoried with the encryption, authentication and cross-border analysis documented. The certification auditor picks a recent principal request, a recent temp-file location, a recent offboarding and a recent transmission flow, and walks each one's evidence end-to-end. The Data Protection Board of India will, after a principal complaint or an incident at a controller-customer, ask whether the processor supported the controller's rights operation, whether the processor's temporary files were the source of the leak, whether the offboarding was executed cleanly, and whether the transmission was the compromised channel. Get A.2.3 and A.2.4 wrong, no rights-cooperation SLA, temp files accumulating forever, offboardings with no destruction certificate, transmission flows with no encryption, 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.3.2, A.2.4.2, A.2.4.3 and A.2.4.4 ask PII processors to support the controller-customer in discharging the controller's obligations to PII principals (access, correction, erasure, objection, portability, grievance) by providing the data, the deletion capability and the audit trail the controller needs within the agreed timeline (A.2.3.2); to control the creation, retention and deletion of temporary files that contain personal data the processor handles on the controller's behalf, so that such files do not accumulate beyond their processing purpose (A.2.4.2); at the end of the processing services for a controller-customer, to return or transfer the personal data to the controller (or to another processor the controller nominates) and to delete the processor's own copies, in accordance with the controller's instructions and the applicable retention rules (A.2.4.3); and to apply controls to the transmission of the controller-customer's personal data, across the processor's internal systems, between the processor and the controller, and between the processor and sub-processors or third parties, so that the data is protected in transit (A.2.4.4).

The family operates at three layers simultaneously. The first is the principal-cooperation layer (A.2.3.2, the processor's contribution to the controller's principal-facing rights operation; the processor is not the principal's counterparty but is the operational arm of the controller's response). The second is the lifecycle layer, the temporary-file hygiene (A.2.4.2) and the end-of-services data handling (A.2.4.3) that govern the data through its lifecycle at the processor. The third is the transmission layer (A.2.4.4, the protection of the data while it moves). A processor that cooperates on rights but accumulates temporary files forever has a leak surface; a processor that manages temp files cleanly but offboards badly has a leak surface at offboarding; a processor that offboards cleanly but transmits unencrypted has a leak surface in transit. The three layers together form the principal-visible and lifecycle-closing surface of the processor's privacy posture.

The lineage, 2019 to 2025

The four controls have clean ancestors in the 2019 edition. Under 27701:2019, the processor-side obligations and privacy-by-design controls lived in clause 8 (the processor controls), at 8.3 (obligations to PII principals) and 8.4 (privacy by design), with the temp-files, return/transfer/disposal and transmission controls at 8.4.x. The 2025 consolidation regroups them inside the A.2.3 and A.2.4 themes of Table A.2 as controls A.2.3.2 and A.2.4.2 to A.2.4.4 (the ".1" position in each family is reserved for the objective statement). The renumbering is mechanical; no substantive requirement has been deleted or added. The 2025 edition's contribution is structural, a standalone PIMS (no longer an extension of 27001/27002) with Annex B made normative, so the B.2.3.2 and B.2.4.x guidance is now an audit-testable benchmark.

The B.2.3.2 and B.2.4.x normative guidance (the 2025 edition's load-bearing change for this family) explains how a processor should structure the principal-cooperation regime (B.2.3.2, the intake channel, the SLA, the audit trail, the breach-cooperation clauses); the temp-file hygiene (B.2.4.2, the inventory, the auto-purge, the developer-environment discipline); the end-of-services handling (B.2.4.3, the controller's instruction, the return-package build, the destruction-with-certificate, the offboarding register); and the transmission controls (B.2.4.4, the inventory, the TLS / mTLS baseline, the API authentication discipline, the cross-border analysis). Auditors now test against these guidance points; the family's evidence base is no longer just the DPA's cooperation and end-of-services clauses but the documented operational discipline.

The architectural posture, cooperation, hygiene, closure, transit

The four controls together express an architectural posture that the processor should be able to articulate in one breath: cooperate, hygienically, with closure, in transit. Cooperate (A.2.3.2), the processor's operational support for the controller's principal-facing duties, on the controller's instructions, with the controller as the principal's counterparty. Hygienically (A.2.4.2), the processor's internal data hygiene so that the controller's data does not accumulate beyond its purpose in the processor's environment. With closure (A.2.4.3), the processor's clean exit at the end of the engagement, with the data returned or destroyed with certificate and the processor's own copies cryptographically erased. In transit (A.2.4.4), the protection of the controller's data as it moves through the processor's environment, between the processor and the controller, and between the processor and sub-processors or third parties.

The posture is architectural in the sense that each control implies engineering investment, not just policy text. The principal-request workflow requires a dedicated intake channel with workflow tooling and SLA tracking, not an email inbox. The temp-file hygiene requires auto-purge mechanisms built into the data pipeline, not a quarterly cleanup drive. The offboarding requires a cryptographic-erasure pipeline with key management and certificate generation, not a database row-deletion. The transmission controls require TLS / mTLS configuration, certificate management and API authentication, not a "we use HTTPS" attestation. A processor that has the policy but not the engineering has a paper defence; a processor that has the engineering but no documented policy has no audit trail. Both are needed.

The principal-cooperation framing (A.2.3.2)

A.2.3.2 is the family's principal-facing control. The processor is not the principal's counterparty, the controller is. The principal's rights (access, correction, erasure, objection, portability, grievance) are exercised against the controller; the controller, in turn, asks the processor to support the response. The support takes three forms: data provision (the processor extracts the principal's data from the processor's systems and provides it to the controller for the controller's access response); action execution (the processor corrects, restricts or deletes the principal's data on the controller's instruction, the operational implementation of the controller's rights decision); audit trail (the processor maintains the evidence of the request, the controller's instruction, the action taken, the timestamp, the audit trail the controller needs to evidence its own rights operation to the principal and to the regulator).

The DPDP Act 2023 sections 11 to 14 rights set (access; correction, completion, updating and erasure; grievance redressal; nomination) is the Indian anchor. The controller's rights-handling process is the controller's duty; the processor's support under A.2.3.2 is the operational arm. The GDPR Article 28(3)(e) cooperation duty (the processor must assist the controller in responding to data-subject requests) and Article 28(3)(f) (the processor must assist the controller in notifying breaches) are the EU lineage. The processor's principal-cooperation SLA, the time within which the processor responds to a controller-forwarded request, is the operational discipline that makes the controller's rights operation workable; the DPDP Rules 2025 grievance-redressal periods (the controller must respond to the principal within the prescribed period) cascade to the processor's SLA as the time available to the controller to assemble the response.

The lifecycle framing (A.2.4.2 and A.2.4.3)

The temp-file hygiene (A.2.4.2) and the end-of-services data handling (A.2.4.3) govern the data through its lifecycle at the processor. Temp-file hygiene is the in-life discipline, every copy of the controller's data that exists outside the system of record (caches, queues, exports, dumps, logs, debug snapshots, backup mirrors, developer-environment mirrors, BI-tool extracts, ad-hoc analyst queries saved to local workstations) must be controlled and purged. The canonical A.2.4.2 failure is the shared-drive folder that has accumulated seven years of monthly exports because no one owns the purge, except in the processor context, the exports are the controller's data, and the controller has no visibility into the processor's shared drives.

End-of-services data handling (A.2.4.3) is the closure discipline, at the end of the engagement, the controller's data must leave the processor's environment cleanly. The controller's instruction (return the data; transfer it to another processor; destroy it) sets the action. The processor executes the action with the destruction-with-certificate workflow; the processor's own copies (the backups, the disaster-recovery mirrors, the log entries that contain the data, the temp files) must also be destroyed or brought within the post-termination retention window (typically a narrow window for legal-hold or audit-defence purposes). The DPDP Act 2023 section 8(7) erasure duty is the Indian anchor; the GDPR Article 28(3)(g) end-of-services clause is the EU lineage.

The transmission framing (A.2.4.4)

PII transmission controls (A.2.4.4) cover four dimensions: confidentiality (the data is encrypted in transit, TLS at minimum, mTLS for high-risk flows); integrity (the data is protected against tampering, TLS, MAC, signature); authentication (both parties to the transmission are authenticated, mTLS, API authentication, service-to-service auth); inventorisation (every transmission flow is documented, source, destination, data category, frequency, encryption method, authentication method, lawful basis, the cross-border dimension under DPDP section 16). The canonical A.2.4.4 failure is the unencrypted partner feed, the daily CSV emailed to the sub-processor; the SFTP with password-only auth; the webhook with no signature verification. In the processor context, the transmission flows extend across the processor↔controller, the processor↔sub-processor, and the processor's internal microservices, each is a transmission flow under A.2.4.4.

Demarcations: A.2.3 / A.2.4 vs A.2.2 / A.2.5 / Clause 8.1 / Clause 7.5; what is NOT required

Four demarcations matter for the family.

A.2.3 / A.2.4 vs A.2.2. A.2.2 governs the contractual and record-keeping conditions for processing; A.2.3 and A.2.4 govern the operational handling, the principal-cooperation, the temp files, the offboarding, the transmission. The A.2.2 customer-agreement schedule sets the rules; the A.2.3 / A.2.4 controls operationalise the rules at runtime. The two are sequential and complementary: the A.2.2.5 instruction-decision log records the controller's instruction (including rights-affecting instructions and offboarding instructions); the A.2.3.2 workflow executes the rights instruction; the A.2.4.3 workflow executes the offboarding instruction.

A.2.4 vs A.2.5. A.2.5 governs the cross-border transfer and the sub-processor chain, the lawful basis for transferring the controller's data to another jurisdiction and the disclosure / engagement / change of sub-processors. A.2.4.4 governs the transmission controls, the technical protection of the data while it moves. The two interlock: a sub-processor engagement under A.2.5.8 triggers a new transmission flow under A.2.4.4; a cross-border transfer under A.2.5.2 triggers the cross-border transmission analysis under A.2.4.4.

A.2.4 vs Clause 8.1 / A.3. Clause 8.1 governs PIMS-level operational planning; A.3 governs the security controls (27002-derived). A.2.4 governs the privacy-specific operational disciplines, temp files, offboarding, transmission, that the security controls (A.3.25 logging; A.3.21 secure disposal; A.3.26 cryptography; A.3.22 endpoint devices) underpin. The A.2.4 controls are the privacy layer; the A.3 controls are the security foundation.

What A.2.3 / A.2.4 does NOT require. It does not require the processor to be the principal's counterparty (the controller is; the processor supports the controller). It does not require the processor to maintain a privacy notice for the principal (the controller does; the processor may be referenced in the controller's notice). It does not require the processor to make the deletion decision (the controller makes the decision on the principal's request; the processor executes the deletion on the controller's instruction). It does not require the processor to delete every copy of the data the moment the controller instructs deletion (the processor may retain a narrow set of copies for legal-hold, audit-defence or legitimate-business purposes, documented in the post-termination retention schedule, but the scope must be narrow and the retention bounded). It does not require the processor to use a specific transmission protocol (the processor chooses the protocol; the requirement is the encryption / authentication / inventorisation discipline, not the specific technology).

What auditors actually check

The certification auditor's A.2.3 / A.2.4 family examination has eight predictable moves (the 28-question checklist is in Section 11). First, ask for the Processor Privacy-by-Design and Principal-Cooperation Policy, does it exist, is it signed off, does it commit to the four controls. Second, ask for the Principal-Request Handling Procedure and sample three to five recent requests, for each, walk the audit trail (the controller's instruction, the data extraction, the controller approval, the fulfilment, the closure; the SLA met). Third, ask for the Temporary-File Hygiene Standard and the inventory, sample three to five temp-file locations and verify the auto-purge. Fourth, ask for the End-of-Services Data Return or Destruction Procedure and sample three recent offboardings, for each, walk the controller's instruction, the return-package or destruction-with-certificate, the offboarding register entry. Fifth, ask for the Transmission Controls Checklist and the transmission-flow inventory, sample three flows and verify the TLS / mTLS documentation. Sixth, ask for the breach-cooperation procedure (the dual-clock drill, DPDP 72-hour; CERT-In 6-hour). Seventh, ask for the KPI dashboard (the four controls' KPIs reported to the management review). Eighth, trace the integration with the A.2.2.5 instruction-decision log, the A.2.5 sub-processor chain, the A.3 security controls, the family is not a stand-alone artefact; it feeds the wider PIMS.

Why This Control Family Matters

The processor as the controller's principal-facing 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 obligations-to-principals theme (A.2.3) is the most principal-visible, it is the layer at which the principal experiences the controller's privacy posture, and the processor is often the operational arm. When a principal files an access request, the controller's response depends on the processor's data extraction; when a principal asks for erasure, the controller's decision depends on the processor's deletion-with-certificate capability; when a principal files a grievance, the controller's response time depends on the processor's SLA. A processor that cannot support the controller's rights operation exposes the controller to principal complaints, regulatory enforcement and reputational damage, and exposes itself to contractual indemnity claims and the loss of the customer.

The privacy-by-design theme (A.2.4) is the layer at which the processor's internal data hygiene and lifecycle discipline are tested. Temp files, offboarding and transmission are the three surfaces at which processor-side incidents most commonly originate, the shared-drive leak; the offboarding leak; the in-transit interception. The four controls together (A.2.3.2 + A.2.4.2 + A.2.4.3 + A.2.4.4) form the principal-visible and lifecycle-closing layer of the processor's privacy posture; the controller's regulator and the principal see the symptoms (the slow access response; the data leak) but the root cause is in the processor's operational discipline.

The Indian regulatory weight

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

The DPDP principal-rights layer. The DPDP Act 2023 sections 11 to 14 rights set is the Indian anchor. Section 11 access, the principal has the right to obtain a summary and a copy of the personal data processed. Section 12 correction and erasure, the principal has the right to correct, complete, update or erase the personal data. Section 13 grievance redressal, the principal has the right to a grievance-redressal mechanism with the controller (and the Consent Manager) responding within the prescribed period. Section 14 nomination, the principal has the right to nominate. The controller's rights-handling process is the controller's duty; the processor's support under A.2.3.2 is the operational arm. The DPDP Rules 2025 prescribe the grievance-redressal periods (the controller must respond within the prescribed period); the processor's SLA cascades from the controller's period minus the controller's own handling time.

The DPDP breach-cooperation layer. The DPDP Act 2023 section 8(6) breach-notification duty (the controller notifies the DPB and affected principals within 72 hours under DPDP Rules 2025 Rule 7) depends on the processor's prompt handoff. The processor's duty under A.2.3.2, to assist the controller in notifying breaches, is the operational arm of the 72-hour clock. The dual-clock pattern (DPDP 72-hour handoff to the controller; CERT-In 6-hour India-ICT-system report) is the canonical breach-cooperation discipline; the drill is the canonical test.

The DPDP erasure layer. The DPDP Act 2023 section 8(7) erasure duty (the controller ensures erasure when the purpose is met or retention is no longer lawful) depends on the processor's offboarding and on-demand erasure capability. The processor's duty under A.2.4.3, to return or destroy the controller's data at end of services, is the operational arm of the section 8(7) duty. The DPDP Rules 2025 retention-and-erasure timelines (including the 48-hour pre-erasure notice to the principal) cascade to the processor's offboarding and on-demand erasure procedures.

The sectoral outsourcing layer (RBI / SEBI / IRDAI). The Indian sector regulators impose granular processor-side duties on the entities they regulate and through them on the processors those entities engage. The RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025) and RBI NBFC Managing Risks in Outsourcing Directions, 2025 require the bank or NBFC customer's instruction on end-of-contract data deletion; the processor's offboarding procedure must produce the destruction certificates the bank's regulator expects. The SEBI Cybersecurity and Cyber Resilience Framework (20 August 2024) sets transmission-controls expectations for SEBI-regulated customers. The IRDAI Information and Cyber Security Guidelines (24 April 2023) impose ICT-outsourcing data-protection clauses including policyholder-data return and destruction. The A.2.3 / A.2.4 stack is the operational vehicle through which the processor satisfies these sector-driven duties.

The cost of non-compliance

The cost of an A.2.3 / A.2.4 family failure breaks down into four bands.

Direct DPDP / sector-regulator exposure. For the controller-customer, the exposure is direct (DPDP section 8(5), 8(6), 8(7) penalties under the Schedule, up to two hundred and fifty crore rupees for security-safeguards failure; up to two hundred crore for breach-notification failure). For the processor, the exposure is indirect but real: the sector regulators can investigate the processor directly under the outsourcing rules; the DPBI can call the processor as a witness or a respondent in a controller-level investigation; the processor's contractual indemnity to the controller can be invoked.

Indirect regulatory consequences are larger and slower. An A.2.3 / A.2.4 failure (no principal-request SLA; temp files accumulating; offboardings with no certificate; transmission flows unencrypted) cascades through the broader privacy architecture, the controller's rights operation is undermined; the breach-notification timeline fails; the offboarding leak becomes the proximate cause of a regulator investigation. The A.2.3 / A.2.4 stack is the principal-visible layer; its failure is the principal's complaint.

Commercial cost is significant. Enterprise customers include A.2.3 / A.2.4-style cooperation and end-of-services clauses in their standard DPAs and audit the processor's compliance during vendor diligence. The processor that cannot produce a principal-request SLA, a temp-file inventory, an offboarding register, a transmission-flow inventory is the processor that loses the procurement. The reputational damage of a public A.2.3 / A.2.4 failure (a regulator's order naming the processor; a customer's press release; a news story on an offboarding-data leak that traces back to the processor's destruction failure) compounds the procurement loss.

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

The board-level question

The board-level question for the A.2.3 / A.2.4 family is not "do we cooperate with our customers on principal requests?", most processors say yes. The question is "for every active controller-customer, can we produce, within 24 hours of an auditor's or a regulator's request: (a) the principal-request SLA and a sample audit trail; (b) the temp-file inventory with the auto-purge cadence; (c) the offboarding register with destruction certificates; (d) the transmission-flow inventory with the TLS / mTLS documentation; (e) the most recent breach-cooperation drill report?" If the honest answer is "partially" or "no", the processor has an A.2.3 / A.2.4 gap regardless of what its privacy policy says.

Scope and Applicability

Who the family applies to

Control families A.2.3 and A.2.4 sit in Table A.2 of the 2025 Annex A, the PII processor control set. They bind every organisation that acts as a processor (DPDP: Data Processor; GDPR: processor) for at least one controller-customer. Controllers (Table A.1) are bound by the mirror controls A.1.3.x (obligations to PII principals) and A.1.4.7 / A.1.4.9 / A.1.4.10 (temporary files, disposal, transmission controls).

The family applies regardless of organisation size. A twenty-person SaaS startup providing analytics services to five controller-customers, a thousand-person BPO serving twenty banking customers, 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 customer portfolio, see Section 22 (Maturity Model).

When the family applies, the lifecycle hooks

The four controls activate at different points in the customer-engagement lifecycle.

• A.2.3.2 (principal cooperation) activates whenever a controller-customer forwards a principal request (or signals an impending breach-notification need). The trigger is event-driven, each request is a discrete event with its own SLA and audit trail.
• A.2.4.2 (temporary files) is always-on, every temp-file location that holds the controller's data is in scope throughout the relationship.
• A.2.4.3 (end-of-services data handling) activates at the end of the engagement (or earlier on the controller's instruction, for example, a partial deletion of a principal's data on an erasure request). The trigger is the controller's instruction.
• A.2.4.4 (transmission controls) is always-on, every transmission flow that carries the controller's data is in scope throughout the relationship.

The lifecycle stages at which the controls become most visible: (i) steady-state operations (the principal requests arrive; the temp files accumulate; the transmissions run); (ii) change management (a new sub-processor is engaged, new transmission flow; a new data category is added, new temp-file location); (iii) offboarding (the A.2.4.3 procedure runs; the destruction certificates are generated; the offboarding register is updated).

What is in scope

The A.2.3 / A.2.4 family's artefact set covers every controller-customer the processor serves and every personal-data copy, deletion event and transmission flow that touches the controller's data. This includes:

• The full principal-request queue, every access, correction, erasure, objection, portability, grievance, nomination request that any controller-customer has forwarded.
• The full temporary-file estate, every cache, queue, export, dump, log directory, debug snapshot, backup mirror, developer-environment mirror, BI-tool extract, ad-hoc analyst query that contains any controller-customer's personal data.
• The full offboarding history, every controller-customer that has been offboarded (or partially offboarded, for example, a partial deletion on an erasure request) with the destruction certificates or return-package receipts.
• The full transmission-flow map, every flow that carries a controller-customer's personal data: ingestion (controller to processor); processor internal microservice flows; processor to sub-processor; sub-processor to processor; processor to controller (return flows; access-request responses); cross-border flows.

What is out of scope

• The processor's own controller-side processing (the processor's employee data, marketing data, customer-relationship data). These are governed by the processor's controller-side obligations (Annex A.1), including the processor's own A.1.4.7 / .4.9 / .4.10 controls. The dual-role discipline is a scoping question (Clause 4.3).
• Anonymous data the processor derives from controller-customer data, if the processor has truly anonymised the data (irreversibly prevented re-identification), the family does not apply to the anonymised output. Pseudonymised data is still personal data; the family applies in full.
• Routine operational communications that are not principal requests (a status update; a query; a routine support interaction), the principal-request intake must distinguish requests from operational communications.
• The controller's own rights-handling decisions, the processor supports the controller's response; the controller decides what to do with the principal's request. The processor does not become the principal's counterparty.

Applicability by organisation size

Applicability by industry (preview, Section 21 has detail)

• BFSI (processors serving banks/NBFCs/insurers), RBI's outsourcing Directions (2025) prescribe specific end-of-contract data-deletion expectations; the offboarding procedure must produce the destruction certificates the bank's regulator expects; the transmission controls must meet the RBI's data-locality and security expectations.
• Healthcare (processors serving hospitals/insurers/telemedicine), sensitive health data; the temp-file hygiene is heightened (health-data leaks are high-impact); the offboarding must reflect the clinical-record retention rules; the transmission controls must use mTLS for high-sensitivity flows.
• IT-ITeS and SaaS, multi-jurisdiction customer portfolios; the principal-request SLA must accommodate DPDP, GDPR and US-state law timelines simultaneously; the temp-file estate is diverse (developer environments; BI-tool extracts; shared BPO delivery centres); the transmission flows cross borders.
• E-commerce enablers (logistics, payments, recommendation engines), high-volume transmission flows; the transmission-flow inventory is the canonical artefact; the offboarding for a payment processor must reflect the RBI storage-of-payment-data rule.
• Edtech processors, DPDP section 9 dominates where the customer serves minors; the principal-request workflow must accommodate parental-consent verification; the temp files must not retain children's behavioural data; the offboarding must reflect the children's-data retention limits.
• Manufacturing (IIoT/Industry 4.0 processors), typically long-tail retention (safety and product-liability records); the offboarding procedure must accommodate legal-hold overlays; the transmission flows extend across the multi-plant operations.

Key Definitions and Terminology

Relationship to Other Clauses and Frameworks

The sibling-control network inside Annex A.2

The A.2.3 / A.2.4 family 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 contractual foundation. The DPA's cooperation clause (A.2.3.2 foundation); the DPA's end-of-services clause (A.2.4.3 foundation); the DPA's security schedule (the transmission controls and temp-file hygiene foundation); the DPA's principal-request SLA. A processor that has a strong DPA but no operational cooperation / temp-file / offboarding / transmission discipline has a paper defence; the inverse has no enforceable reference point.

A.2.2.3, Organization's purposes. The temp files must respect the purposes discipline, a temp file that processes customer data for an undocumented purpose fails both A.2.2.3 and A.2.4.2.

A.2.2.4, Marketing and advertising use. The temp files and the transmission flows must not enable the processor's own marketing use, a temp file that leaks customer data into a benchmarking feature fails both A.2.2.4 and A.2.4.2; a transmission flow that sends customer data to the processor's marketing system fails both A.2.2.4 and A.2.4.4.

A.2.2.5, Infringing instruction. The gate through which every customer instruction passes, including rights-affecting instructions (an instruction to ignore or delay a principal request, an A.2.3.2 infringement and an A.2.2.5 infringement) and offboarding instructions (an instruction to retain the data beyond the agreed retention, an A.2.4.3 infringement and an A.2.2.5 infringement).

A.2.2.6, Customer obligations. The confirmation that the controller has stood up its rights-handling process, the foundation for A.2.3.2 cooperation. Without the confirmation, the processor's principal-request workflow is unworkable.

A.2.2.7, Records related to processing PII. The ROPA reflects the four controls, the principal-request-handling columns; the temp-file columns; the offboarding columns; the transmission-flow columns. The ROPA is the audit object that ties the four controls together.

A.2.5.2 to A.2.5.6, Cross-border transfer. The transmission controls (A.2.4.4) operationalise the technical protection of the cross-border flow; the A.2.5 controls govern the lawful basis. The two interlock, a cross-border transmission flow triggers both the A.2.5.2 transfer-basis analysis and the A.2.4.4 transmission-control analysis.

A.2.5.7 / A.2.5.8 / A.2.5.9, Sub-processor chain. Each sub-processor engagement triggers a new transmission flow (processor to sub-processor); each sub-processor change triggers a transmission-flow inventory update. The offboarding procedure extends to sub-processors, the controller's instruction to delete flows downstream to the sub-processor.

A.3, Security controls. The integrity of the principal-request audit trail (A.3.25 logging; A.3.14 protection against falsification); the temp-file access controls (A.3.9 access rights); the disposal integrity (A.3.21 secure disposal); the transmission integrity (A.3.26 cryptography; A.3.25 logging). The A.3 controls are the security foundation on which the A.2.4 controls sit.

Clause 8.1, Operational planning and control. The PIMS-level framework within which the A.2.3 / A.2.4 stack sits.

Clause 9.1 / 9.3, Monitoring, measurement, analysis, evaluation; management review. The KPI reporting on the four controls feeds the Clause 9.1 monitoring and the Clause 9.3 management review.

Clause 7.5, Documented information. The principal-request audit trail; the temp-file inventory; the offboarding register; the transmission-flow inventory, all are documented information under Clause 7.5 (version-controlled; access-controlled; retention-managed; retrievable).

The controller-side mirror (Annex A.1)

The A.2.3 / A.2.4 family has a clean mirror in Annex A.1, the controller-side obligations-to-principals and privacy-by-design controls.

• A.1.3.x, Obligations to PII principals. The controller's rights-handling operation that the processor supports under A.2.3.2. The controller decides; the processor executes.
• A.1.4.7, Temporary files (controller-side). The controller's own temp-file hygiene for the controller's own data; the processor-side mirror is A.2.4.2 for the controller-customer's data at the processor.
• A.1.4.9, Disposal. The controller's own disposal discipline; the processor-side mirror is A.2.4.3 (the offboarding of the controller's data at the processor).
• A.1.4.10, PII transmission controls. The controller's own transmission discipline; the processor-side mirror is A.2.4.4.
• A.1.5.x, Sharing, transfer and disclosure. The controller's transfer-basis analysis that the processor's transmission-flow cross-border analysis under A.2.4.4 supports.

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. The 27018 clauses that map most cleanly:

• Clause 9, Sub-contractors. The cloud PII processor's cooperation with the controller on principal requests.
• Clause 10, Cross-border transfer. The transmission-controls framework.
• Clause 11, Data return and destruction. The cloud PII processor's end-of-engagement handling, the A.2.4.3 foundation for cloud processors.

A.2.3 / A.2.4 of 27701:2025 is the management-system-level counterpart of 27018:2019's clause-level processor code of practice.

The lineage from GDPR Article 28(3)(e) / (f) / (g)

GDPR Article 28(3) sets the mandatory DPA content. The (e), (f) and (g) sub-paragraphs are the load-bearing hooks for the A.2.3 / A.2.4 family:

• Article 28(3)(e), the processor assists the controller in responding to data-subject requests. The A.2.3.2 foundation.
• Article 28(3)(f), the processor assists the controller in notifying breaches (the cooperation that feeds the controller's Article 33 / 34 timeline). The breach-cooperation slice of A.2.3.2.
• Article 28(3)(g), at the end of the services, the processor deletes or returns the personal data (and deletes existing copies) unless EU law or Member State law requires storage. The A.2.4.3 foundation.

The CJEU jurisprudence and the EDPB Guidelines 07/2020 on the concepts of controller and processor operationalise Article 28. 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.

Detailed Implementation Guidance, Control by Control

This section walks through each of the four 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.

A.2.3.2, Comply with obligations to PII principals

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.3.2 asks PII processors to support the controller-customer in discharging the controller's obligations to PII principals, access, correction, erasure, objection, portability, grievance and any other rights the applicable law grants, by providing the controller with the data the controller needs to respond, executing the controller's instructions on the principal's data (correction, deletion, restriction), and maintaining the audit trail that evidences the processor's cooperation, all within the timeline the Customer DPA prescribes and the applicable law requires.

(b) What it means in practice. The processor is the controller's operational arm for principal-facing rights. When a principal exercises a right against the controller, the controller (not the processor) decides what to do, but the controller's response depends on the processor's data, the processor's execution capability and the processor's audit trail. The processor's role is therefore threefold: data provision (extract the principal's data from the processor's systems and provide it to the controller); action execution (correct, restrict or delete the principal's data on the controller's instruction); audit trail (maintain the evidence end-to-end).

The marquee A.2.3.2 patterns are: (i) the access request, the principal asks the controller for a summary and copy of the data processed; the controller forwards the request to the processor; the processor extracts the principal's data (across the systems the processor operates on the controller's behalf, the primary data store, the analytics warehouse, the temp files, the backups within the retention window); the processor provides the data to the controller; the controller assembles the response and delivers it to the principal; (ii) the correction request, the principal corrects an inaccurate data point; the controller forwards the correction to the processor; the processor corrects the data across its systems and propagates the correction downstream (to the sub-processors; to the derived datasets; to the analytics models); the processor confirms the correction to the controller; (iii) the erasure request, the principal erases the data; the controller forwards the erasure to the processor (typically after the 48-hour pre-erasure notice under DPDP Rules 2025); the processor executes the erasure with the destruction-with-certificate workflow (cryptographic erasure; the certificate is the audit evidence); (iv) the grievance, the principal files a grievance with the controller; the controller's grievance officer investigates; the processor supports the investigation with the data and the audit trail; (v) the breach-cooperation, a personal-data breach occurs; the processor hands off the breach to the controller within the SLA (typically 24 hours, to leave the controller enough time to meet the DPDP 72-hour DPBI clock or the GDPR 72-hour supervisory-authority clock); the processor runs the CERT-In 6-hour clock in parallel where an India-ICT system is affected (the dual-clock pattern).

(c) DPDP and GDPR mapping. DPDP Act 2023 sections 11 (access); 12 (correction and erasure); 13 (grievance redressal); 14 (nomination); section 8(6) (breach notification, the controller's 72-hour clock that the processor's handoff feeds); section 8(7) (erasure on the fiduciary's instruction). DPDP Rules 2025, the grievance-redressal response period (the controller's timeline that cascades to the processor's SLA); the 48-hour pre-erasure notice (the processor's erasure-on-instruction procedure must accommodate); Rule 7 (the breach-notification format the processor's handoff feeds). GDPR Article 28(3)(e) (cooperation on DSARs); Article 28(3)(f) (cooperation on breach); Articles 15 to 22 (the rights set); Article 33 (breach, 72-hour supervisory authority); Article 34 (breach, to the data subject without undue delay where high risk). UK GDPR + DPA 2018 (same as EU GDPR). ISO/IEC 27018:2019 clause 9 (sub-contractor cooperation with the controller). ISO/IEC 27002:2022 control 5.34 (PII protection). NIST Privacy Framework v1.0 Communicate-P (data-review). SOC 2 Privacy TSC P5.0 (Access) and P6.0 (Disclosure and notification).

(d) The implementation discipline. Six sub-disciplines drive conformant principal-cooperation:

• Principal-request intake channel. A dedicated channel (typically a ticketing tool integrated with the privacy management platform for mid-market and enterprise processors; a structured email inbox for growing processors). The intake channel distinguishes principal requests from routine operational communications. Each request gets a unique identifier that travels with the request through the workflow.
• Principal-request SLA. The processor's documented response time for each request type, access (5 to 15 business days); correction (15 to 30 days); erasure (15 to 30 days, executed after the controller's 48-hour pre-erasure notice); objection (15 to 30 days); portability (15 to 30 days); grievance (the controller's grievance-redressal period minus the controller's handling time); breach-handoff (24 hours, leaving the controller time to meet the 72-hour DPBI / supervisory-authority clock). The SLA is documented in the Customer DPA and committed to the controller-customer at onboarding.
• End-to-end audit trail. Each request's audit trail captures: the controller's instruction (date; the principal identifier; the request type; the request scope); the processor's review (the A.2.2.5 instruction-decision log entry, was the instruction lawful? did the processor refuse, comply or seek clarification?); the data extraction or action execution (the systems touched; the timestamp; the operator); the controller's approval (where the controller approves the response before delivery); the fulfilment (the data delivered; the action confirmed); the closure (the date; the certificate reference where applicable). The audit trail is the A.2.3.2 artefact and the audit's primary walk-through document.
• Multi-system data extraction. The principal's data may live in multiple systems, the primary data store, the analytics warehouse, the temp files, the backups within the retention window, the sub-processor's systems. The extraction workflow must reach across all of them; a partial extraction (the primary store only, missing the warehouse and the temp files) is a canonical A.2.3.2 failure (the principal's access response is incomplete).
• Correction propagation. A correction at the primary store must propagate to the derived datasets (the analytics warehouse's aggregates; the AI/ML model's training data; the sub-processor's copies). The propagation discipline is engineering investment; a correction that updates the primary store but not the derived datasets is an A.2.3.2 failure (the principal's correction is incomplete).
• Breach-cooperation drill. The processor drills the breach-handoff at least annually, the dual-clock pattern (DPDP 72-hour handoff; CERT-In 6-hour India-ICT-system report). The drill exposes the gap between the documented playbook and the operational reality (the customer-portal credentials for breach-notification handoff have expired; the Rule 7 intimation content is not pre-staged; the CERT-In point-of-contact has changed). The drill closes the gap before the regulator does.

(e) Audit evidence. (i) The Processor Privacy-by-Design and Principal-Cooperation Policy (toolkit doc 01); (ii) the Principal-Request Handling Procedure (toolkit doc 02, Part A) with the SLA; (iii) sample audit trails for three to five recent principal requests covering access, correction, erasure, grievance; (iv) the multi-system data extraction documentation; (v) the correction propagation documentation; (vi) the breach-cooperation drill report (the most recent drill, with the dual-clock pattern); (vii) the Consent Manager integration documentation (where the processor operates in the Indian ecosystem and the controller uses Consent Managers).

A.2.4.2, Temporary files

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.4.2 asks PII processors to control the creation, retention and deletion of temporary files that contain the controller-customer's personal data, every copy that exists outside the system of record, so that such files do not accumulate beyond their processing purpose, and to apply the access controls, the audit logging and the documented purge cadence that prevent temp files from becoming an uncontrolled leak surface.

(b) What it means in practice. "Temporary files" is a broad category: caches (the application cache; the database query cache; the CDN cache); queues (the message queue; the event stream; the batch-processing queue); exports (the daily CSV export; the monthly regulatory report; the ad-hoc analyst export); dumps (the database dump; the disaster-recovery snapshot); logs (the application log; the access log; the audit log; the security log; the debug log); debug snapshots (the developer's snapshot of production data for a debugging session); backup mirrors (the backup system's mirrors of production); developer-environment mirrors (production-data copies in developer environments, the highest-risk pattern); BI-tool extracts (the BI tool's local extracts of warehouse data); ad-hoc analyst queries saved to local workstations.

In the processor context, every temp file is a copy of the controller-customer's data. The controller has no visibility into the processor's shared drives; the controller's privacy posture depends entirely on the processor's temp-file hygiene. The canonical A.2.4.2 failure is the shared-drive folder that has accumulated seven years of monthly exports because no one owns the purge, except in the processor context, the exports are the controller's data, and a leak from the shared drive is the controller's incident under DPDP section 8(6) and the processor's contractual indemnity event under the DPA.

The marquee A.2.4.2 anti-patterns are: (i) the developer-environment mirror, production-data copies in developer environments for debugging or testing; the highest-risk pattern because developer environments are typically less hardened than production; (ii) the BI-tool extract, the analyst's saved extract of warehouse data on a local workstation or a shared drive; (iii) the indefinite backup retention, backups retained long after the live data has been disposed at offboarding; (iv) the unbounded log retention, application logs that contain personal data (user IDs; IP addresses; session tokens) retained indefinitely; (v) the debug snapshot, the developer's ad-hoc snapshot of production data for a debug session, never deleted.

(c) DPDP and GDPR mapping. DPDP Act 2023 section 8(5) (reasonable security safeguards, covers temp-file integrity and access); section 8(7) (erasure, temp files must be erased when no longer needed); CERT-In Directions 20(3)/2022-CERT-In, the 180-day log retention rule (the temp-file purge cadence must accommodate the 180-day rule for logs that are also CERT-In-prescribed). GDPR Article 5(1)(c) (data minimisation, temp files are still personal data); Article 5(1)(e) (storage limitation, temp files must not be retained longer than necessary); Article 25(1) (data protection by design, temp-file hygiene is a design discipline); Article 32 (security, temp-file integrity and access). ISO/IEC 27018:2019 clause 11 (end-of-processing disposal, extends to temp files at offboarding). ISO/IEC 27002:2022 control 8.10 (information deletion, the security-side backstop). NIST Privacy Framework v1.0 Control-P (data-processing management). SOC 2 Privacy TSC P4.0 (Use, retention and disposal).

(d) The implementation discipline. Six sub-disciplines drive conformant temp-file hygiene:

• Temporary-file inventory. The catalogue of every temp-file location that contains controller-customer data, the location (the system path; the storage bucket; the queue name); the data categories; the volume; the access pattern; the documented purpose; the purge cadence; the owner. The inventory is the A.2.4.2 artefact and the audit's primary walk-through document. The inventory is reconciled quarterly against the operational reality (new temp-file locations discovered through the data-discovery tool are added; obsolete locations are removed).
• Auto-purge at the source. Each temp-file location has an auto-purge mechanism, cron job (the daily CSV export purged after 30 days); queue TTL (the message-queue messages purged after 7 days); cache eviction policy (the CDN cache evicted after 24 hours); backup rotation (the daily backup retained for 30 days, the weekly for 90 days, the monthly for 12 months); log retention policy (the application log retained for 180 days per CERT-In, the access log for 365 days, the audit log for 7 years per the limitation period). Manual purge is the failure pattern; auto-purge is the conformant pattern.
• Access control. Each temp-file location is in the access-control regime, least-privilege, audit-logged. The shared-drive-with-everyone-read-write is the canonical A.2.4.2 failure; the access-controlled location with the audit-logged access is the conformant pattern. The access controls extend to backups (the backup system's access controls; the restore permissions); to logs (the log-management system's access controls; the SIEM integration); to developer environments (the developer-environment access controls; the break-glass procedure).
• Developer-environment discipline. Production-data mirrors in developer environments are the highest-risk pattern. The conformant pattern: no production data in developer environments; the developer environment uses synthetic or de-identified data; any exception (a production-data mirror for a debug session) is time-boxed (a 24-hour TTL), access-logged, and approved by the DPO and the Security Lead. The developer-environment discipline is engineering investment, the synthetic-data generator; the de-identification pipeline; the developer-environment hardening.
• BI-tool and analyst-discipline. BI-tool extracts and analyst-saved queries are temp files. The conformant pattern: the BI tool queries the warehouse live; no permanent extracts; analyst-saved queries run on the warehouse, not on local copies; the BI tool's local-extract feature is disabled or audited.
• Backup and log discipline. Backups and logs are temp files that often outlive the live data. The backup retention schedule is documented per processing activity; the log retention schedule is documented per log type. At offboarding, the backups and the logs are brought within the post-termination retention scope (the narrow window for legal-hold and audit-defence) and disposed at the end of that scope.

(e) Audit evidence. (i) The Temporary-File Hygiene Standard (toolkit doc 02, Part B); (ii) the temporary-file inventory with the auto-purge cadence per location; (iii) sample walks of three to five temp-file locations showing the purge configuration, the access controls, the audit log; (iv) the developer-environment policy and the synthetic/de-identified data set; (v) the BI-tool and analyst-discipline policy; (vi) the backup and log retention schedules; (vii) the quarterly reconciliation reports.

A.2.4.3, Return, transfer or disposal of PII

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.4.3 asks PII processors, at the end of the processing services for a controller-customer (or earlier on the controller's instruction, for example, a partial deletion on an erasure request), to return the controller-customer's personal data to the controller, transfer it to another processor the controller nominates, or dispose of it (destroy with certificate), and to delete the processor's own copies (the primary store; the backups; the disaster-recovery mirrors; the temp files; the logs containing the data), in accordance with the controller's documented instruction and the applicable retention rules, with a narrow post-termination retention scope documented in the offboarding register.

(b) What it means in practice. End-of-services is the closure discipline. The controller's instruction sets the action: return the data; transfer to another processor; destroy. The processor executes the action with the destruction-with-certificate workflow and the offboarding register. The processor's own copies, the primary store, the backups, the disaster-recovery mirrors, the temp files, the logs containing the data, must be brought within the post-termination retention scope (the narrow window for legal-hold and audit-defence) or destroyed.

The canonical A.2.4.3 failure is the offboarding-data leak, the customer ends the engagement; the processor stops the API calls but the data sits in the database forever; the backups are retained indefinitely; the disaster-recovery mirror is forgotten; the temp files accumulate; eventually a leak occurs (the processor's engineer accidentally exposes the database in a debug session) and the controller's principal data is compromised. The offboarding procedure is the canonical control that prevents this failure pattern.

The marquee A.2.4.3 patterns are: (i) the full offboarding, the customer ends the engagement; the controller's instruction is to destroy the data and certify; the processor executes the destruction with the cryptographic-erasure pipeline (the per-customer encryption key is destroyed; the ciphertext is left on the storage but is unreadable); the destruction certificate is generated; the backups are brought within the post-termination retention scope (typically 90 to 180 days for audit-defence); the offboarding register is updated; (ii) the partial offboarding, the customer remains engaged but a principal has filed an erasure request; the controller's instruction is to erase the principal's data; the processor executes the erasure with the destruction-with-certificate workflow for that principal's data; (iii) the transfer to another processor, the customer is migrating to a different processor; the controller's instruction is to transfer the data to the new processor; the processor builds the return-package (the data in the agreed format; the documentation; the chain-of-custody); the transfer is encrypted; the offboarding register records the transfer.

(c) DPDP and GDPR mapping. DPDP Act 2023 section 8(7) (erasure when retention no longer lawful or purpose is met, the foundation for the processor's offboarding and on-demand erasure). DPDP Rules 2025, the retention-and-erasure timelines (the controller's retention rules that cascade to the processor's offboarding); the 48-hour pre-erasure notice (the processor's erasure-on-instruction procedure must accommodate). GDPR Article 28(3)(g) (at the end of the services, the processor deletes or returns the personal data, direct mapping); Article 5(1)(e) (storage limitation); Article 17 (right to erasure, the controller's instruction to the processor on a principal's erasure request). UK GDPR + DPA 2018 (same as EU GDPR). ISO/IEC 27018:2019 clause 11 (end-of-processing data return and destruction in public clouds, direct mapping). ISO/IEC 27002:2022 control 8.10 (information deletion); control 7.14 (secure disposal or re-use of equipment). NIST Privacy Framework v1.0 Control-P (data-processing management) and Protect-P (protective controls). SOC 2 Privacy TSC P4.0 (Use, retention and disposal). RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025), the bank-customer's instruction on end-of-contract data deletion is governed by the RBI rule; the offboarding procedure must produce the destruction certificates the bank's regulator expects. RBI NBFC Managing Risks in Outsourcing Directions, 2025, similar. IRDAI Information and Cyber Security Guidelines, ICT-outsourcing data-protection clauses including policyholder-data return.

(d) The implementation discipline. Six sub-disciplines drive conformant end-of-services handling:

• Controller-instruction intake. The offboarding begins with the controller's documented instruction, return the data; transfer to a nominated processor; destroy with certificate. The instruction is processed through the A.2.2.5 instruction-decision log (was the instruction lawful? did the controller have the right to instruct the action?, typically yes, but the intake is documented). The instruction's scope is documented, full offboarding vs partial; the data categories in scope; the retention scope if any.
• Return-package build (where the instruction is return or transfer). The processor builds the return-package, the personal data in the agreed format (typically CSV or JSON for structured data; PDF or image for documents; the data dictionary); the documentation (the data-flow description; the schema; any caveats); the chain-of-custody documentation. The return-package is encrypted (with the controller's public key or a mutually-agreed encryption mechanism); the transfer is over mTLS; the receipt is acknowledged by the controller.
• Destruction-with-certificate (where the instruction is destroy). The destruction is executed with the cryptographic-erasure pipeline (the per-customer encryption key is destroyed; the ciphertext is left on the storage but is unreadable) for cloud-native processors, or with the physical-destruction chain (the licensed e-waste vendor; the certificate-of-destruction; the chain of custody) for on-premises media. The destruction certificate is generated, the method; the timestamp; the witness; the chain of custody. The certificate is the audit evidence.
• Post-termination retention scope. The narrow scope of personal-data copies the processor may retain after offboarding, for legal-hold (a pending litigation or regulatory inquiry); audit-defence (the processor's evidence base for the limitation period); legitimate-business purposes (the processor's statutory compliance, tax records; employment records). The scope is documented in the offboarding register with the bounded retention period (typically 90 to 180 days for audit-defence; the limitation period for legal-hold). The post-termination retention is the exception, not the rule; the offboarding procedure must narrow the scope aggressively.
• Offboarding register. The per-customer register of offboardings, the customer; the offboarding date; the controller's instruction (return / transfer / destroy); the action taken; the certificate or receipt reference; the post-termination retention scope; the final retention-end date. The offboarding register is the audit's primary walk-through document for A.2.4.3.
• Backup and DR-mirror handling. The offboarding extends to backups (the backups containing the controller-customer's data) and disaster-recovery mirrors. The conformant pattern: the backups are brought within the post-termination retention scope (the same 90 to 180 days); the DR mirror is destroyed or repurposed (the per-customer encryption key destroyed; the mirror overwritten). Backups retained indefinitely after the live data is disposed is the canonical A.2.4.3 failure.

(e) Audit evidence. (i) The End-of-Services Data Return or Destruction Procedure (toolkit doc 03); (ii) the offboarding register; (iii) sample destruction certificates for three recent offboardings; (iv) sample return-package receipts for three recent returns or transfers; (v) the post-termination retention scope documentation; (vi) the backup and DR-mirror handling documentation; (vii) the cryptographic-erasure pipeline documentation with the key-management discipline; (viii) the licensed-disposal-vendor credentials (where applicable).

A.2.4.4, PII transmission controls

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.4.4 asks PII processors to apply controls to the transmission of the controller-customer's personal data, across the processor's internal systems, between the processor and the controller, between the processor and sub-processors, and between the processor and any third-party recipients, so that the data is protected in transit through documented confidentiality (encryption), integrity (tamper-protection), authentication (both parties authenticated) and inventorisation (every flow documented with the source, destination, data categories, frequency, encryption method, authentication method, lawful basis, and the cross-border analysis where applicable).

(b) What it means in practice. Transmission controls cover four dimensions in the processor context. Confidentiality, the data is encrypted in transit; TLS at minimum (TLS 1.2 or 1.3); mTLS for high-risk flows (sensitive data; cross-border; partner-fed; high-volume). Integrity, the data is protected against tampering; TLS / MAC / signature. Authentication, both parties to the transmission are authenticated; mTLS with X.509 certificates; API authentication (OAuth 2.0 / OIDC for user-context flows; signed JWTs for service-to-service flows; HMAC signatures for webhook verification). Inventorisation, every transmission flow is documented in the transmission-flow inventory with the source, destination, data categories, frequency, volume, encryption method, authentication method, lawful basis (for cross-border flows), the responsible owner, the last-review date.

The transmission flows in the processor context extend across five interfaces: (i) the ingestion interface, the controller sends the data to the processor (the controller's API calls to the processor; the controller's file uploads; the controller's database replication); (ii) the processor internal microservices, the data flows through the processor's internal microservices (the ingestion service; the processing service; the storage service; the analytics service; the alert service); (iii) the processor-to-sub-processor flows, the data flows to the sub-processors (the cloud-infrastructure provider; the SMS-gateway; the analytics-engine sub-processor; the AI/ML-model-training sub-processor); (iv) the sub-processor-to-processor return flows, the sub-processors send processed data back; (v) the processor-to-controller flows, the processor sends the data back to the controller (the access-request response; the analytics dashboard data; the offboarding return-package).

The canonical A.2.4.4 failure is the unencrypted partner feed, the daily CSV emailed to the sub-processor (the highest-risk pattern, email is not a secure transmission channel for personal data); the SFTP with password-only auth (the second-highest, the password can be phished); the webhook with no signature verification (the third-highest, the webhook can be spoofed). The transmission-flow inventory is the canonical artefact that surfaces these patterns; the auto-detection (a network scan that flags unencrypted flows) is the canonical control.

(c) DPDP and GDPR mapping. DPDP Act 2023 section 8(5) (reasonable security safeguards, covers transmission confidentiality, integrity, authentication); section 16 (cross-border negative list, the transmission-route dimension for cross-border flows). GDPR Article 32 (security of processing, encryption in transit; the integrity dimension; the authentication dimension); Article 25(1) (data protection by design, transmission is engineered into the pipeline); Articles 44 to 49 (cross-border flows, the lawful-basis dimension for cross-border transmission). UK GDPR + DPA 2018 (same as EU GDPR). ISO/IEC 27018:2019 clause 10 (cross-border in public clouds, transmission-controls framework). ISO/IEC 27002:2022 control 8.24 (cryptography, the encryption discipline); control 8.16 (monitoring activities, the transmission log); control 8.10 (information deletion, adjacent). NIST Privacy Framework v1.0 Protect-P (data security, protective controls). SOC 2 Privacy TSC P6.0 (Disclosure and notification, transmission is a disclosure channel). SEBI CSCRF, transmission-controls expectations for SEBI-regulated customers. RBI Storage of Payment System Data, the data-locality rule that constrains cross-border transmission for payment-system data.

(d) The implementation discipline. Six sub-disciplines drive conformant transmission controls:

• Transmission-flow inventory. Every transmission flow that carries controller-customer data is documented: source system; destination system; data categories; frequency; volume; encryption method (TLS 1.2 / 1.3; mTLS; the cipher suite); authentication method (mTLS; OAuth; signed JWT; HMAC); lawful basis (for cross-border flows); the responsible owner; the documentation date and the last-review date. The inventory is the A.2.4.4 artefact and the audit's primary walk-through document. The inventory is reconciled quarterly against the operational reality (new flows discovered through the network scan are added; obsolete flows are removed).
• TLS-plus-encryption baseline. Every transmission flow uses TLS for in-transit protection. The TLS version is documented (TLS 1.2 minimum; TLS 1.3 preferred); the cipher suite is documented (the strong ciphers; the weak ciphers disabled); the certificate management is documented (the certificate authority; the renewal cadence; the revocation mechanism). The TLS-baseline is enforced at the load balancer, the API gateway, and the application layer.
• mTLS for high-risk flows. High-risk flows (sensitive data; cross-border; partner-fed; high-volume; sub-processor) use mutual TLS, both sides authenticate each other through X.509 certificates. The PKI / certificate management is documented (the internal CA; the certificate issuance; the rotation cadence; the revocation mechanism). The mTLS configuration is the conformant pattern for processor-to-sub-processor and processor-to-controller flows.
• API authentication discipline. Every API that transmits personal data uses strong authentication, OAuth 2.0 / OIDC for user-context flows (the user's identity verified through the identity provider; the API call authorised through the OAuth scope); signed JWTs for service-to-service flows (the service's identity verified through the JWT signature; the JWT signed with the service's private key; the JWT validated by the receiving service); HMAC signatures for webhook verification (the webhook signed with the shared secret; the signature verified by the receiver). The authentication discipline is documented per API.
• Cross-border transmission analysis. Where the transmission crosses the Indian border (outbound or inbound), the cross-border analysis under DPDP section 16 (negative list) and GDPR Chapter V (adequacy / safeguards / derogations) is documented. The A.2.5.2 transfer-basis record cross-references the transmission-inventory entry. The transmission route is documented (the data flows through the India region of the cloud provider; the data flows through the EU region; the cross-border transfer mechanism, SCCs; BCRs; the DPDP negative-list screen).
• Transmission log. Every transmission event is logged: the source; the destination; the data category; the volume; the timestamp; the result (success; failure; the error). The log feeds the breach-detection pipeline (an anomalous transmission, a large volume to an unusual destination, triggers an alert) and the audit trail. The transmission log is retained per the CERT-In 180-day rule (where the flow is an India-ICT-system flow) and the processor's broader log-retention schedule.

(e) Audit evidence. (i) The Transmission Controls Checklist (toolkit doc 04); (ii) the transmission-flow inventory; (iii) the TLS / mTLS configurations with the certificate-management documentation; (iv) sample walks of three to five transmission flows showing the encryption, the authentication, the inventorisation, the cross-border analysis where applicable; (v) the API authentication documentation; (vi) the transmission log with sample entries; (vii) the network-scan reports (the auto-detection of unencrypted flows).

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

The certification auditor's end-to-end A.2.3 / A.2.4 walk picks a recent principal-request-and-offboarding scenario and traces it through the full stack. A representative walk for an Indian SaaS healthtech processor's service of a hospital customer:

1. Principal-request cooperation (A.2.3.2). A patient (the principal) files an access request with the hospital (the controller). The hospital's grievance officer forwards the request to the processor (the intake channel, a ticketing-tool integration; the unique identifier, PR-2026-0456). The processor's SLA (10 business days for access) starts. The processor's analyst runs the multi-system extraction (the patient's data in the primary store, the patient-identity record, the appointment history, the prescription record; the analytics warehouse, the patient's engagement metrics; the temp files, the patient's data in the daily export cache). The processor provides the data to the hospital (encrypted package; mTLS transfer; the controller's approval before delivery to the patient). The audit trail captures every step.
2. Temp-file hygiene (A.2.4.2). The patient's data in the daily export cache (a temp file) is in the temporary-file inventory, the location (the export-cache bucket); the data categories (patient identity, appointment history); the volume; the access pattern (the hospital's daily export job reads the cache); the documented purpose (the daily export to the hospital's BI tool); the purge cadence (the cache is purged every 30 days by the auto-purge cron job). The audit verifies the auto-purge configuration.
3. End-of-services handling (A.2.4.3). Six months later, the hospital ends the engagement. The hospital's instruction is to destroy the data with certificate and to transfer the patient records to the hospital's on-premises system. The processor builds the return-package (the patient records in the agreed format; the chain-of-custody documentation); the package is transferred over mTLS; the hospital acknowledges the receipt. The processor then executes the destruction of its own copies, the primary store (cryptographic erasure; the per-hospital encryption key destroyed); the analytics warehouse (the hospital's partition dropped; the per-hospital key destroyed); the temp files (the export cache purged); the backups (the hospital's backups brought within the 90-day post-termination retention scope; the key destruction scheduled for day 90). The destruction certificate is generated. The offboarding register is updated.
4. Transmission controls (A.2.4.4). The transmission flows that carried the hospital's data are in the transmission-flow inventory, the ingestion flow (the hospital's API calls to the processor, mTLS; OAuth 2.0); the internal microservice flows (the ingestion service to the processing service, mTLS; signed JWT); the sub-processor flows (the processor to the SMS-gateway sub-processor, TLS; HMAC signature); the return flow (the offboarding return-package, mTLS; the hospital's public key); the cross-border analysis (none, all flows within the India region per the hospital's data-locality requirement). The transmission log captures every event.

The walk closes with the audit evidence: the principal-request audit trail (PR-2026-0456); the temporary-file inventory entry for the export cache; the destruction certificate and the return-package receipt; the transmission-flow inventory entries. A processor that can produce this walk for any active or recently-offboarded customer is operating at A.2.3 / A.2.4 L4 or L5. A processor that cannot produce this walk is operating at L1 or L2.

Tools, Technologies, and Solutions

The tool landscape

The A.2.3 / A.2.4 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 principal-request queue, the SLA tracking, the audit trail, the offboarding register, the transmission-flow inventory. The A.2.3 / A.2.4-relevant slice is the principal-request module (DSAR / rights-request queue), the offboarding module (the destruction-certificate workflow), and the data-flow-mapping module (the transmission-flow inventory). Generic category terms, "enterprise privacy management platform", "privacy operations platform", "data governance platform", are the right vocabulary; this guide does not name vendors.

Data discovery and classification tools. Products that scan the processor's data estate (databases, file shares, cloud storage, endpoints, developer environments) and classify personal data. The output drives the temporary-file inventory (the data-discovery tool finds every location that contains controller-customer data, including the long-forgotten shared-drive folder) and the transmission-flow inventory (the network-flow analysis identifies every transmission that carries personal data).

Data lifecycle and retention automation tools. Products that integrate with the data stores (databases, file systems, cloud storage, SaaS apps) and automate the retention-and-deletion schedule. The conformant pattern is the tool that reads the retention schedule and fires the deletion at the period end, with the audit log of every deletion event. The A.2.4.2 (temp-file auto-purge) and A.2.4.3 (offboarding destruction) controls benefit from this class of tool.

Cryptographic-erasure and key-management tools. Products that manage the per-customer or per-data-category encryption keys and the destruction-with-certificate workflow. The cloud-hyperscalers' native key-management services (the major cloud providers' India regions provide the in-India key-storage) often form the foundation; the processor's responsibility is to integrate the key management with the offboarding procedure (the per-customer key destruction triggers the cryptographic erasure).

Disposal-vendor chain tools and services. Products and services that manage the physical-destruction vendor chain (the vendor's ISO/IEC 27001 certification; the certificate-of-destruction workflow; the chain-of-custody documentation). The Indian market has a small number of licensed e-waste and data-destruction vendors with the certifications and the chain-of-custody discipline.

Network and transmission-security tooling. Products that enforce the TLS / mTLS baseline (the load balancer; the API gateway), manage the certificates (the PKI / certificate-management system), and detect unencrypted flows (the network-flow analyser; the intrusion-detection system). The transmission log is typically maintained in the SIEM (security information and event management) platform.

The cost ranges

Illustrative third-party cost ranges (not Singahi pricing; for general orientation only).

The build-vs-buy decision

The build-vs-buy decision turns on four factors.

Customer-portfolio volume. High-volume processors (200+ customers) typically benefit from a top-tier PMP; lower-volume processors (5 to 25 customers) can run effectively on a focused combination of a ticketing tool (for the principal-request queue), a structured document (for the temp-file inventory and the transmission-flow inventory), and a key-management service (for the cryptographic erasure).

Existing stack integration. The privacy tooling must integrate with the processor's existing product (the customer portal; the ingestion API; the internal microservices), the ITSM (the ticketing system), the engineering pipeline (the data-flow reality), and the SIEM (the transmission log). Tools that do not integrate produce shadow artefacts (the privacy team's spreadsheet does not match the operational reality).

Cost and capability. For growing companies, the cost of a top-tier PMP can exceed the value; a focused combination of a mid-tier PMP, an in-house principal-request workflow, and a disciplined manual cadence can be conformant. For mid-market and enterprise, the volume of customer relationships and the multi-jurisdiction dimension typically justify the tooling investment.

Cloud-native vs on-premises. For cloud-native processors (the major cloud providers' India regions), the cryptographic-erasure pipeline, the key-management service, the TLS / mTLS enforcement, and the transmission log are built into the cloud platform; the processor's responsibility is to configure them correctly. For on-premises processors (BPO / ITeS delivery centres; on-premises data centres), the tooling investment is harder and requires deliberate engineering.

The Indian-specific tool dimension

The Indian-specific tool dimension is the DPDP-native slice, the principal-request workflow that accommodates the Consent Manager (section 2(1)(g)) withdrawals; the offboarding procedure that produces the destruction certificates the RBI / SEBI / IRDAI regulators expect; the transmission controls that respect the data-locality rules (the RBI storage-of-payment-data directive; the broader Indian data-locality expectation). As of mid-2026, the Indian PMP market is at the early-adopter stage; most processors run on a combination of global PMPs (with Indian-jurisdiction configuration), in-house built principal-request workflows, and manual processes for the DPDP-specific features. The market is expected to mature through 2026 and 2027 as the DPDP Rules' commencement phases in.

The cloud-hyperscaler India regions (the major cloud providers' Mumbai / Hyderabad / Pune regions) provide the in-India data-residency backdrop for the RBI storage-of-payment-data rule and the broader Indian data-locality expectation. The hyperscalers' built-in key-management services (with India-region key storage) and the cryptographic-erasure patterns (the per-customer key destruction) often form the foundation for the processor's offboarding procedure.

Policy and Procedure Templates

The Singahi toolkit (Section 19) ships ready-to-customize templates for the A.2.3 / A.2.4 artefact set. The eight core artefacts are:

The Processor Privacy-by-Design and Principal-Cooperation Policy (toolkit doc 01)

The policy commits the processor to the four controls. The load-bearing clauses (the processor's own "shall" clauses, drafted by Singahi, not the standard's text):

• The processor shall support each controller-customer in discharging the controller's obligations to PII principals, access, correction, erasure, objection, portability, grievance and nomination, by providing the data the controller needs to respond, executing the controller's instructions on the principal's data, and maintaining the end-to-end audit trail, all within the documented SLA.
• The processor shall maintain a dedicated principal-request intake channel with the SLA tracking, the audit trail, and the breach-cooperation procedure.
• The processor shall control the creation, retention and deletion of temporary files that contain controller-customer data through the documented Temporary-File Hygiene Standard, including the temporary-file inventory, the auto-purge configuration, the access controls, and the developer-environment discipline.
• The processor shall, at the end of the processing services for a controller-customer (or earlier on the controller's instruction), return the personal data to the controller, transfer it to a nominated processor, or dispose of it (with certificate), and shall delete the processor's own copies (the primary store; the backups; the DR mirrors; the temp files; the logs containing the data), with the post-termination retention scope documented in the offboarding register.
• The processor shall apply transmission controls to every flow that carries controller-customer data, confidentiality (TLS or mTLS encryption), integrity (tamper-protection), authentication (both parties authenticated), and inventorisation (every flow documented in the transmission-flow inventory with the source, destination, data categories, frequency, encryption method, authentication method, lawful basis, and cross-border analysis where applicable).
• The processor shall drill the breach-cooperation procedure (the dual-clock pattern, DPDP 72-hour handoff to the controller; CERT-In 6-hour India-ICT-system report) at least annually; for high-risk processors (BFSI, healthcare, sensitive-data processors), semi-annually.
• The processor shall apply the DPDP Act 2023 sections 8(5), 8(6), 8(7), 11 to 14, and 2(1)(g); the GDPR Article 28(3)(e), (f), (g), Article 25, Article 32, Article 5(1)(e) where EU personal data is processed; and the sector-rule overlays applicable to the processor's regulated customers (RBI Managing Risks in Outsourcing Directions, 2025; SEBI CSCRF; IRDAI Information and Cyber Security Guidelines).
• The processor shall report the A.2.3 / A.2.4 KPIs (doc 11) to the management review (Clause 9.3) on cadence and act on the trends.

The Principal-Request Handling Procedure (toolkit doc 02, Part A)

The procedure covering the intake channel, the SLA, the audit trail, the multi-system data extraction, the correction propagation, the erasure-with-certificate workflow, the grievance support, and the breach-cooperation procedure.

The Temporary-File Hygiene Standard (toolkit doc 02, Part B)

The standard covering the temporary-file inventory, the auto-purge configuration per location, the access controls, the developer-environment discipline, the BI-tool and analyst discipline, and the backup and log retention schedules.

The End-of-Services Data Return or Destruction Procedure (toolkit doc 03)

The procedure covering the controller-instruction intake, the return-package build (for return or transfer instructions), the destruction-with-certificate workflow (for destroy instructions), the post-termination retention scope, the offboarding register, and the backup and DR-mirror handling.

The Transmission Controls Checklist (toolkit doc 04)

The checklist covering the transmission-flow inventory, the TLS / mTLS baseline, the API authentication discipline, the cross-border transmission analysis, and the transmission log.

The Customer-DPA Clause Library (toolkit doc 10)

The library of processor-side "shall" clauses we recommend for every customer agreement, the principal-cooperation clause (the SLA; the audit trail; the breach-handoff); the temp-file clause (the hygiene standard; the auto-purge); the end-of-services clause (the return / transfer / destroy instruction; the destruction certificate; the post-termination retention); the transmission-controls clause (the TLS / mTLS baseline; the API authentication).

The Breach-Cooperation Playbook (toolkit doc 09)

The playbook covering the dual-clock pattern (DPDP 72-hour handoff; CERT-In 6-hour), the drill, the post-incident review template, and the customer-communication templates.

The KPI Dashboard (toolkit doc 11)

The dashboard covering the principal-request SLA performance, the temp-file inventory currency, the offboarding certificate generation, the transmission-flow inventory reconciliation, and the breach-cooperation drill score.

Risk Assessment and Treatment

The risk register entries that touch A.2.3 / A.2.4

A.2.3 / A.2.4-specific risks in the processor's privacy risk register typically include:

The DPIA trigger analysis for A.2.3 / A.2.4

The processor's own DPIA (under A.1.2.6, in its controller-side capacity for its own processing) and the support the processor provides to the controller-customer's DPIA trigger DPIAs for several A.2.3 / A.2.4 patterns:

• New processing activities that involve new temp-file locations (especially high-risk locations like developer environments).
• New transmission flows (especially cross-border flows to non-equivalent jurisdictions).
• New offboarding scenarios (especially for SDF customers with enhanced expectations).
• New AI/ML uses of customer data (the highest-risk pattern, the DPIA drives the correction-propagation analysis for the AI/ML model's training data).

The DPIA's outputs feed back into the A.2.3 / A.2.4 stack, the temp-file purge cadence may be tightened; the transmission controls may be hardened (mTLS added); the offboarding procedure may be tightened (the post-termination retention scope narrowed).

The risk-treatment decision points

For each A.2.3 / A.2.4-related risk, the treatment decision takes one of four paths:

• Modify, change the procedure, the configuration, or the engineering to reduce the likelihood or impact (tighten the temp-file purge; harden the transmission controls; narrow the post-termination retention scope).
• Avoid, do not engage in the high-risk pattern (do not put production data in developer environments; do not use email for personal-data transmission).
• Share, transfer the risk to a third party (the cyber-insurer; the sub-processor under contractual indemnity; the disposal vendor under the certificate-of-destruction chain).
• Accept, accept the residual risk with documented sign-off (typically a top-management decision under Clause 6.1.3 / 6.1.4).

The risk-treatment decisions are recorded in the privacy risk treatment plan (Clause 8.3) and reflected in the Statement of Applicability (the A.3 controls selected to mitigate the A.2.3 / A.2.4 risks).

Audit and Compliance Checklist

The following 28 questions cover the certification auditor's typical A.2.3 / A.2.4 family examination. For each, the expected evidence and the red flag are noted.

1. Is there a Processor Privacy-by-Design and Principal-Cooperation Policy? Expected: a dated, version-controlled policy signed off by the DPO and top management, covering the four controls. Red flag: no policy; or policy exists but is generic (no India-specific content; no sector-rule integration).

2. Is there a Principal-Request Handling Procedure with the SLA? Expected: the procedure documenting the intake channel, the SLA per request type, the audit-trail requirements, the multi-system extraction, the correction propagation, the erasure-with-certificate workflow. Red flag: no procedure; or procedure exists but no SLA documented.

3. Is the principal-request intake channel dedicated? Expected: a ticketing-tool integration or a structured email inbox distinct from routine operational communications. Red flag: principal requests land in the generic Customer Success inbox with no segregation.

4. Are principal-request audit trails end-to-end? Expected: each request's audit trail captures the controller's instruction, the processor's review (the A.2.2.5 instruction-decision log entry), the data extraction, the controller approval, the fulfilment, the closure. Red flag: partial audit trails (the closure recorded but not the data extraction).

5. Are sample principal requests within the SLA? Expected: sample walks of three to five recent requests showing the SLA met. Red flag: SLA misses; or no SLA tracking.

6. Does the multi-system extraction reach across all the systems? Expected: the extraction workflow documented to reach the primary store, the analytics warehouse, the temp files, the backups within retention, and the sub-processor's systems. Red flag: extraction from the primary store only.

7. Does the correction propagate to derived datasets? Expected: the correction-propagation discipline documented and engineered; the derived-dataset lineage tracked. Red flag: correction at the primary store only; the analytics warehouse and the AI/ML model retain the uncorrected data.

8. Is the erasure executed with a destruction certificate? Expected: the destruction-with-certificate workflow documented; sample certificates for recent erasures. Red flag: erasure executed without a certificate; the certificate cannot be produced.

9. Is the breach-cooperation procedure drilled? Expected: the most recent drill report; the dual-clock pattern documented; the semi-annual cadence for high-risk processors. Red flag: no drill; or drill exists but does not trace the dual-clock pattern.

10. Is there a Temporary-File Hygiene Standard? Expected: the standard documenting the inventory, the auto-purge configuration, the access controls, the developer-environment discipline. Red flag: no standard; or standard exists but is generic.

11. Is the temporary-file inventory complete? Expected: the inventory covering every temp-file location that contains controller-customer data; the quarterly reconciliation reports. Red flag: incomplete inventory; or inventory with stale entries.

12. Is the auto-purge configured per location? Expected: sample walks of three to five temp-file locations showing the auto-purge configuration (the cron job; the queue TTL; the cache eviction policy). Red flag: manual purge only; or no purge at all.

13. Are the temp files in the access-control regime? Expected: the access-control matrix; the audit-logged access. Red flag: shared-drive-with-everyone-read-write; or no audit log.

14. Is the developer-environment discipline enforced? Expected: the policy; the synthetic/de-identified data set; the time-boxed exception workflow. Red flag: production data in developer environments without controls.

15. Are backups and logs within the retention schedule? Expected: the retention schedule per backup type and log type; the CERT-In 180-day rule for logs accommodated. Red flag: indefinite retention; or no documented schedule.

16. Is there an End-of-Services Data Return or Destruction Procedure? Expected: the procedure documenting the controller-instruction intake, the return-package build, the destruction-with-certificate workflow, the post-termination retention scope, the offboarding register. Red flag: no procedure; or procedure exists but is not followed.

17. Is the offboarding register maintained? Expected: the per-customer register of offboardings with the controller's instruction, the action taken, the certificate or receipt reference, the post-termination retention scope, the final retention-end date. Red flag: no register; or register with stale entries.

18. Are destruction certificates produced and archived? Expected: sample certificates for three recent offboardings. Red flag: no certificates; or certificates that lack the method, timestamp, witness, chain of custody.

19. Is the post-termination retention scope narrow? Expected: documented legal-hold and audit-defence rationale; the bounded retention period (typically 90 to 180 days). Red flag: broad scope; the data retained indefinitely "just in case".

20. Are backups and DR mirrors handled at offboarding? Expected: the backups brought within the post-termination retention scope; the DR mirror destroyed or repurposed. Red flag: backups retained indefinitely; the DR mirror forgotten.

21. Is the cryptographic-erasure pipeline documented? Expected: the per-customer or per-data-category key-management discipline; the key-destruction workflow; the audit log. Red flag: no cryptographic-erasure pipeline; or pipeline without key-management discipline.

22. Is there a Transmission Controls Checklist? Expected: the checklist documenting the transmission-flow inventory, the TLS / mTLS baseline, the API authentication discipline, the cross-border transmission analysis, the transmission log. Red flag: no checklist; or checklist exists but is generic.

23. Is the transmission-flow inventory complete? Expected: the inventory covering every flow that carries controller-customer data (ingestion, internal microservices, sub-processor, return, cross-border); the quarterly reconciliation. Red flag: incomplete inventory; or inventory with stale entries.

24. Is the TLS / mTLS baseline enforced? Expected: the configuration at the load balancer, the API gateway, the application layer; the certificate management; the cipher-suite documentation. Red flag: TLS 1.0 or 1.1 in use; weak ciphers enabled; expired certificates.

25. Are high-risk flows using mTLS? Expected: the mTLS configuration for sensitive-data, cross-border, partner-fed, high-volume, and sub-processor flows; the PKI / certificate-management documentation. Red flag: mTLS not configured for high-risk flows; password-only auth.

26. Is the API authentication discipline documented per API? Expected: the per-API authentication documentation (OAuth 2.0 / OIDC; signed JWT; HMAC signatures). Red flag: no documentation; or weak authentication (basic auth; shared API keys).

27. Is the cross-border transmission analysis integrated with A.2.5.2? Expected: every cross-border flow's transmission-inventory entry cross-references the A.2.5.2 transfer-basis record. Red flag: cross-border flows without the DPDP section 16 negative-list screen; or without the GDPR Chapter V transfer mechanism.

28. Is the transmission log retained and integrated with the SIEM? Expected: the transmission log retained per the CERT-In 180-day rule (where applicable) and the processor's broader schedule; the SIEM integration for breach detection. Red flag: no transmission log; or log retained for less than 180 days.

Metrics and KPIs

The Singahi A.2.3 / A.2.4 KPI set (toolkit doc 11) covers principal-request SLA performance, temp-file hygiene currency, offboarding certificate generation, transmission-flow inventory reconciliation, and the breach-cooperation drill. The fifteen KPIs below are the recommended minimum.

Principal-cooperation KPIs

1. Principal-request SLA met rate, the percentage of principal requests fulfilled within the SLA. Target: 100%.

   • Formula: (requests fulfilled within SLA / total requests) × 100
   • Frequency: monthly
   • Owner: DPO / Customer Success

2. Principal-request audit-trail completeness, the percentage of principal requests with an end-to-end audit trail. Target: 100%.

   • Frequency: monthly
   • Owner: DPO

3. Multi-system extraction coverage, the percentage of principal-request data extractions that reached all relevant systems (primary, warehouse, temp files, backups within retention, sub-processors). Target: 100%.

   • Frequency: monthly
   • Owner: DPO / Engineering

4. Breach-cooperation drill score, the score on the most recent drill (the dual-clock pattern met; the controller notified within the SLA; the Rule 7 intimation content pre-staged). Target: 100%; trend monitored.

   • Frequency: annually (or semi-annually for high-risk processors)
   • Owner: DPO / Security Lead

Temporary-file KPIs

5. Temporary-file inventory coverage, the percentage of temp-file locations that hold controller-customer data and are in the inventory. Target: 100%.

   • Frequency: monthly
   • Owner: Engineering / DPO

6. Auto-purge configuration rate, the percentage of inventoried temp-file locations with the auto-purge configured. Target: 100%.

   • Frequency: monthly
   • Owner: Engineering

7. Temp-file access-control compliance, the percentage of temp-file locations in the access-control regime with audit-logged access. Target: 100%.

   • Frequency: monthly
   • Owner: Security Lead

8. Developer-environment exceptions, the count of time-boxed exceptions for production data in developer environments in the period. Trend monitored.

   • Frequency: monthly
   • Owner: Engineering / DPO

End-of-services KPIs

9. Offboarding register currency, the count of offboardings in the period with the destruction certificate or return receipt archived. Target: 100% of offboardings.

   • Frequency: monthly
   • Owner: DPO / Operations

10. Post-termination retention scope, the count of customers with post-termination retention, and the aggregate scope (in records or volume). Trend monitored.

    • Frequency: quarterly
    • Owner: DPO

11. Backup-handling compliance at offboarding, the percentage of offboardings where the backups were brought within the post-termination retention scope. Target: 100%.

    • Frequency: monthly
    • Owner: Engineering / DPO

Transmission-controls KPIs

12. Transmission-flow inventory coverage, the percentage of transmission flows that carry controller-customer data and are in the inventory. Target: 100%.

    • Frequency: monthly
    • Owner: Engineering / DPO

13. TLS / mTLS baseline compliance, the percentage of transmission flows using TLS 1.2 or 1.3; the percentage of high-risk flows using mTLS. Target: 100%.

    • Frequency: monthly
    • Owner: Engineering / Security Lead

14. Unencrypted-flow detection count, the count of unencrypted flows detected by the network scan in the period. Target: zero; trend monitored.

    • Frequency: monthly
    • Owner: Security Lead

15. Cross-border transmission analysis coverage, the percentage of cross-border flows with the DPDP section 16 negative-list screen and the GDPR Chapter V transfer mechanism documented. Target: 100%.

    • Frequency: quarterly
    • Owner: DPO / Legal

Common Pitfalls and Audit Failures

The most common A.2.3 / A.2.4 family audit findings in the Indian growing-company processor segment, in rough descending order of frequency.

The "principal requests land in the Customer Success inbox" gap

The processor has no dedicated principal-request intake channel. Requests from controller-customers land in the Customer Success team's shared inbox alongside routine queries. There is no SLA tracking; no audit trail; no segregation. Fails A.2.3.2. Remediation: dedicated intake channel (ticketing-tool integration); SLA documentation; audit-trail workflow.

The partial-extraction anti-pattern

The processor's principal-request data extraction reaches the primary data store but not the analytics warehouse, the temp files, or the backups within retention. The principal's access response is incomplete. Fails A.2.3.2. Remediation: multi-system extraction workflow; data-discovery tool integration; the extraction checklist per request.

The correction-not-propagated gap

The processor corrects the principal's data at the primary store but not in the analytics warehouse or the AI/ML model's training data. The derived datasets retain the uncorrected data. Fails A.2.3.2. Remediation: correction-propagation engineering; derived-dataset lineage tracking.

The erasure-without-certificate gap

The processor executes the erasure (deletes the database row) but does not generate a destruction certificate. No audit evidence of the erasure. Fails A.2.3.2 read with A.2.4.3. Remediation: destruction-with-certificate workflow; the cryptographic-erasure pipeline.

The shared-drive of seven years of exports

The processor's shared drive has accumulated seven years of monthly CSV exports from multiple controller-customers. No owner; no purge cadence; everyone-read-write access. Fails A.2.4.2. Remediation: temporary-file inventory; auto-purge; access-control remediation.

The production-data-in-developer-environments anti-pattern

The processor's developer environments contain production-data mirrors for debugging and testing. The mirrors are not time-boxed; the access controls are weaker than production; the audit logging is absent. Fails A.2.4.2. Remediation: developer-environment discipline; synthetic-data generation; time-boxed exceptions with DPO sign-off.

The offboarding-without-destruction-certificate gap

The processor's customer ended the engagement six months ago. The processor stopped the API calls but the data sits in the database. No destruction certificate was generated; the offboarding register was not updated. Fails A.2.4.3. Remediation: end-of-services procedure; the offboarding register; the destruction-with-certificate workflow.

The indefinite-backup-retention failure

The processor disposed the live data at offboarding but the backups are retained indefinitely. The backups contain the controller-customer's personal data. Fails A.2.4.3. Remediation: backup retention schedule; the offboarding-procedure extension to backups; the key destruction at the post-termination retention end.

The broad post-termination retention scope

The processor retains "all data for compliance purposes" after offboarding. The scope is broad; the retention is indefinite; the rationale is undocumented. Fails A.2.4.3 narrow-scope requirement. Remediation: narrow-scope design; documented legal-hold and audit-defence rationale; quarterly review.

The CSV-by-email anti-pattern

The processor's transmission to a sub-processor is a daily CSV sent by email. Email is not a secure transmission channel for personal data. Fails A.2.4.4. Remediation: secure-file-transfer protocol; mTLS API; the transmission-flow inventory; the auto-detection of unencrypted flows.

The SFTP-with-password-only anti-pattern

The processor's transmission to a partner is over SFTP with password-only authentication. The password can be phished. Fails A.2.4.4 authentication dimension. Remediation: mTLS or SSH key-pair authentication; the transmission-flow inventory.

The webhook-without-signature-verification anti-pattern

The processor's webhook to a partner has no signature verification. The webhook can be spoofed. Fails A.2.4.4 integrity dimension. Remediation: HMAC signature discipline; the webhook-verification engineering.

The transmission-flow-without-inventory gap

The processor has transmission flows that carry controller-customer data but are not in the transmission-flow inventory. The flows are invisible to the privacy team. Fails A.2.4.4 inventorisation dimension. Remediation: network-flow analysis; the transmission-flow inventory reconciliation; the data-discovery tool integration.

The TLS-1.0-still-in-use gap

The processor's transmission flows include TLS 1.0 or 1.1 (legacy protocols with known vulnerabilities). Fails A.2.4.4 confidentiality dimension. Remediation: TLS 1.2 minimum; TLS 1.3 preferred; the configuration audit at the load balancer, the API gateway, the application layer.

The cross-border-flow-without-DPDP-section-16-screen gap

The processor's cross-border flow to a non-India region is not screened against the DPDP section 16 negative list. Fails A.2.4.4 cross-border dimension read with A.2.5.2. Remediation: cross-border transmission analysis; integration with the A.2.5.2 transfer-basis record; the negative-list screen at the gateway.

The transmission-log-not-retained gap

The processor's transmission log is retained for less than the CERT-In 180-day period. Fails the CERT-In Directions 20(3)/2022-CERT-In read with A.2.4.4. Remediation: transmission-log retention schedule; SIEM integration; the 180-day retention enforced.

The drill-never-run gap

The processor's breach-cooperation procedure exists on paper. The drill has never been run. The dual-clock pattern has not been tested. Fails A.2.3.2 operational dimension. Remediation: annual drill; semi-annual for high-risk processors; the drill report with the lessons learned.

The "we have a PMP, so we are done" over-reliance

The processor bought a privacy management platform and assumed compliance follows. The PMP was not configured to the processor's customer portfolio; the principal-request queue was not integrated; the temp-file inventory was not populated. Fails operational discipline. Remediation: configure the PMP to the processor's documented standard; audit the configuration quarterly.

The sub-processor-flow-without-mTLS gap

The processor's transmission to a sub-processor is over TLS without mTLS. The sub-processor's endpoint is not authenticated. Fails A.2.4.4 authentication dimension. Remediation: mTLS for sub-processor flows; the PKI / certificate-management documentation.

The Consent Manager withdrawal not accommodated

The processor's principal-request workflow does not accommodate the Consent Manager (DPDP section 2(1)(g)), a withdrawal initiated through the Consent Manager is not actioned because the intake channel does not ingest Consent Manager events. Fails A.2.3.2 read with DPDP section 2(1)(g). Remediation: Consent Manager integration; the principal-request workflow update.

The 48-hour-pre-erasure-notice missing

The processor's erasure-on-instruction procedure fires immediately on the controller's instruction, without accommodating the controller's 48-hour pre-erasure notice to the principal under DPDP Rules 2025. Fails A.2.3.2 / A.2.4.3. Remediation: the 48-hour notice built into the controller's instruction intake; the erasure workflow delayed until the notice period ends.

The instruction-to-ignore-or-delay anti-pattern

The processor receives an instruction from the controller to ignore or delay a principal's request (typically a request that would expose the controller's compliance gap). The processor complies without escalation. Fails A.2.3.2 read with A.2.2.5. Remediation: A.2.2.5 instruction-decision log; DPO escalation; the refusal pathway.

The audit-trail-falsification gap

The processor's principal-request audit trail can be edited or deleted by the operator. The audit trail is not tamper-evident. Fails A.2.3.2 read with A.3.14 (protection against falsification). Remediation: append-only audit-trail architecture; A.3.25 logging; the integrity controls.

Illustrative Scenario 1: Failure, Pradyut BPO and the Offboarding Data Leak (Illustrative)

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

Disclaimer: This is an illustrative scenario developed for educational purposes. The company name is fictional; the patterns are drawn from the publicly documented audit-failure patterns of multiple Indian BPO and ITeS providers. No specific real company is described.

The setting. Pradyut Business Process Outsourcing Private Limited operates a BPO delivery centre in Pune, serving approximately 40 controller-customers, banks, NBFCs, insurers, healthcare providers, e-commerce platforms, with customer-support, claims-processing, and back-office operations. The company employs approximately 1,200 staff across three shifts. The processing includes access to controller-customers' principal data (the bank's customers' account details; the insurer's policyholders' claims records; the healthcare provider's patient records; the e-commerce platform's customers' contact and order data).

The A.2.3 / A.2.4 architecture at the audit. At the time of the ISO/IEC 27701:2025 Stage 1 audit in mid-2027, Pradyut's A.2.3 / A.2.4 architecture was typical of an Indian growing-company BPO processor that had prioritised operational throughput over privacy discipline:

• The principal-request intake channel was the Customer Success team's shared inbox, "privacy@pradyut.example". Requests from controller-customers landed alongside routine queries; there was no SLA tracking; the audit trail was an email folder.
• The temporary-file estate included: the shared "Exports" drive (seven years of monthly CSV exports from multiple controller-customers; everyone-read-write access); the developer environment (production-data mirrors for the issue-debugging workflow; not time-boxed); the BI-tool extracts (the analyst team's local extracts on workstations); the application logs (retained indefinitely on the centralised log server).
• The offboarding register did not exist. Offboardings were handled by stopping the API calls and the VPN access; the data sat in the database forever. No destruction certificates were generated.
• The transmission-flow inventory did not exist. The flows included: the ingestion flows (SFTP with password-only authentication for several controller-customers); the internal microservice flows (HTTP without TLS for some legacy services); the sub-processor flows (the SMS-gateway vendor; the email-gateway vendor, TLS without mTLS); the cross-border flows (one controller-customer's data flowed to a Singapore-based analytics sub-processor, without the DPDP section 16 negative-list screen).
• The breach-cooperation procedure existed on paper but had never been drilled.

The trigger. In April 2027, one of Pradyut's controller-customers (a Mumbai-based insurer) ended the engagement. The insurer's instruction was to destroy the policyholder data with certificate. Pradyut's Customer Success team acknowledged the instruction by email and stopped the API calls. Six weeks later, a Pradyut engineer, debugging an unrelated issue on the production database, accidentally exposed a database snapshot through a misconfigured cloud-storage bucket. The snapshot contained the insurer's policyholder data (approximately 280,000 records) and the data of three other controller-customers (a bank's customer-support transcripts; an e-commerce platform's customer contact data; a healthcare provider's patient appointment records). The exposure was detected by an external security researcher who notified CERT-In.

The audit findings. The Stage 1 audit, conducted in June 2027 by an IAF-accredited certification body, surfaced the following A.2.3 / A.2.4 findings:

• Major nonconformity, A.2.3.2 (no principal-request SLA). The Customer Success inbox had no SLA tracking; the audit trails were email folders; the multi-system extraction was ad-hoc.
• Major nonconformity, A.2.4.2 (temporary-file estate). The shared "Exports" drive; the developer environment mirrors; the BI-tool extracts; the indefinite log retention, all were uncontrolled. No temporary-file inventory; no auto-purge; no access-control regime beyond the everyone-read-write default.
• Major nonconformity, A.2.4.3 (no offboarding register). The insurer's offboarding had been acknowledged but not executed, the data sat in the database. No destruction certificate; no post-termination retention scope. Three other controller-customers' offboardings were similarly incomplete.
• Major nonconformity, A.2.4.4 (no transmission-flow inventory). The SFTP password-only flows; the unencrypted internal microservice flows; the cross-border flow to Singapore without the DPDP section 16 screen; the sub-processor flows without mTLS.
• Cross-control findings. The A.2.2.5 instruction-decision log was empty. The A.2.2.7 processor ROPA did not reflect the four controls' dimensions. The A.3 security controls (especially A.3.9 access rights; A.3.21 secure disposal; A.3.25 logging; A.3.26 cryptography) were applied unevenly.

The regulatory outcome. The CERT-In report triggered a parallel DPBI investigation (the breach was a personal-data breach under DPDP section 8(6) for each of the four affected controller-customers). The insurer filed an indemnity claim against Pradyut (approximately INR 12 crore, the estimated DPBI penalty exposure plus the remediation cost plus the reputational damage). The bank, the e-commerce platform and the healthcare provider filed parallel indemnity claims. The DPBI's investigation tested whether Pradyut had supported the controller-customers' breach-notification duties (it had not, the breach-handoff had taken weeks, not the 24-hour SLA); whether the temporary files were the source of the leak (they were not, the source was the production database snapshot, but the temp files were an additional uncontrolled surface); whether the offboarding was executed cleanly (it was not); and whether the transmission flows were compromised (the cross-border flow to Singapore was a separate finding). The reputational impact was substantial; Pradyut lost approximately 18% of its customer base over the following two quarters as enterprise customers migrated to better-governed competitors.

The lessons.

• The offboarding-procedure gap is the canonical A.2.4.3 failure. A BPO processor that handled offboardings by stopping the API calls had four controller-customers' data sitting in its production database indefinitely. The remediation cost (the offboarding procedure build; the destruction-with-certificate workflow; the customer-by-customer offboarding remediation; the lost customers) was an order of magnitude greater than the cost of building the procedure at the start.
• The temp-file estate is the uncontrolled leak surface. The shared Exports drive and the developer-environment mirrors were not the proximate cause of the leak, but they were additional surfaces that the auditor and the regulator flagged. The temporary-file inventory and the auto-purge are the canonical controls.
• The transmission-flow inventory surfaces the cross-border gaps. The flow to Singapore without the DPDP section 16 screen was a separate regulatory exposure that the audit and the DPBI investigation both surfaced. The transmission-flow inventory is the canonical control.
• The audit and the regulator read the same evidence. The Stage 1 audit findings and the DPBI investigation were substantially overlapping. An ISO/IEC 27701:2025 audit is a near-proxy for regulatory readiness.

Illustrative Scenario 2: Success, Tarani Health Cloud Builds the End-to-End Processor Privacy Stack (Illustrative, with ROI)

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

The setting. Tarani Health Cloud Private Limited operates a SaaS healthtech platform in India, electronic medical records, telemedicine, appointment management, pharmacy integration, serving approximately 180 active controller-customers ranging from hospital chains to single-doctor telemedicine practices. The company is headquartered in Bengaluru, with engineering in Hyderabad and a customer-success team in Mumbai. The platform processes substantial principal data on behalf of its customers (the patients' medical records, prescriptions, appointment histories, telemedicine consultation transcripts).

The pre-remediation state. In mid-2025, ahead of the ISO/IEC 27701:2025 publication and the DPDP Rules notification, Tarani's A.2.3 / A.2.4 architecture was functional but uneven. The principal-request intake was a Customer Success inbox; the SLA was implicit; the audit trail was an email folder. The temporary-file estate included a shared exports drive (everyone-read-write access), BI-tool extracts on analyst workstations, and indefinite log retention. The offboarding procedure was stop-the-API-calls. The transmission flows used TLS but no mTLS for sub-processor flows.

The trigger. Tarani's board, on the recommendation of the newly-appointed DPO, decided in late 2025 to seek ISO/IEC 27701:2025 certification ahead of the DPDP Rules' full-enforceability window. The decision was driven by three considerations: (i) the hospital-chain customers were increasingly asking for ISO/IEC 27701 attestation as a procurement requirement; (ii) Tarani was planning to launch an AI-driven clinical-decision-support feature that would attract DPDP section 10 scrutiny (the controller-customers' SDF status would flow through); (iii) a competitor had recently lost a procurement to a better-governed rival.

The remediation programme (January 2026 to December 2026). The DPO structured the programme in four quarters.

Quarter 1, Policy and quick wins. The team adopted the Singahi Processor Privacy-by-Design and Principal-Cooperation Policy (toolkit doc 01). The team built the Principal-Request Handling Procedure (doc 02, Part A) with the dedicated intake channel (a ticketing-tool integration), the SLA (10 business days for access; 15 days for correction; 30 days for erasure after the 48-hour pre-erasure notice), and the audit-trail workflow. The team ran the temporary-file inventory (the data-discovery tool scanned the shared drives, the databases, the cloud storage, the developer environments, the BI tool, the log server) and surfaced 47 temp-file locations. The team stopped the practice of production-data in developer environments and stood up a synthetic-data generator for the engineering team.

Quarter 2, Temp-file hygiene and offboarding. The team built the Temporary-File Hygiene Standard (doc 02, Part B) and configured the auto-purge per location (the shared exports drive, auto-purge at 30 days; the application logs, retention per the CERT-In 180-day rule and the audit-defence 7-year rule for the access log; the BI-tool extracts, disabled the local-extract feature; the developer-environment mirrors, time-boxed 24-hour exceptions with DPO sign-off). The team built the End-of-Services Data Return or Destruction Procedure (doc 03) with the controller-instruction intake, the return-package build, the destruction-with-certificate workflow (the per-customer encryption key destruction for cloud-native data; the licensed-vendor chain for any physical media), the offboarding register, and the backup-handling procedure (the per-customer key destruction scheduled for day 90 of the post-termination retention scope). The team remediated three legacy offboardings that had been stop-the-API-calls only.

Quarter 3, Transmission controls. The team built the Transmission Controls Checklist (doc 04) and the transmission-flow inventory. The team ran the network-flow analysis and identified 62 transmission flows across the processor's environment. The team hardened the TLS baseline (disabled TLS 1.0 and 1.1; enforced TLS 1.2 minimum, TLS 1.3 preferred; documented the cipher suite; renewed the certificate-management discipline). The team configured mTLS for the sub-processor flows (the SMS-gateway vendor; the email-gateway vendor; the pharmacy-integration sub-processor). The team documented the API authentication per API (OAuth 2.0 / OIDC for the controller-facing APIs; signed JWTs for the internal microservices; HMAC signatures for the webhooks). The team ran the cross-border transmission analysis (one flow to a Singapore-based analytics sub-processor, the team screened it against the DPDP section 16 negative list and documented the A.2.5.2 transfer-basis record).

Quarter 4, Breach-cooperation drill and certification. The team ran the breach-cooperation drill, tabletop in Q3, full drill in Q4, tracing the dual-clock pattern (the DPDP 72-hour handoff to the controller; the CERT-In 6-hour India-ICT-system report). The drill exposed three gaps (the customer-portal credentials for the breach-notification handoff had expired for some customers; the Rule 7 intimation content was not pre-staged for the BFSI customers; the CERT-In point-of-contact had changed). The team closed the gaps before the certification audit. The team ran the internal audit (Clause 9.2) covering all four A.2.3 / A.2.4 controls and the management review (Clause 9.3) with the fifteen KPIs.

The certification outcome. The team went to the certification audit in January 2027. The Stage 1 audit passed without major nonconformities on the A.2.3 / A.2.4 family. The Stage 2 audit, conducted in March 2027, traced three sample customers (a hospital chain; a single-doctor telemedicine practice; an insurer) through the full A.2.3 / A.2.4 stack, the principal-request audit trails; the temporary-file inventory entries; the offboarding register entries (for one offboarded customer); the transmission-flow inventory entries. Zero major nonconformities on the A.2.3 / A.2.4 family.

The quantified ROI.

• Avoided penalty exposure. The pre-remediation pattern carried estimated DPDP penalty exposure (on the controller-customers, with contractual indemnity flow-through to Tarani) of approximately INR 30 to 90 crore (the uncontrolled temp-file estate; the stop-the-API-calls offboardings; the unencrypted cross-border flow; the missing principal-request SLA). The remediation reduced the exposure by an estimated 90%.
• Operational efficiency. The principal-request workflow removed approximately 120 person-hours per quarter of manual coordination effort. The temporary-file inventory and auto-purge recovered approximately 4 terabytes of storage. The transmission-flow inventory accelerated the security team's incident-response by surfacing every flow within minutes.
• Procurement-cycle acceleration. The certification cut the average enterprise-procurement cycle from 16 weeks to 8 weeks.
• Engineering dividend. The synthetic-data generator improved the developer-environment realism (the synthetic data was richer than the production-data mirrors it replaced) and accelerated the test cycle by 30%.

The lessons.

• Treat the A.2.3 / A.2.4 stack as a commercial investment, not a compliance cost. The principal-request workflow, the temp-file hygiene, the offboarding procedure, the transmission controls delivered direct revenue (the hospital-chain wins), avoided penalty exposure an order of magnitude greater than the build cost, and produced operational efficiency that the fragmented pre-remediation architecture could not match.
• The temporary-file inventory is the unlock for the data estate. The data-discovery scan surfaced 47 temp-file locations; the auto-purge recovered 4 terabytes; the access-control remediation closed the highest-risk pattern. The inventory is the foundation on which the rest of the temp-file discipline runs.
• The offboarding procedure is the closure discipline. The customer-by-customer remediation of the legacy stop-the-API-calls offboardings was painful but bounded. The forward-looking procedure ensures every future offboarding is clean.
• The transmission-flow inventory surfaces the invisible risks. The cross-border flow to Singapore was a separate regulatory exposure that the inventory surfaced; the mTLS hardening for the sub-processor flows closed the authentication gap.
• The drill makes the breach-cooperation survivable. The full drill in Q4 exposed three gaps that the documented playbook had missed. The drill closed the gaps before the regulator did.

Multi-Framework Mapping

The detailed crosswalk

The DPDP-section-to-A.2.3 / A.2.4 map (load-bearing for India)

The DPDP Act section-by-section A.2.3 / A.2.4 hooks: section 8(5) (reasonable security safeguards, the A.2.4.2 temp-file integrity, the A.2.4.3 disposal integrity, the A.2.4.4 transmission integrity); section 8(6) (breach notification, the A.2.3.2 breach-cooperation duty; the 72-hour Rule 7 clock the processor's handoff feeds); section 8(7) (erasure, the A.2.4.3 foundation); section 11 (access, the A.2.3.2 access-cooperation duty); section 12 (correction and erasure, the A.2.3.2 correction and erasure-cooperation duty); section 13 (grievance redressal, the A.2.3.2 grievance-cooperation duty); section 14 (nomination, the A.2.3.2 nomination-cooperation duty); section 16 (cross-border negative list, the A.2.4.4 cross-border transmission dimension); section 2(1)(g) (Consent Manager, the A.2.3.2 Consent-Manager-withdrawal integration); section 33 and the Schedule (penalties, the fiduciary's penalty exposure that flows contractually to the processor through the DPA's indemnity clauses when cooperation or offboarding fails).

The sector-regulator overlay (India-specific)

Implementation Roadmap

The Singahi 30 / 90 / 180-day implementation roadmap (toolkit doc 05) for the A.2.3 / A.2.4 family.

The first 30 days, policy and quick wins

• Day 1 to 5, Sponsor and team. The DPO confirms executive sponsorship and convenes the cross-functional team (DPO, Legal, Customer Success, Engineering, Operations, Security). The team adopts the Singahi Processor Privacy-by-Design and Principal-Cooperation Policy (toolkit doc 01).
• Day 6 to 15, Principal-request inventory. The team inventories every principal-request received from each controller-customer in the last 12 months (the source channel; the request type; the response time; the audit trail). The output: the principal-request baseline that drives the SLA design and the gap remediation.
• Day 16 to 25, Temporary-file inventory scan. The team runs the data-discovery tool across the processor's data estate and builds the initial temporary-file inventory. The output typically surfaces 30 to 80 temp-file locations (the shared drives; the database dumps; the BI-tool extracts; the developer environments; the log directories).
• Day 26 to 30, Quick wins. The team implements the top-three highest-risk remediations (typically: stopping the practice of production-data in developer environments; remediating the shared-drive-with-everyone-read-write access pattern; building the principal-request intake channel).

The 90-day milestone, procedures and SLA

• Day 31 to 50, Principal-Request Handling Procedure. The team finalises the procedure (toolkit doc 02, Part A) with the dedicated intake channel, the SLA, the audit-trail workflow, the multi-system extraction checklist, the correction-propagation discipline, the erasure-with-certificate workflow. The team configures the ticketing-tool integration.
• Day 51 to 70, Temporary-File Hygiene Standard. The team finalises the standard (toolkit doc 02, Part B) and configures the auto-purge per location. The team configures the access-control remediation. The team stands up the synthetic-data generator for the developer environment.
• Day 71 to 90, End-of-Services Data Return or Destruction Procedure. The team finalises the procedure (toolkit doc 03) with the controller-instruction intake, the return-package build, the destruction-with-certificate workflow, the post-termination retention scope, the offboarding register. The team builds the cryptographic-erasure pipeline.

The 180-day milestone, transmission and drill

• Day 91 to 120, Transmission Controls Checklist. The team builds the checklist (toolkit doc 04) and the transmission-flow inventory. The team runs the network-flow analysis. The team hardens the TLS baseline and configures mTLS for high-risk flows.
• Day 121 to 150, Cross-border transmission analysis. The team runs the cross-border analysis under DPDP section 16 and GDPR Chapter V for every cross-border flow. The team documents the A.2.5.2 transfer-basis record cross-references.
• Day 150 to 180, Breach-cooperation drill. The team runs the first breach-cooperation drill (tabletop first, then full drill) tracing the dual-clock pattern (CERT-In six hours; DPDP seventy-two hours; sector-regulator clocks where applicable).

The 9-to-12-month arc, full A.2.3 / A.2.4 maturity

• Month 7, Offboarding remediation. The team runs the customer-by-customer offboarding remediation for any legacy stop-the-API-calls offboardings; the destruction certificates are generated retroactively where possible; the offboarding register is back-populated.
• Month 8, Sub-processor chain integration. The team integrates the sub-processor chain controls (A.2.5.7 / A.2.5.8 / A.2.5.9) with the A.2.3 / A.2.4 stack, the offboarding procedure extends to sub-processors; the transmission-flow inventory includes the sub-processor flows with mTLS.
• Month 9, KPI rollout and management review. The team rolls out the fifteen KPIs (Section 12). The team reports the KPIs to the management review (Clause 9.3). The team identifies the improvement actions for the next cycle (Clause 10.1).
• Month 10, Internal audit. The team runs the internal audit (Clause 9.2) covering all four A.2.3 / A.2.4 controls. The team closes the findings before the certification Stage 1.
• Month 11, Consent Manager integration. The team integrates the Consent Manager (DPDP section 2(1)(g)) with the principal-request workflow; the 48-hour pre-erasure notice is accommodated in the erasure workflow.
• Month 12, Certification. The certification audit. The Stage 1 documentation review. The Stage 2 operational-effectiveness test. The A.2.3 / A.2.4 walk-through (the auditor picks a recent principal request, a recent temp-file location, a recent offboarding and a recent transmission flow).

The ongoing cadence (post-certification)

• Weekly, KPI dashboard review (DPO); incident review (DPO); principal-request queue check (Customer Success).
• Monthly, Principal-request SLA performance; temp-file inventory currency; offboarding register currency; transmission-flow inventory currency.
• Quarterly, full reconciliation of the A.2.3 / A.2.4 stack against the operational reality; the sub-processor-chain reconciliation; the post-termination retention scope review.
• Semi-annually, full breach-cooperation drill (mid-market and enterprise processors); management review of the A.2.3 / A.2.4 KPIs.
• Annually, internal audit of A.2.3 / A.2.4; training refresh; sector-overlay testing.
• Event-driven, corrective action on each finding; offboarding for each customer that ends the engagement; transmission-flow inventory update on each new flow.

FAQ

Q1. We are a SaaS processor and our customers' principals rarely contact us directly, they go through the customer. Do we still need a dedicated principal-request intake channel?

Yes. Even if the principal contacts the controller (not the processor), the controller will forward the request to you when the controller needs your data to respond. A dedicated intake channel (a ticketing-tool integration with the controller's privacy team as the requester, or a structured email inbox) ensures the request is distinguished from routine operational communications, the SLA is tracked, and the audit trail is end-to-end. The Customer Success inbox pattern fails A.2.3.2 because it provides none of these.

Q2. How should we set the principal-request SLA?

The SLA cascades from the controller's regulatory timeline minus the controller's own handling time. Under DPDP Rules 2025 the controller's grievance-redressal period is the prescribed period (typically 30 days from the principal's request). If the controller needs 15 days for its own handling (assembling the response; legal review; delivery), the processor's SLA for the data extraction is 15 days. For access requests, the processor's SLA is typically 5 to 15 business days (the controller needs the data quickly to assemble the response). For erasure, the processor's SLA is typically 30 days (executed after the controller's 48-hour pre-erasure notice).

Q3. We delete a principal's data on the controller's instruction. Do we need a destruction certificate even for a database-row deletion?

Yes. A destruction certificate is the audit evidence that the erasure was executed. Without the certificate, the processor cannot evidence the erasure to the controller, the certification auditor or the regulator. The certificate documents the method (cryptographic erasure; database-row deletion with key destruction; physical destruction), the timestamp, the witness, the chain of custody. For cloud-native processors, the cryptographic-erasure pattern (the per-customer or per-data-category key destruction) is the recommended method because it generates a clean certificate (the key-destruction event in the key-management system) and is irreversible.

Q4. Our shared drive has years of customer exports. Where do we start?

Start with the Singahi temporary-file inventory template (toolkit doc 02, Part B). Run the data-discovery tool across the shared drive and surface every file that contains controller-customer data. For each file: classify (the customer; the data categories; the volume; the date); document the purpose (the original reason the export was created); set the purge cadence (typically 30 to 90 days for routine exports; longer for audit-defence exports). Configure the auto-purge (the script that deletes the file at the cadence end). Remediate the access controls (least-privilege; audit-logged). The remediation is engineering investment, typically 2 to 6 weeks of effort for a shared drive of moderate complexity.

Q5. How do we handle backups at offboarding?

Backups are the canonical A.2.4.3 failure pattern, the live data is disposed but the backups are retained indefinitely. The conformant pattern: the offboarding procedure extends to backups. The backups containing the controller-customer's data are brought within the post-termination retention scope (the narrow window for legal-hold and audit-defence, typically 90 to 180 days). The per-customer encryption key for the backups is destroyed at the end of the retention scope (the cryptographic erasure of the backups). The offboarding register records the backup-handling.

Q6. Our developer team needs production data for debugging. What is the conformant pattern?

The conformant pattern: no production data in developer environments. The developer environment uses synthetic data (generated by a synthetic-data generator that produces realistic but fake data) or de-identified data (production data with the identifiers removed or tokenised). Any exception (a production-data mirror for a specific debug session) is time-boxed (a 24-hour TTL), access-logged, and approved by the DPO and the Security Lead. The exception is recorded in the developer-environment exception register.

Q7. Our customer wants the offboarding data returned as a CSV file sent by email. Is that acceptable?

No. Email is not a secure transmission channel for personal data. The conformant pattern: a secure file-transfer protocol (SFTP with SSH key-pair authentication; or a managed file-transfer service) with TLS / mTLS; or a download link to a secure portal (the customer logs in with strong authentication; the link expires after a defined period; the download is logged). The return-package is encrypted (with the customer's public key or a mutually-agreed encryption mechanism). The CSV format is acceptable for structured data; the encryption and the channel are the critical dimensions.

Q8. We have a sub-processor that processes data for our customers. What transmission controls apply?

Every transmission flow to and from a sub-processor is in scope under A.2.4.4. The conformant pattern: mTLS (both parties authenticated through X.509 certificates); documented in the transmission-flow inventory; the API authentication discipline documented; the cross-border analysis documented if the sub-processor is in a different jurisdiction. The sub-processor engagement under A.2.5.8 triggers the transmission-flow inventory update; the offboarding procedure extends to the sub-processor (the controller's instruction to delete flows downstream).

Q9. How do we accommodate the Consent Manager?

The Consent Manager (DPDP section 2(1)(g)) is the Indian-native registered, interoperable, principal-side intermediary through which a Data Principal gives, manages, reviews and withdraws consent. A withdrawal initiated through the Consent Manager flows to the controller (the Data Fiduciary) and from the controller to you (the processor). The processor's principal-request workflow must accommodate Consent Manager-initiated withdrawals, the intake channel ingests the controller's instruction (which references the Consent Manager event); the erasure-on-instruction procedure fires; the audit trail captures the Consent Manager event reference. The integration is at the early-adopter stage in mid-2026; processors building today should design the principal-request workflow to accommodate the Consent Manager integration as the ecosystem goes live.

Q10. How do we handle the 48-hour pre-erasure notice under DPDP Rules 2025?

The 48-hour pre-erasure notice is the controller's duty (the controller notifies the principal 48 hours before the erasure). The processor's role: do not execute the erasure until the controller's notice period ends. The conformant pattern: the controller's instruction to the processor includes the notice-period end date (the date after which the erasure may proceed); the processor's erasure workflow is scheduled for that date; the erasure is not executed before the date. If the controller instructs immediate erasure, the processor should remind the controller of the 48-hour notice obligation and confirm in writing before proceeding.

Q11. We received an instruction from a controller to ignore a principal's erasure request. What do we do?

Refuse. The instruction is an A.2.3.2 infringement and an A.2.2.5 infringement. The processor's role is to support the controller's rights operation (A.2.3.2), not to help the controller infringe it. The refusal follows the A.2.2.5 refusal pathway: the DPO documents the instruction; the senior management is informed; the refusal is communicated to the controller in writing, with a reminder of the controller's obligations and the processor's duties. If the controller insists, the processor may need to escalate to the regulator or to terminate the engagement (the DPA's termination right for unlawful instructions).

Q12. How long should we retain the principal-request audit trail?

The principal-request audit trail should be retained for the period the processor may need to produce it, typically the limitation period for contractual claims (3 years under the Indian Limitation Act, 1963, for civil claims; longer for specialised categories) plus a safety margin. The audit trail is itself documented information under Clause 7.5; the retention is governed by the processor's documented information retention schedule.

Q13. We are a startup processor with five customers and no formal principal-request procedure. Where do we start?

Start with the Singahi Processor Privacy-by-Design and Principal-Cooperation Policy (toolkit doc 01). Build the Principal-Request Handling Procedure (toolkit doc 02, Part A) with the dedicated intake channel (a structured email inbox is sufficient for five customers). Build the Temporary-File Hygiene Standard (toolkit doc 02, Part B) and inventory the temp-file locations. Build the End-of-Services Data Return or Destruction Procedure (toolkit doc 03). Build the Transmission Controls Checklist (toolkit doc 04).

Q14. We have a customer that processes children's data (an edtech). How does DPDP section 9 affect our A.2.3 / A.2.4 stack?

The customer's section 9 obligations flow through the A.2.2.2 DPA to you. Your principal-request workflow must accommodate the verifiable-parental-consent overlay (a parent or guardian may file the request on behalf of the child); your temp-file hygiene must not retain children's behavioural data beyond the purpose; your offboarding must reflect the children's-data retention limits; your transmission flows must respect the heightened sensitivity. The 48-hour pre-erasure notice applies to the child's parent or guardian.

Q15. How often should we drill the breach-cooperation procedure?

Annually at minimum. For high-risk processors (BFSI, healthcare, sensitive-data processors, processors serving SDFs), semi-annually. The drill traces the dual-clock pattern (DPDP 72-hour handoff to the controller; CERT-In 6-hour India-ICT-system report). The drill report documents the lessons learned; the gaps are closed before the next drill. The drill is the canonical test of the breach-cooperation procedure's operational reality.

Industry-Specific Requirements

BFSI (processors serving banks, NBFCs, insurers)

BFSI is the most prescriptively regulated Indian sector for processor relationships, and the A.2.3 / A.2.4 family has a strong BFSI overlay. The load-bearing instruments: RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025); RBI NBFC Managing Risks in Outsourcing Directions, 2025; the SEBI CSCRF (20 August 2024) for SEBI-regulated intermediary customers; the IRDAI Information and Cyber Security Guidelines (24 April 2023) for insurer customers; the RBI Storage of Payment System Data (6 April 2018) for payment-system data.

A.2.3 / A.2.4 emphasis for BFSI processors. The principal-request SLA is typically tighter (the BFSI customer's regulator-facing timeline is tighter); the principal-request workflow must accommodate the RBI's grievance-redressal expectations for the bank's customers. The temp-file hygiene must reflect the BFSI data-classification discipline (the RBI's'sensitive personal data' categories). The offboarding procedure must produce the destruction certificates the bank's regulator expects; the post-termination retention scope must accommodate the RBI's record-retention rules. The transmission controls must meet the RBI's data-locality and security expectations (the in-India region for payment-system data); the cross-border transmission analysis must accommodate the DPDP section 16 negative list and the sector-specific restrictions. The breach-cooperation drill must trace the dual-clock pattern (DPDP 72-hour; CERT-In 6-hour) plus the sector-regulator clocks (RBI; SEBI; IRDAI).

Healthcare (processors serving hospitals, insurers, telemedicine platforms)

Healthcare data is sensitive (DPDP Rules' sensitive-PDP categories; GDPR Article 9 special categories). The A.2.3 / A.2.4 stack for healthcare processors has heightened sensitivity throughout.

A.2.3 / A.2.4 emphasis for healthcare processors. The principal-request workflow must accommodate the heightened sensitivity (the patient's medical records; the prescription history; the telemedicine transcripts). The temp-file hygiene is heightened (health-data leaks are high-impact; the developer-environment mirrors of health data are the highest-risk pattern). The offboarding must reflect the clinical-record retention rules (typically 5 to 7 years for adult patients; longer for minors). The transmission controls must use mTLS for high-sensitivity flows (the telemedicine video stream; the prescription-data flow). The breach-cooperation drill must trace the healthcare-specific notification patterns. For US-healthcare customers, the customer agreement may need to reflect the HIPAA Business Associate Agreement pattern, the processor's principal-cooperation must accommodate the HIPAA rights set.

IT-ITeS and SaaS

IT-ITeS and SaaS companies typically operate across multiple jurisdictions (DPDP, GDPR, US-state, sectoral) and act as processors for diverse customer portfolios. The A.2.3 / A.2.4 stack for the SaaS processor is the canonical illustrative scenario (Section 15).

A.2.3 / A.2.4 emphasis for IT-ITeS and SaaS. Multi-jurisdiction principal-request SLA regime (DPDP, GDPR, US-state, sectoral); the temp-file estate is diverse (developer environments; BI-tool extracts; shared BPO delivery centres for ITeS); the offboarding regime is multi-jurisdiction (the data may need to be returned to the controller in the EU, the US, India, simultaneously); the transmission flows cross borders; the Consent Manager integration as the Indian ecosystem goes live.

E-commerce enablers (logistics processors, payment processors, recommendation-engine processors)

E-commerce enablers typically operate as processors to multiple e-commerce platforms. The data is high-volume; the cross-border dimension is significant (international shipping; cross-border payments).

A.2.3 / A.2.4 emphasis for e-commerce enablers. The principal-request workflow must accommodate the high volume (the automated data-extraction pipeline); the temp-file estate is large (the logistics-tracking events; the payment-transaction logs); the offboarding for a payment processor must reflect the RBI storage-of-payment-data rule; the transmission flows are high-volume and cross-border (the international-shipping flows; the cross-border payment flows). The recommendation-engine processor that determines the targeting may be a joint controller, the A.2.3.2 cooperation analysis may differ.

Edtech processors

Edtech processors serve edtech platforms that may attract users under eighteen (DPDP section 9). The A.2.3 / A.2.4 stack for edtech processors has the children's-data overlay throughout.

A.2.3 / A.2.4 emphasis for edtech processors. The principal-request workflow must accommodate the verifiable-parental-consent overlay (a parent or guardian may file the request on behalf of the child); the temp-file hygiene must not retain children's behavioural data beyond the purpose (the no-behavioural-monitoring prohibition); the offboarding must reflect the children's-data retention limits; the transmission flows must respect the heightened sensitivity. The 48-hour pre-erasure notice applies to the child's parent or guardian.

Manufacturing (IIoT, Industry 4.0 processors)

Manufacturing processors typically serve OEM customers; the data may include operator-identification, shift-rotation, safety-incident records.

A.2.3 / A.2.4 emphasis for manufacturing processors. The long-tail retention dimension (safety and product-liability records may need 10 to 15 years retention) interacts with the post-termination retention scope; the offboarding procedure must accommodate legal-hold overlays. The transmission flows extend across the multi-plant operations (the IIoT data flows; the safety-incident reporting flows). The temp-file estate includes the IIoT-data caches and the safety-incident log dumps. The cross-border dimension for multi-plant operations across jurisdictions (the OEM's plants in multiple countries) requires the cross-border transmission analysis.

Maturity Model

Figure · Tiers

Maturity levels for obligations and a.2.4 privacy by design (remaining)

Level 1, Initial / Ad-hoc

Characteristics. No Processor Privacy-by-Design and Principal-Cooperation Policy. Principal requests land in the Customer Success inbox; no SLA tracking; no audit trail. No temporary-file inventory. No auto-purge. The shared drive accumulates indefinitely. Production data in developer environments. No offboarding procedure. Stop-the-API-calls. No transmission-flow inventory. TLS by default; no mTLS. No breach-cooperation drill.

Typical artefacts. A privacy policy on the website. The Customer Success inbox. The CRM.

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

Level 2, Repeatable / Defined

Characteristics. A documented Processor Privacy-by-Design and Principal-Cooperation Policy. The principal-request procedure drafted. The dedicated intake channel configured (ticketing-tool integration for mid-market; structured email inbox for growing processors). The SLA documented. The temporary-file inventory drafted. The auto-purge configured for the top locations. The offboarding procedure drafted. The transmission-flow inventory drafted. The first breach-cooperation tabletop drill run.

Typical artefacts. The policy; the principal-request procedure; the temporary-file inventory; the offboarding procedure; the transmission-flow inventory; the tabletop drill report.

Level 3, Managed / Measured

Characteristics. The principal-request workflow operational across the customer portfolio. The SLA tracked; the audit trail end-to-end. The temporary-file inventory complete; the auto-purge operational across all locations. The access-control remediation complete. The developer-environment discipline enforced (synthetic data; time-boxed exceptions). The offboarding register maintained; the destruction certificates produced and archived. The cryptographic-erasure pipeline operational. The transmission-flow inventory complete; the TLS / mTLS baseline enforced. The first full breach-cooperation drill run; the dual-clock pattern documented. The fifteen KPIs reporting; the first management-review pack produced.

Typical artefacts. The operational principal-request workflow; the temporary-file inventory (live); the auto-purge configurations; the offboarding register; the destruction certificates; the transmission-flow inventory; the TLS / mTLS configurations; the full drill report; the KPI dashboard; the first internal-audit report.

Level 4, Quantitatively Managed

Characteristics. The principal-request workflow automated (the controller-portal intake; the auto-extraction pipeline). The temporary-file inventory reconciled quarterly through the data-discovery tool; the drift detected and corrected. The offboarding register drilled with the customer-by-customer remediation cycle. The cryptographic-erasure pipeline integrated with the key-management service. The transmission-flow inventory reconciled quarterly through the network-flow analysis; the unencrypted flows auto-detected. The mTLS enforced across all sub-processor flows. The breach-cooperation drill running semi-annually with multi-incident scenarios. The KPI targets consistently met; the management-review pack driving Clause 10.1 improvement. The Consent Manager integration live.

Typical artefacts. The automated principal-request workflow; the data-discovery-driven temp-file reconciliation; the cryptographic-erasure integration; the network-flow analysis reports; the semi-annual drill reports; the Consent Manager integration.

Level 5, Optimising

Characteristics. The A.2.3 / A.2.4 stack is a continuous improvement discipline. The principal-request workflow produces predictive analytics (which customers are likely to file high-volume requests; which principal categories are likely to require complex extraction). The temporary-file hygiene is a zero-trust architecture (per-customer encryption; per-customer access tokens; per-customer audit trails). The offboarding procedure produces predictive analytics (which customers are likely to offboard; which offboardings will be high-complexity). The transmission controls include the zero-trust network architecture (per-flow mTLS; per-flow authentication; the auto-detection of every new flow). The breach-cooperation drill is run quarterly with multi-incident scenarios (a ransomware incident that affects multiple customers simultaneously; a sub-processor breach that cascades). The KPI programme produces predictive analytics.

Typical artefacts. The continuous-improvement log; the predictive-analytics dashboards; the zero-trust architectures; the multi-incident drill reports; the engineering-integration evidence.

Maturity-model quick-reference

Emerging Trends

The DPDP Rules' phased commencement and the A.2.3 / A.2.4 stack

The DPDP Rules 2025 (notified 13 November 2025) phase in through 2026 and 2027. The 48-hour pre-erasure notice, the verifiable-parental-consent mechanism, the SDF DPIP format, the Consent Manager registration conditions, all affect the A.2.3 / A.2.4 stack. Processors that build the stack ahead of the full-enforceability window (estimated May 2027) will have a two-to-three-year advantage over those that retrofit in 2027 and 2028.

The convergence of A.2.3 / A.2.4 with AI governance

The DPDP section 10 algorithmic-fairness overlay (for SDFs) and the broader AI-governance movement are converging with the A.2.3 / A.2.4 stack. The principal-request workflow must accommodate the algorithmic-fairness dimension (a principal may ask for an explanation of an automated decision; the processor's support for the controller's response includes the input-data minimisation and the model-explanation evidence). The temp-file hygiene must address the model-training datasets (the AI/ML model's training data is a temp file that contains personal data; the purge cadence and the access controls apply). The transmission flows include the model-inference API calls (the personal data in the inference request is a transmission flow under A.2.4.4). The emerging practice is to treat AI governance as an extension of A.2.3 / A.2.4, with the algorithmic-fairness review as the AI-specific overlay.

The Consent Manager ecosystem and A.2.3.2

The Consent Manager (DPDP section 2(1)(g)) is the Indian-native construct that, as the ecosystem matures, will integrate with the A.2.3.2 principal-request workflow. A Consent Manager-initiated withdrawal will flow from the principal to the Consent Manager to the controller to the processor; the processor's workflow will ingest the Consent Manager event reference and execute the erasure-on-instruction. The integration is at the early-discussion stage in mid-2026; processors building today should design the principal-request workflow to accommodate the Consent Manager integration as the ecosystem goes live.

The rise of privacy-enhancing technologies (PETs) and the temp-file hygiene

PETs, pseudonymisation, tokenisation, differential privacy, federated learning, homomorphic encryption, synthetic data, are changing the temp-file hygiene discipline. Where the processor can demonstrate that the temp file is truly anonymised (with the anonymisation discipline documented), the A.2.4.2 control may be satisfied with reduced rigour (the data is no longer personal data). The current state of PETs does not reliably achieve anonymisation for high-dimensional behavioural data; the standard temp-file hygiene discipline remains the conformant pattern. As PETs mature, the discipline will narrow.

The integration of A.2.4.3 with the right-to-be-forgotten jurisprudence

The CJEU's right-to-be-forgotten jurisprudence (the Google Spain case; the subsequent clarifications) and the DPDP Act 2023 section 8(7) erasure duty are converging on a more demanding offboarding-and-erasure regime. The processor's A.2.4.3 procedure must accommodate the erasure-on-demand pattern (a principal's erasure request that triggers the controller's instruction to the processor to erase); the propagation of the erasure to the derived datasets; the propagation to the sub-processors; the propagation to the search-engine delisting (where applicable).

The convergence of A.2.4.4 with zero-trust network architectures

Zero-trust network architectures, every flow authenticated, authorised, encrypted; no implicit trust based on network location, are converging with the A.2.4.4 transmission-controls discipline. The zero-trust pattern is the conformant pattern for high-volume, multi-customer, multi-jurisdiction processors; the mTLS-everywhere discipline, the per-flow authentication, and the per-flow audit trail are the operational expressions.

The emergence of post-quantum cryptography and the transmission-controls future

Post-quantum cryptography (the NIST PQC standardisation; the imminent PQ algorithms) is emerging as a future dimension of the transmission-controls discipline. Processors building today should design the TLS / mTLS configurations to be algorithm-agile (the ability to swap to PQ algorithms when the standards mature). The Indian ecosystem, CERT-In's PQ guidance; the Bureau of Indian Standards' PQ work; the hyperscalers' PQ-enabled India regions, is at the early stage.

The integration of A.2.4.3 with the cyber-insurance market

The cyber-insurance market in India is maturing; the cyber-insurance underwriting increasingly requires the processor to demonstrate the A.2.4.3 offboarding procedure (the destruction-with-certificate workflow; the post-termination retention scope) and the breach-cooperation drill. The processor that can produce the A.2.4.3 evidence base is the processor that obtains favourable cyber-insurance terms.

References and Further Reading

Standards and regulations

• ISO/IEC 27701:2025, Privacy information management system, Requirements and guidance (published 14 October 2025).
• ISO/IEC 27001:2022, Information security management systems, Requirements.
• ISO/IEC 27002:2022, Information security controls (controls 5.34 PII protection; 8.10 information deletion; 8.24 cryptography; 8.16 monitoring activities; 7.14 secure disposal or re-use of equipment).
• ISO/IEC 27018:2019, Code of practice for protection of PII in public clouds acting as PII processor (clause 9 sub-contractors; clause 10 cross-border; clause 11 data return/destruction).
• 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 27706:2025, PIMS certification-scheme competence (Ed 1, October 2025).
• 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 and 72A. Source: indiacode.nic.in.
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (notified 11 April 2011).
• CERT-In Directions No. 20(3)/2022-CERT-In (28 April 2022) under section 70B(6) of the IT Act, 2000. Source: cert-in.org.in.
• RBI, RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025). Source: rbi.org.in.
• RBI, RBI NBFC Managing Risks in Outsourcing Directions, 2025. Source: rbi.org.in.
• RBI, Storage of Payment System Data, RBI circular DPSS.CO.OD.No.1098/06.08.005/2017-18 (6 April 2018). Source: rbi.org.in.
• 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.
• IRDAI, Information and Cyber Security Guidelines, 2023 (24 April 2023). Source: irdai.gov.in.
• The Limitation Act, 1963 (Act No. 36 of 1963).

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).
• Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1 (26 September 2018, five-judge Bench).
• 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).
• Google Spain SL v. Agencia Española de Protección de Datos (AEPD), Case C-131/12, EU:C:2014:317 (Court of Justice of the European Union, Grand Chamber, 13 May 2014), the right-to-be-forgotten lineage.

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(3)(e) (cooperation on DSARs); Article 28(3)(f) (breach cooperation); Article 28(3)(g) (end-of-services deletion or return); Article 5(1)(e) (storage limitation); Article 25 (data protection by design); Article 32 (security of processing); Articles 15 to 22 (rights); Article 33 (breach, 72 hours).
• Commission Implementing Decision (EU) 2021/914 of 4 June 2021, modernised Standard Contractual Clauses.
• 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.), effective 1 January 2023.
• Colorado Privacy Act (C.R.S. § 6-1-1301), effective 1 July 2023.
• Brazil, LGPD (Lei nº 13.709/2018), Article 18 (rights); Article 39 (operator duties).
• China, PIPL, Article 21 (entrustment agreement); Article 45 (rights).
• Singapore, PDPA 2012 (No. 26 of 2012), section 22 (access and correction).
• Canada, PIPEDA (S.C. 2000, c. 5), Schedule 1 Principle 4.9 (individual access).
• Australia, Privacy Act 1988; Australian Privacy Principles.
• UAE, Federal Decree-Law No. 45 of 2021 (PDPL).
• Saudi Arabia, PDPL (Royal Decree M/19).
• South Africa, POPIA (Act 4 of 2013).

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. Communicate-P (data-review); Control-P (data-processing management); Protect-P (data security).
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (TSC 2017; 2022 Points of Focus update). The Privacy criteria: P4.0 (Use, retention and disposal), P5.0 (Access), P6.0 (Disclosure and notification).
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor; Guidelines 9/2022 on personal data breach notification; Recommendations 01/2020 on supplementary measures.

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.