ISO 27701 A.2.2: Conditions for Collection and Processing (Remaining)

Quick Reference (60 Seconds)

If you only read one thing: the A.2.2 family is where the processor's privacy claim moves from a slogan to a defensible posture. An A.2.2-conformant processor is one in which every controller-customer has a written DPA with the Article 28(3) mandatory terms in place; every customer's purposes are documented in a register that the operational pipelines reconcile with; the processor's own marketing or analytics use of customer data is gated by a documented prior-authorisation workflow; the controller-customer has confirmed in writing that its notices, consents, lawful bases and rights-handling are in place; and the processor maintains a current record of processing activities (ROPA) that can be produced to any controller-customer, certification auditor or regulator within hours. The certification auditor picks a recent customer onboarding and walks the full A.2.2 stack, the signed DPA, the purposes register entry, the marketing-use attestation, the customer-obligations confirmation, the ROPA entry, and traces each into the operational pipeline. The Data Protection Board of India will, after an incident at a controller-customer or after a principal complaint, ask whether the processor had a written agreement that flowed the section 8 obligations downstream, whether the processor processed within the documented purposes, whether the processor used the customer's data for its own marketing without authorisation, and whether the processor maintained the records that would let the investigation establish what was processed and why. Get A.2.2 wrong, no DPA, no purposes register, undocumented marketing use, no obligations confirmation, no ROPA, and the processor's broader privacy claim is unsupported by the contractual and record-keeping evidence that 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.2.2, A.2.2.3, A.2.2.4, A.2.2.6 and A.2.2.7 ask PII processors to put in place a written customer agreement with each controller-customer that records what the processor is engaged to do, the purposes, the customer's instructions, the security duties, the sub-processor terms, the breach-handoff and the audit/cooperation duties (A.2.2.2); to process the controller's personal data only for the purposes the controller has documented and not for the processor's own purposes (A.2.2.3); to not use the controller's personal data for the processor's own marketing or advertising without first establishing that the appropriate PII principal's prior consent was obtained (A.2.2.4); to provide the controller-customer with the information it needs to demonstrate compliance with its own obligations, including whether and how the processor allows for and contributes to audits conducted by the customer or the customer's mandated auditor (A.2.2.6); and to maintain records of the processing activities performed on behalf of each controller-customer, a processor-side record of processing activities (A.2.2.7).

The family operates at three levels simultaneously. The first is the contractual level (A.2.2.2, the data-processing agreement that defines the relationship). The second is the operational level, the purposes discipline (A.2.2.3), the marketing-use prohibition (A.2.2.4) and the customer-obligations confirmation (A.2.2.6) that govern the running of the relationship. The third is the evidentiary level (A.2.2.7, the records that prove the other four are working). A processor that has a strong DPA but no operational discipline has a paper defence; a processor that has operational discipline but a weak DPA has no enforceable reference point against which to assess a customer instruction; a processor that has both but no records cannot evidence either to the auditor or the regulator. The three levels together form the conditions stack on which the A.2.2.5 infringing-instruction gate runs.

The lineage, 2019 to 2025

The five controls have clean ancestors in the 2019 edition. Under 27701:2019, the processor-side conditions controls lived in clause 8 (the processor controls), at 8.2.1 to 8.2.4, the relationships-and-purposes block. The 2025 consolidation regroups them inside the A.2.2 theme of Table A.2 as controls A.2.2.2 to A.2.2.7 (the ".1" position in each family is reserved for the objective statement, which is why the controls start at .2, the same pattern runs through A.1.2, A.1.3, A.1.4, A.1.5, A.2.3, A.2.4 and A.2.5). 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.2.x guidance is now an audit-testable benchmark. Auditors test against B.2.2.x explicitly; an A.2.2.x audit that does not also walk through the B.2.2.x guidance is incomplete. The pre-2019 framing of "have a DPA on file" is no longer sufficient; the processor must show the operational discipline behind the DPA, the purposes register, the marketing-use authorisations, the obligations confirmations, the ROPA.

The B.2.2.x normative guidance (the 2025 edition's load-bearing change for this family) explains how a processor should structure the customer-agreement regime (B.2.2.2, the DPA content, the change-control process, the customer-portfolio governance); the purposes discipline (B.2.2.3, the per-customer purposes register, the pipeline reconciliation, the compatible-secondary-purpose test where the controller authorises one); the marketing-use prohibition (B.2.2.4, the prior-authorisation workflow, the Article 28(10) status-drift register); the customer-obligations confirmation (B.2.2.6, what the processor asks the controller to confirm, the renewal cadence, the escalation if the controller cannot confirm); and the processing records (B.2.2.7, the processor ROPA, the reconciliation cadence, the production-on-request timeline). Auditors now test against these guidance points; the family's evidence base is no longer just the contract but the documented operational discipline.

The customer agreement as the contractual foundation (A.2.2.2)

A.2.2.2 is the family's contractual foundation. The processor must put in place, and be able to evidence, a written agreement with each controller-customer that records the terms on which the processor processes personal data on the controller's behalf. GDPR Article 28(3) sets the mandatory content of the DPA: the subject-matter and duration of the processing; the nature and purpose of the processing; the type of personal data and the categories of principals; and the obligations and rights of the controller. ISO/IEC 27701:2025 control A.2.2.2 asks the processor to maintain this agreement as the foundation of the processing relationship. The DPDP Act 2023 does not prescribe the DPA's content in the same granular detail, but the section 8 flow-through (the fiduciary's obligations that propagate through the processor agreement) and the section 2(1)(k) functional test ("on behalf of") depend on the agreement being in place and being honoured.

The customer agreement must, at minimum, set out: (i) the subject-matter, what processing the processor is engaged to perform; (ii) the duration, the term of the engagement and the post-termination data-return or data-destruction duties; (iii) the nature and purpose, the categories of processing operations; (iv) the type of personal data, the data categories the processor will handle; (v) the categories of principals, the customer's employees, customers, patients, users, etc.; (vi) the obligations and rights of the controller, what the controller may instruct, what the controller must confirm, what the controller's audit and inspection rights are; (vii) the documented-instructions regime, how the controller gives instructions (the A.2.2.5 intake channel); (viii) the security schedule, the security measures the processor implements (the Article 32 / DPDP section 8(5) content); (ix) the sub-processor schedule, the sub-processors the processor may engage and the change-notification procedure (A.2.5.7 to A.2.5.9); (x) the cross-border transfer schedule, the destinations and the transfer mechanisms (A.2.5.2 to A.2.5.6); (xi) the breach-handoff clause, the processor's duty to notify the controller of a personal-data breach within an agreed timeline (the controller then notifies the DPBI within 72 hours under DPDP Rules 2025 Rule 7); (xii) the audit-and-inspection clause, the controller's right to audit, the third-party audit rights, the certification evidence the processor provides; (xiii) the return-or-destruction clause, what happens to the data at end of the engagement (A.2.4.3); (xiv) the indemnity and liability clauses, the financial consequences of a processor breach.

A.2.2.2 is therefore not a single contract clause but an entire agreement schedule that anchors the A.2.2 family and feeds the A.2.5 sub-processor chain. The Singahi Customer-DPA Master Template (toolkit doc 01) operationalises this and the per-customer DPA register (toolkit doc 02) records each active customer's DPA content.

The purposes discipline (A.2.2.3)

A.2.2.3 narrows the processor's processing to the controller's documented purposes. The processor shall not process the controller's personal data for purposes other than those documented in the customer agreement (and any compatible secondary purposes the controller has authorised in writing). This is the processor-side mirror of the controller's A.1.2.2 (identify and document purpose) and the purpose-limitation principle in GDPR Article 5(1)(b) and DPDP Act 2023 section 6.

The operational implications are non-trivial. A processor typically runs shared infrastructure (a multi-tenant SaaS platform; a shared analytics warehouse; a shared BPO delivery centre) across multiple controller-customers. Each customer's data must flow only through the pipelines that customer's purposes authorise. The processor's pipeline architecture must therefore enforce per-customer purposes isolation, a discipline that touches the data pipeline, the access controls, the analytics warehouse, the AI/ML feature store, the developer environments, the backup and the logging. The Singahi Purposes-Limitation Register (toolkit doc 02) is the artefact that records each customer's authorised purposes; the per-pipeline reconciliation is the operational evidence that the register is honoured.

The compatible-secondary-purpose test (where the controller authorises the processor to use the data for a purpose compatible with the original) is narrow. The marquee compatible secondary purpose is the processor's own product-improvement work that uses customer data with the controller's consent, but this is the A.2.2.4 marketing-and-advertising-use control's territory, and the Article 28(10) status-drift trap (Section 2.7 below) is the load-bearing risk.

The marketing-and-advertising-use prohibition (A.2.2.4)

A.2.2.4 is the family's bright-line rule. The processor shall not use the controller's personal data for the processor's own marketing or advertising purposes unless it has first established that prior consent was obtained from the appropriate PII principal. Note precisely where the standard sets the bar: the test is the principal's consent, not the controller-customer's sign-off. The controller's written authorisation is normally necessary as a contractual matter, but on its own it does not satisfy A.2.2.4, a processor that markets on the strength of a customer's permission alone, with no principal-level consent behind it, still fails the control. The control is the marquee A.2.2 anti-pattern: the analytics vendor that uses customer data to train a benchmarking product it sells to other customers; the BPO that uses one customer's data to refine a service it sells to another customer; the SaaS provider that uses customer contact data for its own marketing campaigns; the cloud reseller that uses customer user-behaviour data for its own product recommendations.

The marketing-use prohibition is load-bearing because it is the cleanest trigger of the GDPR Article 28(10) controller-status-drift rule. Article 28(10) provides that where a processor processes personal data for purposes other than those instructed by the controller, the processor is treated as a controller in respect of that processing, and inherits the entire controller obligation set (lawful basis, notice, consent, rights, DPIA, records, security, breach notification, the controller side of Annex A.1). The marketing-use pattern is the textbook Article 28(10) trigger: the processor has gone beyond the controller's instructions and processed for its own purposes. A processor that complies with A.2.2.4, by establishing that the appropriate PII principal's prior consent was obtained, and by securing the controller's authorisation as a contractual matter, keeps itself on the processor side of the line; a processor that ignores A.2.2.4 drifts into controller status and inherits the controller's regulatory exposure.

In India the DPDP equivalent is less explicit but functionally parallel. The Data Processor definition in section 2(1)(k) is functional, the processor is a processor only while it processes "on behalf of" the Data Fiduciary. A processor that processes for its own marketing or advertising has lost the "on behalf of" character; the DPDP Act does not expressly reclassify the processor as a fiduciary for that processing, but the processor loses the contractual shield that protects it from fiduciary liability, and the original controller-customer may have a contractual indemnity claim and a tortious exposure if the controller's principals are harmed. The Article 28(10) status-drift register (toolkit doc 09, Part B) documents the processor's internal analysis of every processing activity where the status question may arise, the marginal cases (the processor's own analytics on aggregated customer data; the processor's troubleshooting logs that may contain personal data; the processor's model-training on customer data with the controller's consent but for the processor's own benefit).

The customer-obligations confirmation (A.2.2.6)

A.2.2.6 is the processor's "what we need from the controller" control. The processor cannot comply with its own obligations under the agreement and the law unless the controller-customer has done certain things on its side: served the privacy notices to its principals; captured valid consent (or identified another lawful basis) for the processing the processor will perform; identified its retention rules; stood up its rights-handling process so the processor's help with principal requests (under A.2.3.2) is workable; given the processor the documented instructions for the processing. A.2.2.6 asks the processor to require the controller to confirm these things, to make the confirmation a condition of onboarding (or renewal), and to escalate where the confirmation is inadequate.

The Customer-Obligations Confirmation Form (toolkit doc 04) is the artefact. The processor asks each controller-customer to confirm, at minimum: (i) the principal categories on whose data the processor will process; (ii) the personal-data categories the controller will provide to the processor; (iii) the notices the controller has served on its principals that disclose the processor's involvement (and the controller's privacy-policy URL); (iv) the consent records (or other lawful bases) the controller holds for the processing; (v) the controller's documented instructions for the processing; (vi) the controller's retention rules; (vii) the controller's rights-handling process and the SLA for forwarding principal requests to the processor; (viii) the controller's sector-law duties (where the controller is a regulated entity, RBI, SEBI, IRDAI); (ix) the controller's cross-border transfer analysis (where the controller's data will cross borders via the processor); (x) the controller's breach-notification timeline (the timeline within which the processor must hand off breaches to the controller, so the controller can meet the DPDP 72-hour or GDPR 72-hour deadline).

The confirmation is renewed annually (or on material change to the processing). A controller-customer that cannot or will not provide the confirmation is a customer the processor should not onboard (or should not renew), the A.2.2.6 escalation mirrors the A.2.2.5 refusal: the processor's senior management makes the commercial decision to refuse the customer where the confirmation is inadequate. The confirmation is the processor's evidence that the controller is fit to instruct; without it, the processor's compliance with its own downstream duties (the security schedule, the breach-handoff, the rights-handling support) is not operationally possible.

The records-of-processing-activities discipline (A.2.2.7)

A.2.2.7 is the family's evidentiary control. The processor shall maintain records of the processing activities performed on behalf of each controller-customer, a processor-side record of processing activities that is the GDPR Article 30(2) analogue. The records are the audit object that proves the other four controls are working: the DPA (A.2.2.2) is the contract; the purposes register (A.2.2.3) is the purposes dimension; the marketing-use attestation (A.2.2.4) is the secondary-use dimension; the obligations confirmation (A.2.2.6) is the controller-fitness dimension; the records (A.2.2.7) are the per-customer, per-processing-activity evidence base that ties it all together.

The processor's ROPA must, at minimum, record for each processing activity: (i) the controller-customer (the entity on whose behalf the processing is performed); (ii) the processing purposes (cross-referenced to the A.2.2.3 purposes register); (iii) the categories of personal data processed; (iv) the categories of principals (the controller's customers, employees, patients, etc.); (v) the recipients of the personal data (sub-processors under A.2.5.7 to A.2.5.9; third parties under A.2.5.4 to A.2.5.6; the controller itself for data returns); (vi) the cross-border transfers (the destinations, the transfer mechanisms, cross-referenced to A.2.5.2); (vii) the retention rules (where the controller sets the retention, the controller's rules; where the processor manages retention on the controller's behalf, the processor's retention schedule); (viii) the security measures implemented (cross-referenced to the DPA's security schedule); (ix) the sub-processor chain (cross-referenced to the A.2.5.7/.5.8/.5.9 controls); (x) the data-flow description (the systems the data passes through; the data stores; the access controls).

The records must be maintained in writing (including electronic form), made available to the controller-customer on request, and produced to the supervisory authority (the DPBI in India; the relevant DPA in the EU) on demand. The processor ROPA is not a static artefact, it is updated as the processing changes (new sub-processors; new transfer destinations; new purposes authorised by the controller under A.2.2.3) and reconciled at least quarterly with the operational reality.

Demarcations: A.2.2 vs A.2.2.5 / Clause 8.1 / Clause 7.5; what is NOT required

Four demarcations matter for the family.

A.2.2.2 to .2.7 (except .5) vs A.2.2.5. A.2.2.5 (Infringing Instruction) governs the operational handling of individual instructions, what the processor does when a controller instruction arrives. A.2.2.2 to .2.4, .2.6 and .2.7 govern the contractual and record-keeping scaffolding on which the A.2.2.5 gate runs. The two are sequential and complementary: the A.2.2.2 DPA sets the rules; the A.2.2.5 gate is the runtime enforcement against each instruction; the A.2.2.7 ROPA records what was actually processed. A processor that has a strong DPA but no A.2.2.5 process has the rules but not the enforcement; a processor that has a strong A.2.2.5 process but a weak DPA has no enforceable reference point.

A.2.2 vs Clause 8.1. Clause 8.1 governs the PIMS-level operational planning, the processor's overall control of its processes, the criteria for control, the implementation. A.2.2 governs a specific operational dimension: the contractual and record-keeping conditions for processing on behalf of controller-customers. The two interlock: Clause 8.1 is the framework within which the A.2.2 stack sits.

A.2.2.7 vs Clause 7.5. Clause 7.5 governs documented information at the PIMS level (the PIMS manuals, policies, procedures, records the processor maintains as part of its management system). A.2.2.7 governs a specific category of documented information: the records of processing activities performed for controller-customers. The two overlap (the processor ROPA is documented information under Clause 7.5) but A.2.2.7 is more specific (it prescribes the content, the maintenance, the production-on-request).

