ISO 27701 A.2.2.5: Infringing Instruction

Quick Reference (60 Seconds)

If you only read one thing: Control A.2.2.5 is where the processor stops being a passive conduit for the controller's instructions and becomes an active compliance gate. An A.2.2.5-conformant processor is one in which every customer instruction is logged; every instruction is triaged against the agreement, the controller's obligations and applicable law; suspect instructions are escalated through a documented workflow; infringing instructions are refused and the refusal is notified to the controller; and the instruction-decision log is the evidence base against which both the certification auditor and (after an incident) the controller's regulator will test the processor's behaviour. Not a DPA clause that says "the processor shall act only on documented instructions"; an instruction-decision log that proves the processor did. The certification auditor picks a recent change to a customer's processing and walks the intake, the review, the escalation (if any), the refusal or compliance decision, the notification and the documentation. The Data Protection Board of India will, after a complaint or an incident at the controller-customer, ask whether the processor flagged the infringing instruction that led to the harm. Get A.2.2.5 wrong, no intake channel, no review checklist, no escalation workflow, no refusal notifications, no instruction-decision log, and the processor's broader privacy claim is unsupported by the operational evidence the controller-customer's regulator, the processor's own regulator (RBI, SEBI, IRDAI), the certification body and the controller-customer (in any contractual indemnity dispute) now expect.

What the Standard Actually Requires

Figure · Process

What Clause A.2.2.5 asks you to do

The paraphrased requirement

ISO/IEC 27701:2025 control A.2.2.5 asks PII processors to inform the controller-customer where, in the processor's opinion, a processing instruction infringes applicable legal requirements. Note precisely what the control does and does not say: the duty the standard imposes is to form an opinion and tell the customer, it does not itself oblige the processor to refuse the instruction. Refusal is a commercial and legal decision the processor may still take (and often should, since acting on an unlawful instruction risks controller status under GDPR Article 28(10) and direct DPDP exposure), but an auditor tests the notification and its record, not the refusal. Five load-bearing ideas sit inside that paraphrase, and auditors test each separately.

The processor must refuse to act on infringing instructions. The verb is operational, not declaratory. A DPA clause that says "the processor shall act only on documented instructions from the controller" does not satisfy A.2.2.5; a documented refusal of an actual infringing instruction, with the notification to the controller, does. The refusal is mandatory once the processor has determined that the instruction infringes, not discretionary, not contingent on the customer's commercial importance, not deferred to a quarterly business review. The processor that quietly complies with an infringing instruction to preserve the customer relationship has already failed the control and has, under the EU lineage (GDPR Article 28(10)), potentially drifted into controller status for that processing.

The processor must apply this duty to a customer's instruction. The customer is the PII controller (DPDP: Data Fiduciary; GDPR: controller); the processor acts on behalf of the customer. An "instruction" is any direction from the controller that determines or modifies the processing, the obvious cases (a new purpose, a new sub-processor, a new cross-border destination, a new marketing use, a new data category, a new recipient) and the less-obvious cases (an ad-hoc pull of personal data for the controller's sales team that exceeds the agreed purpose; a request to retain data beyond the agreed retention; a request to use the controller's data to train the processor's own model; a request to share the controller's data with another controller-customer of the processor; a request to disable a security control to speed up an integration). The breadth of what counts as an instruction is itself a control decision, the processor's intake-triage checklist defines the categories that trigger a formal review.

The processor must assess whether the instruction would infringe the agreement or the customer's own obligations or applicable law. Three reference points, each auditable. The agreement is the data-processing agreement (or the master services agreement with a DPA overlay, or the cloud-service terms with a DPA addendum) between the processor and the controller, the document that defines what the processor is engaged to do, on whose data, for what purposes, with what sub-processors, with what security, with what cross-border flows, with what retention, with what breach-handoff. An instruction that exceeds the scope of the agreement infringes the agreement. The customer's own obligations are the obligations the controller owes to its PII principals and to its regulator, the controller's notices, consents, lawful bases, retention rules, principal-side rights, sector-law duties. An instruction that the controller gives but that would put the controller in breach of its own obligations (because, for example, the controller has not obtained consent for the new purpose, or the new sub-processor was not disclosed in the controller's privacy notice, or the new cross-border destination is on the DPDP section 16 negative list) infringes the customer's obligations. Applicable law is the law that governs the processing, DPDP, GDPR, US-state laws, China PIPL, Brazil LGPD, the sector rules (RBI, SEBI, IRDAI, CERT-In). An instruction that would cause the processing to breach applicable law infringes on the law itself.

The processor must notify the customer of the refusal. The notification is a documented communication through a defined channel (the DPA's notice channel, typically email to a designated controller contact, with a ticket in the processor's request-management system). The notification states the instruction that was refused, the reasoning (which of the three reference points the instruction infringed), the processor's proposed alternative (where one exists, for example, "we cannot use your customer data to train our model, but we can offer a separate licensed-data arrangement"), and the escalation path (the controller's right to withdraw the instruction, to amend the agreement, or to escalate to the processor's senior management). A refusal without a notification is not a refusal, the controller must know that the processor did not act.

The processor must do this through a documented process. The instruction-decision log is the canonical evidence object, every instruction received, the intake-triage decision, the legal-and-compliance review (where triggered), the customer-escalation record (where triggered), the final disposition (comply, comply-with-conditions, refuse), the notification record, the follow-up. The log is documented information under Clause 7.5, version-controlled, access-controlled, retention-managed, retrievable. The certification auditor and (after an incident) the controller's regulator will walk this log end-to-end.

The lineage, 2019 to 2025

The 2025 control has a clean ancestor in the 2019 edition. Under 27701:2019, the processor-side infringing-instruction duty lived in clause 8 (the processor controls), at 8.2.4, the wording tracked the GDPR Article 28(3) language. The 2025 consolidation moves it to A.2.2.5 inside theme A.2.2 (conditions for collection and processing) of the single consolidated Annex A. The relocation is architecturally meaningful: the infringing-instruction control is now positioned as a condition for processing, alongside the customer-agreement control (A.2.2.2), the processor's-own-purposes control (A.2.2.3), the marketing-use control (A.2.2.4), the customer-obligations control (A.2.2.6) and the records-related-to-processing control (A.2.2.7). The six controls together form the conditions under which a processor may collect and process personal data on behalf of a controller, and the infringing-instruction control is the operational gate through which every actual instruction must pass.

The 2025 edition also makes Annex B (implementation guidance) normative. The B.2.2.5 guidance explains how a processor should structure the infringing-instruction process, the intake channel, the legal-and-compliance review, the customer-escalation workflow, the refusal and notification mechanics, the documentation discipline. Auditors now test against B.2.2.5 explicitly; an A.2.2.5 audit that does not also walk through the B.2.2.5 guidance is incomplete. The pre-2019 framing of "act only on documented instructions" is no longer sufficient; the processor must show the process behind the clause.

The Article 28(10) trap, processor becomes controller

The most consequential external anchor for A.2.2.5 is GDPR Article 28(10), which 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). Article 28(10) is the legal mechanism that turns an A.2.2.5 failure (the processor complied with an infringing instruction, or the processor went beyond the controller's instructions for its own purposes) into a controller-status determination.

The Indian DPDP equivalent is less explicit but functionally parallel. The DPDP Act defines Data Processor in section 2(1)(k) as a person who processes personal data on behalf of a Data Fiduciary, and the entire data-processor regulatory regime (the section 8 flow-through, the section 8(6) breach-handoff, the contractual foundation) is premised on the processor acting on the fiduciary's instructions. A processor that processes for its own purposes (a SaaS analytics vendor that uses customer data to train a benchmarking model that it sells to other customers; a BPO that uses one customer's data to refine a service it sells to another customer) is no longer "processing on behalf of", 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 is the processor's internal documentation 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 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?). A.2.2.5 is the control that keeps the register short, every instruction that would push the processor towards controller status is the kind of instruction the control is designed to refuse.

The DPDP processor-side framing

In India, A.2.2.5 has a regulatory weight that goes beyond the ISO standard itself. The DPDP Act 2023 builds the data-processor regime around four load-bearing provisions.

Section 2(1)(k), Data Processor. A person who processes personal data on behalf of a Data Fiduciary. The definition is functional, the test is whether the processing is "on behalf of" the fiduciary, which in turn depends on whether the fiduciary's instructions determine the purposes and means of the processing. A.2.2.5 is the operational control that keeps the processor on the "on behalf of" side of the line.