What A.2.2 does NOT require. It does not require the processor to write the controller's privacy notices or to obtain the controller's principal consents (those are controller-side duties under A.1.2.3 and A.1.2.5; A.2.2.6 requires the controller to confirm they are done, not to delegate them to the processor). It does not require the processor to refuse every customer whose obligations-confirmation has a gap (the processor may onboard with documented conditions and a remediation timeline, with senior-management sign-off). It does not require the processor to obtain the principal's consent directly for the marketing-use authorisation under A.2.2.4 (the processor's duty is to obtain the controller's authorisation; the controller's duty is to ensure it has the principal's consent or another lawful basis, the Article 28(3) chain). It does not require a separate DPA for every customer (the processor's master template, with customer-specific schedules, satisfies A.2.2.2). It does not require the processor ROPA to be in any specific format (the Article 30(2) content is the requirement; the format is the processor's choice, a privacy management platform, a structured document, a database).

What auditors actually check

The certification auditor's A.2.2 family examination has seven predictable moves (the 28-question checklist is in Section 11). First, ask for the Customer-Agreement and Processor-Conditions Policy, does it exist, is it signed off, does it commit to the DPA-master-template discipline, the purposes register, the marketing-use policy, the obligations-confirmation form, the processor ROPA. Second, ask for the per-customer DPA register and sample five to ten customers, for each, walk the Article 28(3) mandatory content (subject-matter, duration, nature/purpose, data types, principal categories, obligations). Third, ask for the Purposes-Limitation Register and reconcile it with the operational pipelines (a customer's data should not flow through a pipeline not listed for that customer). Fourth, ask for the Marketing-and-Advertising-Use Policy and a sample of prior-authorisation records, were any secondary uses authorised in the last 12 months; what was the Article 28(10) status-drift analysis. Fifth, ask for the Customer-Obligations Confirmation and sample five customers, was the confirmation collected at onboarding; was it renewed; what does the processor do where the confirmation is inadequate. Sixth, ask for the Processor ROPA and walk three entries, does the ROPA content match the operational reality; when was it last reconciled. Seventh, trace the A.2.2 stack's integration with the A.2.2.5 instruction-decision log, the A.2.5 sub-processor change notifications, the Clause 9.1 KPI reporting, the stack is not a stand-alone artefact; it feeds the wider PIMS.

Why This Control Family Matters

The processor as the controller's compliance partner

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 conditions theme is the load-bearing one, without a lawful, agreed, properly-instructed processing arrangement, no other processor control matters. And of the conditions-for-processing controls, the five covered in this guide form the contractual and record-keeping scaffolding on which the family's operational gate (A.2.2.5, Infringing Instruction) runs. A processor that cannot produce a written DPA with the Article 28(3) mandatory terms, that cannot show a purposes register reconciled with the operational pipelines, that has no documented marketing-use prior authorisations, that has never collected a customer-obligations confirmation, and that has no processor ROPA, has no defensible privacy position, regardless of how strong its product security is.

This is why the A.2.2 family is the second-most-audited processor theme (after A.2.5, sub-processor chain, which depends on A.2.2.2 being in place). The early GDPR enforcement actions on processor conduct, the regulatory decisions on analytics vendors that processed beyond the controller's purposes; the marketing-technology vendors that used customer data for their own campaigns; the cloud providers that shared customer data across their own service lines, all turned on the absence or the weakness of the A.2.2 stack. In India, the DPDP Act's section 8 flow-through to processors, the RBI IT-outsourcing regime, and the SEBI and IRDAI third-party expectations make the A.2.2 stack the foundational compliance layer for every Indian processor that serves regulated customers.

The Indian regulatory weight

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

The DPDP Act data-processor layer. The DPDP Act's section 2(1)(k) Data Processor definition is functional, the processor is a processor only while it processes "on behalf of" the Data Fiduciary. The processor's protection against being reclassified as a fiduciary (with full section 8 liability) depends on the customer agreement (A.2.2.2) being in place and being honoured. A processor without a written DPA is a processor without the contractual shield; in any dispute with the controller-customer or the DPBI, the processor is at risk of being treated as a fiduciary for the unregulated processing.

The DPDP section 8 flow-through layer. The Data Fiduciary's section 8 obligations flow through the processor agreement to the processor. The processor's failure on A.2.2.3 (processes beyond the documented purposes) or A.2.2.4 (uses customer data for its own marketing without authorisation) propagates back to the fiduciary's penalty exposure (up to two hundred and fifty crore rupees for section 8(5) failure; up to two hundred crore for section 8(6) failure) and forward to the processor's contractual indemnity exposure (the DPA's indemnity clause typically makes the processor liable for the fiduciary's losses caused by the processor's breach). The A.2.2 stack is the gate that prevents the flow-through cascade.

The sectoral outsourcing layer (RBI / SEBI / IRDAI). The Indian sector regulators impose granular processor-side duties on the entities they regulate (the banks, the NBFCs, the SEBI-regulated intermediaries, the insurers) and through them on the processors those entities engage. The RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025) require the bank to ensure that the outsourcing agreement "does not impede the ability of the Reserve Bank to inspect the bank and its service provider" and "does not permit the service provider to further outsource the services without the bank's prior written permission", both of which are A.2.2.2 customer-agreement content that the processor must accept. The RBI NBFC Managing Risks in Outsourcing Directions, 2025 extends similar duties to NBFCs. The SEBI CSCRF (20 August 2024) requires SEBI-regulated entities to impose privacy and security duties on their processors, including the customer-agreement terms. The IRDAI Information and Cyber Security Guidelines (24 April 2023) impose ICT-outsourcing data-protection clauses on insurers' processors. The A.2.2.2 customer agreement is the operational vehicle through which the processor accepts and honours these sector-driven terms.

The constitutional layer (Puttaswamy). The Supreme Court's K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (judgment delivered 24 August 2017 by a nine-judge Bench) declared informational privacy a fundamental right under Articles 14, 19 and 21, and articulated the proportionality test that any limitation of the right must meet. The Aadhaar judgment, Justice K.S. Puttaswamy (Retd.) v. Union of India, (2019) 1 SCC 1 (26 September 2018, five-judge Bench), applied the test and struck down section 57 of the Aadhaar Act as failing it. A processor that processes beyond the documented purposes (A.2.2.3) or uses customer data for its own marketing without authorisation (A.2.2.4) contributes to a proportionality failure at the controller level, the controller's processing became non-proportional in part because the processor went beyond what the controller instructed. The A.2.2 stack is, in contractual and record-keeping terms, the processor's internal proportionality regime, the documented set of conditions that keeps the processor on the lawful side of the line.

The cost of non-compliance

The cost of an A.2.2 family failure breaks down into four bands.

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

Indirect regulatory consequences are larger and slower. An A.2.2 failure (no DPA; no purposes register; undocumented marketing use; no obligations confirmation; no ROPA) cascades through the broader privacy architecture, the infringing-instruction control (A.2.2.5) is undermined (no reference agreement against which to assess an instruction); the obligations-to-principals control (A.2.3.2) is unguarded (the processor cannot help the controller with rights-handling if the controller has not stood up its rights process, the A.2.2.6 confirmation); the sub-processor-chain controls (A.2.5.7 to A.2.5.9) are unmonitored (no DPA schedule to refer to); the security controls (A.3) are inconsistently applied (no security schedule to point to). The A.2.2 stack is the foundational layer; its absence weakens every other processor control.

Commercial cost is significant. The Indian processor market, SaaS vendors, BPO / ITeS providers, analytics vendors, cloud-service resellers, is increasingly differentiated by privacy posture. Enterprise customers (the banks, the insurers, the SEBI-regulated intermediaries, the MNCs operating in India) include A.2.2-style customer-agreement clauses in their standard DPAs and audit the processor's compliance during vendor diligence. The processor that cannot produce a sample DPA, a purposes register, a marketing-use policy, an obligations-confirmation form and a processor ROPA is the processor that loses the procurement. The reputational damage of a public A.2.2 failure (a regulator's order naming the processor; a customer's press release; a news story on a controller-level breach that traces back to a processor's undocumented secondary use of customer data) 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.2 family is not "do we have a DPA with our customers?", most processors have something on paper. 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 signed DPA with the Article 28(3) mandatory content; (b) the per-customer purposes register entry reconciled with the operational pipeline; (c) the marketing-use authorisation or the attestation that no secondary use has been made; (d) the customer-obligations confirmation; (e) the processor ROPA entry?" If the honest answer is "partially" or "no", the processor has an A.2.2 gap regardless of what its privacy policy or its marketing collateral says.

Scope and Applicability

Who the family applies to

Control family A.2.2 sits in Table A.2 of the 2025 Annex A, the PII processor control set. It binds every organisation that acts as a processor (DPDP: Data Processor; GDPR: processor) for at least one controller-customer. Controllers (Table A.1) are bound by the mirror control A.1.2.7 (contracts with PII processors) and by the controller-side instruction discipline (the controller must give lawful instructions; the controller must respond to the processor's clarification requests; the controller must accept the processor's refusals or amend the agreement).

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 customer-engagement lifecycle

A.2.2 applies throughout the customer-engagement lifecycle. Unlike A.2.2.5 (which activates when an individual instruction arrives) or A.2.3.2 (which activates when a principal request is forwarded), the A.2.2 family is always-on, every active controller-customer has a DPA, a purposes register entry, a marketing-use attestation, an obligations confirmation and a ROPA entry throughout the relationship. The lifecycle stages are: (i) pre-sales and vendor diligence (the customer's procurement team audits the processor; the processor provides the DPA master template, the security schedule, the sub-processor list, the certifications); (ii) onboarding (the DPA is negotiated and signed; the purposes register is populated; the marketing-use attestation is taken; the obligations confirmation is collected; the ROPA entry is created); (iii) steady-state operations (the DPA is honoured; the purposes register is reconciled; the marketing-use discipline is enforced; the obligations confirmation is renewed annually; the ROPA is updated); (iv) change management (the customer requests changes to purposes, data categories, sub-processors, transfers, retention, each change is processed through the A.2.2.5 gate and reflected in the A.2.2 stack); (v) offboarding (the data is returned or destroyed per A.2.4.3; the DPA's post-termination clauses survive; the ROPA entry is closed with the offboarding evidence).

What is in scope for the A.2.2 artefacts

The A.2.2 family's artefact set covers every controller-customer the processor serves and every processing activity the processor performs on each customer's behalf. This includes:

• The full customer portfolio, every entity on whose behalf the processor processes personal data (SaaS customers; BPO/ITeS customers; analytics-platform customers; cloud-service customers; white-label/B2B2C partners).
• The full set of processing activities, every distinct set of operations the processor performs on the customer's data (data ingestion; data storage; data processing; data analytics; data transfer to sub-processors; cross-border transfers; data return; data destruction).
• The full sub-processor chain, every sub-processor the processor engages for any customer (the A.2.5.7/.5.8/.5.9 controls operate inside the A.2.2.2 DPA's sub-processor schedule).
• The full cross-border transfer map, every destination the processor sends customer data to (the A.2.5.2/.5.3/.5.4 controls operate inside the A.2.2.2 DPA's transfer schedule).
• The processor's own secondary-use surface, any place where the processor may use customer-derived insights, benchmarks, models or analytics for the processor's own purposes (the A.2.2.4 marketing-use prohibition and the Article 28(10) status-drift register).

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), the processor is a controller for its own data, even while it is a processor for its customers' data. The dual-role discipline is a scoping question (Clause 4.3), not an A.2.2 question.
• Routine operational communications that are not customer instructions (a status update, a query, a routine support interaction). The A.2.2.3 purposes register is not updated for every communication; the A.2.2.5 instruction-decision log distinguishes instructions from operational communications.
• Anonymous data the processor derives from customer data, if the processor has truly anonymised the data (irreversibly prevented re-identification), the A.2.2 family does not apply to the anonymised output. Pseudonymised data is still personal data; the family applies in full. The line between anonymisation and pseudonymisation is documented per processing activity in the Article 28(10) status-drift register.
• Public-sector processor engagements that fall under specific government-contracting regimes, the customer agreement may follow a government-standard template (the GFR, the GeM standard clauses); the A.2.2 family applies in full but the DPA content is constrained by the government's contracting rules.

Applicability by organisation size

Applicability by industry (preview, Section 21 has detail)

• BFSI (processors serving banks/NBFCs/insurers), RBI's outsourcing Directions (2025) and the IRDAI ICT-outsourcing clauses prescribe specific customer-agreement content (RBI inspection rights; sub-outsourcing restrictions; data-locality clauses). The most prescriptive Indian sectoral processor regime.
• Healthcare (processors serving hospitals/insurers/telemedicine), sensitive health data; the customer agreement must reflect the heightened sensitivity; the HIPAA-equivalent discipline for US-healthcare customers (the BA Agreement pattern).
• IT-ITeS and SaaS, multi-jurisdiction customer portfolios; the DPA master template must accommodate DPDP, GDPR, US-state, Brazil LGPD, China PIPL simultaneously; the developer-environment discipline and the multi-tenant isolation are the operational A.2.2.3 challenge.
• E-commerce enablers (logistics, payments, recommendation engines), typically joint-controller or processor relationships with multiple e-commerce platforms; the customer agreement's joint-controller schedule (A.1.2.8-equivalent) and the purposes discipline must be tight.
• Edtech processors, DPDP section 9 dominates where the customer is an edtech serving minors; the processor's customer agreement must reflect the verifiable-parental-consent overlay and the no-behavioural-monitoring and no-targeted-advertising prohibitions.
• Manufacturing (IIoT/Industry 4.0 processors), typically processor relationships with OEM customers; the data may include operator-identification, shift-rotation, safety-incident records; the customer agreement's purposes discipline must bound the processor's use of the IIoT data.

Key Definitions and Terminology

Relationship to Other Clauses and Frameworks

The sibling-control network inside Annex A.2

The A.2.2 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.5, Infringing instruction. The flagship operational control that sits inside this family. A.2.2.2 sets the contractual rules; A.2.2.5 is the runtime enforcement against each instruction. The instruction-decision log (A.2.2.5) references the customer agreement (A.2.2.2) as the reference point against which each instruction is assessed. A processor that has a strong DPA but no instruction process has not satisfied A.2.2.5; a processor that has a strong instruction process but a weak DPA has no enforceable reference point.

A.2.3.2, Comply with obligations to PII principals. The processor's help with the controller-customer's principal-side duties (the controller's access, correction, erasure, objection, portability requests that the processor supports). The help is operationally possible only if the A.2.2.6 customer-obligations confirmation has established that the controller has stood up its rights-handling process. A.2.2.6 and A.2.3.2 are sequentially linked: the confirmation enables the help.

A.2.4.2 / A.2.4.3 / A.2.4.4, Temporary files, return/transfer/disposal, transmission controls. The operational handling that the A.2.2.2 DPA's security schedule governs. The customer agreement defines the security measures; the A.2.4 controls operationalise them on the customer's data. The A.2.4.3 return-or-destruction clause at offboarding is part of the A.2.2.2 DPA.

A.2.5.2 to A.2.5.6, Cross-border transfer. The transfer terms of the A.2.2.2 DPA's transfer schedule. The transfer-basis analysis under A.2.5.2 references the customer's instruction (and the customer's obligations confirmation under A.2.2.6, which includes the controller's transfer analysis).

A.2.5.7 / A.2.5.8 / A.2.5.9, Sub-processor chain. The sub-processor schedule of the A.2.2.2 DPA; the engagement-of-subcontractor procedure (A.2.5.8) and the change-of-subcontractor procedure (A.2.5.9) operate inside the A.2.2.2 framework. The sub-processor disclosure under A.2.5.7 is part of the customer agreement.

A.3, Security controls. The integrity of the customer-agreement register, the obligations-confirmation records, the marketing-use authorisations and the processor ROPA. The A.3 controls (especially A.3.3 policies; A.3.9 access rights; A.3.14 protection against falsification; A.3.25 logging) protect the A.2.2 stack's evidence base.

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

Clause 9.1 / 9.3, Monitoring, measurement, analysis, evaluation; management review. The KPI reporting on the A.2.2 stack (Section 12) feeds the Clause 9.1 monitoring and the Clause 9.3 management review. Trends in DPA coverage, purposes-register reconciliation, marketing-use authorisations, obligations-confirmation renewal and ROPA currency are the A.2.2 KPI set.

Clause 7.5, Documented information. The processor ROPA (A.2.2.7), the customer-agreement register (A.2.2.2), the purposes register (A.2.2.3), the marketing-use authorisations (A.2.2.4) and the obligations confirmations (A.2.2.6) are documented information under Clause 7.5, version-controlled, access-controlled, retention-managed, retrievable.

The controller-side mirror (Annex A.1)

The A.2.2 family has a clean mirror in Annex A.1, the controller-side conditions-for-processing controls. The mirror points:

• A.1.2.7, Contracts with PII processors. The controller-side mirror of A.2.2.2. The controller has a duty to put in place a written DPA with each processor; the processor's A.2.2.2 customer agreement is the same artefact, viewed from the processor side. The two controls meet at the DPA, a single artefact that satisfies both sides.
• A.1.2.2 / A.1.2.3, Identify and document purpose; identify lawful basis. The controller-side mirrors of A.2.2.3. The controller's documented purposes drive the processor's purposes register. The controller's lawful basis drives what the processor may do.
• A.1.2.9, Records related to processing PII (controller ROPA). The controller-side mirror of A.2.2.7. The controller maintains its ROPA; the processor maintains its own ROPA for the processing it performs. The two ROPAs overlap on the controller-processor relationship (the controller's ROPA records the processor as a recipient; the processor's ROPA records the controller as the customer).
• A.1.2.5, Obtain and record consent. The controller's consent records are part of what the A.2.2.6 obligations confirmation asks the controller to confirm. The processor does not capture the principal's consent directly; the processor relies on the controller's confirmation that consent was captured.
• A.1.2.6, Privacy impact assessment (DPIA / DPIP). The controller's DPIA, where the controller is an SDF under DPDP section 10, drives the processor's customer-agreement content (the DPA must reflect the DPIA's recommendations, additional security measures; tighter retention; sub-processor restrictions). The processor's compliance with the A.2.2 stack depends on the controller having done its A.1.2.6 work.

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

The lineage from ISO/IEC 27018:2019

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

• Clause 7, Customer agreement. The cloud PII processor's agreement with the cloud customer (the controller) covers the customer's instructions, the purposes, the security measures, the sub-processor disclosure, the cross-border transfer, the data return and destruction.
• Clause 9, Sub-contractors. The cloud PII processor's sub-processor discipline (the A.2.5.7/.5.8/.5.9 controls operate inside this).
• Clause 10, Cross-border transfer. The cloud PII processor's transfer-discipline framework.
• Clause 11, Data return and destruction. The cloud PII processor's end-of-engagement handling (the A.2.4.3 control).

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

The lineage from GDPR Article 28

GDPR Article 28 is the most-litigated processor regime in the world. Article 28(1) sets the principle (processing by a processor only on the controller's documented instructions). Article 28(2) prohibits the processor from engaging another processor without the controller's prior specific or general written authorisation (the A.2.5.8 control). Article 28(3) sets the mandatory DPA content (the six categories described in Section 2.3). Article 28(4) sets the processor-imposed sub-processor duties (the sub-processor must be bound by the same terms as the processor itself). Article 28(5) permits the adherence to approved codes of conduct (the 27701 PIMS itself is such a code) and certifications. Article 28(6) permits a single DPA template to satisfy multiple controllers. Article 28(7) and (8) deal with DPAs and the supervisory authority. Article 28(9) requires a written record of sub-processors (the A.2.5.7 control). Article 28(10) sets the controller-status-drift rule. 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. The A.2.2 family is the 27701 operationalisation of this converged posture.

Detailed Implementation Guidance, Control by Control

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

A.2.2.2, Customer agreement

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.2.2 asks PII processors to put in place, with each controller-customer, a written agreement that records the terms on which the processor processes personal data on the controller's behalf, including (at minimum) the subject-matter and duration of the processing; the nature and purpose of the processing; the type of personal data and the categories of principals; the obligations and rights of the controller; the documented-instructions regime; the security measures; the sub-processor terms; the cross-border transfer terms; the breach-handoff clause; the audit-and-inspection rights; and the data-return-or-destruction clause.

(b) What it means in practice. Every controller-customer relationship has a written DPA, not a master services agreement that mentions data protection in passing, but a dedicated DPA (or a DPA addendum to the MSA) that records the Article 28(3) mandatory content. The DPA is the foundational artefact of the A.2.2 stack; every other control in the family references it. A processor that has an MSA but no DPA has not satisfied A.2.2.2; a processor that has a DPA but the DPA lacks the mandatory content (or has the content but no operational discipline to honour it) has a paper defence but no operational one.

The DPA must be more than boilerplate. The Article 28(3) mandatory content, subject-matter, duration, nature/purpose, data types, principal categories, obligations/rights, must be populated with customer-specific information. A DPA that says "the processor shall process personal data on the controller's instructions" without recording what personal data, for what purposes, for what duration, with what security measures, is not a conformant DPA. The Singahi Customer-DPA Master Template (toolkit doc 01) provides the structure; the per-customer DPA schedule fills in the customer-specific content.

(c) DPDP and GDPR mapping. DPDP Act 2023 section 2(1)(k) (Data Processor, the functional definition depends on the written agreement being in place); section 8 (the fiduciary's obligations flow through the agreement); section 8(5) (security safeguards, the security schedule of the DPA); section 8(6) (breach notification, the breach-handoff clause); section 8(7) (erasure, the data-return-or-destruction clause). GDPR Article 28(3) (the mandatory DPA content); Article 28(4) (sub-processor terms); Article 28(10) (the controller-status-drift rule, the DPA's purposes clause is the reference point against which status drift is assessed); Article 32 (security, the security schedule); Article 33 (breach, the breach-handoff clause). UK GDPR + DPA 2018 (same as EU GDPR). ISO/IEC 27018:2019 clause 7 (customer agreement in public clouds). ISO/IEC 27002:2022 control 5.20 (security within supplier agreements). NIST Privacy Framework v1.0 Control-P (data-use agreements). SOC 2 Privacy TSC P6.0 (Disclosure and notification) and Common Criteria CC9.2 (vendor oversight). RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025) (the DPA with a bank customer must allow RBI inspection; must restrict sub-outsourcing); RBI NBFC Managing Risks in Outsourcing Directions, 2025; SEBI CSCRF (third-party and outsourcing expectations); IRDAI Information and Cyber Security Guidelines (ICT-outsourcing clauses).

(d) The implementation discipline. Six sub-disciplines drive conformant customer-agreement management:

• DPA master template. A single master template owned by Legal, approved by the DPO, that contains all the Article 28(3) mandatory content, the security schedule, the sub-processor schedule, the transfer schedule, the breach-handoff clause, the audit-and-inspection clause, and the data-return-or-destruction clause. Customer-specific schedules fill in the customer-specific content. The master template is reviewed at least annually; material updates trigger a customer-communication cycle (a side-letter or an amended DPA, depending on the change).
• Per-customer DPA register. A register of every active customer's DPA, the customer name; the DPA execution date; the DPA version; the customer-specific schedule content (purposes, data types, principal categories, retention, sub-processors, transfers); the renewal date (where applicable); the obligations-confirmation reference; the ROPA entry reference. The register is the operational evidence that the DPA master template has been applied across the portfolio.
• DPA gap remediation. For each existing customer whose DPA predates the master template or is missing the Article 28(3) mandatory content, a documented remediation plan, a side-letter or an amended DPA, with a target completion date. The gap remediation is the canonical A.2.2.2 finding-closure evidence.
• DPA change control. Any change to the DPA's content (new purposes; new data categories; new sub-processors; new transfers; new retention) is processed through the A.2.2.5 instruction-decision log and reflected in the per-customer DPA register. A DPA that has been informally amended through operational practice (without a documented side-letter) has drifted; the drift is the canonical A.2.2.2 weakness.
• Sector-specific overlays. For customers in regulated sectors (RBI-regulated banks; SEBI-regulated intermediaries; IRDAI-regulated insurers), the sector-specific clauses (RBI inspection rights; sub-outsourcing restrictions; data-locality) are layered into the DPA. A generic DPA that does not reflect the sector overlay is non-conformant for the regulated customer.
• Customer-portal workflow. For mid-market and enterprise processors, the customer-portal workflow, the customer signs in, fills in the customer-specific schedule, signs the DPA electronically, and the signed DPA is filed in the per-customer DPA register automatically. The workflow is the conformant pattern for high-volume customer portfolios; manual DPA management does not scale.

(e) Audit evidence. (i) The Customer-Agreement Policy (toolkit doc 01); (ii) the DPA Master Template; (iii) the per-customer DPA register; (iv) sample walks of five to ten signed customer DPAs showing the Article 28(3) mandatory content populated with customer-specific information; (v) the DPA gap-remediation plan (where applicable); (vi) the DPA change-control records (cross-referenced to the A.2.2.5 instruction-decision log); (vii) the sector-overlay documentation (where applicable); (viii) the customer-portal workflow configuration (where applicable).

A.2.2.3, Organization's purposes

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.2.3 asks PII processors to process the controller-customer's personal data only for the purposes documented in the customer agreement and not for the processor's own purposes (except where the controller has authorised a compatible secondary purpose in writing).

(b) What it means in practice. The processor operates shared infrastructure, a multi-tenant SaaS platform, a shared analytics warehouse, a shared BPO delivery centre, across multiple controller-customers. Each customer's data must flow only through the pipelines that customer's purposes authorise. The processor's pipeline architecture must therefore enforce per-customer purposes isolation, a discipline that touches the data pipeline, the access controls, the analytics warehouse, the AI/ML feature store, the developer environments, the backup and the logging. The purposes register is the artefact that records each customer's authorised purposes; the per-pipeline reconciliation is the operational evidence that the register is honoured.

The marquee A.2.2.3 failure patterns are: (i) the SaaS analytics platform that ingests customer A's event data into a shared feature store that is also used to train a model deployed for customer B (cross-customer data leakage, the customer A purposes did not authorise the model-training use, even if the model itself is anonymised); (ii) the BPO that uses one customer's call-centre transcripts to refine its sentiment-analysis service sold to other customers (customer-data reuse for the processor's own product); (iii) the cloud reseller that uses customer user-behaviour data to optimise its own infrastructure-placement recommendations (the processor's own operational analytics, which may be compatible or not depending on the customer's purposes register entry).

(c) DPDP and GDPR mapping. DPDP Act 2023 section 6 (purpose-limitation, consent tied to specified purpose; processing limited to that purpose). Section 8 (the fiduciary's obligations flow through the agreement; the processor's purposes are bounded by the fiduciary's instructions). GDPR Article 5(1)(b) (purpose limitation). Article 28(3) (the documented-instructions clause). Article 28(10) (the controller-status-drift rule, processing beyond the documented purposes triggers Article 28(10)). ISO/IEC 27018:2019 clause 7 (the cloud processor processes only on the customer's instructions). ISO/IEC 29100:2011 Purpose Legitimacy and Specification principle. 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 purposes-limitation:

• Per-customer purposes register. For each customer, a documented register of the purposes for which the processor may process the customer's personal data. The register is populated at onboarding (from the DPA's nature-and-purpose clause) and updated through the change-control process (a new purpose is added only through an A.2.2.5 instruction-decision). The register is the A.2.2.3 artefact and the audit's primary walk-through document.
• Pipeline-to-register reconciliation. For each processing pipeline (the ingestion pipeline; the storage layer; the analytics warehouse; the AI/ML feature store; the sub-processor outbound feeds; the cross-border transfer flows; the data-return pipeline), the live data flows are reconciled against the per-customer purposes register. A pipeline that processes customer data for an undocumented purpose fails A.2.2.3.
• Multi-tenant isolation. The SaaS/BPO infrastructure enforces per-customer isolation, the customer's data is logically (and where required, physically) isolated from other customers' data; the access controls prevent cross-customer data access; the analytics warehouse has per-customer partitions; the AI/ML feature store has per-customer training datasets (or, where shared training is permitted, the customer's purposes register entry documents the cross-customer use).
• Compatible-secondary-purpose analysis. Where the processor proposes to use customer data for a purpose compatible with the original (the processor's own product-improvement work that uses customer data with the controller's consent), the compatible-secondary-purpose analysis is run and documented. The analysis tests: would the controller reasonably expect the secondary use? is the secondary use compatible with the original purpose? is the secondary use sensitive in a way the original was not? Where compatibility fails, the secondary use is the A.2.2.4 marketing-and-advertising-use control's territory, and the prior-authorisation workflow (A.2.2.4) governs.
• Out-of-scope discipline. A "do not use for" list per customer, marketing, advertising, model-training for own benefit, cross-customer benchmarking, processor's own operational analytics beyond the agreed scope, drives the design-stage and operational-stage gates.
• Purposes-register reconciliation cadence. Quarterly reconciliation of the per-customer purposes register against the operational pipelines (the live data flows). Drift (a pipeline running on an undocumented purpose) is the canonical A.2.2.3 finding; the reconciliation closes the loop.

(e) Audit evidence. (i) The per-customer purposes register; (ii) the pipeline-to-register reconciliation reports; (iii) the multi-tenant isolation configuration (logical-separation evidence; access-control matrix; analytics-warehouse partitioning); (iv) the compatible-secondary-purpose analysis files (where applicable); (v) the out-of-scope lists per customer; (vi) the quarterly reconciliation cadence evidence.

A.2.2.4, Marketing and advertising use

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.2.4 asks PII processors to not use the controller-customer's personal data for the processor's own marketing or advertising purposes without first establishing that the appropriate PII principal's prior consent was obtained. Where the controller authorises the use, the controller must have a lawful basis (consent or another ground) for the secondary use; the processor relies on the controller's authorisation as the Article 28(3) instruction.

(b) What it means in practice. The marketing-use prohibition is the family's bright-line rule. The processor's own marketing, advertising, product-recommendation, benchmarking-product, model-training-for-own-benefit, or service-refinement-for-other-customers uses of customer data are all within the prohibition unless the controller has authorised the specific use. The processor's own operational uses that are necessary to deliver the agreed service (logging, monitoring, performance analytics, security analytics) are not marketing/advertising uses and are within the agreed purposes, these are compatible with the original purpose and do not require separate authorisation. The line between the two, the processor's own operational uses (permitted) and the processor's own marketing/advertising uses (prohibited without authorisation), is documented per processing activity in the Article 28(10) status-drift register.

The marquee A.2.2.4 anti-patterns are: (i) the SaaS provider that uses customer contact data for its own marketing campaigns ("we'd like to send you information about our premium tier", sent to the controller's employees using the controller's data); (ii) the analytics vendor that uses customer data to train a benchmarking product it sells to other customers ("industry benchmarks based on anonymised data from leading companies", built on customer data the customer did not authorise for benchmarking); (iii) the cloud provider that uses customer user-behaviour data to drive its own product recommendations across the customer base; (iv) the BPO that uses one customer's call recordings to refine its own service quality, marketed to other customers as a competitive differentiator.

The marketing-use prohibition is load-bearing because it is the cleanest trigger of the GDPR Article 28(10) controller-status-drift rule. Article 28(10) provides that where a processor processes personal data for purposes other than those instructed by the controller, the processor is treated as a controller in respect of that processing. The marketing-use pattern is the textbook Article 28(10) trigger; the A.2.2.4 prior-authorisation workflow is the operational control that keeps the processor on the processor side of the line.

(c) DPDP and GDPR mapping. DPDP Act 2023 section 2(1)(k) (the Data Processor definition, a processor that processes for its own marketing has lost the "on behalf of" character). Section 6 (purpose-limitation, the controller's consent is tied to specified purposes; processing for the processor's marketing is outside those purposes). Section 8(5) (the safeguards duty, applies to the marketing-use processing as much as to the agreed processing). GDPR Article 28(3) (the documented-instructions clause). Article 28(10) (the controller-status-drift rule). Article 5(1)(b) (purpose limitation). Article 6 (each purpose needs its own lawful basis, the marketing use needs a fresh lawful basis). EDPB Guidelines 07/2020 on the concepts of controller and processor. ISO/IEC 27018:2019 clause 7 (the cloud processor processes only on the customer's instructions). NIST Privacy Framework v1.0 Control-P (data-processing management, the processor's secondary uses). SOC 2 Privacy TSC P4.0 (Use).

(d) The implementation discipline. Six sub-disciplines drive conformant marketing-use discipline:

• Marketing-and-Advertising-Use Policy. A policy that prohibits the processor's own marketing, advertising, product-recommendation, benchmarking, model-training-for-own-benefit, or service-refinement-for-other-customers uses of customer data without prior authorisation. The policy is signed off by the DPO and top management; it is communicated to Sales, Marketing, Product, Engineering and Operations.
• Prior-authorisation workflow. A documented workflow for any processor-side secondary use of customer data. The workflow captures: the proposed use; the customer whose data is involved; the data categories; the lawful basis (the controller's authorisation; the principal's consent or another ground, evidenced through the controller); the Article 28(10) status-drift analysis (does the proposed use push the processor towards controller status?); the DPO sign-off; the customer's signed authorisation; the operational implementation; the audit trail.
• Article 28(10) status-drift register. A register of every processing activity where the controller-status question may arise, the marginal cases (the processor's own analytics on aggregated customer data; the processor's troubleshooting logs that may contain personal data; the processor's model-training on customer data with the controller's consent but for the processor's own benefit). The register documents the analysis (is this processing within the controller's instructions, or outside? if outside, has the processor become a controller for this processing? what are the consequences?). The register is reviewed quarterly.
• Sales and Marketing training. The Sales and Marketing teams are trained on the prohibition, they may not use customer data for their campaigns without going through the prior-authorisation workflow. The training is refreshed at least annually; the sign-off is recorded.
• Engineering and Product training. The Engineering and Product teams are trained on the prohibition as it applies to product analytics, model training, and benchmarking, they may not use customer data for these purposes without the prior-authorisation workflow. The training is refreshed at least annually.
• Operational analytics discipline. The processor's own operational analytics (logging, monitoring, performance, security) are scoped to remain within the agreed-purposes category, they are necessary for delivering the service and are documented as such in the per-customer purposes register. Where the operational analytics drift towards product-improvement (using customer data to refine the processor's own service in a way that benefits other customers), the prior-authorisation workflow fires.

(e) Audit evidence. (i) The Marketing-and-Advertising-Use Policy; (ii) the prior-authorisation workflow documentation; (iii) sample prior-authorisation records (where any secondary uses were authorised in the last 12 months); (iv) the Article 28(10) status-drift register; (v) the training records for Sales, Marketing, Product, Engineering and Operations; (vi) the operational-analytics scoping documentation.

A.2.2.6, Customer obligations

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.2.6 asks PII processors to require each controller-customer to confirm that the controller's own notices, consents, lawful bases, retention rules, rights-handling process, sector-law duties, cross-border transfer analysis and breach-notification timeline are in place, and to make available to the processor what the processor needs to comply with its obligations under the agreement and applicable law.

(b) What it means in practice. The processor cannot comply with its own obligations under the DPA and the law unless the controller-customer has done certain things on its side. A.2.2.6 is the processor's "what we need from you" control, the contractual and operational mechanism by which the processor asks the controller to confirm the controller's own readiness. The confirmation is not a one-off at onboarding; it is renewed annually (or on material change to the processing) and re-confirmed at each renewal of the customer agreement.

The Customer-Obligations Confirmation Form (toolkit doc 04) is the artefact. The processor asks each controller-customer to confirm: (i) the principal categories on whose data the processor will process; (ii) the personal-data categories the controller will provide to the processor; (iii) the notices the controller has served on its principals that disclose the processor's involvement (and the controller's privacy-policy URL); (iv) the consent records (or other lawful bases) the controller holds for the processing; (v) the controller's documented instructions for the processing; (vi) the controller's retention rules; (vii) the controller's rights-handling process and the SLA for forwarding principal requests to the processor; (viii) the controller's sector-law duties (where the controller is a regulated entity); (ix) the controller's cross-border transfer analysis; (x) the controller's breach-notification timeline (the timeline within which the processor must hand off breaches to the controller).

The confirmation is the processor's evidence that the controller is fit to instruct. Without it, the processor's compliance with its own downstream duties (the security schedule, the breach-handoff, the rights-handling support) is not operationally possible. A controller-customer that cannot or will not provide the confirmation is a customer the processor should not onboard (or should not renew), the A.2.2.6 escalation mirrors the A.2.2.5 refusal: the processor's senior management makes the commercial decision to refuse the customer where the confirmation is inadequate.

(c) DPDP and GDPR mapping. DPDP Act 2023 section 8 (the fiduciary's obligations that the processor's confirmation establishes are in place). Section 5 (notice, the controller's notice duty that the processor asks the controller to confirm). Section 6 (consent, the controller's consent records that the processor asks the controller to confirm). Section 7 (the legitimate uses, the controller's non-consent grounds). Section 8(5) (security safeguards). Section 8(6) (breach notification, the controller's timeline that the processor's handoff feeds). Section 8(7) (erasure, the controller's retention rules). Sections 11 to 14 (the principal rights that the controller's rights-handling process must support). GDPR Article 28(3) (the controller's obligations and rights, the DPA's sixth mandatory term). Article 13/14 (the controller's notice duties). Article 6 (the controller's lawful bases). Article 28(10) (the controller-status-drift rule, the controller's instructions that keep the processor on the processor side of the line). Article 33 (the controller's breach-notification timeline). ISO/IEC 27018:2019 clause 7 (the cloud processor's reliance on the controller's instructions).

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

• Customer-Obligations Confirmation Form. A standardised form (toolkit doc 04) that the processor sends to each controller-customer at onboarding and at each renewal. The form captures the ten confirmations described above. The completed form is filed in the per-customer DPA register.
• Onboarding gate. The confirmation is a condition of onboarding, the customer is not onboarded until the confirmation is received and reviewed. The processor's Sales and Customer Success teams enforce the gate; the DPO reviews the confirmation for substantive adequacy.
• Renewal cycle. The confirmation is renewed annually (or on material change to the processing). The renewal cycle is driven by the customer-portal workflow (for mid-market and enterprise processors) or by the Customer Success team (for growing-company processors).
• Inadequate-confirmation escalation. Where the controller-customer cannot or will not provide the confirmation (or where the confirmation is substantively inadequate, the controller has not served the notices; the controller does not have a rights-handling process), the processor escalates. The escalation follows the A.2.2.5 refusal pattern: the DPO documents the gap; the senior management makes the commercial decision (refuse the customer; onboard with documented conditions and a remediation timeline; renew with conditions). The escalation is logged in the A.2.2.5 instruction-decision log.
• Substantive review. The confirmation is not just a paperwork exercise, the DPO reviews the substantive content. A confirmation that says "yes we have notices and consents" without supporting evidence (the privacy-notice URL; the consent-capture mechanism) is not a conformant confirmation. The DPO's review notes are filed with the confirmation.
• Customer-education support. The processor may support the controller's readiness by providing templates, FAQs and onboarding guides that help the controller understand what is needed. The support is not the same as doing the controller's work for it, the controller remains responsible for its own notices, consents and rights-handling; the processor's support is an enablement, not a delegation.

(e) Audit evidence. (i) The Customer-Obligations Confirmation Form template; (ii) the per-customer DPA register showing the confirmation references; (iii) sample completed confirmations for five to ten customers; (iv) the renewal-cycle evidence; (v) the inadequate-confirmation escalation records (where applicable); (vi) the DPO's substantive-review notes; (vii) the customer-education support materials.

A.2.2.7, Records related to processing PII

(a) The paraphrased requirement. ISO/IEC 27701:2025 control A.2.2.7 asks PII processors to maintain records of the processing activities performed on behalf of each controller-customer, a processor-side record of processing activities (ROPA) that includes (at minimum) the processing purposes; the categories of personal data; the categories of principals; the recipients (including sub-processors and third parties); the cross-border transfers; the retention rules; the security measures; and the data-flow description.

(b) What it means in practice. The processor ROPA is the family's evidentiary artefact. It is the audit object that proves the other four controls are working: the DPA (A.2.2.2) is the contract; the purposes register (A.2.2.3) is the purposes dimension; the marketing-use attestation (A.2.2.4) is the secondary-use dimension; the obligations confirmation (A.2.2.6) is the controller-fitness dimension; the ROPA (A.2.2.7) is the per-customer, per-processing-activity evidence base that ties it all together. The auditor and (after an incident) the regulator will walk this ROPA end-to-end.

The processor ROPA is the GDPR Article 30(2) analogue. Article 30(2) of GDPR requires each processor to maintain a record of all categories of processing activities carried out on behalf of a controller, containing: the name and contact details of the processor and of each controller on behalf of which the processor is acting; the categories of processing carried out on behalf of each controller; the categories of personal data; the categories of principals; the recipients (including sub-processors); the cross-border transfers; the security measures. The Article 30(2) content maps almost one-to-one to the A.2.2.7 content.

The processor ROPA is not a static artefact. It is updated as the processing changes (new sub-processors; new transfer destinations; new purposes authorised by the controller under A.2.2.3) and reconciled at least quarterly with the operational reality. The ROPA is produced on request to any controller-customer (typically within hours) and to the supervisory authority (the DPBI in India; the relevant DPA in the EU) on demand.

(c) DPDP and GDPR mapping. DPDP Act 2023 section 8 (the fiduciary's record-keeping duty that flows through the processor, the processor's ROPA is part of the fiduciary's section 8 records). Section 8(5) (security safeguards, the ROPA's security-measures content). DPDP Rules 2025 (the SDF DPIP records and the audit records, where the controller is an SDF, the processor's ROPA supports the controller's DPIP). GDPR Article 30(2) (the processor's ROPA, direct mapping). Article 28(3) (the DPA's content that the ROPA operationalises). Article 32 (security measures, the ROPA's security-measures content). ISO/IEC 27018:2019 clause 7 (the cloud processor's record-keeping). ISO/IEC 27002:2022 control 5.34 (PII protection, the ROPA is part of the PII-protection evidence). NIST Privacy Framework v1.0 Identify-P (data-mapping, the ROPA is the data map). SOC 2 Privacy TSC P3.0 (Collection) and P8.0 (Monitoring).

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

• ROPA template. A standardised template (toolkit doc 10) that captures the Article 30(2) content per customer per processing activity: customer name and contact; processor name and contact; categories of processing; purposes (cross-referenced to the A.2.2.3 purposes register); data categories; principal categories; recipients (sub-processors cross-referenced to the A.2.5.7/.5.8/.5.9 controls; third parties cross-referenced to the A.2.5.4/.5.5/.5.6 controls); cross-border transfers (cross-referenced to the A.2.5.2/.5.3 controls); retention rules; security measures (cross-referenced to the A.2.2.2 DPA's security schedule); data-flow description.
• Per-customer ROPA entries. Each active customer has at least one ROPA entry (and typically several, one per processing activity the processor performs for that customer). The entries are populated at onboarding and updated through the change-control process.
• Central ROPA register. The per-customer entries are aggregated into a central register (typically maintained in a privacy management platform for mid-market and enterprise processors; in a structured document for growing-company processors). The central register is the audit's primary walk-through document.
• Reconciliation cadence. Quarterly reconciliation of the ROPA against the operational reality (the live data flows; the active sub-processors; the active transfer destinations). Drift (a ROPA entry that does not match the operational reality) is the canonical A.2.2.7 finding; the reconciliation closes the loop.
• Production-on-request timeline. The processor can produce a specific customer's ROPA entry within hours of a request (from the customer; from the customer's regulator; from the certification auditor). The production-on-request capability is the operational test of the ROPA's currency and accessibility.
• Sub-processor chain integration. The ROPA's recipients content (the sub-processor list) is integrated with the A.2.5.7/.5.8/.5.9 sub-processor chain controls, when a sub-processor is added or changed, the affected customers' ROPA entries are updated.

(e) Audit evidence. (i) The processor ROPA template; (ii) the central ROPA register; (iii) sample walks of three to five customers' ROPA entries showing the Article 30(2) content populated; (iv) the reconciliation reports; (v) the production-on-request capability evidence (a recent customer or regulator request and the response); (vi) the sub-processor-chain integration evidence.

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

The certification auditor's end-to-end A.2.2 walk picks a recent customer onboarding and traces it through the full stack. A representative walk for an Indian SaaS analytics processor's onboarding of a digital-lending customer:

1. Customer-agreement (A.2.2.2). The processor and the digital-lending customer sign the DPA, the Article 28(3) mandatory content is populated: subject-matter (real-time event analytics for the customer's loan-origination flow); duration (the MSA term of three years plus the post-termination data-destruction 90-day window); nature and purpose (event ingestion, analytics processing, dashboard delivery, alert generation); type of personal data (the customer's borrower PII, name, contact, PAN, loan-reference); principal categories (the customer's borrowers); obligations (the customer's documented-instructions regime, the audit rights, the breach-handoff SLA). The sector overlay, the RBI Managing Risks in Outsourcing Directions, 2025, is layered in: the DPA allows RBI inspection; the sub-outsourcing restrictions; the data-locality clause (the data stays in the India region).
2. Purposes register (A.2.2.3). The customer's purposes are documented: real-time event analytics; dashboard delivery; alert generation; monthly aggregated reporting to the customer's leadership. The out-of-scope list: no marketing use; no cross-customer benchmarking; no model-training for the processor's own benefit; no operational analytics beyond what is necessary to deliver the service.
3. Marketing-use attestation (A.2.2.4). The processor attests that no marketing/advertising use of the customer's data is made or planned. The Article 28(10) status-drift register entry for this customer documents the analysis (the processor's own operational analytics, performance, security, logging, are within the agreed purposes; no other secondary use).
4. Customer-obligations confirmation (A.2.2.6). The customer confirms: notices served on borrowers that disclose the processor's involvement (the customer's privacy-notice URL is recorded); consent captured under DPDP section 6 for the analytics processing; the customer's documented instructions; the customer's retention rules (the borrower-loan-event data retained for the post-loan-closure period per the RBI rule); the customer's rights-handling process (the grievance officer; the SLA for forwarding principal requests); the customer's sector-law duties (the RBI digital-lending rules; the RBI storage-of-payment-data rule); the customer's cross-border transfer analysis (no cross-border, the data stays in the India region); the customer's breach-notification timeline (the 72-hour DPBI timeline, the processor must hand off breaches to the customer within 24 hours to leave the customer enough time).
5. Processor ROPA (A.2.2.7). The processor's ROPA entry for this customer is created: customer name; purposes (the four documented purposes); data categories (the borrower PII categories); principal categories (the customer's borrowers); recipients (the cloud-infrastructure provider in the India region; the sub-processor for the alert-delivery SMS gateway); transfers (none, the India region); retention (the customer's rules); security measures (the DPA's security schedule); data-flow description (the ingestion API; the storage layer; the analytics engine; the dashboard service; the alert pipeline).