Section 8, obligations of the Data Fiduciary. Section 8 imposes the substantive privacy obligations on the fiduciary (section 8(5) reasonable security safeguards; section 8(6) breach notification; section 8(7) erasure). The fiduciary discharges these obligations partly through its own operations and partly through the processor's operations. The processor's agreement with the fiduciary flows the obligations downstream, the processor implements the safeguards, the processor notifies the fiduciary of breaches (the fiduciary then notifies the Board), the processor erases on the fiduciary's instruction. A.2.2.5 is the control that ensures the processor's compliance with these flowed obligations, an infringing instruction that the processor complied with (for example, "skip the breach notification for this incident, we do not want the Board to know") would expose both the fiduciary (section 8(6) failure) and the processor (contractual indemnity, reputational damage, the prospect of being named in the DPBI's investigation).

Section 8(6), the breach-handoff. On becoming aware of a personal data breach, the Data Fiduciary must notify the Board and each affected Data Principal in the prescribed form and timeline (DPDP Rules 2025 Rule 7: 72 hours to the Board). The processor's role is to notify the fiduciary, the Rules' the Rule 7 intimation content expects the fiduciary to know the breach details, and the fiduciary can know them only if the processor has handed them off. A.2.2.5 is implicated at two points: first, the instruction that may have caused the breach (an instruction to disable a security control; an instruction to add a sub-processor without due diligence; an instruction to share the data with an unauthorised recipient) is the kind of infringing instruction the control is designed to refuse; second, the instruction that attempts to suppress the breach notification (the controller instructs the processor not to report the breach to the fiduciary's management, or not to log the breach in the processor's incident records) is a textbook infringing instruction. The processor's A.2.2.5 process is the upstream gate that prevents the breach-handoff failure.

Section 33 + Schedule, the penalty exposure. The Schedule's penalty maxima (up to two hundred and fifty crore rupees for section 8(5) failure; up to two hundred crore for section 8(6) failure; up to one hundred and fifty crore for section 10 SDF non-fulfilment; up to fifty crore for various other failures) attach to the Data Fiduciary. The fiduciary's exposure flows contractually to the processor through the indemnity clauses in the DPA, the processor that complied with an infringing instruction that caused a fiduciary-level breach is the processor that pays the indemnity.

The five-stage process, preview; full methodology in Section 7

A conformant A.2.2.5 operation runs five stages, and the Singahi five-stage infringing-instruction lifecycle (Section 7) operationalises them. The stages map to the certification auditor's examination moves, and each stage's evidence is testable.

1. Intake and triage, every customer instruction received through a defined intake channel; the instruction logged in the instruction-decision log with the metadata (customer, date, instruction category, requestor, channel); a triage decision (routine / review-required / urgent-escalation) made by the trained operations team.
2. Legal-and-compliance review, for review-required instructions, a structured review against the three reference points (the agreement, the controller's obligations, applicable law); the review produces a recommendation (comply / comply-with-conditions / refuse / escalate-to-customer) with the documented reasoning.
3. Customer escalation, for instructions where the review is inconclusive or where the instruction is presumptively infringing, a documented escalation to the controller-customer with a clarification request; the controller's response is logged and feeds the final decision.
4. Refusal or comply decision, the final disposition, with the authority level commensurate with the risk (operational for routine; DPO for review-required; executive for high-risk refusals of significant customers); the notification of the decision to the controller-customer through the DPA's notice channel.
5. Documentation and notification, the instruction-decision log updated with the full decision trail; the breach-handoff procedure triggered where the instruction-related processing caused or may cause a personal-data breach; the Article 28(10) status-drift analysis logged where the instruction may have moved the processor towards controller status.

Demarcations: A.2.2.5 vs A.2.2.2 / A.2.2.6 / Clause 8.1; what is NOT required

Four demarcations matter.

A.2.2.5 vs A.2.2.2, Customer agreement. A.2.2.2 governs the existence and content of the data-processing agreement, the contract under which instructions are issued. A.2.2.5 governs the operation of the agreement, what the processor does when an actual instruction arrives. The two are sequential: the A.2.2.2 DPA sets the rules; A.2.2.5 is the runtime enforcement. 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 against which to assess an instruction.

A.2.2.5 vs A.2.2.6, Customer obligations. A.2.2.6 governs the processor's help to the controller in discharging the controller's own obligations (the controller's notices, consents, rights-handling, retention rules). A.2.2.5 governs the processor's refusal when the controller's instruction would put the controller in breach of those obligations. The two are complementary: A.2.2.6 is the processor's positive help; A.2.2.5 is the processor's negative gate. Together they implement the broader principle that the processor is the controller's compliance partner, not the controller's mute servant.

A.2.2.5 vs Clause 8.1, Operational planning and control. 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.5 governs a specific operational process: the handling of controller instructions. The two interlock: Clause 8.1 is the framework within which the A.2.2.5 process sits; A.2.2.5 is a specific process within that framework.

What A.2.2.5 does NOT require. It does not require the processor to refuse every instruction that is operationally inconvenient (the control is about legal and contractual infringement, not operational difficulty). It does not require the processor to act as the controller's privacy lawyer (the processor's review is a reasonableness check against the three reference points; the controller remains responsible for its own obligations). It does not require the processor to refuse an instruction that is unusual but lawful and within the agreement (the processor may comply, with the review documented). It does not require the processor to refuse an instruction that is unlawful but compelled by a valid legal process (a court order, a regulator's directive, the processor complies with the legal process and notifies the controller where the legal process permits). It does not require the processor to refuse an instruction that the controller has documented authority to give even if the processor disagrees with the controller's judgement (the processor's role is not to second-guess the controller's lawful business decisions).

The companion guidance, Annex B is normative in 2025

In 27701:2019 the implementation guidance lived in informative Annex F. In 27701:2025 the guidance lives in Annex B (Implementation Guidance for PII Controllers and Processors), and Annex B is normative. The B.2.2.5 guidance explains how a processor should structure the infringing-instruction process, the intake channel, the legal-and-compliance review checklist, the customer-escalation workflow, the refusal-notification template, the instruction-decision log, the breach-handoff integration, the Article 28(10) status-drift register. Auditors test against it. The five most relevant external anchors (full mapping in Section 16): GDPR Article 28(3) (the documented-instructions duty) and Article 28(10) (the controller-status-drift rule); ISO/IEC 27018:2019 (the cloud-PII-processor code of practice, its clauses on customer instructions and co-operation with the controller); ISO/IEC 27002:2022 control 5.19 (supplier relationships) and control 5.34 (Privacy and protection of PII, the only PII-specific control in 27002); NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020), Control-P (data-use agreements); SOC 2 Privacy TSC P6.0 (Disclosure and notification) and the Common Criteria on vendor oversight (CC9.2).

What auditors actually check

The certification auditor's A.2.2.5 examination has seven predictable moves (the 26-question checklist is in Section 11). First, ask for the Infringing-Instruction Policy and the Instruction-Decision Log, do they exist, are they current, does the log's coverage reconcile with the customer change-management records. Second, ask for the intake-triage procedure, what channels are authorised, what categories trigger a formal review, who is trained on the triage. Third, pick a recent change to a customer's processing (a new field, a new sub-processor, a new analytics use, a marketing-use ask, a cross-border destination change) and walk the intake and review decision. Fourth, walk a sample instruction-decision record through the five stages, intake, review, escalation (if any), final disposition, notification. Fifth, ask for the refusal-notification template and a sample of refusals issued in the last 12 months. Sixth, ask for the Article 28(10) status-drift register and the breach-handoff procedure (with the most recent drill). Seventh, trace the instruction-decision log's entries into the change-management records, the sub-processor-change notifications (A.2.5.9) and the ROPA (A.2.2.7), the log is not a stand-alone artefact; it feeds the wider PIMS.

Why This Control Matters

The processor as the compliance gate

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, A.2.2.5 is the operational heart. A processor that cannot show its working, that cannot demonstrate, for the actual instructions it received from controller-customers, that it triaged each instruction, reviewed the suspect ones, escalated the marginal ones, refused the infringing ones, notified the customer, and documented the entire decision trail, has no defensible privacy position, whatever its DPA says.

This is why A.2.2.5 is the most-audited processor control in the 27701 universe, and the control most often cited in the post-incident reviews that follow a controller-level breach. The European early GDPR enforcement actions on processor conduct, the Garante's decisions on analytics vendors that processed beyond the controller's instructions; the CNIL's decisions on marketing-technology vendors that used customer data for their own purposes; the AEPD's decisions on cloud providers that shared customer data across their own service lines; the EDPB's guidelines on Article 28 that emphasise the processor's "duty to inform the controller if an instruction infringes the Regulation", all turned on whether the processor had operated the gate that A.2.2.5 requires. In India, the DPDP Act's section 8(5) and section 8(6) flow-through to processors, the RBI IT-outsourcing regime, and the SEBI / IRDAI third-party expectations make A.2.2.5 the highest-exposed operational control in the Indian processor landscape.

The Indian regulatory weight

In India, A.2.2.5 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 that complied with an infringing instruction (or that processed for its own purposes) is at risk of losing the "on behalf of" status, with the consequence that the processor may be treated as a fiduciary for that processing (with the section 8 obligations, the section 10 SDF duties if the thresholds are met, and the section 33 + Schedule penalty exposure). The A.2.2.5 control is the operational discipline that keeps the processor on the right side of the line.

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 to flag an infringing instruction that causes a section 8(5) safeguards failure or a section 8(6) breach-notification failure propagates back to the fiduciary's penalty exposure (up to two hundred and fifty crore rupees for section 8(5); up to two hundred crore for section 8(6)) and forward to the processor's contractual indemnity exposure (the DPA's indemnity clause typically makes the processor liable for the fiduciary's losses caused by the processor's breach). The A.2.2.5 control 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.5-adjacent instructions that the processor must respect. 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 instruction-handling expectations. The IRDAI Information and Cyber Security Guidelines (24 April 2023) impose ICT-outsourcing data-protection clauses on insurers' processors. A.2.2.5 is the operational control through which the processor satisfies these sector-driven expectations.

The constitutional layer (Puttaswamy). The Supreme Court's K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (judgment delivered 24 August 2017 by a nine-judge Bench) declared informational privacy a fundamental right under Articles 14, 19 and 21, and articulated the proportionality test that any limitation of the right must meet. The Aadhaar judgment, Justice K.S. Puttaswamy (Retd.) v. Union of India, (2019) 1 SCC 1 (26 September 2018, five-judge Bench), applied the test and struck down section 57 of the Aadhaar Act as failing it. The processor that complied with an infringing instruction is the processor that contributed to a proportionality failure at the controller level, the controller's processing became non-proportional in part because the processor did not flag the instruction. A.2.2.5 is, in operational terms, the processor's internal proportionality test, the analytical exercise that asks, of each instruction, whether it stays within the agreed purposes, the controller's notices and consents, and the applicable law.

The cost of non-compliance

The cost of an A.2.2.5 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.5 failure (the processor complied with an infringing instruction; the processor did not have an instruction process; the processor's instruction-decision log was empty or partial) cascades through the broader privacy architecture, the customer-agreement control (A.2.2.2) is undermined; the customer-obligations control (A.2.2.6) is unguarded; the records-related-to-processing control (A.2.2.7) does not reflect the actual processing; the sub-processor-chain controls (A.2.5.7 to A.2.5.9) are unmonitored; the security controls (A.3) are inconsistently applied. The instruction process is the operational input to multiple other controls; its absence weakens the broader architecture.

Commercial cost is significant. The Indian processor market, SaaS vendors, BPO / ITeS providers, analytics vendors, cloud-service resellers, is increasingly differentiated by privacy posture. Enterprise customers (the banks, the insurers, the SEBI-regulated intermediaries, the MNCs operating in India) include A.2.2.5-style instruction-handling clauses in their standard DPAs and audit the processor's compliance during vendor diligence. The processor that cannot demonstrate an instruction-decision log is the processor that loses the procurement. The reputational damage of a public A.2.2.5 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 complacent instruction-handling) compounds the procurement loss.

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

The board-level question

The board-level question for A.2.2.5 is not "do we have an instruction clause in our DPA?", most processors can point to the boilerplate. The question is "for every customer-initiated change to processing in the last twelve months, every new field, every new purpose, every new sub-processor, every new cross-border flow, every marketing-use ask, every analytics ask, every security-control exception, can we produce the documented intake-triage decision, the legal-and-compliance review where it was triggered, the customer-escalation record where it was issued, and the refusal notification where the instruction was refused?" If the honest answer is "partially" or "no", the processor has an A.2.2.5 gap regardless of what its DPA says.

Scope and Applicability

Who the control applies to

Control A.2.2.5 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 control 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 control applies, the instruction categories

A.2.2.5 applies whenever the processor receives an instruction from a controller-customer. The instruction categories that the processor's intake-triage checklist should flag for review are:

1. New purpose, an instruction to process the controller's personal data for a purpose not recorded in the agreement or the controller's privacy notice (the marquee infringing-instruction pattern; a textbook Article 28(10) trigger).
2. New data category, an instruction to ingest a new category of personal data into the processing (sensitive data the controller has not lawfully collected; data the controller's notice did not disclose to principals).
3. New sub-processor, an instruction to add a sub-processor without following the agreement's sub-processor-change procedure (the controller instructs the processor to start using a new sub-processor "immediately" without the notice period the agreement requires; see A.2.5.8 and A.2.5.9).
4. New cross-border destination, an instruction to transfer the controller's data to a destination not authorised by the agreement (a destination on the DPDP section 16 negative list; a destination without an adequacy decision under GDPR Chapter V; a destination the controller's transfer-impact assessment did not cover).
5. Marketing or advertising use, an instruction to use the controller's personal data for the processor's own marketing or advertising (the A.2.2.4 control; the marquee infringing instruction that pushes the processor towards controller status under Article 28(10)).
6. Analytics or model-training use, an instruction to use the controller's personal data to train the processor's own model, build a benchmarking product, or develop a separate service offering (a less-obvious variant of the marketing-use pattern; equally an Article 28(10) trigger).
7. Security-control exception, an instruction to disable, weaken, or bypass a security control (open a firewall port, disable encryption, share admin credentials, exempt a sub-processor from due diligence).
8. Retention extension, an instruction to retain the controller's data beyond the agreed retention period without a lawful basis for the extension.
9. Sharing across customers, an instruction to share the controller's data with another controller-customer of the processor (the cross-customer data-leakage pattern; a textbook infringement of the agreement and of the controller's obligations to its principals).
10. Breach-related instruction, an instruction to suppress, delay, or omit a breach notification (the textbook section 8(6) infringement under DPDP; the textbook Article 33 infringement under GDPR).
11. Rights-request instruction, an instruction to ignore, delay, or refuse a principal's rights request that the controller has forwarded to the processor (an A.2.3.2 infringement).
12. Audit-related instruction, an instruction to omit records, alter logs, or misrepresent the processing during an audit (an instruction that infringes the agreement's audit-cooperation clause and Clause 9.2 of the standard).

The processor's intake-triage checklist (toolkit doc 03) operationalises these categories. The triage is itself a control, the documented decision that an instruction is routine (no review required) or review-required. The decision is recorded in the instruction-decision log even where the decision is "routine"; the negative decisions are evidence the processor has thought about the triage.

What is in scope for the review

The review covers the instruction against the three reference points (the agreement, the controller's obligations, applicable law). The review's inputs include: the customer agreement (the DPA, the master services agreement, the cloud-service terms, the relevant schedules); the controller's documented obligations (the controller's privacy notice, the controller's consent records, the controller's ROPA, the controller's sector-law duties); the applicable law (DPDP, GDPR, US-state laws, the sector rules that apply to the controller or to the processor); the processor's own obligations (the security controls, the sub-processor-chain discipline, the records, the breach-handoff procedure). The review's output is a recommendation, comply, comply-with-conditions, refuse, escalate-to-customer, with the documented reasoning.

What is out of scope

• Routine operational communications that are not instructions (a status update, a query, a routine support interaction). The intake-triage procedure distinguishes instructions from operational communications; the operational communications are logged in the request-management system but not in the instruction-decision log.
• Instructions compelled by valid legal process (a court order, a regulator's directive, a law-enforcement request). The processor complies with the valid legal process and notifies the controller where the legal process permits (the agreement's legal-process clause). The processor does not "refuse" a valid legal process; the processor's review confirms the legal process is valid and notifies the controller.
• The controller's lawful business decisions that the processor disagrees with but that are within the agreement and the controller's obligations. The processor's role is not to second-guess the controller's lawful business judgement; the processor's role is to flag infringements.
• The processor's own processing activities (the processor's employee data, the processor's marketing data, the processor's own 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.5 question.

Applicability by organisation size

Applicability by industry (preview, Section 21 has detail)

• BFSI processors, the RBI IT-outsourcing regime (banks, NBFCs), the SEBI CSCRF (market intermediaries), the IRDAI ICT-outsourcing rules (insurers). The most prescriptive Indian sectoral processor duties sit in BFSI; the instruction process is the gate through which the processor's compliance is demonstrated.
• Healthcare processors, processors handling health data on behalf of hospital-controller, insurer-controller, telemedicine-controller customers. The sensitivity of health data amplifies every instruction-related risk; the processor's intake discipline is critical.
• IT-ITeS and SaaS processors, the largest segment of Indian processors; multi-jurisdiction customer portfolios; the most diverse instruction profiles (from routine support tickets to complex analytics-use and model-training requests).
• E-commerce and retail processors, processors handling customer data on behalf of e-commerce-controller customers (payment processors, logistics providers, marketing-technology vendors). The marketing-use instruction is the marquee.
• Edtech processors, processors handling student and parent data on behalf of edtech-controller customers. The children's-data overlay (DPDP section 9) makes every instruction involving a child's data a high-risk instruction.
• Manufacturing processors, processors handling supplier-contact data, IIoT data, employee data on behalf of manufacturing-controller customers. The instruction profile is typically lighter, but the cross-border dimension is often material.

Key Definitions and Terminology

Relationship to Other Clauses and Frameworks

The sibling-control network inside Annex A.2

A.2.2.5 does not stand alone, it sits inside a tight sibling network in theme A.2.2, and the audit will trace the network end-to-end.

A.2.2.2, Customer agreement. The DPA is the reference point against which every instruction is assessed. The A.2.2.5 review reads the DPA's purpose limitations, sub-processor-change procedures, security requirements, cross-border-transfer clauses, retention rules, breach-notification clauses, audit-cooperation clauses. A strong A.2.2.5 operation requires a strong A.2.2.2 DPA, the two controls are sequential.

A.2.2.3, Organisation's purposes. The processor's own purposes (the processor's internal analytics, the processor's marketing, the processor's product development) are governed by A.2.2.3 and must be kept separate from the controller's purposes. A controller instruction that asks the processor to use the controller's data for the processor's own purposes is an A.2.2.5 infringement (the marquee Article 28(10) trigger) and an A.2.2.3 infringement.

A.2.2.4, Marketing and advertising use. The processor's use of the controller's personal data for the processor's own marketing or advertising is the textbook A.2.2.4 infringement, and the textbook A.2.2.5 infringement when the controller instructs it (the controller cannot lawfully instruct the processor to use the controller's data for the processor's marketing; the controller's instruction is infringing and the processor must refuse).

A.2.2.6, Customer obligations. The controller's own obligations to its principals (the notices, consents, rights-handling, retention rules) are governed by A.2.2.6 from the processor's perspective. A.2.2.5 is the gate: an instruction that would put the controller in breach of its own A.2.2.6 obligations is an infringing instruction that the processor must refuse.

A.2.2.7, Records related to processing PII (processor ROPA). The processor's ROPA entries reference the controller-customer's processing; the instruction-decision log's entries reference the ROPA. The two artefacts cross-reference. An instruction that changes the processing triggers a ROPA update; the ROPA update references the instruction-decision log entry.

A.2.3.2, Comply with obligations to PII principals. The processor's help to the controller in discharging the controller's principal-side duties. An instruction to ignore, delay, or refuse a principal's rights request is an A.2.3.2 infringement and an A.2.2.5 infringement.

A.2.4.2 / A.2.4.3 / A.2.4.4, Temporary files, return / transfer / disposal, transmission controls. The operational handling of personal data. An instruction that asks the processor to retain temporary files beyond their purpose, to dispose of data in a non-secure manner, or to transmit data over an insecure channel is an A.2.4 infringement and an A.2.2.5 infringement.

A.2.5.7 to A.2.5.9, Sub-processor chain. The controller's instructions on sub-processor engagement, disclosure, and change. An instruction to engage a sub-processor without following the A.2.5.8 procedure is an A.2.5 infringement and an A.2.2.5 infringement.

A.1.2.7, Contracts with PII processors (controller-side mirror). The controller-side control that mirrors A.2.2.2, the controller's duty to put in place a DPA with the processor. The two controls together establish the contractual foundation for the instruction-handling discipline.

Clause 8.1, Operational planning and control. The PIMS-level framework within which the A.2.2.5 process sits. The processor's operational controls are governed by Clause 8.1; the instruction-handling process is one such operational control.

Clause 9.1 / 9.3, Monitoring and management review. The KPIs (Section 12) report to the management review. The instruction-decision log feeds the management review's analysis of the processor's customer-instruction risk profile.

A.3, Information security controls. The integrity of the instruction-decision log is governed by Annex A.3 controls: A.3.14 (protection against destruction or falsification, tamper-evidence, integrity seals, version control); A.3.9 (least-privilege access); A.3.23 (strong authentication, multi-factor for administrative access); A.3.25 (logging of every read and write); A.3.26 (cryptography, encryption at rest, TLS in transit); A.3.24 (backup with annual restoration test); A.3.21 (secure disposal at end of retention with disposal logged).

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

The lineage from GDPR Article 28

GDPR Article 28 is the most-litigated processor-side provision in the world and the source of most operational commentary on processor conduct. Article 28(1) sets the basic rule (processing by a processor only on the basis of a contract). Article 28(3) sets the mandatory DPA content, including the clause that the processor "processes the personal data only on documented instructions from the controller", the contractual foundation that A.2.2.5 operationalises. Article 28(5) authorises adherence to codes of conduct (the ISO/IEC 27018:2019 cloud-processor code is the marquee example). Article 28(10) is the controller-status-drift rule (a processor that processes outside the controller's instructions is a controller for that processing). The EDPB Guidelines 07/2020 on the concepts of controller and processor (the authoritative EDPB guidance on the controller-processor distinction) operationalise Article 28 and are the most-cited processor-side guidance globally. The EDPB Guidelines 07/2020 explicitly address the processor's duty to refuse infringing instructions and to inform the controller, the marquee A.2.2.5 anchor in the EU lineage.

The lineage from ISO/IEC 27018:2019

ISO/IEC 27018:2019, Code of practice for protection of PII in public clouds acting as PII processor, is the cloud-processor reference standard. The 27018 clauses on customer instructions (the cloud processor's agreement with the customer must specify the processing; the cloud processor must act on the customer's documented instructions; the cloud processor must co-operate with the customer's reasonable instructions) are the ISO operational expression of A.2.2.5 for cloud processors. A cloud processor that operates 27018 in its cloud-service terms and DPAs is operating A.2.2.5 in the way the wider ISO community expects.

The lineage from the NIST Privacy Framework and SOC 2

NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020) is the US voluntary risk-based framework. The Control-P function covers data-processing policies, data-processing management, and data-use agreements (DUAs), the processor-side instrument through which the controller's instructions are formalised. A.2.2.5 is the operation of the DUA, the runtime enforcement of the data-use rules.

SOC 2 Privacy TSC, the AICPA Trust Services Criteria. The P6.0 (Disclosure and notification) criterion covers the entity's disclosure of personal information to third parties and the notification of processing changes. The Common Criteria (CC1.1 to CC9.2) cover the security side; CC9.2 (Risk mitigation; vendor oversight) is the criterion that drives the controller's oversight of its processors, and, conversely, the processor's discipline in handling the controller's instructions. A.2.2.5 is the processor-side operational expression of CC9.2 from the controller's perspective and P6.0 from the principal's perspective.

Detailed Implementation Guidance, The Five-Stage Infringing-Instruction Lifecycle

The Singahi five-stage infringing-instruction lifecycle (toolkit doc 02) operationalises A.2.2.5 by integrating the GDPR Article 28(3) documented-instructions duty, the Article 28(10) status-drift discipline, the DPDP Act 2023 data-processor regime, the sector-regulator outsourcing expectations (RBI, SEBI, IRDAI), and the ISO/IEC 27018:2019 cloud-processor instruction clauses into a single coherent workflow. Every conformant processor runs these five stages; some add a sixth (Article 28(10) status-drift register review) as a separate quarterly cadence.

Stage 1, Intake and triage

The intake and triage stage is the documented entry point for every customer instruction. The stage is itself a control, the absence of a defined intake channel is the most common A.2.2.5 finding in Indian growing-company processors. The stage operates at four points in the processor's customer-facing workflow.

The authorised intake channels. Every customer instruction must arrive through one of the authorised channels: a designated email address (typically privacy@ or dpo@ at the processor's domain, with a documented routing to the request-management system); a ticket in the request-management system (opened by the customer through the customer portal or by the customer-success team on the customer's behalf); a signed-instruction workflow in the customer portal (the gold standard, the customer's designated authorised signatory signs the instruction, the system logs the signature, the workflow routes to the request-management system). The intake channels exclude over-the-phone, in-person, instant-message, or side-email instructions that are not recorded, the processor's training must drive the customer's designated contact to the authorised channel.

The intake-triage checklist. Every instruction logged through an authorised channel is triaged against the twelve categories from Section 4.2 (new purpose, new data category, new sub-processor, new cross-border destination, marketing or advertising use, analytics or model-training use, security-control exception, retention extension, sharing across customers, breach-related instruction, rights-request instruction, audit-related instruction). The triage is operated by the trained operations team (typically the customer-success or the operations / delivery team), not by the legal team (the legal team reviews the flagged instructions, not every instruction). The triage decision is recorded in the instruction-decision log: routine (no review required), review-required (escalate to legal-and-compliance), or urgent-escalation (immediate escalation to the DPO and senior management, typically breach-related instructions, audit-related instructions, or security-control exceptions in production environments).

The training dimension. The intake-triage discipline depends on the operations team's training. The training must cover: the twelve instruction categories; the intake channel discipline (every instruction logged, no over-the-phone exceptions); the triage decision criteria; the escalation paths. The training is delivered at onboarding (for new operations team members) and refreshed at least annually. The training completion is logged; the auditor will ask for the training records at Stage 2.

The intake-triage KPI. The intake-triage discipline is measured by the intake-channel-coverage KPI (the percentage of customer instructions received through an authorised channel, target: 100%) and the triage-decision-timeliness KPI (the median time from instruction receipt to triage decision, target: 1 business day). The KPIs are reported to the management review (Clause 9.3).

The customer-portal integration. For mid-market and enterprise processors, the intake channel is typically integrated into the customer portal, the customer's authorised signatory logs in, opens the instruction workflow, fills in the instruction-template fields (purpose, data category, sub-processor, destination, retention, recipient), signs, and submits. The portal logs the signature, routes the instruction to the request-management system, and notifies the operations team. The portal integration eliminates the over-the-phone and side-email patterns at the source.

Stage 2, Legal-and-compliance review

The legal-and-compliance review stage is the structured assessment of a review-required instruction against the three reference points. The stage is operated by the DPO (or the privacy lead, or in the absence of a DPO, by the legal team) with input from the operations and engineering teams.

The three reference points.

The first reference point is the agreement, the DPA, the master services agreement, the cloud-service terms, the relevant schedules. The review reads the agreement's purpose limitations (does the new purpose fall within them?); the data-category scope (is the new data category in the agreed scope?); the sub-processor procedure (does the new sub-processor follow the A.2.5.8 procedure?); the cross-border-transfer clauses (is the new destination authorised by the agreement?); the retention rules (does the retention extension have a contractual basis?); the security requirements (does the security-control exception breach the agreement?); the breach-notification clauses (does the breach-suppression instruction breach the agreement?); the audit-cooperation clauses (does the audit-related instruction breach the agreement?). The review produces a documented finding on each applicable clause.

The second reference point is the controller's own obligations, the controller's privacy notice (has the controller disclosed the new purpose to its principals?); the controller's consent records (does the controller have consent for the new purpose?); the controller's lawful-basis register (does the controller have a lawful basis for the new processing?); the controller's ROPA (does the controller's ROPA reflect the new processing?); the controller's sector-law duties (does the new processing comply with the controller's RBI / SEBI / IRDAI / DPDP duties?). The review produces a documented finding on each applicable obligation. Where the controller's documentation is incomplete (the processor cannot verify the controller's notice or consent), the review flags the gap and triggers the customer-escalation stage.

The third reference point is applicable law, DPDP, GDPR, US-state laws, China PIPL, Brazil LGPD, the sector rules. The review reads the instruction against the applicable law's processor-side duties (DPDP section 8 flow-through; GDPR Article 28(3) documented instructions; PIPL Article 21 entrusted processing; LGPD Article 39 operator duties) and the applicable law's substantive requirements (the section 16 negative list for cross-border; the GDPR Chapter V transfer regime; the section 9 children's overlay). The review produces a documented finding on each applicable law.

The recommendation. The review produces one of four recommendations. Comply, the instruction is within the agreement, the controller's obligations and applicable law; the processor may proceed. Comply-with-conditions, the instruction is conditionally acceptable (for example, the new purpose is acceptable if the controller confirms the principal notice has been updated; the new sub-processor is acceptable if the controller confirms the sub-processor-change notice period has run); the processor proceeds on the controller's confirmation. Refuse, the instruction infringes one or more of the three reference points and cannot be cured by the controller's confirmation; the processor refuses. Escalate-to-customer, the review is inconclusive (the controller's documentation is incomplete; the legal interpretation is unclear); the processor escalates to the controller-customer with a clarification request.

The recommendation is documented in the instruction-decision log with the reasoning, the reference-point findings, and the reviewer's name and date. The recommendation is then routed to Stage 3 (escalation) or Stage 4 (refusal-or-comply decision).

The legal-and-compliance review KPI. The review discipline is measured by the review-completeness KPI (the percentage of review-required instructions with a documented three-reference-point finding, target: 100%) and the review-timeliness KPI (the median time from triage to recommendation, target: 5 business days).

Stage 3, Customer escalation

The customer-escalation stage is the processor's documented communication to the controller-customer seeking clarification, additional information, or confirmation of an instruction. The escalation is the processor's opportunity to surface the infringement concern before the formal refusal, and is, in many cases, the trigger for the controller to withdraw or amend the instruction.

The escalation workflow. The escalation is initiated by the DPO or the legal team (the reviewer from Stage 2). The escalation is sent through the DPA's notice channel (typically email to the controller's designated notice contact, the DPA should specify the contact; if it does not, the processor's DPA clause library refresh should fix this). The escalation includes: the instruction being queried; the specific clarification or confirmation requested (for example, "please confirm that the principal notice has been updated to reflect the new purpose"; "please confirm that the new sub-processor was disclosed in your privacy notice; please share the transfer-impact assessment for the new cross-border destination"); the processor's concerns (a summary of the three-reference-point findings); the response deadline (typically 5 to 10 business days, calibrated to the urgency); and the consequences of non-response (the processor's process for handling non-response, typically, after a follow-up and a further deadline, the instruction is treated as refused for want of clarification).

The escalation-log discipline. Every escalation is logged in the instruction-decision log: the instruction being queried, the clarification requested, the date sent, the controller's response (when received), the response date, the processor's reaction to the response (the response resolves the concern → comply; the response does not resolve the concern → refuse; the controller withdraws the instruction → closed). The escalation log is the evidence that the processor gave the controller a fair opportunity to clarify before any refusal.

The escalation-and-refusal playbook. The Singahi Customer Escalation and Refusal Playbook (toolkit doc 08) provides the templates for the escalation communications, the clarification request, the follow-up, the response analysis, the refusal notification. The templates are calibrated to the typical scenarios (the new-purpose-without-notice pattern; the new-sub-processor-without-notice pattern; the marketing-use pattern; the security-control-exception pattern; the breach-suppression pattern). The playbook also covers the customer-relationship dimension, the refusal of a high-revenue customer's instruction is a commercial decision, and the playbook provides the senior-management escalation path for the processor's internal alignment.

The customer-escalation KPI. The escalation discipline is measured by the escalation-outcome-rate KPI (the percentage of escalations that resolve the concern without refusal, the higher the better, because it indicates the escalation is working as a collaborative instrument) and the escalation-cycle-time KPI (the median time from escalation to resolution, target: 5 to 10 business days).

Stage 4, Refusal or comply decision

The refusal-or-comply decision is the formal disposition of the instruction. The decision is mandatory, documented, and notified to the controller-customer.

The four dispositions.

Comply. The instruction is within the agreement, the controller's obligations and applicable law (either confirmed by the review at Stage 2, or cured by the controller's response at Stage 3). The processor proceeds with the instruction; the comply decision is logged in the instruction-decision log with the reviewer's name, date and reasoning.

Comply-with-conditions. The instruction is acceptable subject to the controller's confirmation of a specific condition (the principal notice has been updated; the consent has been obtained; the sub-processor notice has run). The processor proceeds on the controller's written confirmation; the confirmation is logged; the comply-with-conditions decision and the confirmation are recorded in the instruction-decision log.

Refuse. The instruction infringes one or more of the three reference points and cannot be cured. The processor refuses; the refusal is notified to the controller-customer through the DPA's notice channel. The refusal notification includes: the instruction being refused; the specific infringement (the reference-point finding); the processor's proposed alternative (where one exists, for example, "we cannot use your customer data to train our model under our existing DPA, but we can offer a separate licensed-data arrangement"); the escalation path (the controller's right to withdraw the instruction, to amend the agreement through the agreed change procedure, or to escalate to the processor's senior management). The refusal is logged in the instruction-decision log with the refuser's name, date, reasoning and notification record.

Escalate further. The instruction raises a question that the standard Stage 3 escalation did not resolve (the controller disputes the processor's reading of the agreement; the controller asserts a legal interpretation the processor cannot assess; the controller asks for a scope the processor is unwilling to provide). The processor escalates further, to the processor's senior management (the COO, the CEO for high-revenue customers) and, where necessary, to the processor's external counsel. The further-escalation is logged; the final disposition follows the senior-management decision.

The sign-off authority matrix. The sign-off authority for the disposition is calibrated to the risk. Routine comply decisions are signed off at the operations-team level. Comply-with-conditions decisions are signed off at the DPO level. Refusal decisions are signed off at the DPO level for routine refusals (the controller's instruction is plainly outside the agreement) and at the executive level (the COO or the CEO) for refusals of high-revenue customers or for refusals with significant commercial implications. The sign-off authority matrix is the processor's documented decision; the matrix is part of the Infringing-Instruction Policy.

The disposition KPI. The disposition discipline is measured by the disposition-timeliness KPI (the median time from instruction receipt to disposition, target: 5 to 10 business days for routine, 15 to 25 business days for complex) and the refusal-rate KPI (the percentage of review-required instructions refused, trend over time; a rising refusal-rate may indicate the processor is engaging higher-risk customers, or that the customer-portfolio's instruction profile is changing).

Stage 5, Documentation and notification

The documentation and notification stage closes the lifecycle and integrates the decision with the wider PIMS.

The instruction-decision log update. The instruction-decision log is updated with the full decision trail: the intake record (date, channel, requestor); the triage decision; the legal-and-compliance review (where triggered); the customer-escalation record (where issued); the controller's response (where received); the final disposition (comply / comply-with-conditions / refuse / escalate-further); the notification record; the sign-off (signatory, date, reasoning); the follow-up (any subsequent action, a change-management record, a sub-processor-change notification, a ROPA update). The log is itself controlled documented information under Clause 7.5, version-controlled, access-controlled, retention-managed, retrievable.

The breach-handoff procedure (where triggered). Where the instruction-related processing caused or may cause a personal-data breach, the breach-handoff procedure is triggered. Under DPDP section 8(6), the controller (Data Fiduciary) notifies the Board and the affected principals within 72 hours; the processor's handoff is the upstream input. The handoff includes: the breach details (what happened, when, what data, what principals); the processor's containment and mitigation actions; the processor's analysis of the breach's relationship to the controller's instruction (was the breach caused by the instruction, or by a separate failure?); the processor's recommendations for the controller's notification content. The breach-handoff procedure is operated in parallel with the CERT-In 6-hour clock (the processor's own incident report to CERT-In, where the processor operates India-ICT systems that fall under the CERT-In Directions). The dual-clock pattern (DPDP 72-hour to the controller; CERT-In 6-hour to CERT-In) is the Indian processor's standard incident-response discipline. The breach-handoff procedure is tested through the incident-response tabletop drills (toolkit doc 08).

The Article 28(10) status-drift analysis (where triggered). Where the instruction may have moved the processor towards controller status, typically, the marketing-use pattern, the analytics-use pattern, the model-training pattern, the Article 28(10) status-drift analysis is logged. The analysis asks: did the processing fall within the controller's instructions, or outside? If outside, did the processor process for its own purposes (the marquee Article 28(10) trigger)? If so, what are the consequences, the processor is a controller for that processing, with the controller obligation set (lawful basis, notice, consent, rights, DPIA, records, security, breach notification). The status-drift analysis is logged in the Article 28(10) status-drift register; the register is reviewed quarterly by the DPO; the cumulative status-drift pattern feeds the management review (Clause 9.3).

The integration with the change-management records. Where the instruction resulted in a change to the processing (a new field, a new sub-processor, a new cross-border destination), the change is reflected in the change-management records. The instruction-decision log references the change record; the change record references the instruction-decision log. The two artefacts cross-reference.

The integration with the sub-processor-change notifications. Where the instruction involved a sub-processor change, the change is reflected in the sub-processor-change notification records (A.2.5.9). The instruction-decision log references the notification record; the notification record references the instruction-decision log.

The integration with the ROPA. Where the instruction resulted in a material change to the processing, the ROPA (A.2.2.7) is updated. The instruction-decision log references the ROPA update; the ROPA entry references the instruction-decision log.

The integration with the management review. The instruction-decision log feeds the management review (Clause 9.3). The KPIs (Section 12) report to the management review. The cumulative instruction profile (the types of instructions the processor receives, the refusal rate, the customer-escalation outcomes) drives the management review's analysis of the processor's customer-portfolio risk and the continual-improvement actions (Clause 10.1).

The Article 28(10) status-drift register, quarterly review

The Article 28(10) status-drift register is the processor's internal documentation of every processing activity where the controller-status question may arise. The register is reviewed quarterly by the DPO. The review asks: for each entry in the register, has the status question been resolved? If the entry has been resolved (the processing is within the controller's instructions; the processor is not a controller for that processing), the entry is closed. If the entry is unresolved (the processing is marginal; the controller-status question is open), the entry remains open with a documented action plan (typically, a renegotiation of the controller's instructions to clarify the boundary; or a re-architecture of the processing to keep it within the controller's instructions).

The register's typical entries include: the processor's own analytics on aggregated customer data (is the aggregation sufficient to take the processing outside the personal-data regime? if not, is the analytics within the controller's instructions?); the processor's troubleshooting logs (do the logs contain personal data? if so, is the troubleshooting within the controller's instructions?); the processor's model-training on customer data (is the training within the controller's instructions, or for the processor's own benefit?); the processor's cross-customer benchmarking (does the benchmarking identify individual customers' principals?); the processor's marketing of its own services using customer case-studies (does the case-study identify individual principals?).

The register is the processor's defence against the Article 28(10) drift, the documented evidence that the processor has thought about the status question, addressed it, and kept the processing on the right side of the line. A processor without a status-drift register is at risk of the drift occurring unnoticed, the marquee A.2.2.5 failure pattern.

The breach-handoff drill

The breach-handoff procedure is tested through the incident-response tabletop drills. The drill simulates a personal-data breach at the processor that affects a controller-customer's data; the drill walks the handoff notification to the controller, the parallel CERT-In 6-hour report, the controller's 72-hour notification to the Board (under the DPDP Rules' the Rule 7 intimation content), the affected-principals notification, and the post-incident review. The drill is conducted at least annually; for high-risk processors (BFSI processors, healthcare processors, processors handling sensitive data at scale), the drill is conducted semi-annually.

The drill's findings feed the breach-handoff procedure's continual improvement. The findings typically surface: gaps in the breach-detection capability (the processor's monitoring did not detect the breach in time); gaps in the breach-assessment capability (the processor's incident-response team could not assess the breach's scope in the time available); gaps in the handoff notification (the controller's notice contact was outdated; the controller's incident-response team was not reachable); gaps in the parallel CERT-In report (the processor's CERT-In PoC was unavailable). Each gap drives a corrective action (Clause 10.2) and a continual-improvement action (Clause 10.1).

The DPA clause refresh, embedding A.2.2.5 in the contract

The processor's DPA with each controller-customer must support the A.2.2.5 operation. The Singahi Customer-DPA Clause Library (processor-side; toolkit doc 10) provides the processor-side drafting for the A.2.2.5-adjacent clauses: the documented-instructions clause (the controller's instructions must be documented and signed); the intake-channel clause (the controller's instructions must be issued through the authorised channel, typically the customer-portal signed-instruction workflow); the infringing-instruction clause (the processor may refuse an infringing instruction; the refusal is notified through the notice channel; the controller's right to withdraw or amend); the sub-processor-change clause (the A.2.5.8 / A.2.5.9 procedure); the breach-notification clause (the processor's handoff to the controller; the timeline; the content); the audit-cooperation clause (the processor's cooperation with the controller's audits; the controller's right to audit under the sector rules); the legal-process clause (the processor's compliance with valid legal process; the processor's notification to the controller where the legal process permits).

The DPA clause refresh is typically triggered by the A.2.2.5 implementation programme, the processor's existing DPAs are reviewed, the A.2.2.5-adjacent clauses are strengthened, the refreshed DPAs are rolled out to the customer portfolio through the contract-amendment process. For mid-market and enterprise processors, the DPA refresh is a 6 to 12 month programme; for growing processors, the DPA refresh is a 1 to 3 month programme.

The customer-relationship dimension

A.2.2.5 has a customer-relationship dimension that no other Annex A.2 control has in the same degree. The refusal of a controller-customer's instruction is, in commercial terms, the refusal of a customer's request, and the customer may react commercially (a renegotiation of the contract; a reduction in scope; a switch to a competitor). The processor's senior management must be prepared for this reaction. The Infringing-Instruction Policy must therefore include: the commercial posture (the processor's commitment to refuse infringing instructions regardless of the customer's commercial importance); the senior-management escalation path (the COO or the CEO signs off on refusals of high-revenue customers); the customer-communication strategy (how the refusal is framed as a compliance discipline that protects both the processor and the controller-customer, not as a service failure); the contractual-protection strategy (the DPA's indemnity and liability clauses protect the processor from the customer's commercial reaction).

The customer-relationship dimension is the hardest A.2.2.5 discipline to implement, because it requires the processor to act against its short-term commercial interest. The processor's senior management commitment is the prerequisite, without it, the operations team will quietly comply with infringing instructions to preserve the customer relationship, and the control will fail in operations regardless of what the policy says.

The instruction-decision log integrity controls

The instruction-decision log is a regulated artefact; its integrity is governed by Annex A.3 controls. The minimum integrity requirements: A.3.14 (tamper-evident storage, version-controlled, integrity seals, append-only event tables); A.3.9 (least-privilege access, DPO and the privacy team write, operations team contributes through a controlled workflow, senior management signs off through an authenticated channel); A.3.23 (strong authentication, multi-factor for administrative access); A.3.25 (audit logging of every read and write); A.3.26 (cryptography, encryption at rest, TLS in transit); A.3.24 (backup with annual restoration test); A.3.21 (secure disposal at end of retention with disposal logged).

Tools, Technologies, and Solutions

The tool landscape

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

Privacy management platforms with a processor module. Software products that manage the customer-instruction workflow, intake, triage, review, escalation, refusal, notification, log. The platforms vary in target use case, some are optimised for the enterprise multi-jurisdiction processor regime; others for the mid-market single-jurisdiction regime; others for the cloud processor with high-volume low-complexity instructions. Generic category terms, "privacy management platform", "enterprise privacy platform", "processor-instruction tool", are the right vocabulary; this guide does not name vendors.

GRC platforms with a customer-management module. Governance, risk and compliance platforms that include a customer-management module adaptable to instruction-handling use. The GRC platform's strength is the integration with the broader enterprise risk register and the third-party-risk-management module (the processor is a third-party to its customers, and the customer-instruction workflow is the inverse of the processor's own third-party-risk workflow); the weakness is that the instruction-specific workflow (the twelve categories, the three-reference-point review, the refusal-notification templates) typically requires customisation.

Specialised instruction / request-management tools. Products focused specifically on the customer-instruction workflow, the intake portal, the triage checklist, the legal-and-compliance review template, the escalation and refusal notifications. These tools are typically lighter-weight than the enterprise platforms and are appropriate for growing processors and growing firms.

The customer portal's instruction workflow module. For SaaS processors, the customer portal's instruction workflow module is the gold standard, the controller's authorised signatory logs in, fills in the instruction template, signs, submits. The portal logs the signature, routes the instruction to the request-management system, and notifies the operations team. The portal integration is typically built in-house (the processor's engineering team extends the existing customer portal) or through a vendor-provided portal module.

In-house instruction-decision log implementations. For processors with bespoke needs (high-volume instructions, unique customer-portfolio characteristics, integration with bespoke intake workflows), a custom-built instruction-decision log is appropriate. The recommended pattern is a structured store (a SharePoint list with controlled workflow, a PostgreSQL database with a service layer, an issue-tracker workflow with custom issue types) with the instruction-template embedded.

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.

Volume and complexity. High-volume processors with complex multi-jurisdiction customer portfolios typically need either a top-tier enterprise privacy platform or an in-house build integrated with the customer portal; lower-volume processors with simpler portfolios can run effectively on a specialised instruction tool or a structured log.

Integration requirements. Where the instruction-decision log must integrate with the change-management records, the sub-processor-change notifications, the ROPA, the management review, the incident-response workflow, the integration overhead favours either the enterprise platform or a deliberate in-house build.

Multi-jurisdiction complexity. Where the processor's customers span DPDP, GDPR, US-state, sectoral regimes, the multi-jurisdiction configuration overhead favours the enterprise platform. Single-jurisdiction processors can run effectively on a simpler tool.

Customer-portal integration. For SaaS processors, the customer-portal instruction workflow is the gold standard, the build is typically done in-house, with a vendor-provided privacy platform as the back-office log.

The intake-channel patterns

Four intake-channel patterns dominate the Indian processor market.

The designated-email pattern. The customer sends instructions to a designated email address (privacy@ or dpo@ at the processor's domain). The email is automatically routed to the request-management system. This pattern is the minimum viable intake channel; it is appropriate for growing processors with low instruction volume.

The request-management-system pattern. The customer opens a ticket in the request-management system (the processor's existing support-system, typically an industry-standard tool). The ticket is routed to the operations team. This pattern is appropriate for processors with an existing request-management culture.

The customer-portal pattern. The customer's authorised signatory logs into the customer portal, fills in the instruction template, signs, submits. The portal logs the signature and routes to the request-management system. This pattern is the gold standard; it eliminates the over-the-phone and side-email patterns at the source.

The API pattern. For high-volume processors (especially cloud processors), the customer's instructions are received through an API (the customer's procurement or compliance system pushes the instruction to the processor's API). The API logs the instruction and routes it to the request-management system. This pattern is appropriate for processors with sophisticated customer bases and high instruction volume.

The instruction-decision log tooling

The instruction-decision log's integrity is governed by Annex A.3 controls. The minimum tooling requirements: tamper-evident storage (version-controlled, Git-style, SharePoint with version history, or a database with append-only event tables); access control (least-privilege, role-based, with quarterly access review); authentication (multi-factor for administrative access); audit logging (every read and write logged; logs retained on the log's schedule); backup and restoration (annual restoration test); cryptography (encryption at rest; TLS in transit).

Policy and Procedure Templates

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

The Infringing-Instruction Policy (toolkit doc 01)

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

• The processor shall operate an infringing-instruction programme that satisfies ISO/IEC 27701:2025 control A.2.2.5; the DPDP Act 2023 data-processor obligations under section 2(1)(k) read with section 8; the GDPR Article 28(3) documented-instructions duty where the processor processes EU personal data; the sector-regulator obligations applicable to the processor's customers.
• The processor shall receive every customer instruction through an authorised intake channel; instructions received through unauthorised channels shall be re-issued through the authorised channel before any action is taken.
• The processor shall log every instruction in the instruction-decision log with the intake metadata, the triage decision, the legal-and-compliance review (where triggered), the customer-escalation record (where issued), the final disposition, the notification record, and the sign-off.
• The processor shall triage every instruction against the twelve instruction categories and escalate the review-required instructions to the legal-and-compliance review.
• The processor shall conduct the legal-and-compliance review against the three reference points, the agreement, the controller's own obligations, applicable law, and document the findings for each reference point.
• The processor shall refuse any instruction that infringes one or more of the three reference points and cannot be cured; the refusal shall be notified to the controller-customer through the DPA's notice channel.
• The processor shall escalate to the controller-customer any instruction where the review is inconclusive or the infringement concern requires the controller's clarification.
• The processor shall sign off on the disposition at the authority level commensurate with the risk, operations-team for routine, DPO for review-required, executive for refusals of high-revenue customers.
• The processor shall trigger the breach-handoff procedure where the instruction-related processing caused or may cause a personal-data breach; the handoff shall meet the DPDP section 8(6) timeline (72 hours to the controller, with the controller's notification to the Board to follow) and the CERT-In 6-hour clock (where the processor operates India-ICT systems).
• The processor shall log the Article 28(10) status-drift analysis in the status-drift register for any instruction that may have moved the processor towards controller status; the register shall be reviewed quarterly by the DPO.
• The processor shall integrate the instruction-decision log with the change-management records, the sub-processor-change notifications (A.2.5.9), the ROPA (A.2.2.7), the management review (Clause 9.3), and the continual-improvement cycle (Clause 10.1).
• The processor shall protect the integrity of the instruction-decision log through the Annex A.3 security controls (A.3.14, A.3.9, A.3.23, A.3.25, A.3.26, A.3.24, A.3.21).
• The processor shall train the operations team, the customer-success team, and the legal team on the intake-triage discipline, the twelve instruction categories, the escalation workflow, and the refusal-notification templates; the training shall be refreshed at least annually.

The Infringing-Instruction Lifecycle Procedure (toolkit doc 02)

The procedure operationalises the policy through the five-stage lifecycle (Section 7). Each stage has documented acceptance criteria, an owner, a control mechanism, a KPI and a cadence.

The Instruction-Intake-and-Review Form (toolkit doc 03)

The form captures the intake metadata, the triage decision, the legal-and-compliance review, the customer-escalation record, the final disposition, the notification record, and the sign-off. The form is the per-instruction template; the instruction-decision log is the register of all such forms.

The Customer Escalation and Refusal Playbook (toolkit doc 08)

The playbook provides the templates for the escalation communications, the clarification request, the follow-up, the response analysis, the refusal notification. The templates are calibrated to the typical scenarios (the new-purpose-without-notice pattern; the new-sub-processor-without-notice pattern; the marketing-use pattern; the security-control-exception pattern; the breach-suppression pattern). The playbook also covers the breach-handoff drill template.

The Customer-DPA Clause Library (toolkit doc 10)

The clause library provides the processor-side drafting for the A.2.2.5-adjacent clauses: the documented-instructions clause; the intake-channel clause; the infringing-instruction clause; the sub-processor-change clause; the breach-notification clause; the audit-cooperation clause; the legal-process clause. The clauses are drafted as the processor's own commitments (the processor's own "shall" clauses), not as quotations from the standard.

The Article 28(10) Status-Drift Register (toolkit doc 09, Part B)

The register template: each entry's identifier, the processing activity, the controller-customer, the instruction that triggered the entry, the status-drift analysis (within the controller's instructions, or outside? if outside, for the processor's own purposes?), the resolution (closed / open with action plan), the reviewer, the date.

The Breach-Handoff Procedure (toolkit doc 08, Part B)

The procedure template: the trigger (a personal-data breach affecting a controller-customer's data), the breach-assessment steps, the handoff notification content (breach details, containment, mitigation, relationship to the controller's instruction, recommendations), the timelines (DPDP 72 hours to the controller; CERT-In 6-hour to CERT-In where applicable), the post-incident review.

The Instruction-Decision Log Schema (toolkit doc 03, Part B)

The schema: the log's fields (instruction identifier; intake date; intake channel; requestor; instruction category; triage decision; review reviewer; review date; review findings on each reference point; review recommendation; escalation date; escalation content; controller response; response date; final disposition; sign-off signatory; sign-off date; sign-off reasoning; notification date; notification content; follow-up actions; integration references, change record, sub-processor notification, ROPA entry, management-review report). The schema is the canonical data model for the instruction-decision log.

The Sign-off Authority Matrix (toolkit doc 13)

The matrix: routine comply → operations team; comply-with-conditions → DPO; routine refusal → DPO; refusal of high-revenue customer → executive (COO / CEO); refusal of SDF-class customer → executive + legal counsel; escalate-further → senior management. The matrix is the processor's documented decision.

Risk Assessment and Treatment

The A.2.2.5-specific risks in the processor's risk register

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

The customer-portfolio risk dimension

A.2.2.5 has a customer-portfolio risk dimension that the processor's risk register should capture. The customer-portfolio risk is the aggregate risk of the processor's customer instructions, the higher the proportion of higher-risk customers (SDF-class controllers, BFSI controllers, controllers handling sensitive data, controllers in restrictive jurisdictions), the higher the processor's aggregate instruction risk. The customer-portfolio risk is monitored at the management review (Clause 9.3); the aggregate instruction profile (the types of instructions, the refusal rate, the escalation outcomes) drives the continual-improvement actions (Clause 10.1).

The risk-treatment decision points

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

• Modify, change the intake, triage, review or escalation process to reduce the likelihood or impact.
• Avoid, do not engage the higher-risk customer (a customer-acquisition decision).
• Share, transfer the risk to a third party (the controller-customer under indemnity; an insurer under a professional-indemnity policy).
• Accept, accept the residual risk with documented sign-off at the appropriate authority level.

The risk-treatment decisions are recorded in the risk register and reflected in the Statement of Applicability.

Audit and Compliance Checklist

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

1. Is there an Infringing-Instruction Policy? Expected: a dated, version-controlled policy signed off by the DPO and top management, covering the intake channel, the triage checklist, the three-reference-point review, the escalation workflow, the refusal-notification template, the sign-off authority matrix, the breach-handoff procedure, the Article 28(10) status-drift register. Red flag: no policy; or policy exists but is generic (no India-specific content; no Article 28(10) register; no breach-handoff).

2. Is there a documented Infringing-Instruction Lifecycle Procedure? Expected: a procedure covering the five stages with acceptance criteria, owners, KPIs and cadence. Red flag: no procedure; or procedure exists but does not cover all five stages.

3. Is there an Instruction-Decision Log? Expected: a current log listing every customer instruction received, the triage decision, the review (where triggered), the escalation (where issued), the final disposition, the notification record. Red flag: no log; or log exists but is incomplete.

4. Are the authorised intake channels defined? Expected: a documented list of authorised intake channels (designated email, request-management system, customer-portal workflow, API); the operations team trained on the channels. Red flag: no defined channels; over-the-phone instructions accepted.

5. Is the intake-channel-coverage KPI at 100%? Expected: every customer instruction received through an authorised channel. Red flag: instructions received through unauthorised channels and acted on.

6. Is the twelve-category triage checklist operational? Expected: the checklist integrated in the intake workflow; the operations team trained on the categories. Red flag: checklist exists but is not embedded in the intake workflow.

7. Is the triage decision recorded for every received instruction? Expected: every instruction in the last 12 months has a documented triage decision in the log. Red flag: instructions without a triage decision.

8. Is the legal-and-compliance review conducted on review-required instructions? Expected: every review-required instruction has a documented three-reference-point finding. Red flag: review-required instructions without the review.

9. Is the review framed against all three reference points? Expected: the agreement, the controller's obligations, applicable law, each with a documented finding. Red flag: review framed against only one reference point (typically the agreement).

10. Is the customer escalation conducted where triggered? Expected: the escalation record (date, content, controller response) for each escalated instruction. Red flag: review-required instructions without the escalation where the review was inconclusive.

11. Is the refusal notification issued through the DPA's notice channel? Expected: the refusal-notification template; the notification record for each refused instruction. Red flag: refusals without the notification; or notifications through informal channels (a phone call).

12. Is the sign-off at the appropriate authority level? Expected: documented sign-off authority matrix; each disposition signed off at the appropriate level. Red flag: high-revenue customer refusal signed off at operations-team level.

13. Does the instruction-decision log reconcile with the change-management records? Expected: the log's instruction-driven changes match the change-management records. Red flag: changes in the change-management records without a corresponding instruction-decision record.

14. Does the log reconcile with the sub-processor-change notifications? Expected: sub-processor-change instructions match the A.2.5.9 notifications. Red flag: sub-processor changes without the corresponding instruction record.

15. Does the log reconcile with the ROPA? Expected: instruction-driven ROPA updates reference the instruction-decision log. Red flag: ROPA updates without the corresponding instruction record.

16. Is the Article 28(10) status-drift register maintained? Expected: a current register; quarterly DPO review documented. Red flag: no register; or register exists but no review.

17. Is the breach-handoff procedure operational? Expected: the procedure; the most recent drill; the integration with the incident-response workflow. Red flag: no procedure; or procedure exists but no drill.

18. Is the breach-handoff drill conducted at the appropriate cadence? Expected: annually for low-risk processors; semi-annually for high-risk processors. Red flag: drill never conducted; or drill conducted but findings not closed.

19. Is the DPA clause library refreshed? Expected: the A.2.2.5-adjacent clauses in the current DPA template; the rollout of the refreshed DPAs to the customer portfolio. Red flag: DPAs with outdated or missing A.2.2.5 clauses.

20. Is the operations team trained on the intake-triage discipline? Expected: training records; annual refresh; the twelve instruction categories covered. Red flag: no training; or training exists but not refreshed.

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

22. Is the multi-jurisdiction dimension covered? Expected: review checklist covers DPDP, GDPR, US-state, sectoral overlays where the customer portfolio spans jurisdictions. Red flag: multi-jurisdiction instructions reviewed against only one legal regime.

23. Is the instruction-decision log integrity protected? Expected: A.3.14, A.3.9, A.3.23, A.3.25, A.3.26, A.3.24, A.3.21 operating on the log. Red flag: any of these controls not operating.

24. Is the log's access least-privilege? Expected: documented access roles; quarterly access review; revocation on role change. Red flag: broad write access; no access review.

25. Is the log's restoration tested? Expected: at-least-annual restoration from backup; restoration time and integrity verified. Red flag: no restoration test; or test exists but restoration time or integrity is unacceptable.

26. Is the breach-handoff pre-staged for the major customers? Expected: the breach-handoff content pre-staged for each major customer; the customer's notice contact current; the dual-clock pattern (DPDP / CERT-In) documented. Red flag: no pre-staged content; outdated notice contacts.

Metrics and KPIs

The Singahi A.2.2.5 KPI set (toolkit doc 11) covers process quality, lifecycle performance, integrity and regulatory responsiveness. The thirteen KPIs below are the recommended minimum.

Process-quality KPIs

1. Intake-channel coverage, the percentage of customer instructions received through an authorised intake channel. Target: 100% within the first quarter of implementation.

   • Formula: (instructions received through authorised channels / total instructions received) × 100
   • Frequency: monthly
   • Owner: Operations / Delivery Lead

2. Triage-decision timeliness, the median time from instruction receipt to triage decision. Target: 1 business day.

   • Formula: median (triage decision date − intake date) across all instructions in the period
   • Frequency: monthly
   • Owner: Operations / Delivery Lead

3. Triage-decision coverage, the percentage of received instructions with a documented triage decision. Target: 100%.

   • Formula: (instructions with documented triage / total instructions received) × 100
   • Frequency: monthly
   • Owner: DPO

4. Review-completeness, the percentage of review-required instructions with a documented three-reference-point finding. Target: 100%.

   • Formula: (review-required instructions with three-reference-point finding / total review-required) × 100
   • Frequency: monthly
   • Owner: DPO

Lifecycle-performance KPIs

5. Review-timeliness, the median time from triage to legal-and-compliance review recommendation. Target: 5 business days.

   • Frequency: monthly
   • Owner: DPO

6. Escalation-cycle-time, the median time from customer escalation to resolution. Target: 5 to 10 business days.

   • Frequency: monthly
   • Owner: DPO

7. Escalation-outcome-rate, the percentage of escalations that resolve the concern without refusal (the higher the better, indicates the escalation is working as a collaborative instrument). Target: 60%+ resolved without refusal.

   • Frequency: monthly
   • Owner: DPO

8. Disposition-timeliness, the median time from instruction receipt to final disposition. Target: 5 to 10 business days for routine; 15 to 25 for complex.

   • Frequency: monthly
   • Owner: DPO

9. Refusal-rate, the percentage of review-required instructions refused. Trend over time; a rising refusal-rate may indicate the processor is engaging higher-risk customers or that the customer-portfolio's instruction profile is changing. Target: trend-stable or falling.

   • Frequency: quarterly
   • Owner: DPO / Senior Management

Integrity KPIs

10. Instruction-decision log access-review completion, the percentage of log access roles reviewed in the period. Target: 100% quarterly.

    • Frequency: quarterly
    • Owner: DPO

11. Instruction-decision log anomaly count, the count of detected anomalies in the log (integrity-seal mismatches, unexpected modifications, access anomalies). Target: zero; each anomaly investigated under Clause 10.2.

    • Frequency: monthly
    • Owner: Engineering Lead

12. Breach-handoff drill score, the score on the most recent breach-handoff tabletop exercise (breach detection, assessment, handoff notification, dual-clock adherence, post-incident review). Trend over time.

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

Regulatory-responsiveness KPIs

13. Article 28(10) status-drift register review, the count of entries in the status-drift register reviewed in the quarterly DPO review; the count of open entries; the action-plan timeline for each open entry. Target: 100% review quarterly; all open entries with action plans.
    • Frequency: quarterly
    • Owner: DPO

Common Pitfalls and Audit Failures

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

The DPA boilerplate without a process

The processor's DPA has the documented-instructions clause (copied from a GDPR-Article-28(3) template or inherited from the standard's neighbour controls). The processor treats the clause as the A.2.2.5 control. There is no instruction-decision log; no intake channel; no triage checklist; no review procedure; no refusal-notification template; no Article 28(10) status-drift register. The auditor's first walk-through surfaces this gap immediately. This is the common nonconformity most often flagged in tier-1 certification-body practitioner commentary, the standard DPA boilerplate on infringing instructions is "not typically sufficient"; auditors expect an actual process. The remediation is to stand up the five-stage lifecycle and the instruction-decision log.

The intake channel that does not exist

The processor accepts customer instructions through any channel, over-the-phone, in-person, instant-message, side-email. The intake-triage discipline fails at the source because the instructions are not recorded. The remediation is to define the authorised intake channels, train the operations team on the channel discipline, and log every instruction.

The triage checklist that is not embedded

The processor has a triage checklist (perhaps the twelve categories from this guide), but the checklist is not embedded in the intake workflow. The operations team receives instructions and acts on them without applying the checklist. The remediation is to embed the checklist in the intake channel, the customer-portal instruction workflow enforces the checklist at the source.

The review framed against one reference point only

The processor conducts the legal-and-compliance review against the agreement only, and ignores the controller's own obligations and applicable law. The review misses, for example, an instruction that is within the agreement but would put the controller in breach of its privacy notice. The remediation is to enforce the three-reference-point review (the agreement, the controller's obligations, applicable law) and to document each finding.

The refusal not notified

The processor refuses an instruction but does not notify the controller-customer through the DPA's notice channel. The controller continues to expect the processor to act; the infringement continues; the processor's refusal is meaningless. The remediation is the refusal-notification template and the notification record in the log.

The high-revenue customer refusal signed off at the wrong level

The processor's operations team refuses a high-revenue customer's instruction without escalating to the executive level. The customer's commercial reaction (the contract cancellation, the scope reduction) hits the processor's revenue without the senior-management preparation. The remediation is the sign-off authority matrix and the DPO review of refusals.

The instruction-decision log that does not reconcile

The log has gaps, instructions acted on without a log entry; changes in the change-management records without a corresponding instruction record; sub-processor changes without the corresponding instruction record. The remediation is the quarterly reconciliation and the cross-reference discipline.

The Article 28(10) status-drift register missing

The processor does not maintain the status-drift register. The marginal cases (the processor's own analytics, the model-training, the cross-customer benchmarking) are not analysed. The status drift occurs unnoticed, the marquee A.2.2.5 failure pattern. The remediation is the register and the quarterly DPO review.

The breach-handoff procedure not drilled

The processor has a breach-handoff procedure on paper but has never drilled it. When a real breach occurs, the handoff is delayed, the controller's notice contact is outdated, the dual-clock pattern (DPDP / CERT-In) is confused. The remediation is the annual (or semi-annual) drill and the findings closure.

The operations team not trained

The processor's operations team has not been trained on the twelve instruction categories. The triage discipline fails because the operations team does not recognise the categories. The remediation is the annual training and the training-completion log.

The DPA clause library outdated

The processor's DPA template does not have the A.2.2.5-adjacent clauses (the documented-instructions clause, the intake-channel clause, the infringing-instruction clause, the sub-processor-change clause, the breach-notification clause, the audit-cooperation clause, the legal-process clause). New customers are signed on DPAs that lack the contractual foundation for the instruction discipline. The remediation is the DPA refresh programme and the new-customer DPA template enforcement.

The marketing-use instruction quietly complied with

The marquee Article 28(10) pattern, a controller-customer asks the processor to use the controller's data for the processor's own marketing (a co-marketing campaign, a joint case-study, a benchmarking report). The processor quietly complies to preserve the customer relationship. The processor has drifted towards controller status for that processing. The remediation is the Article 28(10) status-drift analysis and the refusal of the marketing-use instruction unless a separate licensed-data arrangement is negotiated.

The sub-processor-change instruction bypassed

A controller-customer asks the processor to add a sub-processor "immediately" (a customer-specific integration, a one-off data flow). The processor complies without following the A.2.5.9 procedure. The sub-processor is uncontrolled; the change-management records do not reflect the change. The remediation is the integration of the instruction process with the sub-processor-change procedure.

The breach-suppression instruction quietly complied with

The marquee DPDP section 8(6) infringement, a controller-customer, on learning of a breach, asks the processor to suppress the breach notification (do not report to the Board; do not notify the principals; do not log the breach in the incident records). The processor quietly complies. The section 8(6) breach-notification failure propagates to the controller's penalty exposure (up to two hundred crore rupees) and to the processor's contractual indemnity. The remediation is the breach-handoff procedure and the operations-team training on the breach-related instruction category.

The instruction-decision log without integrity controls

The log is a generic spreadsheet or a SharePoint list that can be edited by any administrator. The integrity dimension is unprotected. The remediation is the integrity controls (tamper-evidence, access control, logging, backup).

The customer-portal workflow not used

The processor has a customer-portal instruction workflow, but the customers continue to email (because the portal requires a signatory login and the email does not). The remediation is the portal-adoption campaign and the customer-onboarding training.

The multi-jurisdiction instruction handled as single-jurisdiction

A controller-customer's instruction involves EU and US and India data (the customer's principals span jurisdictions). The processor reviews the instruction against DPDP only and misses the GDPR Article 28(3) implication for the EU principals. The remediation is the multi-jurisdiction review checklist and external counsel on call.

The "we have an instruction clause in our DPA" complacency

The processor's privacy posture says "we act only on documented instructions". The processor treats this as A.2.2.5 compliance. The instruction-decision log is empty or partial. The remediation is the instruction-decision log and the operational evidence.

The intake channel that the customer did not know about

The processor defined an authorised intake channel (privacy@) but did not communicate it to the customers. The customers continue to email their sales contact or their customer-success manager. The remediation is the customer-communication campaign and the DPA's notice-channel clause.

The sign-off authority matrix not documented

The processor's sign-off authority levels are not documented. Different dispositions are signed off at different levels without a consistent matrix. The remediation is the documented sign-off authority matrix.

Illustrative Scenario 1: Failure, Kaveri BPO and the Infringing Instruction That Was Complied With (Illustrative)

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

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

The setting. Kaveri BPO Private Limited operates a pan-India business-process-outsourcing operation with approximately 4,200 employees across Bengaluru, Hyderabad and Pune, serving 18 controller-customers, 9 US-based financial-services controllers, 5 India-based BFSI controllers, 3 UK-based insurance controllers, and 1 India-based healthcare controller. The company processes customer-data on behalf of its controller-customers across voice (call-centre), back-office (claims processing, loan origination, customer-onboarding KYC) and analytics (customer-segmentation, churn-prediction) services. The company is RBI-regulated indirectly (its BFSI customers impose the RBI IT-outsourcing obligations contractually), SEBI-regulated indirectly (its capital-markets-intermediary customers), and IRDAI-regulated indirectly (its insurer customers).

The A.2.2.5 programme at the audit. At the time of the ISO/IEC 27701:2025 Stage 1 audit in late 2026, Kaveri BPO's A.2.2.5 programme was typical of an Indian growing-company processor that had prioritised operational scale over privacy discipline:

• The DPA with each customer had the documented-instructions clause (a one-line inheritance from the customer's standard processor-contract template). The clause was treated as the A.2.2.5 control. No instruction-decision log existed.
• Customer instructions were received through any available channel, over-the-phone from the customer's operations lead, by email to the customer-success manager, through the WhatsApp groups that several customer operations teams maintained for routine operational coordination. The intake-triage discipline did not exist.
• In the 18 months before the audit, the company had received and acted on at least 47 customer instructions that would have triggered a review-required triage, 12 new-purpose instructions (analytics uses pitched by the customer's marketing team and quietly accommodated by Kaveri's analytics lead); 9 new-sub-processor instructions (Kaveri engaged two new sub-processors for a customer-specific integration without the A.2.5.9 notice); 7 retention-extension instructions; 6 marketing-use instructions (Kaveri used customer testimonials and case-studies derived from one customer's data in its own marketing); 4 security-control-exception instructions (firewall ports opened for a customer's legacy integration); 3 cross-customer-sharing instructions (one customer's data was inadvertently visible to another customer's team through a shared reporting dashboard); 2 audit-related instructions (a customer asked Kaveri to omit certain records from the next quarterly audit); 4 breach-related instructions (a customer asked Kaveri to delay reporting a phishing incident until the customer's crisis-communications team was ready).
• The Article 28(10) status-drift register did not exist. The 6 marketing-use instructions had caused status drift (Kaveri had processed one customer's data for Kaveri's own marketing purposes); the drift was unanalysed.
• The breach-handoff procedure existed on paper but had never been drilled. The 4 breach-related instructions had been quietly complied with; the handoff notifications to the controllers were either absent or substantially delayed (in one case, the controller was notified 11 days after the breach; the controller's own DPDP section 8(6) clock had already run).

The trigger. In September 2026, a phishing incident at one of Kaveri's India-based BFSI controller-customers exposed the loan-application data of approximately 84,000 of the controller's retail customers. The breach originated at Kaveri (a Kaveri agent's credentials were phished). The controller-customer, on learning of the breach from Kaveri's incident-response team on day 1, instructed Kaveri to delay the breach-handoff notification (the controller's crisis-communications team needed time to prepare the principal notification and the press statement). Kaveri's incident-response lead complied; the breach-handoff to the controller was formally issued on day 11. The controller's DPDP section 8(6) notification to the Board was filed on day 13 (one day after the 72-hour clock from the controller's formal awareness, but the controller's awareness had been backdated). A whistleblower complaint from a Kaveri insider to the Data Protection Board of India in October 2026 triggered the DPBI's investigation, which surfaced the 11-day delay, the backdating, and the broader A.2.2.5 programme failure.

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

• Major nonconformity, A.2.2.5 (intake channel and triage). No defined intake channel; no triage checklist; no instruction-decision log. The 47 customer instructions in the prior 18 months had been received and acted on without any A.2.2.5 process.
• Major nonconformity, A.2.2.5 (breach-related instruction). The breach-suppression instruction (the day-1 instruction to delay the handoff) was a textbook A.2.2.5 infringement. Kaveri's compliance with the instruction contributed directly to the DPDP section 8(6) failure at the controller-customer (the 11-day delay) and to the backdating.
• Major nonconformity, A.2.2.5 read with Article 28(10) status-drift. The 6 marketing-use instructions had caused controller-status drift (Kaveri had processed one customer's data for Kaveri's own marketing purposes). The status-drift register did not exist; the drift was unanalysed.
• Major nonconformity, A.2.2.5 read with A.2.5.9 (sub-processor change). The 9 new-sub-processor instructions had been acted on without the A.2.5.9 notice procedure. Two of the sub-processors did not meet Kaveri's own security requirements.
• Major nonconformity, A.2.2.5 read with A.2.3.2 (rights-request instruction). One of the audit-related instructions had included a request to delay a principal's correction request that the controller had forwarded to Kaveri. The instruction was an A.2.3.2 infringement that Kaveri complied with.
• Minor nonconformity, A.2.2.2 (customer agreement). The DPAs with several customers lacked the documented-instructions clause with the operational specificity A.2.2.5 expects.
• Cross-control findings. The ROPA (A.2.2.7) did not reflect the 47 instructions; the change-management records did not reconcile with the (non-existent) instruction-decision log; the sub-processor register did not reflect the 9 sub-processor changes; the breach register did not reflect the 4 breach-related instructions.

The regulatory outcome. The DPBI, on the whistleblower complaint and the parallel audit, found in January 2027 that Kaveri BPO's A.2.2.5 programme failure had contributed to the controller-customer's DPDP section 8(6) breach-notification failure. The DPBI's investigation focused on the controller-customer (the controller owed the section 8(6) notification to the Board and the affected principals), but the DPBI's order named Kaveri as a processor whose compliance with the breach-suppression instruction had materially contributed to the failure. The controller-customer was fined in the section 8(6) band (the order referenced the up-to-two-hundred-crore-rupee maximum; the actual fine was in the high tens of crores). The controller-customer then invoked the indemnity clause in its DPA with Kaveri, claiming the fine and the associated costs (the principal notifications, the crisis-communications, the legal defence, the brand-repair). Three of Kaveri's other controller-customers, on learning of the DPBI order, suspended or terminated their contracts; the company's revenue declined approximately 18% over the following two quarters.

The lessons.

• The DPA clause without the process is not A.2.2.5. The documented-instructions clause in the DPA is the contractual foundation; the operational process is the control. Kaveri's DPA had the clause; its operations did not have the process; the audit found the control failed.
• The breach-related instruction is the highest-risk category. The breach-suppression instruction is the marquee A.2.2.5 infringement, and the one with the most severe commercial consequences (the DPBI investigation, the controller's indemnity claim, the contract suspensions). The processor that does not train its incident-response team on the breach-related instruction category is at the highest A.2.2.5 risk.
• The Article 28(10) drift is real and consequential. Kaveri's marketing-use instructions had caused status drift that Kaveri had not analysed. The drift, in a regulator's hands, is evidence of the processor's broader privacy-programme failure.
• The instruction-decision log is the evidence. Without the log, the processor cannot demonstrate that the A.2.2.5 process operated. With the log, the processor can demonstrate the triage, the review, the escalation, the refusal or compliance decision, the notification.
• The audit and the regulator read the same evidence. The Stage 1 audit findings and the DPBI investigation findings were substantially overlapping. An ISO/IEC 27701:2025 audit is a near-proxy for regulatory readiness.

Illustrative Scenario 2: Success, Tarun Cloud Services Builds the Instruction-Intake Discipline (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 SaaS and cloud-processor companies. No specific real company is described.

The setting. Tarun Cloud Services Private Limited is a Bengaluru-based SaaS analytics processor with approximately 380 employees, serving 64 controller-customers, 28 India-based (across BFSI, healthcare, retail and edtech), 22 EU-based, 10 US-based, and 4 in the Middle East and Southeast Asia. The company provides customer-analytics, churn-prediction, and personalisation services on top of its customers' first-party data. The company is indirectly RBI-regulated (its BFSI customers), SEBI-regulated (its capital-markets-intermediary customers), and IRDAI-regulated (its insurer customers); directly GDPR-relevant for its EU customers; and DPDP-bound for its India customers.

The pre-remediation state. In early 2025, ahead of the ISO/IEC 27701:2025 publication and the DPDP Rules notification, Tarun Cloud's A.2.2.5 programme was uneven. The DPA template had a documented-instructions clause (inherited from an early template). Customer instructions were received through the customer-success team by email, with no formal intake channel, no triage checklist, and no instruction-decision log. In the 12 months before the remediation, the company had received approximately 130 customer instructions of varying significance, most were routine operational changes (new dashboard views, new event-tracking parameters), but approximately 30 were review-required under the twelve categories (new analytics uses, new cross-border destinations, marketing-use asks, security-control exceptions for legacy customer integrations, sub-processor additions). The 30 review-required instructions had been acted on without any A.2.2.5 review; the Article 28(10) status-drift register did not exist; the breach-handoff procedure existed on paper but had never been drilled.

The trigger. Tarun Cloud's board, on the recommendation of the Chief Privacy Officer (a VP-level role reporting to the CEO), decided in mid-2025 to seek ISO/IEC 27701:2025 certification. The decision was driven by three considerations: (i) the company's enterprise customers (especially the BFSI and the EU customers) were increasingly asking for ISO/IEC 27701 attestation as a procurement requirement; (ii) the company had lost a major BFSI deal in Q1 2025 because the customer's vendor-diligence team flagged the absence of a documented instruction process; (iii) the company was planning to launch a new AI-driven personalisation product that would attract scrutiny on the processor's instruction-handling discipline.

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

Quarter 1, Policy, log, and intake channel. The team stood up the Infringing-Instruction Policy (toolkit doc 01). The team stood up the Instruction-Decision Log on the company's existing GRC platform (extended with a customer-instruction module). The team defined the authorised intake channels (the customer-portal instruction workflow as the gold standard; a designated email address as the fallback during the portal rollout). The team ran the retrospective instruction sweep on the previous 12 months, the 130 instructions were logged retrospectively, the 30 review-required were triaged, the analysis produced the gap findings (the marketing-use pattern, the sub-processor pattern, the security-control-exception pattern).

Quarter 2, Triage checklist and legal-and-compliance review. The team wrote the twelve-category triage checklist (toolkit doc 03) calibrated to Tarun Cloud's customer portfolio. The team wrote the three-reference-point legal-and-compliance review procedure (toolkit doc 02). The team trained the operations and customer-success teams on the intake-triage discipline (40 staff trained in the first wave). The team ran the first review-required reviews on new instructions received in the quarter, 8 instructions received, 6 routine, 2 review-required, both reviewed and disposed within the 5-business-day target.

Quarter 3, Escalation playbook and refusal notifications. The team wrote the Customer Escalation and Refusal Playbook (toolkit doc 08) with the templates calibrated to the typical scenarios. The team wrote the sign-off authority matrix and the DPO review of refusals. The team ran the first refusal, an EU customer's instruction to use the customer's data for Tarun Cloud's own model-training (a textbook Article 28(10) trigger). The refusal was issued through the DPA's notice channel; the customer's response (initially hostile, then collaborative) led to a separate licensed-data arrangement that was commercially beneficial to both parties. The Article 28(10) status-drift register was stood up; the marketing-use patterns from the retrospective sweep were logged and resolved.

Quarter 4, DPA refresh and certification. The team refreshed the DPA template (toolkit doc 10) with the A.2.2.5-adjacent clauses, the documented-instructions clause, the intake-channel clause, the infringing-instruction clause, the sub-processor-change clause, the breach-notification clause, the audit-cooperation clause, the legal-process clause. The refreshed DPAs were rolled out to the 64-customer portfolio through the contract-amendment programme (the larger customers first; the smaller customers on the renewal cycle). The team ran the breach-handoff tabletop drill with the incident-response team and one volunteer BFSI customer. The team ran the internal audit (Clause 9.2) covering the A.2.2.5 programme. The team ran the management review (Clause 9.3) with the thirteen KPIs (Section 12). The team went to the certification audit in February 2027. The Stage 1 audit passed without major nonconformities on A.2.2.5. The Stage 2 audit, conducted in April 2027, traced a sample of instruction-decision records (a routine comply, a comply-with-conditions, a refused marketing-use instruction, a sub-processor-change instruction, a multi-jurisdiction instruction involving EU and India data) through the five-stage lifecycle and the three-reference-point review. Zero major nonconformities on A.2.2.5.

The quantified ROI.

• Avoided penalty exposure. The pre-remediation pattern carried estimated DPDP penalty exposure (propagated from the controller-customers through the indemnity clauses) of approximately INR 25 to 80 crore on the breach-related instruction category alone, and approximately INR 8 to 25 crore on the marketing-use status-drift category. The remediation reduced the exposure by an estimated 90%.
• Operational efficiency. The intake-channel coverage KPI moved from approximately 30% (most instructions arriving by side-email pre-remediation) to 96% (most instructions arriving through the customer-portal workflow) within the four quarters. The triage-decision-timeliness median moved from "never" (no triage pre-remediation) to 1 business day. The review-timeliness median moved to 4 business days (within the 5-business-day target). The refusal-rate settled at approximately 6% of review-required instructions, stable, indicating the customer portfolio's instruction profile was not engaging higher-risk instructions over time.
• Reputational dividend. The company's brand-tracking among enterprise-buyer segments showed an approximately 5-point lift in the "trustworthy processor" dimension over the four quarters. The company's investor-relations team reported that the ISO/IEC 27701 certification was cited positively in two institutional-investor ESG reviews and in one strategic-acquisition diligence.

The lessons.

• Treat A.2.2.5 as a customer-trust investment, not a compliance cost. The instruction discipline delivered direct revenue (the BFSI-procurement wins, the EU-customer renewals), avoided indemnity exposure one order of magnitude greater than the build cost, and produced operational efficiency that the pre-remediation ad-hoc approach could not match.
• The customer-portal instruction workflow is the operational unlock. Most of the audit findings and most of the operational improvements flowed from the portal workflow's embedding. The portal eliminates the over-the-phone and side-email patterns at the source and produces the documented instruction record at the moment of instruction.
• The Article 28(10) status-drift register caught a real risk. The marketing-use instructions from the retrospective sweep were the kind of pattern the register is designed to surface. Without the register, the drift would have continued, with potential controller-status consequences.
• The refusal of the EU customer's model-training instruction led to a better commercial outcome. The initial refusal (the marquee Article 28(10) trigger) opened the negotiation that produced the separate licensed-data arrangement, a more profitable and more defensible commercial structure than the original instruction.
• The breach-handoff drill paid off. The drill surfaced gaps (an outdated customer notice contact; an unclear dual-clock pattern between DPDP and CERT-In) that were closed before a real breach tested them.

Multi-Framework Mapping

The detailed crosswalk

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

The DPDP Act section-by-section A.2.2.5 hooks: section 2(1)(k) (Data Processor definition, the "on behalf of" test the processor must protect); section 4 (grounds, the processor's review checks the controller's grounds); section 5 (notice, the processor's review checks the controller's notice); section 6 (consent, the processor's review checks the controller's consent); section 7 (legitimate uses, the processor's review checks the controller's legitimate-use basis); section 8(5) (security safeguards, the processor implements; the processor's refusal protects the safeguards); section 8(6) (breach notification, the processor's handoff to the fiduciary; the breach-suppression instruction is the marquee A.2.2.5 infringement); section 8(7) (erasure, the processor erases on the fiduciary's instruction at end of retention); section 9 (children, the processor's review checks the children's-data overlay); section 10 (SDF, the processor's instructions process is the operational gate for the SDF's enhanced duties, including DPIP support and independent-audit cooperation); section 11 to 14 (rights, the processor's review checks the controller's rights operation; the rights-request instruction category is the A.2.2.5 hook); section 16 (cross-border negative list, the processor's review checks the controller's transfer basis); section 33 and the Schedule (penalties, the controller's penalty exposure propagates contractually to the processor through the indemnity clauses).

The sector-regulator overlay (India-specific)

The cross-border overlay

Where the processor's controller-customer is in a different jurisdiction, A.2.2.5 inherits the multi-jurisdiction complexity. A controller in the EU instructing an India-based processor: the instruction is governed by the GDPR Article 28(3) documented-instructions duty, the EU SCCs (controller-to-processor module), and the Schrems II transfer-impact assessment. A controller in the US instructing an India-based processor: the instruction is governed by the US-state laws (the CCPA/CPRA service-provider instruction duty; the VCDPA / CPA / CTDPA processor duties) and the Federal Trade Commission's processor expectations. A controller in China instructing an India-based processor: the instruction is governed by the PIPL Article 21 entrusted-processing regime (one of the strictest processor-side regimes globally). A controller in Brazil instructing an India-based processor: the LGPD Article 39 operator duties. The processor's legal-and-compliance review must address each applicable regime; the multi-jurisdiction review checklist (toolkit doc 09) operationalises this.

Implementation Roadmap

The Singahi 30 / 90 / 180-day implementation roadmap (toolkit doc 05) for Control A.2.2.5.

The first 30 days, log 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, Operations Lead, Customer Success Lead, Legal, Information Security, Engineering, Internal Audit). The team adopts the Singahi Instruction-Decision Log template (toolkit doc 03).
• Day 6 to 15, Instruction-Decision Log stand-up. The team stands up the log (spreadsheet acceptable first cycle if integrity, access control and reconciliation are documented; GRC platform or in-house build for the steady state). The team loads the existing instruction-decisions (even if the log starts with the few documented refusals or reviews, it starts).
• Day 16 to 25, Retrospective instruction sweep. The team runs the retrospective sweep on the last 12 (or 18) months of customer-initiated changes, new fields, new purposes, new sub-processors, new cross-border destinations, marketing-use asks, analytics asks, security-control exceptions. The team identifies the review-required instructions that were acted on without a documented A.2.2.5 process.
• Day 26 to 30, Quick wins. The team prioritises the top three retrospective findings for the gap-closure work and launches the intake-channel definition.

The 90-day milestone, design and template

• Day 31 to 50, Template adoption. The team adopts the Singahi Infringing-Instruction Policy (toolkit doc 01), the Lifecycle Procedure (toolkit doc 02), and the Instruction-Intake-and-Review Form (toolkit doc 03), calibrated to the processor's customer-portfolio and regulatory profile (DPDP, GDPR, US-state, sector rules). The team writes the twelve-category triage checklist and the sign-off authority matrix.
• Day 51 to 70, Intake-channel rollout. The team rolls out the authorised intake channels, the customer-portal instruction workflow as the gold standard; the designated email as the fallback. The team trains the operations and customer-success teams on the intake-triage discipline (the twelve categories, the channel discipline, the escalation paths).
• Day 71 to 90, First reviews and refusals. The team runs the first review-required reviews and the first refusals (where triggered). The team tests the refusal-notification template and the customer-escalation workflow. The team runs the first customer-communication campaign on the intake-channel discipline.

The 180-day milestone, DPA refresh and integration

• Day 91 to 120, DPA clause refresh. The team refreshes the DPA template with the A.2.2.5-adjacent clauses (toolkit doc 10). The team begins the contract-amendment rollout to the existing customer portfolio (the larger customers first; the smaller customers on the renewal cycle).
• Day 121 to 150, Article 28(10) register and breach-handoff drill. The team stands up the Article 28(10) status-drift register; the team logs the retrospective findings from the marketing-use pattern. The team runs the first breach-handoff tabletop drill with the incident-response team.
• Day 151 to 180, Integration. The team builds the integration with the change-management records, the sub-processor-change notifications (A.2.5.9), the ROPA (A.2.2.7), and the management review (Clause 9.3). The team rolls out the KPIs (Section 12) and the dashboard.

The 9-to-12-month arc, full A.2.2.5 maturity

• Month 7, Sub-processor integration. The team integrates the instruction process with the sub-processor-change procedure. Every sub-processor-change instruction now flows through the A.2.5.9 procedure and the instruction-decision log.
• Month 8, Log integrity review. The team runs the instruction-decision log integrity review (access review, anomaly check, restoration test).
• Month 9, KPI rollout and management review. The team rolls out the thirteen KPIs to the management review (Clause 9.3). The team identifies the improvement actions for the next cycle (Clause 10.1).
• Month 10, Internal audit. The team runs the internal audit (Clause 9.2) covering the instruction-decision log, the intake channel, the triage checklist, the legal-and-compliance review, the refusal-notification discipline, the Article 28(10) register, the breach-handoff procedure.
• Month 11, Certification Stage 1. The certification Stage 1 documentation review. The team closes the findings before the Stage 2.
• Month 12, Certification Stage 2. The Stage 2 operational-effectiveness test. The A.2.2.5 walk-through (the auditor picks a recent instruction-decision record and traces it through the five-stage lifecycle and the three-reference-point review, and through the integration with the change-management records, the sub-processor-change notifications, the ROPA and the management review).

The ongoing cadence (post-certification)

• Weekly, Instruction-decision log activity review (DPO); new-instruction triage log review (DPO); urgent-escalation review (DPO and senior management).
• Monthly, KPI dashboard review (DPO); refusal-rate trend review (DPO and senior management); customer-escalation outcome review.
• Quarterly, Instruction-decision log reconciliation with change-management records; log access review; Article 28(10) status-drift register review (DPO); customer-portfolio risk analysis (DPO and senior management).
• Semi-annually, Instruction-decision log integrity review (mid-market and enterprise); management review of the A.2.2.5 KPIs.
• Annually, Internal audit of A.2.2.5; breach-handoff tabletop drill (semi-annually for high-risk processors); instruction-decision log restoration test; Infringing-Instruction Policy review; operations-team training refresh.
• Event-driven, Refusal of high-revenue customer instruction (executive sign-off and senior-management escalation); instruction-related incident (breach-handoff procedure and dual-clock pattern); customer DPA amendment (the A.2.2.5-adjacent clauses in the amended DPA); regulatory-change (the legal-and-compliance review checklist updated).

FAQ

Q1. Our DPA already says "the processor shall act only on documented instructions from the controller". Is that enough for A.2.2.5?

No. A.2.2.5 is an operational control, not a contractual control. The DPA clause must be backed by the instruction-decision log, the intake channel, the triage checklist, the legal-and-compliance review, the escalation workflow, the refusal notifications, the Article 28(10) status-drift register, the breach-handoff procedure. The certification auditor and the regulator will both look behind the clause to the operational evidence.

Q2. We have never refused a customer instruction. Are we done?

Probably not. The absence of refusals may indicate that the processor is not running the triage discipline (every instruction is treated as routine) or that the processor is quietly complying with infringing instructions to preserve customer relationships. Run the retrospective instruction sweep on the last 12 months; identify the review-required instructions that were not reviewed. The remediation starts there.

Q3. A customer asks us to add a new sub-processor "immediately", no time for the A.2.5.9 notice. What do we do?

Refuse or comply-with-conditions. The A.2.5.9 sub-processor-change procedure is the processor's control; the controller's instruction to bypass it is an A.2.5.9 infringement and an A.2.2.5 infringement. The processor's options: refuse the sub-processor addition until the notice period runs; comply-with-conditions (the controller confirms in writing that the notice waiver is intentional and accepts the consequences); or escalate to the controller's senior management.

Q4. A customer asks us to use its customer data to train our own model. What do we do?

Refuse, unless a separate licensed-data arrangement is negotiated. The marketing-use / analytics-use / model-training pattern is the marquee Article 28(10) trigger, the processor that complies has drifted towards controller status for that processing. The refusal-notification should propose the licensed-data alternative (a separate agreement under which the controller licenses the data to the processor for the model-training, with the controller's principals notified and the processor acting as a controller for the licensed-data processing).

Q5. A customer asks us to delay reporting a breach to its management. What do we do?

Refuse. The breach-suppression instruction is the marquee DPDP section 8(6) infringement and the marquee A.2.2.5 infringement. The processor's duty is to hand off the breach to the controller without undue delay (the GDPR Article 33(2) language; the DPDP equivalent). The controller's section 8(6) clock starts from the controller's awareness, the processor's handoff starts the clock. The processor that complies with the breach-suppression instruction has contributed to the controller's section 8(6) failure and to the processor's own contractual indemnity exposure.

Q6. A customer instructs us over the phone. What do we do?

Re-issue the instruction through the authorised intake channel. The operations team's training must drive the customer's designated contact to the authorised channel, typically a polite "could you send that through the customer portal so we have the instruction on record?" The over-the-phone instruction is not logged until it is re-issued; the operations team's compliance with the unrecorded instruction is the A.2.2.5 failure.

Q7. We are an SaaS processor with 200 controller-customers. Do we need an instruction-decision log entry for every routine support ticket?

No. The intake-triage procedure distinguishes instructions (which require a log entry) from routine operational communications (which are logged in the request-management system but not in the instruction-decision log). The triage checklist defines the boundary, routine support tickets (status queries, bug reports, configuration help) are operational communications; changes to the processing (new fields, new purposes, new sub-processors) are instructions. The triage decision is documented for each instruction; the routine operational communications are aggregated in the request-management system's reports.

Q8. Our customer is in the EU; we are in India. Does A.2.2.5 apply?

Yes. A.2.2.5 applies to every processor regardless of jurisdiction. For EU controller-customers, the legal-and-compliance review must address the GDPR Article 28(3) documented-instructions duty, the EU SCCs (the controller-to-processor module), and the Schrems II transfer-impact assessment. The multi-jurisdiction review checklist (toolkit doc 09) operationalises the multi-jurisdiction dimension.

Q9. Our customer instructs us to ignore a data-principal's rights request the customer forwarded to us. What do we do?

Refuse. The rights-request instruction category is the A.2.3.2 infringement and the A.2.2.5 infringement. The processor's role is to support the controller's rights operation (A.2.3.2), not to help the controller infringe it. The refusal notification should remind the controller of the A.2.3.2 obligation and the timeline.

Q10. Our customer instructs us to disable a security control to speed up an integration. What do we do?

Refuse, unless the security-control exception can be made safe through compensating controls. The security-control-exception instruction category is a high-risk infringement, the processor that complies may breach its own section 8(5) safeguards duty (under DPDP) or its Article 32 security duty (under GDPR). The processor's options: refuse the exception; comply-with-conditions (the controller accepts the risk and the indemnity; the processor implements compensating controls); or escalate to the controller's senior management.

Q11. Our customer is an SDF under DPDP section 10. Does A.2.2.5 impose additional duties on us?

Yes. The SDF's enhanced duties (DPIP support, independent-audit cooperation, algorithmic-fairness-review support) propagate to the processor through the processor agreement. The processor's instruction process is the operational gate, every instruction from the SDF customer that touches a new processing activity triggers the DPIP support (the processor supports the SDF's DPIP with information about the sub-processor chain, the security controls, the cross-border flows); every instruction that touches an AI feature triggers the algorithmic-fairness-review support; every independent-audit cycle triggers the audit-cooperation duty.

Q12. Our Article 28(10) status-drift register has an open entry. What do we do?

Resolve it. The open entry means the status-drift question is unresolved, the processing is marginal and may have moved the processor towards controller status. The resolution options: renegotiate the controller's instructions to clarify the boundary (the controller confirms in writing that the processing is within the controller's instructions); re-architect the processing to keep it within the controller's instructions (typically, by aggregating or anonymising the data so the processing no longer involves personal data); or accept the status drift (the processor acknowledges it has become a controller for that processing and adopts the controller obligation set).

Q13. Our instruction-decision log is on a spreadsheet. Is that acceptable?

Acceptable for the first cycle if integrity, access control and reconciliation are documented. Not acceptable as the steady state for any processor with more than a handful of instructions per month. The spreadsheet's integrity gaps (no integrity seals, broad write access, no audit log, no automated backup) make it unsuitable for a regulated artefact. Migrate to a structured register (GRC platform, in-house build, specialised instruction tool) within the first year.

Q14. We are a B2B service and our customer is the controller; we are the processor. Does A.2.2.5 sit on our side or our customer's side?

Both sides. The customer (controller) has 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 processor has the A.2.2.5 control, the operational gate through which every instruction passes. The two sides are sequential: the controller issues the instruction; the processor operates the A.2.2.5 gate; the controller accepts or amends.

Q15. Our customer instructs us to comply with a court order that requires us to share the customer's data with a third party. What do we do?

Comply with the valid legal process and notify the customer where the legal process permits. A.2.2.5 does not require the processor to refuse valid legal process. The processor's review confirms the legal process is valid (a genuine court order, a genuine regulator's directive); the processor complies; the processor notifies the customer unless the legal process prohibits notification (in which case the processor complies with the prohibition, with the legal-process documentation retained).

Industry-Specific Requirements

BFSI processors

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

• RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025), the bank's outsourcing agreement with the processor must allow RBI inspection; the bank's instructions must be governed; sub-contracting without permission prohibited; the processor must co-operate with the RBI's supervisory action.
• RBI NBFC Managing Risks in Outsourcing Directions, 2025, equivalent NBFC duties.
• SEBI CSCRF (20 August 2024), third-party and outsourcing expectations for SEBI-regulated intermediaries.
• IRDAI Information and Cyber Security Guidelines (24 April 2023), ICT-outsourcing data-protection clauses for insurers' processors.
• RBI Storage of Payment System Data (6 April 2018), payment-data localisation; the processor's cross-border destination instructions are constrained.

A.2.2.5 emphasis for BFSI processors. The instruction process is the operational gate through which the processor's compliance with the RBI / SEBI / IRDAI outsourcing rules is demonstrated. The refusal of a bank's instruction to bypass the sub-contracting control (RBI IT Outsourcing); the refusal of an NBFC's instruction to share data cross-border in violation of the localisation rule; the refusal of a SEBI-regulated intermediary's instruction to omit records from the SEBI audit, these are the marquee A.2.2.5 refusals in the BFSI context.

Healthcare processors

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

A.2.2.5 emphasis for healthcare processors. The instruction process is the gate for health-data-specific instructions: a hospital-customer's instruction to share patient data with a pharmaceutical company for marketing (a textbook infringement); an insurer-customer's instruction to use claims data for the processor's own actuarial-product development (a textbook Article 28(10) trigger); a telemedicine-customer's instruction to retain consultation recordings beyond the agreed retention (a retention-extension infringement). The processor's intake-triage discipline must flag health-data instructions as review-required by default.

IT-ITeS and SaaS processors

IT-ITeS and SaaS processors, the largest segment of Indian processors, operate across multiple jurisdictions (DPDP for India customers, GDPR for EU customers, US-state laws for US customers, PIPL for China customers, LGPD for Brazil customers) and serve the most diverse customer portfolio. The instruction profile is correspondingly diverse, from routine support tickets to complex analytics-use and model-training requests.

A.2.2.5 emphasis for IT-ITeS and SaaS processors. The multi-jurisdiction instruction regime (single instruction-decision log, per-jurisdiction review); the customer-portal instruction workflow as the gold-standard intake channel; the Article 28(10) status-drift register for the processor's own analytics and model-training; the sub-processor-change integration; the customer-portfolio risk analysis at the management review.

E-commerce and retail processors

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

A.2.2.5 emphasis for e-commerce and retail processors. The marketing-use instruction category is the marquee; the cross-customer data-sharing instruction is the second marquee (a payment-processor serving two competing e-commerce customers must refuse instructions that would expose one customer's data to the other); the personalisation-use instruction is the third marquee (the processor's own personalisation product, if trained on customer data, is an Article 28(10) trigger).

Edtech processors

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

A.2.2.5 emphasis for edtech processors. The children's-data overlay (DPDP section 9) makes every instruction involving a child's data a high-risk instruction. The processor's intake-triage discipline must flag children's-data instructions as urgent-escalation. The behavioural-monitoring and targeted-advertising prohibitions in section 9 are absolute, an edtech-controller customer's instruction to enable behavioural monitoring or targeted advertising for users under eighteen is a textbook section 9 infringement and a textbook A.2.2.5 infringement.

Manufacturing processors

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

A.2.2.5 emphasis for manufacturing processors. The employee-monitoring instruction category (a manufacturing-controller customer's instruction to enable location-tracking on the plant floor, or to monitor IIoT-equipment usage by identified employees); the cross-border instruction category (a multinational manufacturing-controller's instruction to share supplier-contact data across the group's global affiliates); the IIoT-data instruction category (an instruction to use IIoT-equipment data, which may identify individual operators, for the processor's own product-development).

Government processors

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

A.2.2.5 emphasis for government processors. The exemption analysis under section 17; the instruction-handling discipline for the consent-based government services (where the government offers a consent-driven service, a public-health portal, an education portal); the joint-controller analysis with the public-sector technology partners; the legal-process handling for government-instructed data sharing.

Maturity Model

Level 1, Initial / Ad-hoc

Characteristics. No Infringing-Instruction Policy. No Instruction-Decision Log. Customer instructions received through any available channel; no intake-triage discipline. DPA boilerplate treated as the A.2.2.5 control. No Article 28(10) status-drift register. No breach-handoff drill. The most common A.2.2.5 audit nonconformity in Indian growing-company processors.

Typical artefacts. A DPA template with a documented-instructions clause inherited from a standard template. No other A.2.2.5 artefacts.

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

The investment covers the log stand-up, the intake channel, the triage checklist, the refusal-notification template, the first DPA-clause refresh.

Level 2, Repeatable / Defined

Characteristics. A documented Infringing-Instruction Policy. A current Instruction-Decision Log. The five-stage lifecycle procedure adopted. The twelve-category triage checklist embedded in the intake workflow. The legal-and-compliance review checklist calibrated to the customer portfolio. The refusal-notification template in use. The first Article 28(10) status-drift register entries logged.

Typical artefacts. The Infringing-Instruction Policy; the Lifecycle Procedure; the Instruction-Decision Log; the Instruction-Intake-and-Review Form; the first refusal notifications; the first status-drift register entries.

The investment covers the DPA refresh, the customer-portal integration, the breach-handoff drill, the KPI maturity.

Level 3, Managed / Measured

Characteristics. The DPA clause refresh completed; the refreshed DPAs rolled out to the customer portfolio. The customer-portal instruction workflow live; intake-channel coverage above 90%. The first breach-handoff drill conducted; the findings closed. The Article 28(10) status-drift register reviewed quarterly. The thirteen KPIs reporting; the first management-review pack produced. The first internal-audit report on A.2.2.5.

Typical artefacts. The refreshed DPA template; the customer-portal instruction workflow; the breach-handoff drill report; the status-drift register; the KPI dashboard; the first internal-audit report on A.2.2.5.

The investment covers the multi-jurisdiction review checklist, the customer-portfolio risk analysis, the integrity-control deepening.

Level 4, Quantitatively Managed

Characteristics. The instruction-decision log integrity seals operating; the access controls at least-privilege; the multi-jurisdiction review checklist operational (DPDP plus GDPR plus US-state plus sector rules). The customer-portfolio risk analysis driving the management review. The refusal-rate trend stable or falling. The breach-handoff drill running semi-annually with both the DPDP and the CERT-In paths tested. The KPI targets consistently met; the management-review pack driving Clause 10.1 improvement.

Typical artefacts. The integrity-seal evidence; the multi-jurisdiction review checklist; the customer-portfolio risk analysis; the semi-annual breach-handoff drill reports; the management-review minutes with KPI trend analysis.

Level 5, Optimising

Characteristics. The instruction-handling programme is continuously improved; the instruction-decision log is the system-of-record for the broader customer-relationship-management practice. The Article 28(10) status-drift methodology is at the frontier (the team contributes to the sector's methodology; publishes anonymised lessons). The breach-handoff drill is run quarterly with multiple volunteer customers. The programme produces predictive analytics (instruction-pattern prediction; refusal-pattern analysis; customer-portfolio risk forecasting). The processor's A.2.2.5 programme is benchmarked against the industry; the processor contributes to the standard's evolution.

Typical artefacts. The continuous-improvement log; the predictive-analytics dashboard; the multi-customer breach-handoff drill reports; the industry-benchmarking evidence.

Maturity-model quick-reference

Emerging Trends

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

The DPDP section 8(6) breach-notification duty, operationalised by the DPDP Rules 2025 Rule 7 (intimation to the Board without delay; detailed report within 72 hours), is becoming the operational standard against which the regulator and the certification auditor compare every processor's A.2.2.5 programme. The breach-handoff procedure, the processor's notification to the controller of a breach affecting the controller's data, is the upstream input. Processors that drill the breach-handoff quarterly (or semi-annually for high-risk processors) are operating A.2.2.5 at the most mature end of the spectrum and are well-prepared for the regulator's increasing enforcement focus on breach-notification failures.

The Article 28(10) status-drift question in the AI era

The Article 28(10) status-drift question is sharpening in the AI era. Processors that offer AI-driven services (analytics, personalisation, recommendation, prediction) on top of customer data face the status-drift question routinely: is the model-training within the controller's instructions, or for the processor's own benefit? The marginal cases (aggregated training; federated learning; differential privacy; synthetic data) are increasingly common, and the methodology for assessing the status-drift question is converging on a multi-factor analysis (the data source; the model's purpose; the controller's instructions; the processor's commercial benefit; the principal's reasonable expectations). Processors that build the Article 28(10) status-drift register and review it quarterly are operating ahead of the regulatory curve.

The customer-portal instruction workflow as the industry standard

The customer-portal instruction workflow is becoming the industry standard for SaaS and cloud processors. The workflow eliminates the over-the-phone and side-email patterns at the source; produces the documented instruction record at the moment of instruction; integrates with the processor's request-management system and the GRC platform; and provides the customer's authorised signatory with a clear, attributable channel. The workflow is increasingly expected by enterprise customers (the banks, the insurers, the MNCs) in their vendor-diligence questionnaires. Processors that have not adopted the workflow by 2027 will be at a competitive disadvantage in the enterprise-procurement segment.

The multi-jurisdiction instruction regime

The multi-jurisdiction instruction regime is becoming the operational reality for Indian processors. The DPDP, GDPR, US-state, China PIPL, Brazil LGPD, and the sector rules (RBI, SEBI, IRDAI) impose overlapping but not identical processor-side duties. A controller-customer's instruction may simultaneously involve DPDP, GDPR and US-state data, the processor's legal-and-compliance review must address each regime. The multi-jurisdiction review checklist (toolkit doc 09) is the operational tool; the processors that build the multi-jurisdiction capability early are well-prepared for the global customer portfolio.

The instruction-decision log as the system-of-record for customer-relationship risk

The instruction-decision log is increasingly the system-of-record for the broader customer-relationship-risk practice, the processor's understanding of which customers are pushing the boundaries, which instructions are recurring, which refusals have triggered commercial reactions. The convergence is operational; the instruction-decision log, the customer-portfolio risk register, the breach-handoff drill findings, and the Article 28(10) status-drift register are increasingly integrated into a single customer-relationship-risk evidence base. Processors that design the integration from day one avoid the fragmentation that the pre-remediation state typically exhibits.

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

The A.2.2.5 dimensions of DPDP, GDPR, US-state laws (CCPA/CPRA service-provider; VCDPA / CPA / CTDPA processor), the sectoral regimes (RBI IT Outsourcing; SEBI CSCRF; IRDAI ICT-outsourcing; CERT-In Directions), and the global processor regimes (PIPL Article 21; LGPD Article 39; PDPA Singapore section 11) are converging on a similar operational core: documented instructions, intake channel, triage checklist, legal-and-compliance review, customer escalation, refusal notification, instruction-decision log, breach-handoff procedure, status-drift register. The convergence is not perfect (the US-state model differs in the processor's refusal expectations; PIPL adds the CAC security-assessment overlay for cross-border processor arrangements), but a processor that builds to the DPDP-plus-GDPR core will be substantially conformant with the wider landscape with per-jurisdiction configuration. The converged architecture is the Singahi recommended pattern.

The instruction process as evidence in regulatory enforcement and civil litigation

The instruction process is increasingly being used as evidence in regulatory enforcement and civil litigation. A processor that operated the A.2.2.5 gate (logged the instruction, conducted the review, escalated, refused, notified) has a stronger defence; a processor that did not is in a weaker position. The trend is most visible in the EU (the GDPR enforcement on processor conduct) and is expected to follow in India as the DPBI becomes operational. The instruction-decision log is not only a compliance artefact; it is a litigation-readiness artefact.

The processor-side ethical-AI dimension

The processor-side ethical-AI dimension is an emerging area that intersects A.2.2.5. A controller-customer's instruction to use the processor's AI-driven service on the controller's data may raise ethical-AI questions (the model's bias, the model's explainability, the principal's right to a human decision). The processor's A.2.2.5 review is not the right place to resolve the ethical-AI questions (those belong in the controller's DPIA under A.1.2.6 and the controller's algorithmic-fairness review under DPDP section 10 SDF), but the processor's review should flag the ethical-AI dimension and route the instruction to the controller's DPIA / fairness-review process. The convergence of A.2.2.5 and the ethical-AI dimension is an emerging area that processors should monitor.

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 (only control 5.34 is PII-specific; control 5.19 governs supplier relationships).
• ISO/IEC 27018:2019, Code of practice for protection of PII in public clouds acting as PII processor.
• ISO/IEC 27017:2015, Code of practice for cloud security.
• ISO/IEC 29100:2011, Privacy framework (eleven privacy principles).
• 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.

Jurisprudence

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

Global regulations (mapped in Section 16)

• Regulation (EU) 2016/679 (General Data Protection Regulation), OJ L 119, 4.5.2016, p. 1; application from 25 May 2018. Source: eur-lex.europa.eu. Article 28 processors (Article 28(3) mandatory DPA content with documented-instructions clause; Article 28(10) controller-status drift; Article 28(4) standard-contractual-clauses); Article 29 cooperation; Article 32 security; Article 33 breach (Article 33(2) processor-to-controller notification).
• Regulation (EU) 2024/1689 (Artificial Intelligence Act), OJ L, 12.7.2024, the fundamental-rights impact assessment overlay for high-risk AI systems.
• Commission Implementing Decision (EU) 2021/914 of 4 June 2021, modernised Standard Contractual Clauses (the controller-to-processor module is the relevant SCC for A.2.2.5).
• European Commission adequacy decision on the EU-US Data Privacy Framework (10 July 2023).
• UK GDPR; Data Protection Act 2018 (c. 12); UK International Data Transfer Agreement (IDTA) and UK Addendum to EU SCCs.
• California Consumer Privacy Act / California Privacy Rights Act (Cal. Civ. Code 1798.100 et seq.), the "service provider" / "contractor" instruction discipline.
• Virginia Consumer Data Protection Act (Va. Code § 59.1-575 et seq.), processor instruction duties.
• Colorado Privacy Act (C.R.S. § 6-1-1301), processor instruction duties.
• Connecticut Data Privacy Act (Public Act 22-15), processor instruction duties.
• Brazil, LGPD (Lei nº 13.709/2018), effective 18 September 2020. Article 39 operator duties.
• China, PIPL, effective 1 November 2021. Article 21 entrusted processing (one of the strictest processor-side regimes).
• Singapore, PDPA 2012 (No. 26 of 2012) as amended; section 11 protection obligation.
• Canada, PIPEDA (S.C. 2000, c. 5); accountability 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.
• South Africa, POPIA (Act 4 of 2013), fully in force 1 July 2021.

Frameworks and guidance

• NIST Privacy Framework v1.0: A Tool for Improving Privacy Through Enterprise Risk Management, NIST.CSWP.01162020 (16 January 2020). Source: nist.gov/privacy-framework.
• NIST AI Risk Management Framework (AI RMF 1.0), NIST.AI.100-1 (26 January 2023). Source: nist.gov/itl/ai-risk-management-framework.
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (TSC 2017; 2022 Points of Focus update). The Privacy criteria: P1.0 to P8.0; P6.0 (Disclosure and notification) is the load-bearing mapping for A.2.2.5; the Common Criteria CC9.2 (vendor oversight) is the controller-side mirror.
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR; Guidelines 07/2020 on Articles 28 and 29 (processor duties); Guidelines 9/2022 on personal data breach notification.
• Article 29 Working Party, WP248 rev.01, Guidelines on Data Protection Impact Assessment (the controller-side DPIA guidelines that the processor supports).
• ICO (UK) Accountability Framework; ICO guidance on controllers and processors; ICO data-processing agreements template.
• CNIL (France), recommendations on the selection of processors; the CNIL DPA models.

Certification-scheme and practitioner references (generic)

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