The walk closes with the audit evidence: the signed DPA, the purposes register entry, the marketing-use attestation, the obligations confirmation, the ROPA entry. A processor that can produce this walk for any active customer is operating at A.2.2 L4 or L5. A processor that cannot produce this walk for any active customer is operating at L1 or L2.

Tools, Technologies, and Solutions

The tool landscape

The A.2.2 family is operationally supported by five 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 customer-DPA register, the per-customer purposes register, the marketing-use prior-authorisation workflow, the customer-obligations confirmation intake, the processor ROPA, the sub-processor disclosure list, the cross-border transfer register. The A.2.2-relevant slice is the customer-portfolio governance module and the processor-ROPA module. Generic category terms, "enterprise privacy management platform", "privacy operations platform", "third-party risk management platform", are the right vocabulary; this guide does not name vendors.

Contract lifecycle management (CLM) tools. Products that manage the DPA's drafting, negotiation, execution, renewal and change control. The CLM integrates with the PMP (the customer-DPA register references the CLM's executed DPAs) and with the e-signature platform. For mid-market and enterprise processors with high-volume customer portfolios, a CLM is the conformant pattern; for growing-company processors, a focused DPA-master-template workflow in a document-management system may suffice.

Customer-portal workflow tools. Products (or custom builds on top of the SaaS product's customer portal) that operationalise the customer-onboarding flow, the customer fills in the customer-specific DPA schedule, signs the DPA electronically, completes the obligations-confirmation form, and the artefacts are filed automatically. The customer-portal workflow is the conformant pattern for high-volume customer portfolios.

Data discovery and pipeline-mapping tools. Products that scan the processor's data estate and map the data flows, the ingestion pipelines, the storage layers, the analytics warehouse, the AI/ML feature store, the sub-processor outbound feeds, the cross-border transfer flows. The output drives the purposes-register reconciliation (A.2.2.3) and the ROPA's data-flow description (A.2.2.7).

Multi-tenant isolation tooling. The SaaS/BPO infrastructure's logical-separation, access-control, and per-customer partitioning tooling. The output drives the multi-tenant isolation evidence (the access-control matrix; the per-customer partitioning configuration; the cross-customer access prevention).

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 plus a CLM; lower-volume processors (5 to 25 customers) can run effectively on a focused DPA-master-template workflow in a document-management system and a structured-spreadsheet ROPA.

Existing stack integration. The privacy tooling must integrate with the processor's existing SaaS product (the customer portal), the CRM (the customer list), the ITSM (the change-management records), the engineering pipeline (the data-flow reality) and the e-signature platform. 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 customer-DPA register, 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.

Multi-tenant isolation maturity. The processor's SaaS/BPO infrastructure's multi-tenant isolation discipline is the foundation on which A.2.2.3 operates. For SaaS processors built on a multi-tenant cloud architecture (the major cloud providers' India regions), the per-customer partitioning is built in; the processor's responsibility is to configure it correctly. For BPO/ITeS processors running shared infrastructure (shared delivery centres; shared networks; shared storage), the isolation discipline is harder and requires deliberate engineering.

The Indian-specific tool dimension

The Indian-specific tool dimension is the DPDP-native slice, the customer-obligations confirmation that asks the controller to confirm its DPDP Act 2023 readiness (notices served under section 5; consent captured under section 6; legitimate-uses analysis under section 7; security safeguards under section 8(5); breach-notification timeline under section 8(6) read with the DPDP Rules 2025 Rule 7; erasure rules under section 8(7); rights-handling process for sections 11 to 14; SDF DPIP records under section 10 where the controller is an SDF). 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 customer-DPA registers, 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 customer-agreement templates (the cloud-provider's standard DPA, available to all customers) often form the starting point for an Indian processor's customer DPA; the processor's responsibility is to layer the DPDP-specific, RBI-specific, SEBI-specific and IRDAI-specific overlays on the cloud-provider's standard DPA where the customer is in a regulated sector.

Policy and Procedure Templates

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

The Customer-Agreement and Processor-Conditions Policy (toolkit doc 01)

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

• The processor shall maintain a written customer agreement (the Data Processing Agreement, "DPA") with each controller-customer that records the Article 28(3) mandatory content (subject-matter, duration, nature/purpose, type of personal data, categories of principals, obligations and rights of the controller), the documented-instructions regime (A.2.2.5), the security schedule, the sub-processor schedule, the cross-border transfer schedule, the breach-handoff clause, the audit-and-inspection clause, and the data-return-or-destruction clause.
• The processor shall process the controller-customer's personal data only for the purposes documented in the DPA and recorded in the per-customer purposes register, and shall not process for the processor's own purposes except where the controller has authorised a compatible secondary purpose in writing.
• The processor shall not use the controller-customer's personal data for the processor's own marketing, advertising, product-recommendation, benchmarking, model-training-for-own-benefit, or service-refinement-for-other-customers purposes without prior authorisation through the documented workflow.
• The processor shall require each controller-customer to complete the Customer-Obligations Confirmation Form at onboarding and at each renewal, and shall escalate where the confirmation is inadequate.
• The processor shall maintain a Processor Records of Processing Activities (ROPA) for each controller-customer that captures the Article 30(2) content, updated at least quarterly and produced on request within hours.
• The processor shall apply the DPDP Act 2023 sections 2(1)(k), 8, 8(5), 8(6), 8(7); the GDPR Article 28 (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 maintain the Article 28(10) status-drift register and review it quarterly.
• The processor shall drill the breach-handoff procedure at least annually; for high-risk processors (BFSI, healthcare, sensitive-data processors), semi-annually.
• The processor shall report the A.2.2 KPIs (doc 11) to the management review (Clause 9.3) on cadence and act on the trends.

The Customer-DPA Master Template (toolkit doc 01, Appendix A)

The master template that contains the Article 28(3) mandatory content, the security schedule, the sub-processor schedule, the transfer schedule, the breach-handoff clause, the audit-and-inspection clause, and the data-return-or-destruction clause. Customer-specific schedules fill in the customer-specific content. The template is reviewed at least annually.

The Purposes-Limitation Register (toolkit doc 02)

The register documenting the bounded set of purposes per customer, the out-of-scope list per customer, and the pipeline-to-register reconciliation cadence. The register is populated at onboarding and updated through the A.2.2.5 instruction-decision-log change-control process.

The Marketing-and-Advertising-Use Policy (toolkit doc 03)

The policy prohibiting the processor's own marketing/advertising/product-recommendation/benchmarking/model-training-for-own-benefit/service-refinement-for-other-customers uses of customer data without prior authorisation; the prior-authorisation workflow; the Article 28(10) status-drift register.

The Customer-Obligations Confirmation Form (toolkit doc 04)

The standardised form capturing the ten confirmations: principal categories; data categories; notices served; consent or lawful basis; documented instructions; retention rules; rights-handling process; sector-law duties; cross-border transfer analysis; breach-notification timeline.

The Customer-DPA Clause Library (toolkit doc 10)

The library of processor-side "shall" clauses we recommend for every customer agreement, the customer-obligations confirmation clause; the documented-instructions regime; the security schedule clauses; the sub-processor schedule clauses; the transfer schedule clauses; the breach-handoff clause; the audit-and-inspection clause; the data-return-or-destruction clause; the indemnity clauses.

The Processor ROPA Template (toolkit doc 10, Appendix B)

The template capturing the Article 30(2) content per customer per processing activity: customer name and contact; processor name and contact; categories of processing; purposes; data categories; principal categories; recipients; transfers; retention rules; security measures; data-flow description.

The Breach-Handoff Procedure (toolkit doc 08)

The procedure covering the dual-clock breach-handoff pattern (DPDP 72-hour handoff to the controller; CERT-In 6-hour India-ICT-system report), the post-incident review template, the drill cadence.

Risk Assessment and Treatment

The risk register entries that touch A.2.2

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

The DPIA trigger analysis for A.2.2

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 (where the controller is an SDF under DPDP section 10) trigger DPIAs for several A.2.2 patterns:

• New processing activities that materially depart from the processor's existing pattern (new data category; new purpose; new technology; new geography).
• New sub-processor engagements (especially where the sub-processor is in a different jurisdiction).
• New cross-border transfer destinations (especially to non-equivalent jurisdictions).
• New marketing-use authorisations (where the controller authorises a secondary use, the DPIA analyses the secondary-use risk).
• New AI/ML model-training uses of customer data (the highest-risk pattern, the DPIA drives the algorithmic-fairness review).

The DPIA's outputs feed back into the A.2.2 stack, the DPA's security schedule may be tightened; the purposes register may be narrowed; the marketing-use authorisation may be conditioned; the ROPA may be updated.

The risk-treatment decision points

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

• Modify, change the DPA, the purposes register, the marketing-use policy or the customer-portal workflow to reduce the likelihood or impact.
• Avoid, do not onboard the customer whose obligations-confirmation is inadequate; do not authorise the marketing-use request; do not engage the sub-processor in the non-equivalent jurisdiction.
• Share, transfer the risk to a third party (the cyber-insurer under a cyber-insurance policy; the sub-processor under contractual indemnity).
• 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.2 risks).

Audit and Compliance Checklist

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

1. Is there a Customer-Agreement and Processor-Conditions Policy? Expected: a dated, version-controlled policy signed off by the DPO and top management, covering the DPA-master-template discipline, the purposes register, the marketing-use policy, the obligations-confirmation form, the processor ROPA, the Article 28(10) status-drift register, the breach-handoff procedure. Red flag: no policy; or policy exists but is generic (no India-specific content; no sector-rule integration).

2. Is there a Customer-DPA Master Template? Expected: a single master template owned by Legal and approved by the DPO, containing the Article 28(3) mandatory content, the security schedule, the sub-processor schedule, the transfer schedule, the breach-handoff clause, the audit-and-inspection clause, and the data-return-or-destruction clause. Red flag: no master template; or the master template is the customer's paper (the processor has no template of its own).

3. Is there a per-customer DPA register? Expected: a register of every active customer's DPA, the customer name; the execution date; the version; the customer-specific schedule content; the renewal date; the obligations-confirmation reference; the ROPA entry reference. Red flag: no register; or register has fewer entries than the active customer list.

4. Does each active customer have a signed DPA with the Article 28(3) mandatory content? Expected: sample walks of five to ten signed customer DPAs showing the subject-matter, duration, nature/purpose, data types, principal categories and obligations populated with customer-specific information. Red flag: missing DPAs; or DPAs that are boilerplate without customer-specific content.

5. Is there a DPA gap-remediation plan for legacy customers? Expected: a documented plan with target completion dates for each customer whose DPA predates the master template or is missing the mandatory content. Red flag: no plan; or plan exists but no progress against the dates.

6. Is there a per-customer purposes register? Expected: the register documenting the bounded set of purposes per customer, with the out-of-scope list. Red flag: no register; or register exists but is shorter than the active customer list.

7. Does each processing pipeline reconcile with the purposes register? Expected: quarterly reconciliation reports showing the pipelines' purposes aligned with the register. Red flag: pipelines running on undocumented purposes; or no reconciliation.

8. Is the multi-tenant isolation enforced? Expected: the access-control matrix; the per-customer partitioning configuration; the cross-customer access prevention. Red flag: shared infrastructure without isolation; cross-customer data access possible.

9. Is there a Marketing-and-Advertising-Use Policy? Expected: the policy prohibiting the processor's own marketing/advertising uses of customer data unless prior consent from the appropriate PII principal has been established; the consent-verification and controller-authorisation workflow. Red flag: no policy; or policy exists but no workflow to enforce it.

10. Are there sample prior-authorisation records? Expected: where any secondary uses were authorised in the last 12 months, the authorisation records with the controller's signed consent, the Article 28(10) status-drift analysis, the DPO sign-off. Red flag: no records (suggesting either no requests or unauthorised uses).

11. Is the Article 28(10) status-drift register maintained? Expected: the register documenting the analysis of every marginal processing activity; the quarterly DPO review. Red flag: no register; or register exists but is empty (suggesting the analysis was not done).

12. Is the Customer-Obligations Confirmation Form in use? Expected: the standardised form sent to each customer at onboarding and at renewal, capturing the ten confirmations. Red flag: no form; or form exists but is not used consistently.

13. Is the onboarding gate enforced? Expected: no customer is onboarded without the completed confirmation. Red flag: customers onboarded without the confirmation; or the confirmation collected after onboarding.

14. Is the renewal cycle operational? Expected: the confirmation renewed annually (or on material change); the renewal cycle driven by the customer-portal workflow or the Customer Success team. Red flag: confirmations collected once at onboarding and never renewed.

15. Are inadequate-confirmation escalations logged? Expected: where the controller-customer cannot or will not provide the confirmation, the escalation records (the DPO's review, the senior-management decision). Red flag: no escalations (suggesting either no inadequate confirmations encountered, or the gap was quietly ignored).

16. Is the DPO's substantive review recorded? Expected: the DPO's review notes on the substantive content of the confirmation (not just that it was completed). Red flag: the confirmation is treated as a paperwork exercise.

17. Is the Processor ROPA template adopted? Expected: the standardised template capturing the Article 30(2) content per customer per processing activity. Red flag: no template; or template exists but lacks the Article 30(2) content.

18. Is the central ROPA register populated? Expected: the central register aggregating the per-customer entries; the register is the audit's primary walk-through document. Red flag: no central register; or register has fewer entries than the active customer list.

19. Is the ROPA reconciled quarterly? Expected: the reconciliation reports showing the ROPA matches the operational reality. Red flag: no reconciliation; or reconciliation shows drift that was not corrected.

20. Can the ROPA be produced on request within hours? Expected: the production-on-request capability evidence (a recent customer or regulator request and the response). Red flag: the ROPA cannot be produced on request; or the production takes days.

21. Is the sub-processor chain integrated with the ROPA? Expected: when a sub-processor is added or changed, the affected customers' ROPA entries are updated. Red flag: sub-processor changes not reflected in the ROPA.

22. Is the sector-overlay documentation in place? Expected: for customers in regulated sectors (RBI, SEBI, IRDAI), the sector-specific clauses (RBI inspection rights; sub-outsourcing restrictions; data-locality) layered into the DPA. Red flag: generic DPA without sector overlays for regulated customers.

23. Are the Sales and Marketing teams trained on the marketing-use prohibition? Expected: the training records; the annual refresh; the sign-off. Red flag: no training; or training exists but no sign-off.

24. Are the Engineering and Product teams trained on the marketing-use prohibition? Expected: the training records covering product analytics, model training, benchmarking; the annual refresh. Red flag: no training; or training exists but no sign-off.

25. Is the breach-handoff procedure drilled? Expected: annual drill; semi-annual for high-risk processors; the drill report with the lessons learned. Red flag: no drill; or drill exists but does not trace the dual-clock pattern.

26. Is the customer-portal workflow enforcing the DPA execution before processing? Expected: the onboarding-gate configuration; the DPO sign-off workflow. Red flag: customer onboards without the DPA executed.

27. Are the A.2.2 KPIs (Section 12) reported to the management review? Expected: the KPIs reported at the Clause 9.3 management review; trends analysed; improvement actions taken. Red flag: no KPIs; or KPIs exist but not reported.

28. Is the A.2.2 evidence base wired into the PIMS internal audit (Clause 9.2)? Expected: the internal audit cycle covers A.2.2 evidence; the findings feed Clause 10.2 corrective action and Clause 10.1 continual improvement. Red flag: A.2.2 not in the audit cycle.

Metrics and KPIs

The Singahi A.2.2 KPI set (toolkit doc 11) covers customer-agreement coverage, purposes discipline, marketing-use discipline, customer-obligations confirmation currency, ROPA currency and the breach-handoff drill. The fifteen KPIs below are the recommended minimum.

Customer-agreement KPIs

1. DPA coverage rate, the percentage of active controller-customers with a signed DPA containing the Article 28(3) mandatory content. Target: 100%.

   • Formula: (customers with signed conformant DPA / total active customers) × 100
   • Frequency: monthly
   • Owner: Legal / DPO

2. DPA gap-remediation completion, the percentage of legacy customers whose DPA gaps have been remediated within the target date. Target: 100% by the documented target date.

   • Frequency: monthly until the gap-remediation cycle is complete
   • Owner: Legal / Customer Success

3. Customer-obligations-confirmation currency, the percentage of active customers with a confirmation less than 12 months old. Target: 100%.

   • Formula: (customers with current confirmation / total active customers) × 100
   • Frequency: monthly
   • Owner: Customer Success / DPO

Purposes-discipline KPIs

4. Purposes register coverage, the percentage of active customers with a documented purposes register entry. Target: 100%.

   • Frequency: monthly
   • Owner: DPO

5. Pipeline-to-register reconciliation rate, the percentage of processing pipelines that reconcile with the per-customer purposes register. Target: 100%.

   • Formula: (pipelines reconciling / pipelines audited) × 100
   • Frequency: quarterly
   • Owner: Engineering / DPO

6. Multi-tenant isolation incident count, the count of cross-customer data-leakage incidents detected in the period. Target: zero.

   • Frequency: monthly
   • Owner: Engineering / Security Lead

Marketing-use KPIs

7. Prior-authorisation workflow compliance, the percentage of processor-side secondary uses of customer data that went through the prior-authorisation workflow. Target: 100%.

   • Frequency: monthly
   • Owner: DPO

8. Article 28(10) status-drift register review, the count of status-drift analyses logged in the period and the count of customers whose processing pushed towards controller status. Target: zero controller-status drift events; trend monitored.

   • Frequency: quarterly
   • Owner: DPO

9. Marketing-use training completion, the percentage of Sales, Marketing, Product and Engineering staff who completed the annual training. Target: 100%.

   • Frequency: annually
   • Owner: DPO / HR

Customer-obligations KPIs

10. Inadequate-confirmation escalation count, the count of customers in the period whose confirmation was inadequate and was escalated. Trend monitored.

    • Frequency: monthly
    • Owner: DPO

11. Inadequate-confirmation resolution rate, the percentage of escalated customers whose confirmation was brought to adequate within the target date. Target: 100%.

    • Frequency: monthly
    • Owner: Customer Success / DPO

ROPA KPIs

12. ROPA coverage rate, the percentage of active customers with at least one current ROPA entry. Target: 100%.

    • Frequency: monthly
    • Owner: DPO

13. ROPA reconciliation currency, the count of ROPA entries that have been reconciled within the last 90 days. Target: 100%.

    • Frequency: monthly
    • Owner: DPO / Engineering

14. ROPA production-on-request time, the time taken to produce a specific customer's ROPA entry on request. Target: under 4 hours.

    • Frequency: per request; reported monthly
    • Owner: DPO

Breach-handoff KPI

15. Breach-handoff drill score, the score on the most recent breach-handoff 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

Common Pitfalls and Audit Failures

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

The "we have a master services agreement, that's enough" gap

The processor's relationship with the customer is governed by a master services agreement (MSA) that mentions data protection in a single clause. No dedicated DPA; no Article 28(3) mandatory content; no security schedule; no sub-processor schedule; no breach-handoff clause. Fails A.2.2.2 read with GDPR Article 28(3) and DPDP Act 2023 section 2(1)(k). Remediation: adopt the DPA Master Template; remediate the legacy MSAs through side-letters or DPA addenda.

The customer's paper DPA accepted without review

The processor signs the customer's paper DPA at the customer's procurement team's request. The DPA is the customer's standard template, designed for the customer's jurisdiction (often a US-state or EU template) and does not reflect the DPDP-specific, RBI-specific, SEBI-specific or IRDAI-specific overlays. Fails the sector-overlay dimension of A.2.2.2. Remediation: redline the customer's paper DPA with the processor-side positions; layer in the sector overlays where the customer is regulated.

The DPA executed once and forgotten

The processor's customer portfolio was onboarded five years ago with the then-current DPA template. The DPA has not been amended since, despite material changes to the processing (new sub-processors; new transfer destinations; new purposes). The DPA has drifted from the operational reality. Fails A.2.2.2 read with A.2.2.3 and A.2.2.7. Remediation: DPA change control; quarterly reconciliation; informal-amendment detection.

The purposes register that mirrors the DPA but not the pipeline

The processor's per-customer purposes register faithfully records the DPA's nature-and-purpose clause. The operational pipelines, however, run on a richer set of purposes (operational analytics, model-training, product-improvement) that the DPA does not authorise. The drift between register and pipeline is undetected. Fails A.2.2.3. Remediation: pipeline-to-register reconciliation; multi-tenant isolation enforcement; drift detection wired to Clause 9.1.

The marketing-use anti-pattern

The processor's marketing team uses customer contact data (the controller-customer's employees' email addresses, captured through the customer-portal sign-ins) for the processor's own marketing campaigns ("upgrade to our premium tier"; "attend our webinar"). The customer's data is used for the processor's own marketing without authorisation. Fails A.2.2.4 read with GDPR Article 28(10). Remediation: Marketing-and-Advertising-Use Policy; CRM access controls; prior-authorisation workflow; annual training.

The benchmarking-product anti-pattern

The processor's product team builds an "industry benchmarks" feature using aggregated customer data. The benchmarks are sold to other customers (or used in marketing collateral). The customer data was not authorised for the benchmarking use. Fails A.2.2.4 read with Article 28(10). Remediation: prior-authorisation workflow for benchmarking uses; Article 28(10) status-drift register; engineering training.

The "customer-obligations confirmation as paperwork" gap

The customer-obligations confirmation form is collected at onboarding as a tick-box exercise. The customer's privacy team ticks "yes we have notices" without providing the URL; ticks "yes we have consent" without providing the consent-capture mechanism; ticks "yes we have a rights-handling process" without naming the grievance officer. The DPO does not review the substantive content. Fails A.2.2.6. Remediation: DPO substantive review; supporting-evidence requirement; customer-education support.

The ROPA as a static spreadsheet

The processor's ROPA is a single spreadsheet with one row per customer, populated at onboarding and never updated. The ROPA does not reflect the operational reality (sub-processors added; transfers initiated; purposes broadened). Fails A.2.2.7. Remediation: central ROPA register in a privacy management platform; quarterly reconciliation; production-on-request capability.

The "no DPA for the long-tail customers" gap

The processor's top-20 customers (by revenue) have signed DPAs. The long-tail customers (the small customers, the legacy customers, the free-tier customers) do not have DPAs. The processor's DPA coverage rate is 30% rather than 100%. Fails A.2.2.2. Remediation: DPA-master-template adoption across the portfolio; customer-portal workflow that enforces the DPA execution before processing.

The customer-portal that lets customers onboard without the confirmation

The customer-portal workflow allows the customer to start using the processor's service immediately on signup; the obligations-confirmation form is sent afterwards (or not at all). The onboarding gate is not enforced. Fails A.2.2.6. Remediation: onboarding-gate configuration; the confirmation completed and reviewed before the customer can process any personal data.

The sub-processor change without the DPA-mandated notice

The processor engages a new sub-processor (a new analytics engine; a new alert-delivery SMS gateway) without notifying the affected customers per the DPA's sub-processor-change clause. The customers' ROPA entries are not updated. Fails A.2.2.2 read with A.2.5.8 and A.2.5.9. Remediation: sub-processor change-control integration; sub-processor disclosure automation.

The status-drift register that does not exist

The processor has not maintained the Article 28(10) status-drift register. The marginal cases (the processor's own analytics on aggregated customer data; the processor's model-training on customer data with the controller's consent) have not been analysed. Fails A.2.2.4 / A.2.2.3 status-drift dimension. Remediation: status-drift register build; quarterly DPO review.

The breach-handoff procedure never drilled

The breach-handoff procedure exists on paper. The drill has never been run. The customer-portal credentials for the breach-notification handoff have not been tested. The Rule 7 intimation content is not pre-staged. Fails the operational dimension of A.2.2.2 (the breach-handoff clause). Remediation: annual drill; semi-annual for high-risk processors.

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 DPA register was not populated; the purposes register was not reconciled; the ROPA was not maintained. Fails operational discipline. Remediation: configure the PMP to the processor's documented standard; audit the configuration quarterly.

The marketing-use training never given

The Marketing and Sales teams have never been trained on the marketing-use prohibition. The teams assume that any contact data in the CRM is fair game for marketing. Fails A.2.2.4 operational dimension. Remediation: annual training; CRM access controls that flag customer-data reuse.

The cross-customer data-leakage in a shared feature store

The processor's AI/ML feature store ingests customer A's event data into a shared dataset that is used to train a model deployed for customer B. The cross-customer data leakage is undetected. Fails A.2.2.3 read with the multi-tenant isolation discipline. Remediation: per-customer training datasets; cross-customer access prevention at the feature-store layer.

The legacy customer with an obsolete DPA

The processor's relationship with a customer dates back seven years. The DPA was signed in 2019 and has not been amended. The DPA does not reflect the DPDP Act 2023 (which was enacted after the DPA was signed); does not reflect the current sub-processor chain; does not reflect the current transfer destinations. Fails A.2.2.2 currency dimension. Remediation: DPA change-control cycle; the legacy customer brought onto the current DPA master template.

The "we are the processor, the controller handles compliance" misreading

The processor's privacy team believes that because the processor is "only" a processor, the controller-customer handles all the compliance. The processor does not maintain the A.2.2 stack. Fails the entire A.2.2 family. Remediation: processor-side privacy programme; the A.2.2 stack built and maintained.

The customer-portal workflow that bypasses Legal

The customer-portal workflow allows the customer to fill in the DPA schedule and execute it without Legal review. The customer-specific schedule content is not reviewed for conformity with the master template. Fails A.2.2.2 review dimension. Remediation: Legal review of each executed DPA; the customer-portal workflow configured to require Legal sign-off.

The ROPA produced for the audit only

The processor's ROPA is maintained for the certification audit. Between audits, the ROPA is not updated; the operational reality drifts. The auditor finds a ROPA that does not match the live processing. Fails A.2.2.7 currency dimension. Remediation: quarterly reconciliation; the ROPA maintained as a living artefact, not a once-a-year exercise.

Illustrative Scenario 1: Failure, Sandesh Cloud Services and the Bulk-Customer DPA Gap (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 SaaS and cloud-service providers. No specific real company is described.

The setting. Sandesh Cloud Services Private Limited operates a multi-tenant SaaS customer-engagement platform in India, marketing automation, customer-support ticketing, in-app messaging, with approximately 1,800 active controller-customers ranging from mid-market e-commerce platforms to growing-company fintechs and healthcare-app providers. The company is headquartered in Bengaluru, with engineering in Hyderabad and a customer-success team in Pune. The platform processes substantial principal data on behalf of its customers (the customers' end-users' contact details, behavioural events, support-ticket transcripts, in-app message content).

The A.2.2 architecture at the audit. At the time of the ISO/IEC 27701:2025 Stage 1 audit in early 2027, Sandesh's A.2.2 architecture was typical of an Indian growing-company SaaS processor that had prioritised customer-acquisition velocity over privacy discipline:

• The customer portfolio was split into three tiers. Tier 1 (the top 50 customers by revenue) had signed DPAs, Sandesh's Legal team had negotiated these one-by-one, mostly accepting the customer's paper. Tier 2 (about 400 mid-market customers) had an MSA in place with a single data-protection clause that referenced "applicable privacy laws" without specifying any. Tier 3 (about 1,350 small and free-tier customers) had clicked-through standard terms and conditions at signup, no DPA, no MSA, no data-protection clause.
• The DPA Master Template existed on paper (Sandesh's Legal team had drafted it in 2024) but had never been enforced across the portfolio. Customer Success was measured on onboarding velocity, not on DPA execution.
• The per-customer purposes register did not exist. The customer-success team's understanding of "what the customer is engaged to do" was informal, drawn from the product description.
• The Marketing and Sales teams used customer contact data (the customer's employees who had signed into the Sandesh admin console) for Sandesh's own marketing campaigns, webinar invitations, expensive upgrade offers, feature-launch announcements. No prior-authorisation workflow existed.
• The product team had built a " benchmarks" feature, aggregated engagement-rate benchmarks derived from the customer data, marketed to other customers as a competitive differentiator. No customer had authorised this use.
• The Customer-Obligations Confirmation Form did not exist. The onboarding workflow collected the customer's billing details, technical integration credentials and logo, but no confirmation of the controller's privacy-side readiness.
• The processor ROPA was a single spreadsheet maintained by the privacy team (one privacy analyst, half-time). The spreadsheet had one row per customer (the customer name; the product tier; the signup date). It did not capture the Article 30(2) content (purposes, data categories, principal categories, recipients, transfers, retention, security measures, data-flow description). It had last been updated six months before the audit.
• The Article 28(10) status-drift register did not exist.
• The breach-handoff procedure existed on paper but had never been drilled.

The trigger. In March 2027, one of Sandesh's Tier-1 customers (a Mumbai-based digital-lending NBFC) received a complaint from a borrower that the borrower's personal data had been used for marketing calls from a third-party lender the borrower had never heard of. The NBFC investigated and traced the leak to a Sandesh sub-processor (an SMS-gateway vendor that had been added in 2025 without notifying the NBFC's team per the DPA's sub-processor-change clause). The NBFC's regulator (the RBI) opened an inspection; the inspection expanded to Sandesh as the processor. Simultaneously, the NBFC invoked the indemnity clause in the DPA, seeking recovery of any RBI penalty.

The audit findings. The Stage 1 audit, conducted in April 2027 by an IAF-accredited certification body, surfaced the following A.2.2 findings:

• Major nonconformity, A.2.2.2 (DPA coverage). Approximately 1,300 of 1,800 active customers had no conformant DPA. The Tier 2 MSAs lacked the Article 28(3) mandatory content; the Tier 3 click-through had no data-protection clause.
• Major nonconformity, A.2.2.2 (DPA currency). Of the 50 Tier-1 DPAs, 42 had been signed before 2023 and did not reflect the DPDP Act 2023; 36 did not reflect the current sub-processor chain; 28 did not reflect the current transfer destinations.
• Major nonconformity, A.2.2.3 (no purposes register). No per-customer purposes register existed; the operational pipelines ran on an undocumented set of purposes.
• Major nonconformity, A.2.2.4 (marketing-use anti-patterns). The benchmarks feature and the marketing-team's use of customer contact data were both unauthorised secondary uses; the Article 28(10) status-drift analysis had not been done.
• Major nonconformity, A.2.2.6 (no obligations confirmation). The Customer-Obligations Confirmation Form did not exist; the onboarding workflow had no gate.
• Major nonconformity, A.2.2.7 (ROPA inadequate). The ROPA did not capture the Article 30(2) content; it was outdated.
• Cross-control findings. The A.2.2.5 instruction-decision log was empty (no instruction had ever been logged). The A.2.5.7 sub-processor disclosure was inconsistent. The A.3 security controls were applied unevenly across the customer portfolio.

The regulatory outcome. The RBI inspection concluded that the NBFC had failed in its vendor-oversight duty under the Master Direction on IT Outsourcing (the missing sub-processor-notice was the canonical failure). The RBI imposed supervisory action on the NBFC; the NBFC's indemnity claim against Sandesh was approximately INR 8 crore (the RBI inspection cost, the remediation cost and the estimated penalty exposure). The DPBI, on the borrower's complaint, opened an investigation into both the NBFC (as fiduciary) and Sandesh (as processor); the DPBI's investigation tested whether Sandesh had a written agreement under DPDP Act 2023 section 2(1)(k) read with section 8 that flowed the obligations downstream, and found that for the Tier 2 and Tier 3 customers it did not. The reputational impact, covered in the business press, was substantial; Sandesh lost approximately 12% of its Tier-1 customer base over the following two quarters as enterprise customers migrated to better-governed competitors.

The lessons.

• The bulk-customer DPA gap is the canonical Indian A.2.2 failure. A SaaS processor that onboarded customers on click-through terms without a conformant DPA has 1,300+ unregulated processing relationships. The remediation cost (the DPA-master-template adoption, the customer-by-customer remediation, the customer-portal rebuild, the lost customers) was an order of magnitude greater than the cost of building the A.2.2 stack at the start.
• The marketing-use anti-pattern is the marquee controller-status-drift trigger. Sandesh's benchmarks feature had drifted the processor into controller territory for that processing. The Article 28(10) analysis, had it been done, would have surfaced the drift and triggered the prior-authorisation workflow.
• The sub-processor change without notice is the breach-handoff failure. The SMS-gateway sub-processor added in 2025 was the proximate cause of the borrower-data leak. The A.2.5.7/.5.9 sub-processor disclosure discipline was the missing control.
• The audit and the regulator read the same evidence. The Stage 1 audit findings and the RBI / DPBI investigations were substantially overlapping. An ISO/IEC 27701:2025 audit is a near-proxy for regulatory readiness.

Illustrative Scenario 2: Success, Atharv Analytics Builds the Processor-Conditions 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 analytics and SaaS processors. No specific real company is described.

The setting. Atharv Analytics Private Limited operates a SaaS product-analytics platform in India, event tracking, funnel analysis, retention analytics, A/B testing, with approximately 320 active controller-customers ranging from Indian digital-lending platforms to e-commerce players and edtech apps. The company is headquartered in Bengaluru, with engineering in Pune and a customer-success team in Mumbai. The platform processes substantial principal data on behalf of its customers (the customers' end-users' behavioural events, session recordings, device-fingerprint data).

The pre-remediation state. In mid-2025, ahead of the ISO/IEC 27701:2025 publication and the DPDP Rules notification, Atharv's A.2.2 architecture was functional but uneven. The top-30 customers had signed DPAs (Atharv's Legal team had negotiated these). The remaining 290 customers had a mix of MSAs and click-through standard terms. The purposes register was informal (the customer-success team's understanding). The Marketing team used customer contact data for Atharv's own campaigns without an authorisation workflow. The Customer-Obligations Confirmation Form did not exist. The ROPA was a single spreadsheet.

The trigger. Atharv'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 (estimated May 2027). The decision was driven by three considerations: (i) the enterprise customers (the digital-lending NBFCs, the SEBI-regulated intermediaries) were increasingly asking for ISO/IEC 27701 attestation as a procurement requirement; (ii) Atharv was planning to launch an AI-driven user-segmentation feature that would attract DPDP section 10 scrutiny; (iii) a competitor had recently lost a procurement to a better-governed rival, and the Atharv leadership did not want to be the next illustrative scenario.

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

Quarter 1, Policy and master template. The team adopted the Singahi Customer-Agreement and Processor-Conditions Policy (toolkit doc 01). The team built the Customer-DPA Master Template with the Article 28(3) mandatory content, the security schedule, the sub-processor schedule, the transfer schedule, the breach-handoff clause (72-hour SLA to the customer; the dual-clock pattern documented), the audit-and-inspection clause (the customer's audit rights; the processor's right to demonstrate compliance through ISO/IEC 27701 certification in lieu of physical audit), and the data-return-or-destruction clause (the 90-day post-termination window). The team layered the sector overlays (the RBI inspection-rights clause for NBFC customers; the SEBI third-party clause for SEBI-regulated customers; the IRDAI ICT-outsourcing clause for insurer customers).

Quarter 2, DPA remediation and purposes register. The team ran a customer-by-customer DPA remediation cycle. For each Tier-1 customer (the top 30), the team negotiated an amendment or a side-letter that brought the DPA onto the current master template. For each Tier-2 customer (the next 200), the team rolled out a DPA-addendum programme through the customer-portal workflow, the customer signed in, reviewed the addendum, signed electronically, and the addendum was filed automatically. For each Tier-3 customer (the smallest 90), the team sent a click-through DPA update with a 30-day notice, the customer either accepted or moved to a paid tier. The team built the per-customer purposes register, populated from the DPA's nature-and-purpose clause and reconciled with the operational pipelines. The team enforced the multi-tenant isolation at the analytics-warehouse layer (per-customer partitions; cross-customer access prevention).

Quarter 3, Marketing-use policy and obligations confirmation. The team built the Marketing-and-Advertising-Use Policy (toolkit doc 03) and the prior-authorisation workflow. The Marketing team's campaigns were audited; the customer-contact-data uses were stopped pending the authorisation workflow. The benchmarks feature (a planned Q4 launch) was put through the workflow; three top customers were asked for authorisation; two agreed (with principal-consent flow-through conditions) and one declined (the feature was not deployed for that customer). The Article 28(10) status-drift register was built; the benchmarks feature and the operational analytics were analysed. The team built the Customer-Obligations Confirmation Form (toolkit doc 04) and the onboarding-gate workflow. The confirmation was collected from all 320 active customers through the customer-portal workflow over a 60-day cycle.

Quarter 4, Processor ROPA and certification. The team built the Processor ROPA template (toolkit doc 10, Appendix B) and populated it for all 320 customers through a combination of customer-portal data (the customer's name, contact, principal categories, data categories, retention rules), engineering data (the data-flow descriptions, the sub-processor list, the transfer destinations), and the security team's input (the security measures). The team ran the breach-handoff drill (tabletop in Q3; full drill in Q4) tracing the dual-clock pattern (DPDP 72-hour handoff to the customer; CERT-In 6-hour India-ICT-system report). The team ran the internal audit (Clause 9.2) covering all five A.2.2 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.2 family. The Stage 2 audit, conducted in March 2027, traced three sample customers (a digital-lending NBFC; an e-commerce platform; an edtech app) through the full A.2.2 stack, the signed DPA, the purposes register entry, the marketing-use attestation, the obligations confirmation, the ROPA entry. Zero major nonconformities on the A.2.2 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 Atharv) of approximately INR 40 to 120 crore (the unauthorised benchmarks feature; the marketing-use of customer data; the missing sub-processor disclosures; the missing DPDP section 2(1)(k) agreements). The remediation reduced the exposure by an estimated 90%.
• Revenue impact. The ISO/IEC 27701:2025 certification enabled the company to win three enterprise-customer contracts (two digital-lending NBFCs; one SEBI-regulated intermediary) that required the certification as a precondition, combined annual revenue approximately INR 9 crore. The certification also accelerated the AI-driven user-segmentation feature launch (the DPA's purposes register was tighter, which reduced the regulatory-review timeline).
• Operational efficiency. The customer-portal workflow removed approximately 280 person-hours per quarter of manual DPA-management effort. The central ROPA produced on request within 2 hours (against the pre-remediation baseline of 3 to 5 days).
• Procurement-cycle acceleration. The certification cut the average enterprise-procurement cycle from 14 weeks (the pre-remediation baseline, with privacy-diligence questions and side-letter negotiations) to 6 weeks (the post-remediation cycle, with the DPA master template and the ROPA on display).

The lessons.

• Treat the A.2.2 stack as a commercial investment, not a compliance cost. The customer-portal workflow, the multi-tenant isolation and the central ROPA delivered direct revenue (the enterprise-customer 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 DPA master template is the unlock. A single template, applied consistently across the portfolio, replaced 320 bespoke DPAs and 280 hours per quarter of manual management. The template is the operational foundation on which everything else runs.
• The purposes register is the engineering discipline. The per-customer purposes register and the multi-tenant isolation at the warehouse are the operational evidence that the processor's "we don't see each other's data" claim is true. The engineering investment pays for itself in the audit and the procurement cycle.
• The marketing-use discipline is the product-revenue unlock. The prior-authorisation workflow turned the benchmarks feature from a compliance risk into a lawful revenue-generating product. The discipline is not a brake on the product; it is the gate that lets the product launch.
• The drill makes the breach-handoff survivable. The full drill in Q4 exposed the gap between the documented playbook and the operational reality (the customer-portal credentials for some customers had expired; the Rule 7 intimation content was not pre-staged for the BFSI customers). The drill closed the gap before the regulator did.

Multi-Framework Mapping

The detailed crosswalk

The DPDP-section-to-A.2.2 map (load-bearing for India)

The DPDP Act section-by-section A.2.2 hooks: section 2(1)(k) (Data Processor, the functional definition that the A.2.2 stack supports); section 4 (grounds, drives the controller's lawful basis that the A.2.2.6 confirmation asks the controller to confirm); section 5 (notice, the controller's notice duty that the confirmation asks the controller to confirm); section 6 (consent, the controller's consent records; the purpose-limitation that drives the A.2.2.3 purposes discipline); section 7 (legitimate uses, the controller's non-consent grounds); section 8 (the fiduciary's obligations that flow through the A.2.2.2 DPA to the processor); section 8(5) (reasonable security safeguards, the A.2.2.2 security schedule); section 8(6) (breach notification, the A.2.2.2 breach-handoff clause; the 72-hour clock the processor's handoff feeds); section 8(7) (erasure, the A.2.2.2 data-return-or-destruction clause); sections 11 to 14 (rights, the controller's rights-handling process that the A.2.2.6 confirmation asks the controller to confirm); section 16 (cross-border negative list, the A.2.2.2 transfer-schedule dimension); section 33 and the Schedule (penalties, the fiduciary's penalty exposure that flows contractually to the processor through the A.2.2.2 indemnity clauses).

The sector-regulator overlay (India-specific)

Implementation Roadmap

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

The first 30 days, policy and quick wins

• Day 1 to 5, Sponsor and team. The DPO confirms executive sponsorship (the CEO or the COO for a growing processor; the board for an enterprise processor) and convenes the cross-functional team (DPO, Legal, Customer Success, Sales Engineering, Engineering, Security, Operations). The team adopts the Singahi Customer-Agreement and Processor-Conditions Policy (toolkit doc 01).
• Day 6 to 15, Customer-portfolio inventory. The team inventories every active controller-customer (the customer name; the relationship start date; the current contract in place; the customer's sector; the principal and data categories involved; the customer's revenue tier). The inventory typically surfaces 10 to 20% more customers than the team's pre-inventory estimate.
• Day 16 to 25, DPA gap audit. The team audits each customer against the Article 28(3) mandatory-terms checklist (toolkit doc 06). The output: the per-customer gap score (which mandatory terms are present; which are missing; which are present but substantively inadequate). The output drives the prioritisation for the gap-remediation cycle.
• Day 26 to 30, Quick wins. The team implements the top-three highest-risk remediations (typically: pulling the top-five customers onto the DPA Master Template; stopping the marketing team's unauthorised use of customer contact data; building the Customer-Obligations Confirmation Form for new customers from this point forward).

The 90-day milestone, registers and policy

• Day 31 to 50, DPA Master Template and gap remediation. The team finalises the DPA Master Template with the sector overlays (RBI, SEBI, IRDAI, CERT-In). The team launches the gap-remediation cycle for the top-quartile customers (by revenue or by risk).
• Day 51 to 70, Purposes register and Marketing-Use Policy. The team builds the per-customer purposes register (toolkit doc 02). The team builds the Marketing-and-Advertising-Use Policy and the prior-authorisation workflow (toolkit doc 03). The Article 28(10) status-drift register is started.
• Day 71 to 90, Customer-Obligations Confirmation Form and onboarding gate. The team builds the form (toolkit doc 04). The team configures the customer-portal workflow to enforce the onboarding gate (no customer is onboarded without the form completed and reviewed).

The 180-day milestone, ROPA and currency

• Day 91 to 120, Processor ROPA build. The team builds the Processor ROPA template (toolkit doc 10, Appendix B). The team populates the ROPA for the top-quartile customers through a combination of customer-portal data, engineering input and security input.
• Day 121 to 150, Reconciliation cadence. The team runs the first quarterly reconciliation of the DPA register, the purposes register, the marketing-use attestations, the obligations confirmations and the ROPA against the operational reality. The drift findings feed Clause 10.2 corrective action.
• Day 150 to 180, Multi-tenant isolation and breach-handoff drill. The team enforces the multi-tenant isolation at the warehouse (per-customer partitions; cross-customer access prevention). The team runs the first breach-handoff 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.2 maturity

• Month 7, 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.2 stack, when a sub-processor is added or changed, the affected customers' DPA schedules and ROPA entries are updated automatically.
• Month 8, Customer-portal workflow automation. The team automates the obligations-confirmation renewal cycle (the customer is reminded 30 days before the renewal; the form is pre-populated; the customer updates and signs electronically). The team automates the DPA change-control workflow (the customer's instruction under A.2.2.5 triggers a DPA review; the review produces a side-letter or an amendment; the customer-portal routes the change for signature).
• 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 five A.2.2 controls. The team closes the findings before the certification Stage 1.
• Month 11, Sector-overlay testing. The team tests the sector overlays (the RBI inspection clause with a sample bank customer; the SEBI third-party clause with a sample intermediary; the IRDAI ICT-outsourcing clause with a sample insurer). The team documents the operational readiness for a sector-regulator inspection.
• Month 12, Certification. The certification audit. The Stage 1 documentation review. The Stage 2 operational-effectiveness test. The A.2.2 walk-through (the auditor picks a recent customer onboarding and traces it through the full stack).

The ongoing cadence (post-certification)

• Weekly, KPI dashboard review (DPO); incident review (DPO); new-customer-onboarding check (Customer Success).
• Monthly, DPA gap-remediation progress; obligations-confirmation currency; ROPA currency; marketing-use workflow compliance.
• Quarterly, full reconciliation of the A.2.2 stack against the operational reality; Article 28(10) status-drift register review; sub-processor-chain reconciliation.
• Semi-annually, full breach-handoff drill (mid-market and enterprise processors); management review of the A.2.2 KPIs.
• Annually, internal audit of A.2.2; obligations-confirmation renewal cycle; marketing-use training refresh; DPA Master Template review.
• Event-driven, DPA change control for each customer-initiated change (the A.2.2.5 instruction-decision log); sub-processor change notifications (A.2.5.7 / A.2.5.8 / A.2.5.9); sector-regulator inspection readiness checks; corrective action on each finding.

FAQ

Q1. We are a SaaS processor and our customers send us their DPAs to sign. Do we still need our own DPA Master Template?

Yes. The customer's DPA may be sufficient for that customer, but you need a master template for two reasons. First, your master template is the fallback when the customer does not have one (the long-tail customers, the click-through customers, the small customers). Second, your master template is the reference point against which you assess customer-proposed DPAs, the redline positions, the sector overlays, the processor-protective clauses. Without your own template, you negotiate every customer DPA from scratch, which is operationally untenable for a portfolio of more than 20 customers.

Q2. How often should we reconcile the per-customer purposes register with the operational pipelines?

Quarterly is the conformant minimum. For high-volume processors (200+ customers) or processors with high-risk pipelines (AI/ML feature stores, cross-customer benchmarking uses), monthly reconciliation is recommended. The reconciliation is the operational evidence that the A.2.2.3 control is working; the absence of the reconciliation is the canonical A.2.2.3 audit finding.

Q3. We use customer data to train our own machine-learning model. Is that an A.2.2.4 violation?

It depends. If the customer has authorised the model-training use through the prior-authorisation workflow, and the customer has the principal's consent (or another lawful basis) for the secondary use, then the use is permitted under A.2.2.4. If the customer has not authorised, the use is prohibited and is a textbook Article 28(10) status-drift trigger. The Singahi recommendation is to run every model-training use through the prior-authorisation workflow regardless of the customer's commercial enthusiasm, and to document the Article 28(10) status-drift analysis. The Article 28(10) status-drift register is the audit evidence.

Q4. Some of our customers do not respond to the Customer-Obligations Confirmation request. What do we do?

Escalate. The onboarding gate should prevent the customer from being onboarded without the confirmation. For an existing customer that does not respond at renewal, the DPO documents the gap, the senior management makes the commercial decision (refuse renewal; renew with documented conditions and a remediation timeline; renew with the gap explicitly accepted as a top-management risk decision under Clause 6.1.3). The escalation pathway mirrors the A.2.2.5 refusal pattern. A customer that will not confirm its own obligations is a customer that puts the processor's A.2.2 conformity at risk.

Q5. Do we need a separate DPA for every customer, or can we use a master template with customer-specific schedules?

A master template with customer-specific schedules is the conformant pattern (and is explicitly permitted under GDPR Article 28(6)). The master template contains the standard clauses; the customer-specific schedule fills in the Article 28(3) mandatory content (subject-matter, duration, nature/purpose, data types, principal categories, obligations). For high-volume customer portfolios, the customer-portal workflow automates this, the customer fills in the schedule, signs electronically, and the executed DPA is filed automatically.

Q6. We process personal data across India, the EU and the US for the same customer. Do we need a single DPA or separate DPAs per jurisdiction?

A single DPA with per-jurisdiction schedules is the conformant pattern. The DPA's transfer schedule lists each destination with the transfer mechanism (the DPDP section 16 negative-list screen for India; the GDPR Chapter V mechanism for the EU; the US-state law compliance for the US). The processor ROPA records the cross-border transfers per customer per destination.

Q7. Our customers ask for our SOC 2 report instead of an on-site audit. Is that acceptable under A.2.2.2?

Yes. The audit-and-inspection clause in the DPA may permit the customer to rely on the processor's certifications (ISO/IEC 27701:2025; ISO/IEC 27001:2022; SOC 2) in lieu of physical audit. The customer's right to audit is preserved (the customer may still audit in defined circumstances, typically after an incident, or where the certification is materially deficient); the processor's right to demonstrate compliance through certifications is also preserved. The Singahi recommended pattern is the certifications-plus-audit-rights-on-incident clause.

Q8. We have a customer that wants us to use one of their sub-processors (not ours). How does that interact with A.2.2?

The customer's instruction to use the customer's-nominated sub-processor is processed through the A.2.2.5 instruction-decision log. The processor's review covers the three reference points: the agreement (does the DPA permit the customer to nominate sub-processors?); the controller's obligations (does the controller's nomination reflect the controller's notices and consents?); applicable law (does the sub-processor meet the security and cross-border requirements?). Where the review is positive, the sub-processor is engaged under a written agreement with the Article 28(4) terms; the sub-processor is added to the processor's ROPA and to the customer's DPA schedule.

Q9. The customer asks us to retain data beyond the agreed retention period because of a regulatory inquiry. What do we do?

The customer's instruction to extend retention is processed through the A.2.2.5 instruction-decision log. The processor's review confirms the legal-hold basis (the regulatory inquiry; the litigation hold); the extension is documented in the per-customer retention schedule (the A.2.2.7 ROPA's retention-rules content); the extension is lifted when the legal-hold basis ends. The customer's instruction is typically a lawful instruction within the A.2.2.2 DPA's legal-hold clause.

Q10. We are a startup processor with five customers and no formal DPAs. Where do we start?

Start with the Singahi Customer-DPA Master Template (toolkit doc 01, Appendix A). Customise it for your five customers; have your Legal team sign them. Build the per-customer purposes register (toolkit doc 02). Build the Customer-Obligations Confirmation Form (toolkit doc 04) and send it to your five customers. Build the Processor ROPA (toolkit doc 10, Appendix B) for the five customers. The alternative, building the stack after a customer incident, is an order of magnitude more expensive.

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

The customer's section 9 obligations flow through the A.2.2.2 DPA to you. The DPA must reflect: the verifiable-parental-consent overlay (the customer confirms in the A.2.2.6 obligations form that parental consent is captured); the no-behavioural-monitoring prohibition (your processing must not include behavioural monitoring of children); the no-targeted-advertising prohibition (your processing must not include targeted advertising to children). Your purposes register for this customer must reflect the tightened purposes (no marketing; no cross-customer benchmarking using the children's data). The retention rules must reflect the children's-data retention limits. The ROPA must reflect the children's principal category.

Q12. Our marketing team wants to publish a illustrative scenario using a customer's logo and aggregate metrics. Is that an A.2.2.4 issue?

Yes, potentially. The customer's logo use is a trademark/licence question (separate from A.2.2.4). The aggregate metrics use is an A.2.2.4 question, the processor's own marketing use of customer-derived data. The illustrative scenario should be processed through the prior-authorisation workflow: the customer's authorisation (typically through a separate case-study consent); the principal-consent flow-through (where the metrics are derived from principal data, the customer's consent-base should cover the case-study use); the Article 28(10) status-drift analysis (the case-study use is the processor's own marketing use; the controller's authorisation keeps the processor on the processor side of the line).

Q13. How long should we retain the processor ROPA entries after a customer is offboarded?

The ROPA entries should be retained for the period the processor may need to produce them, 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 offboarding evidence (the data-destruction certificate; the final ROPA entry at the time of offboarding) should be retained for the same period. The offboarded customer's personal data, however, must be returned or destroyed at offboarding per the A.2.2.2 DPA's data-return-or-destruction clause.

Q14. Our DPA with a customer says "the processor shall comply with applicable privacy laws". Is that enough?

No. A general "comply with applicable privacy laws" clause is a recital, not an operative commitment. The DPA must specify which privacy laws apply (DPDP Act 2023; GDPR if EU personal data; the US-state laws if US personal data; the sector rules); what the processor's specific obligations are under each (the security schedule; the sub-processor schedule; the transfer schedule; the breach-handoff clause; the audit clause); and what the consequences of non-compliance are (the indemnity; the liability cap; the termination right). The Singahi DPA Master Template provides the operative content.

Q15. We are a processor to an SDF (Significant Data Fiduciary under DPDP section 10). What additional A.2.2 content do we need?

The SDF's enhanced obligations under section 10 flow through the A.2.2.2 DPA to you. The DPA must reflect: the SDF's DPIP recommendations (additional security measures; tighter retention; sub-processor restrictions; transfer restrictions); the SDF's independent-data-audit rights (the audit clause must accommodate the SDF's Board-recognised independent auditor); the SDF's algorithmic-AI fairness review (where the processing involves AI / statistical inference, the DPA must specify the processor's support for the fairness review, input-data minimisation, accuracy KPIs, disparate-impact analysis). Your purposes register, your obligations confirmation and your ROPA for the SDF customer must reflect these overlays. The SDF is also typically subject to enhanced sector-regulator oversight (RBI, SEBI, IRDAI), which the DPA must accommodate.

Industry-Specific Requirements

BFSI (processors serving banks, NBFCs, insurers)

BFSI is the most prescriptively regulated Indian sector for processor relationships. The load-bearing instruments:

• RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025), the customer agreement with a bank customer must allow the RBI to inspect the processor; must restrict the processor from further outsourcing without the bank's prior written permission; must include the data-locality clauses; must provide for the bank's audit rights; must specify the breach-notification timeline; must include the indemnity and liability clauses.
• RBI NBFC Managing Risks in Outsourcing Directions, 2025, similar duties for NBFC customers; the customer agreement must reflect the NBFC outsourcing framework.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) (20 August 2024), for SEBI-regulated intermediary customers, the customer agreement must reflect the third-party and outsourcing expectations.
• IRDAI Information and Cyber Security Guidelines (24 April 2023), for insurer customers, the customer agreement must reflect the ICT-outsourcing data-protection clauses; the policyholder-data confidentiality; the data-locality for policyholder data.
• RBI Storage of Payment System Data (6 April 2018), where the processor processes payment-system data for a bank or PSO customer, the data-locality rule applies; the customer agreement's transfer schedule must reflect this.

A.2.2 emphasis for BFSI processors. The DPA must be sector-overlayed (the RBI / SEBI / IRDAI clauses layered onto the master template); the customer-obligations confirmation must capture the customer's sector-law duties; the ROPA must reflect the data-locality dimension; the breach-handoff drill must trace the RBI / SEBI / IRDAI clocks alongside CERT-In and DPDP; the marketing-use policy is non-negotiable (the BFSI customer's data must not be used for the processor's own marketing or benchmarking without explicit authorisation).

Healthcare (processors serving hospitals, insurers, telemedicine platforms)

Healthcare data is sensitive (DPDP Rules' sensitive-PDP categories; GDPR Article 9 special categories). The customer agreement must reflect the heightened sensitivity, the security schedule is tighter (encryption at rest and in transit; tighter access controls; tighter audit logging); the sub-processor schedule reflects the healthcare-specific sub-processors (the diagnostic-lab partners; the pharmacy partners; the telemedicine-platform partners); the retention rules reflect the clinical-record retention rules (typically 5 to 7 years for adult patients; longer for minors); the breach-handoff drill must trace the healthcare-specific notification patterns.

For US-healthcare customers, the customer agreement may need to reflect the HIPAA Business Associate Agreement (BAA) pattern, a US-specific overlay on the Article 28(3) DPA. The Singahi DPA Master Template includes the HIPAA BAA overlay where applicable.

A.2.2 emphasis for healthcare processors. Explicit-tighter security schedule; healthcare-specific sub-processor schedule; clinical-record retention rules; HIPAA BAA overlay where applicable; the customer-obligations confirmation must capture the heightened sensitivity; the ROPA must reflect the healthcare data categories and the heightened retention.

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.2 stack for the SaaS processor is the canonical illustrative scenario (Section 15).

A.2.2 emphasis for IT-ITeS and SaaS. Multi-jurisdiction DPA regime (single master template with per-jurisdiction schedules); the customer-portal workflow for high-volume onboarding; the multi-tenant isolation discipline; the marketing-use prior-authorisation workflow (the marquee A.2.2.4 risk for SaaS processors that have customer-contact data and benchmarks features); the Article 28(10) status-drift register; the developer-environment discipline (no production data in dev environments; the developer-environment data is synthetic or de-identified); 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 controller-customers). The customer portfolio is diverse; the data is high-volume; the cross-border dimension is significant (international shipping; cross-border payments).

A.2.2 emphasis for e-commerce enablers. Joint-controller-relationship analysis where the line between processor and joint controller is unclear (the recommendation-engine processor that determines the targeting is arguably a joint controller); the purposes discipline must bound the processor's use of the e-commerce platform's data; the cross-border transfer schedule must reflect the international-shipping and cross-border-payment destinations; the marketing-use policy must address the temptation to use the e-commerce platform's data for the processor's own product recommendations.

Edtech processors

Edtech processors serve edtech platforms that may attract users under eighteen (DPDP section 9). The customer agreement must reflect the verifiable-parental-consent overlay; the no-behavioural-monitoring prohibition; the no-targeted-advertising prohibition. The processor's purposes register for an edtech customer must reflect the tightened purposes.

A.2.2 emphasis for edtech processors. The DPDP section 9 overlay on the customer agreement; the customer-obligations confirmation must capture the edtech platform's parental-consent mechanism; the purposes register must exclude marketing and behavioural-monitoring uses of children's data; the retention schedule must reflect the children's-data retention limits; the ROPA must reflect the children's principal category.

Manufacturing (IIoT, Industry 4.0 processors)

Manufacturing processors typically serve OEM customers (the controller-customers); the data may include operator-identification, shift-rotation, safety-incident records. The customer agreement's purposes discipline must bound the processor's use of the IIoT data; the marketing-use policy must address the temptation to use the OEM's data for the processor's own benchmarking or product-recommendation uses.

A.2.2 emphasis for manufacturing processors. The IIoT-data purposes discipline (the processor must not use the OEM's operator data for cross-OEM benchmarking without authorisation); the long-tail retention dimension (safety and product-liability records may need 10 to 15 years retention); the cross-border dimension for multi-plant operations; the joint-controller analysis where the OEM and the processor jointly determine the processing purposes.

Maturity Model

Figure · Tiers

Maturity levels for conditions for collection and processing (remaining)

Level 1, Initial / Ad-hoc

Characteristics. No Customer-Agreement Policy. No DPA Master Template. The customer portfolio is governed by a mix of MSAs and click-through terms. No per-customer purposes register. No Marketing-and-Advertising-Use Policy. The Marketing and Sales teams use customer contact data freely. No Customer-Obligations Confirmation Form. No processor ROPA (or a single spreadsheet with one row per customer, last updated 12+ months ago). No Article 28(10) status-drift register. No breach-handoff drill.

Typical artefacts. A privacy policy on the website. The MSA template. The CRM with the customer list.

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

The investment covers the policy adoption, the DPA Master Template, the customer-portfolio inventory, the DPA gap audit, the top-customer remediation.

Level 2, Repeatable / Defined

Characteristics. A documented Customer-Agreement Policy. A DPA Master Template in place. The customer-portfolio inventory complete. The top-quartile customers on conformant DPAs. The per-customer purposes register drafted for the top customers. The Marketing-and-Advertising-Use Policy adopted. The Customer-Obligations Confirmation Form designed. The processor ROPA template drafted. The Article 28(10) status-drift register designed. The first onboarding gate configured.

Typical artefacts. The Customer-Agreement Policy; the DPA Master Template; the per-customer purposes register (top customers); the Marketing-and-Advertising-Use Policy; the Customer-Obligations Confirmation Form template; the Processor ROPA template.

The investment covers the full customer-portfolio remediation, the customer-portal workflow build, the multi-tenant isolation enforcement, the purposes-register reconciliation cadence, the first breach-handoff drill.

Level 3, Managed / Measured

Characteristics. The full customer portfolio on conformant DPAs. The customer-portal workflow enforcing the DPA execution and the obligations confirmation before processing. The per-customer purposes register reconciled quarterly with the operational pipelines. The multi-tenant isolation enforced at the warehouse. The Marketing-and-Advertising-Use Policy and the prior-authorisation workflow operating. The Article 28(10) status-drift register maintained and reviewed quarterly. The Processor ROPA populated across the portfolio, reconciled quarterly. The first full breach-handoff drill run; the dual-clock pattern documented. The fifteen KPIs reporting; the first management-review pack produced.

Typical artefacts. The operational DPA register; the customer-portal workflow; the per-customer purposes register (live); the multi-tenant isolation configuration; the prior-authorisation workflow records; the Article 28(10) status-drift register; the central ROPA; the breach-handoff drill report; the KPI dashboard; the first internal-audit report on A.2.2.

The investment covers the KPI maturity, the sector-overlay testing, the Article 28(10) status-drift register drilled quarterly with marginal-case analyses, the multi-tenant isolation drift detection.

Level 4, Quantitatively Managed

Characteristics. The DPA change-control operating automatically (customer instructions under A.2.2.5 trigger DPA reviews; the customer-portal routes changes for signature). The multi-tenant isolation drift-detection firing quarterly; each drift feeding Clause 10.2 corrective action. The Article 28(10) status-drift register reviewed quarterly with documented marginal-case analyses. The breach-handoff drill running semi-annually with the CERT-In 6-hour clock, the DPDP 72-hour clock and the sector-regulator clocks met. The KPI targets consistently met; the management-review pack driving Clause 10.1 improvement. The sub-processor chain integrated with the ROPA (sub-processor changes update the affected customers' ROPA entries automatically). The customer-obligations-confirmation renewal cycle automated.

Typical artefacts. The DPA change-control automation evidence; the drift-detection log; the Article 28(10) status-drift marginal-case analyses; the semi-annual drill reports; the management-review minutes with KPI trend analysis; the sub-processor-chain integration evidence.

Level 5, Optimising

Characteristics. The A.2.2 stack is a continuous improvement discipline. The customer-portfolio governance produces predictive analytics (which customers are at risk of drift; which customers' purposes registers need refresh; which customers' obligations confirmations are likely to be inadequate at renewal). The multi-tenant isolation is a zero-trust architecture (per-customer encryption; per-customer access tokens; per-customer audit trails). The breach-handoff 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 (which sub-processor changes are likely; which marketing-use requests will surface; which customer-agreement gaps will emerge). The A.2.2 architecture is integrated with the broader privacy engineering practice (the customer-DPA-master-template is the system-of-record for the entire customer portfolio; the ROPA is the system-of-record for the entire processing estate).

Typical artefacts. The continuous-improvement log; the predictive-analytics dashboard; the zero-trust multi-tenant isolation architecture documentation; the multi-incident drill reports; the engineering-integration evidence.

Maturity-model quick-reference

Emerging Trends

The DPDP Rules' phased commencement and the A.2.2 stack

The DPDP Rules 2025 (notified 13 November 2025) phase in through 2026 and 2027. The customer-obligations confirmation (A.2.2.6) is the load-bearing A.2.2 dimension affected, the customer's notices, consents, retention rules and rights-handling process must reflect the Rules' operational features (the consent-notice content; the verifiable-parental-consent mechanism; the 48-hour pre-erasure notice; the SDF DPIP format). Processors that build the A.2.2 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.2 with AI governance

The DPDP section 10 algorithmic-fairness overlay (for SDFs) and the broader AI-governance movement are converging with the A.2.2 stack. The processor's customer-agreement must reflect the SDF customer's DPIP recommendations; the marketing-use policy must address the model-training uses of customer data (the prior-authorisation workflow); the Article 28(10) status-drift register must address the AI-training cases. The emerging practice is to treat AI governance as an extension of A.2.2, with the algorithmic-fairness review as the AI-specific overlay on the A.2.2.6 obligations confirmation.

The customer-portal as the A.2.2 operating system

The customer-portal workflow is becoming the operating system for the A.2.2 stack. The portal hosts the DPA execution, the obligations-confirmation intake, the marketing-use authorisation requests, the sub-processor-change notifications, the ROPA production-on-request, the breach-handoff communication. The portal-driven A.2.2 stack is the conformant pattern for high-volume customer portfolios; manual A.2.2 management does not scale beyond 25 to 50 customers.

The rise of the standard contractual clauses and the Indian response

The GDPR modernised SCCs (Implementing Decision (EU) 2021/914 of 4 June 2021) and the UK IDTA / UK Addendum are the transfer tools referenced in the A.2.2.2 DPA's transfer schedule for EU and UK origin data. The DPDP Act 2023 section 16 negative-list approach is structurally different, transfer permitted to any country except those notified as restricted. As the Central Government notifies the restricted countries (the first notifications are expected through 2026 and 2027), the A.2.2.2 transfer schedule must be updated for the affected customers; the affected flows must be re-routed (typically to in-India regions or to non-restricted destinations).

Privacy-enhancing technologies (PETs) and the marketing-use discipline

PETs, pseudonymisation, tokenisation, differential privacy, federated learning, homomorphic encryption, synthetic data, are changing the marketing-use discipline. Where the processor can demonstrate that the secondary use (the benchmarking feature; the model-training use) is performed on truly anonymised data (with the anonymisation discipline documented), the A.2.2.4 control may be satisfied without the prior-authorisation workflow (the data is no longer personal data). The current state of PETs does not reliably achieve anonymisation for high-dimensional behavioural data; the prior-authorisation workflow remains the conformant pattern. As PETs mature, the workflow will narrow.

The integration of A.2.2 with the consent-manager ecosystem

The DPDP Consent Manager (section 2(1)(g)) is the Indian-native construct that may, as the ecosystem matures, integrate with the A.2.2 stack, the customer-obligations confirmation (A.2.2.6) may, for consent-based processing, draw on the Consent Manager's interoperable consent records. The integration is at the early-discussion stage in mid-2026; processors building today should design the A.2.2 stack to accommodate the Consent Manager integration as the ecosystem goes live.

The convergence of A.2.2 with security-by-design

Privacy by design (the A.1.4 / A.2.4 family for the controller / processor) and security by design (ISO/IEC 27002:2022 control 8.25 / secure development life cycle) are converging with the A.2.2 stack. The customer-DPA-master-template's security schedule is the contractual anchor; the A.2.4 controls operationalise the security on the customer's data; the security-by-design engineering discipline builds the security into the product. The three layers, contractual (A.2.2.2), operational (A.2.4), and engineering (security-by-design), are increasingly designed as a single discipline.

The emergence of the data-mesh and the implications for A.2.2

The data-mesh architectural pattern, distributed data ownership, domain-oriented data products, federated governance, is being adopted by some Indian enterprises for analytics-scale data estates. The implications for A.2.2: the per-customer purposes register must operate across the mesh (each domain must respect the per-customer purposes); the ROPA must reflect the mesh's data flows; the multi-tenant isolation discipline must operate at the domain level. The mesh is operationally complex; processors adopting it should design the A.2.2 discipline in parallel, not as an afterthought.

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.19 to 5.23 supplier agreements; control 5.34 PII protection, the only PII-specific 27002 control).
• ISO/IEC 27018:2019, Code of practice for protection of PII in public clouds acting as PII processor (clause 7 customer agreement; 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, Accountability; Purpose Legitimacy and Specification; Openness, Transparency and Notice).
• ISO/IEC 29134:2017, Guidelines for privacy impact assessment.
• ISO/IEC 27706:2025, PIMS certification-scheme competence (Ed 1, October 2025; replaces ISO/IEC TS 27006-2:2021).
• ISO/IEC 17021-1:2015, Management-system certification-body requirements.
• ISO/IEC 27006 (current edition), ISMS certification-body requirements.

Indian regulatory instruments

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

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 (processor relationships); Article 28(3) (mandatory DPA content); Article 28(4) (sub-processor terms); Article 28(10) (controller-status drift); Article 30(2) (processor ROPA); Article 32 (security of processing); Article 33 (breach notification, 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.); CCPA effective 1 January 2020; CPRA effective 1 January 2023.
• 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 39 (operator/processor duties). Effective 18 September 2020.
• China, PIPL, Article 21 (entrustment agreement, mandatory content). Effective 1 November 2021.
• Singapore, PDPA 2012 (No. 26 of 2012), section 9 (protection obligation, written contract with processors).
• Canada, PIPEDA (S.C. 2000, c. 5), Schedule 1 Principle 4.1.3.
• Australia, Privacy Act 1988; Australian Privacy Principles.
• South Korea, PIPA (Act No. 10469 of 2011, as amended 2023).
• UAE, Federal Decree-Law No. 45 of 2021 (PDPL).
• Saudi Arabia, PDPL (Royal Decree M/19), in force 14 September 2023; full enforcement 14 September 2024.
• South Africa, POPIA (Act 4 of 2013), section 21 (operator).

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. Govern-P (privacy roles); Control-P (data-use agreements, data-processing management); Identify-P (data-mapping).
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (TSC 2017; 2022 Points of Focus update). The Privacy criteria: P3.0 (Collection), P4.0 (Use, retention, and disposal), P6.0 (Disclosure and notification), P8.0 (Monitoring). The Common Criteria CC9.2 on vendor oversight.
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor; Guidelines 05/2020 on consent; Guidelines 9/2022 on personal data breach notification; Recommendations 01/2020 on supplementary measures.

Certification-scheme and practitioner references (generic)

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