ISO 27701 A.3: Organisational Controls

Quick Reference (60 Seconds)

If you only read one thing: the A.3 organisational controls are where the PIMS stops being a privacy paperwork exercise and becomes the security backstop that makes the privacy commitments defensible. A controller can have a perfect Privacy Policy (clause 5.2), a perfect ROPA (A.1.2.9), a perfect consent record (A.1.2.5) and still lose a principal's data through a misconfigured access right (A.3.9), an unguarded supplier connection (A.3.10) or an incident response that missed the DPDP breach clock (intimation without delay, then a seventy-two-hour report; A.3.12). The fourteen controls in this guide are not privacy controls in the strict sense, they are the organisational scaffolding that holds the privacy controls up. Get them wrong and however strong the A.1 / A.2 privacy discipline, the PIMS is non-conformant and the Data Protection Board of India, after a breach or a complaint, will ask why the backstop was missing.

What the Standard Actually Requires

The paraphrased family-level requirement

ISO/IEC 27701:2025 controls A.3.3, A.3.4, A.3.9, A.3.10, A.3.11, A.3.12, A.3.14 and A.3.16 ask PII controllers and processors to put in place a coherent, governance-driven set of organisational security controls, a board-endorsed information security policy (A.3.3) with topic-specific policy overlays where PII is processed (A.3.3, with compliance tested under A.3.16); clearly defined security roles and responsibilities aligned to the privacy roles under clause 5.3 (A.3.4); access rights that follow least-privilege and need-to-know for PII (A.3.9); supplier agreements that propagate PII-protection duties down the processor and sub-processor chain (A.3.10); security treated as a first-class concern in every project and change initiative that touches personal data (A.3.11); an incident response capability that meets the dual-clock breach-notification pattern (CERT-In six hours, DPDP without delay plus a seventy-two-hour detailed report, sector-regulator clocks) (A.3.12); protection of records, including the PII records and the PIMS evidence base, against destruction, loss, falsification and unauthorised modification (A.3.14); so that the security backstop under the A.1 controller and A.2 processor privacy controls is operationally real, not theoretical.

The fourteen controls operate as a single governance stack: the policy layer (A.3.3, A.3.16) sets the commitments and tests conformance; the governance layer (A.3.4, A.3.13, A.3.15) assigns the people, tracks the obligations and reviews the approach independently; the data layer (A.3.5, A.3.6, A.3.7) classifies, labels and governs movement; the access layer (A.3.8, A.3.9) establishes identity and bounds reach; the operational layer (A.3.9, A.3.10, A.3.14) runs access, supplier and records in steady state; the responsive layer (A.3.12) handles the breach when it lands. A controller or processor that holds the stack as one coherent architecture will pass an A.3 audit; a controller that holds each control as a disconnected compliance duty will pass the paperwork but fail the operational test.

The lineage, 2019 to 2025

Under ISO/IEC 27701:2019, the security controls lived in clause 6, an extension of clauses 5 (the 27001 ISMS) and 7 (the 27002 control set). The 2019 structure was awkward because it required the organisation to hold a 27001 certificate (or at least a 27001-conformant ISMS) before 27701 could attach. The 2025 edition consolidates the security controls into Annex A.3 as a normative annex of the standalone PIMS, aligned to ISO/IEC 27002:2022's four themes (5 Organisational / 6 People / 7 Physical / 8 Technological). A separate 27001 certificate is no longer a prerequisite, but the A.3 controls must be implemented within the PIMS, the 2025 edition explicitly contemplates a standalone 27701 scope that includes the A.3 security controls without a separate 27001 certificate. The 2019 → 2025 renumbering is mechanical; no substantive security requirement has been deleted or added.

The 2025 edition's relationship to ISO/IEC 27002:2022 is explicit: Annex B has no B.3 section, and the implementation guidance for A.3 controls points directly to ISO/IEC 27002:2022. Auditors test the A.3 controls against the 27002:2022 control statement (with the PII-protection overlay that 27701 brings via the broader PIMS), not against a 27701-specific restatement. The Singahi ISO/IEC 27001 / 27002 library is therefore the reference for the generic security depth; this A.3 guide adds the privacy overlay.

The privacy overlay, what makes an A.3 control "PII-aware"

An A.3 control is "PII-aware" when the underlying security control is implemented with a specific, documented dimension that addresses the protection of personal data. The privacy overlay is not optional in a PIMS scope, it is what distinguishes an A.3 control from a generic 27002 control. The fourteen controls in this guide carry the following overlays:

• A.3.3 Policies for information security, the policy names PII as a protected-asset category; it cross-references the Privacy Policy (clause 5.2); it commits to the topic-specific privacy policy under A.3.3; it addresses the principal-rights dimension (access, correction, erasure requests as security-relevant events).
• A.3.4 Information security roles and responsibilities, the security roles integrate with the privacy roles under clause 5.3 (the DPO, the privacy lead, the grievance officer); the joiner-mover-leaver workflow covers PII access; the segregation-of-duties analysis covers the high-PII-risk functions.
• A.3.9 Access rights, least-privilege is enforced for PII specifically (not all data equally); the access-recertification cadence reviews PII access at higher frequency; the privileged-access management covers the PII stores (the customer database, the consent ledger, the rights-request queue, the breach register).
• A.3.10 Supplier agreements, the supplier contracts include the DPA clauses required by A.1.2.7 (controllers) and A.2.2.x (processors); the sub-processor chain propagation under A.2.5.7 to A.2.5.9; the cross-border supplier dimension under A.1.5.2 / A.2.5.2.
• A.3.11 Information security incident management planning and preparation, the project-management gate triggers the privacy impact assessment under A.1.2.6 for new processing activities (which, for SDFs, feeds the SDF DPIA due every 12 months under DPDP section 10); the gate is the upstream checkpoint that prevents the privacy-by-design failures A.1.4 is designed to catch.
• A.3.12 Response to information security incidents, the incident response capability includes the dual-clock breach-notification pattern (CERT-In six hours, DPDP without delay plus a seventy-two-hour detailed report, sector-regulator clocks); the principal-notification decision tree; the cross-control feedback into A.1.3 obligations and A.1.5 disclosure records.
• A.3.14 Protection of records, the records-protection discipline extends to the PIMS evidence base (the ROPA, the consent records, the DPIA records, the breach records, the audit records, the management-review minutes); the integrity of the consent records is the integrity of the controller's lawful-basis claim.
• A.3.16 Compliance with policies, rules and standards for information security, the topic-specific policy set includes the privacy policy (cross-link to clause 5.2), the access-control policy, the supplier-management policy, the retention policy, the incident-management policy, the records-management policy, the cryptography policy, the logging policy, each with a documented PII overlay.

The architectural posture, security as the privacy backstop

The A.3 family is the security backstop for the A.1 / A.2 privacy controls. The relationship is asymmetric: a strong A.3 security implementation does not, by itself, make a strong PIMS (the privacy discipline lives in A.1 / A.2 and the MSS clauses); but a weak A.3 implementation undermines every privacy commitment the PIMS makes. A controller that promises consent withdrawal (A.1.3.5) but cannot enforce deletion of the principal's PII across the database, the backup, the analytics warehouse, the supplier chain and the cross-border replica has a privacy commitment the security backstop cannot honour. A processor that promises to process only on the customer's instructions (A.2.2.x) but cannot evidence least-privilege access for its own engineering team has a privacy commitment the security backstop cannot honour.

The architectural posture is therefore: design the A.3 organisational controls from the privacy commitment backward. Start with the A.1 / A.2 privacy commitments; identify the security controls each commitment depends on; verify that the A.3 implementation honours each dependency. The certification auditor traces this backward path: pick an A.1 commitment (e.g. A.1.3.7 access / correction / erasure) and verify the A.3 controls that operationalise it (A.3.9 access rights for the rights-request handlers; A.3.14 records integrity for the consent ledger; A.3.12 incident response for the rights-request breach scenarios).

The Indian statutory anchors

In India, the A.3 organisational family is statutorily anchored in four overlapping instruments.

DPDP Act 2023 section 8(5), reasonable security safeguards. This is the Indian statutory counterpart of GDPR Article 32 and the statutory backbone for the entire A.3 family. The Data Fiduciary shall implement reasonable security safeguards to protect personal data in its possession or under its control, including the integrity, confidentiality and availability of the personal data. Section 8(5) covers the A.3.9 access-rights discipline (confidentiality, who can read the PII); the A.3.10 supplier-agreements discipline (the chain of safeguards down the processor and sub-processor chain); the A.3.11 project-management discipline (the security-by-design duty); the A.3.14 records-protection discipline (the integrity and availability of the PII records and the consent ledger). Section 8(5) failure exposes the Data Fiduciary to penalty of up to two hundred and fifty crore rupees under section 33 and the Schedule, the highest single penalty exposure in the Act.

DPDP Act 2023 section 8(6), breach notification. The duty to notify the Data Protection Board and each affected Data Principal of a personal-data breach, with the notification clock (intimation without delay; seventy-two-hour report) operationalised by DPDP Rules 2025 Rule 7. Section 8(6) is the load-bearing Indian anchor for A.3.12 incident response, the requirement to detect, assess, decide, notify and document within the dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report; sector-regulator clocks where applicable). Section 8(6) failure (failure to notify) exposes the Data Fiduciary to penalty of up to two hundred crore rupees.

DPDP Act 2023 section 10, Significant Data Fiduciary. For controllers designated as SDF, section 10 layers the DPO appointment, the SDF DPIA (the Data Protection Impact Assessment of section 10(2)(c)(i)), the periodic independent data audit and the algorithmic-software review. The DPO is the privacy-role counterpart of the A.3.4 security roles; the SDF DPIA is the upstream privacy assessment that the A.3.11 project-management gate triggers; the independent data audit is the third-line assurance that the A.3 records and evidence base must support; the algorithmic-software review is the privacy overlay that intersects with the A.3.9 access-rights discipline for ADM pipelines.

CERT-In Directions 20(3)/2022-CERT-In (28 April 2022). The horizontal Indian incident baseline. Six headline obligations apply to every ICT operator in India: report prescribed cyber incidents (including data breach, unauthorised access, ransomware) to CERT-In within six hours of noticing; maintain ICT logs for 180 days within Indian jurisdiction; sync ICT clocks to NIC NTP; KYC of VPN / data-centre / cloud / anonymous-service customers for five years; appoint a point of contact for CERT-In; cooperate with investigations. The six-hour CERT-In clock runs in parallel with the DPDP clock (intimation without delay; seventy-two-hour report), an Indian Data Fiduciary must run both clocks simultaneously. This is the cleanest dual-clock example in the Indian privacy and security landscape, and the load-bearing operational pattern for A.3.12.

The sector-regulator overlays (RBI Digital Lending; RBI Storage of Payment System Data; SEBI CSCRF; IRDAI Information and Cyber Security Guidelines) layer additional, more granular supplier-management, incident-reporting, data-locality and records-retention duties on the regulated entities. The A.3 implementation for a BFSI controller is not complete without these overlays; see Section 21.

Demarcations: PIMS scope vs ISMS scope; A.3 vs MSS; what is NOT required

Three demarcations matter for the A.3 family.

PIMS scope vs ISMS scope. In the 2025 standalone structure, the PIMS scope (clause 4.3) defines what the privacy management system covers; the A.3 security controls are implemented within the PIMS scope, not across an enterprise-wide ISMS scope. A controller with a broad ISMS scope and a narrower PIMS scope (e.g. the ISMS covers the entire enterprise, the PIMS covers only the customer-facing personal-data processing) can implement A.3 at the PIMS scope, with cross-references to the ISMS evidence base for the broader security discipline. The certification audit tests the A.3 controls at the PIMS scope but accepts evidence from the ISMS where the ISMS scope subsumes the PIMS scope.

A.3 vs MSS. The A.3 controls are annex controls, they sit in the consolidated Annex A and are selected through the risk assessment under clause 6.1 (which selects the A.3 controls relevant to the PIMS scope) and justified in the Statement of Applicability. The MSS clauses (4 to 10) govern the management system that operates the controls. The A.3 controls do not duplicate the MSS; they are the technical-and-organisational measures the MSS operates.

What the A.3 family does NOT require. It does not require a separate ISO/IEC 27001 certificate (the 2025 edition is standalone-certifiable). It does not require the full ISO/IEC 27002:2022 control set (the PIMS selects the controls relevant to its scope; the privacy overlay narrows the selection further). It does not require the PIMS to operate at the same maturity as an enterprise-wide ISMS, the maturity scales with the PIMS scope (Section 22). It does not require a specific technology stack (the controls are technology-neutral; the controller or processor selects the technology appropriate to the risk and the scope). It does not require the DPO to be the CISO (the two roles are distinct; the A.3.4 discipline documents the integration between them).

What auditors actually check

The certification auditor's A.3 examination has seven predictable moves (the 28-question checklist is in Section 11). First, open the Information Security Policy, does it exist, is it signed off, does it name PII as a protected-asset category, does it cross-reference the Privacy Policy. Second, ask for the security RACI (A.3.4) and verify the integration with the privacy roles under clause 5.3 (especially the DPO and the grievance officer). Third, pick a high-PII-risk system (e.g. the customer database, the consent ledger, the rights-request queue) and trace the access rights (A.3.9), least-privilege analysis, recertification cadence, privileged-access management. Fourth, pick a PII-touching supplier and walk the supplier agreement (A.3.10), the DPA clauses, the security controls, the sub-processor propagation. Fifth, pick a recently-launched processing activity and verify the A.3.11 project-management gate fired, with the DPIA trigger where required. Sixth, walk the incident response plan (A.3.12) and trace the dual-clock pattern, pick a recent incident (or a tabletop scenario) and verify the six-hour CERT-In clock, the DPDP clock (intimation without delay; seventy-two-hour report), and the sector-regulator clocks. Seventh, pick a PIMS evidence artefact (the ROPA, the consent ledger, a DPIA record, a breach record) and verify the A.3.14 records-protection discipline, integrity, availability, retention, falsification prevention. The topic-specific policies (A.3.3) and their compliance records (A.3.16) are sampled across the set. The integrity controls across the technological A.3 family (A.3.25 logging, A.3.26 cryptography) are tested alongside as the technical backstop.

Why This Control Family Matters

The security backstop as the privacy credibility test

Of the four PII themes that run through Annex A.1 (conditions for processing; obligations to principals; privacy by design; sharing, transfer and disclosure) and the parallel four themes of Annex A.2 (processor-side), none is fully credible without the A.3 security backstop. A controller that promises consent withdrawal (A.1.3.5) but cannot operationally delete the principal's PII across the data estate is making a commitment the security backstop cannot honour. A processor that promises to process only on instructions (A.2.2.x) but cannot evidence least-privilege access for its engineering team is making a commitment the security backstop cannot honour. A controller that promises secure transmission (A.1.4.10) but operates an unguarded supplier connection (A.3.10) is one compromised supplier away from a personal-data breach triggering the dual-clock pattern.

This is why the A.3 organisational family is the most cross-referenced family in the PIMS, every privacy commitment traces back to a security control. The certification auditor's walk through any A.1 or A.2 control will, at some point, land in A.3: the access right that lets the rights-request handler see the principal's PII (A.3.9); the supplier agreement that propagates the deletion duty to the sub-processor (A.3.10); the incident response that fires when a breach occurs (A.3.12); the records protection that preserves the consent ledger (A.3.14). An A.3 weakness is rarely isolated, it cascades through the privacy commitments that depend on it.

The Indian regulatory weight

In India, the A.3 organisational family has a regulatory weight that goes beyond the ISO standard itself. The DPDP Act 2023 makes the security safeguards duty (section 8(5)) and the breach-notification duty (section 8(6)) statutory duties, not merely contractual or certification commitments. The DPDP Rules 2025 operationalise the breach clock (intimation without delay; seventy-two-hour report) with the Rule 7 intimation content. The CERT-In Directions operationalise the six-hour cyber-incident clock. The sector regulators layer additional granularity.

The section 8(5) safeguards duty is the load-bearing Indian anchor for the entire A.3 family. The duty covers integrity, confidentiality and availability of personal data, the three dimensions that the A.3 organisational controls exist to protect. Section 8(5) failure carries the highest single penalty under the Act (up to two hundred and fifty crore rupees). The DPBI's enforcement priority (once operational) will land on the controllers whose safeguards are inadequate, and the safeguards evidence is the A.3 evidence base.

The section 8(6) breach-notification duty is the load-bearing Indian anchor for A.3.12. The duty to notify the Board and each affected principal runs on the breach clock (intimation without delay; seventy-two-hour report); failure to notify carries a separate penalty (up to two hundred crore rupees). The intersection with the CERT-In six-hour clock creates the dual-clock pattern that is the single most-tested incident-response dimension in the Indian privacy and security landscape.

The section 10 SDF overlay layers the DPO, SDF DPIA, independent data audit and algorithmic-software review on controllers designated as Significant. The DPO is the privacy-role counterpart of the A.3.4 security roles; the SDF DPIA is the upstream privacy assessment the A.3.11 gate triggers; the independent audit is the third-line assurance the A.3 evidence base must support.

The sector-regulator overlays layer additional, more granular duties on BFSI, healthcare and listed-company controllers. The RBI Digital Lending Guidelines (2 September 2022) require LSP-supplier data-protection clauses, the A.3.10 sector overlay. The RBI Storage of Payment System Data directive (6 April 2018) requires payment-data localisation, the A.3.10 cross-border supplier overlay. The SEBI CSCRF (20 August 2024) requires six-hour incident reporting and third-party data-handling discipline, the A.3.10 and A.3.12 sector overlay. The IRDAI Information and Cyber Security Guidelines (24 April 2023) require policyholder-data confidentiality and ICT-outsourcing data-protection clauses, the A.3.10 and A.3.14 sector overlay.

The cost of non-compliance

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

Direct DPDP penalty exposure for a controller or processor whose A.3 implementation missed a statutory criterion can run to the Schedule maxima, up to two hundred and fifty crore rupees for section 8(5) failure (access-rights failure exposing PII; supplier-chain failure leaking PII; records-integrity failure losing the consent ledger); up to two hundred crore for section 8(6) failure (the breach-notification clock missed); up to one hundred and fifty crore for section 10 failure (the SDF DPIA not run within 12 months; the independent audit not conducted).

Indirect regulatory consequences are larger and slower. An A.3 failure cascades through every privacy commitment that depends on the security control, the consent record becomes unreliable (A.3.14 failure on the consent ledger), the rights-response becomes unverifiable (A.3.9 failure on the rights-request queue access), the supplier-chain becomes opaque (A.3.10 failure on the DPA clauses), the breach response becomes evidentially weak (A.3.12 failure on the incident records). The DPBI, once operational, will request the A.3 evidence base after a complaint or a breach; the absence of the evidence is itself an aggravating factor in the penalty determination.

Commercial cost is significant. The Indian privacy incidents most cited in board rooms, the 2020 grocery-delivery-platform data exposure; the 2021 payment-processor exposure (approximately 35 million card tokens); the 2021 airline/SITA breach (approximately 4.5 million customers); the 2021 healthcare-portal exposure (a state insurance scheme); the contested 2021 fintech exposure (denied by the company); the 2022 telecom-exposure pattern, all carried post-incident examinations that tested the A.3 organisational family. For consumer-facing brands, a public A.3 failure (an unguarded supplier connection leaking PII; an incident response that missed the breach clock (intimation without delay; seventy-two-hour report)) erodes the trust signal the brand spent years building; recovery costs are typically an order of magnitude larger than the prevention cost.

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

The board-level question

The board-level question for the A.3 organisational family is not "do we have an information security policy?", every controller has one. The question is "if the Data Protection Board asked us tomorrow to produce, for any personal-data breach in the last three years, the dual-clock notification trail (CERT-In within six hours; DPDP without delay, with a detailed report within seventy-two hours; sector-regulator clocks), the access-rights recertification record for the affected PII stores, the supplier-agreement PII schedule for every processor in the chain, and the integrity evidence for the consent ledger, could we?" If the honest answer is "partially" or "no", the controller has an A.3 gap regardless of what its information security policy says.

Scope and Applicability

Who the family applies to

Table A.3 sits in the 2025 Annex A as the single security-control set for both controllers and processors. Unlike A.1 (controllers) and A.2 (processors), A.3 binds every organisation in the PIMS scope regardless of role. A controller-only PIMS implements A.3 across its own operations; a processor-only PIMS implements A.3 across its own operations; a mixed PIMS implements A.3 once, covering both roles. The dual-applicability is the load-bearing structural point: A.3 is the security backstop under the entire privacy commitment set, and it does not matter whether the organisation acts as controller or processor, the security discipline is the same.

The fourteen organisational controls in this guide bind every organisation that processes personal data in the PIMS scope, from a two-person startup running a single lead-capture form, to a thousand-person fintech running dozens of processing activities, to a Significant Data Fiduciary under DPDP section 10. The maturity expectations scale with the volume, sensitivity and risk of the processing, see Section 22 (Maturity Model).

When the family applies

The A.3 family is always-on. Unlike A.1.2.5 (which activates when consent is the lawful basis) or A.1.3 (which activates when a rights request is exercised), the organisational security controls run continuously across every processing activity. The access-rights discipline (A.3.9) is enforced every minute of every day; the supplier-agreements discipline (A.3.10) is enforced for every supplier interaction; the incident-response discipline (A.3.12) is enforced from the moment an event is detected; the records-protection discipline (A.3.14) is enforced across every record lifecycle.

What is in scope for the A.3 artefacts

The A.3 family's artefact set covers every system, supplier, project and record that touches PII in the PIMS scope. This includes:

• PII stores, the customer database, the consent ledger, the rights-request queue, the breach register, the grievance log, the analytics warehouse, the marketing-automation platform, the CRM, the HR system, the supplier-management system.
• PII-touching systems, the application stack that processes PII (the web front end, the API layer, the microservices that handle PII, the integration layer with PII-touching suppliers).
• PII-touching suppliers, every processor and sub-processor in the chain; every cloud provider that hosts PII; every analytics provider that ingests PII; every marketing provider that segments PII; every support provider that handles PII tickets.
• PII-touching projects, every new processing activity; every material change to an existing processing activity; every new product or feature that introduces a new PII flow.
• PIMS evidence base, the ROPA, the DPIA records, the consent records, the breach records, the audit records, the management-review minutes, the training records, the policy version history.
• Cross-border PII flows, every cross-border processor flow; every cross-border replica; every cross-border backup flow; every cross-border analytics flow.

What is out of scope

• PII-free systems, a system that processes no personal data (e.g. an internal inventory-management system for an SKU-only warehouse) is out of scope for the PII overlay, though the broader ISMS may still cover it.
• Anonymous data, if the data does not relate to an identifiable principal (true anonymisation, not pseudonymisation), the A.3 PII overlay does not apply. Pseudonymised data is still personal data under DPDP and GDPR; the A.3 overlay applies in full.
• Pure infrastructure data (router configurations, infrastructure-as-code, network topologies) that does not relate to identifiable principals, though logging and monitoring of PII-touching systems remain in scope.
• Public-sector exemptions under DPDP section 17 (state processing) where the exemption applies, note the exemption is narrow.

Applicability by organisation size

Key Definitions and Terminology

The A.3 organisational family draws terms from ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27701:2025 and the DPDP Act 2023. The load-bearing terms below appear throughout the guide.

• PII (personally identifiable information), any information that can be used to identify a PII principal directly or indirectly. The 27701 term; the DPDP analogue is "personal data" (section 2(1)(o), any data about an individual who is identifiable by or in relation to such data).
• PII controller (Data Fiduciary), the organisation that determines the purposes and means of PII processing. A.1 controls bind the controller.
• PII processor (Data Processor), the organisation that processes PII on behalf of a controller. A.2 controls bind the processor.
• PII principal (Data Principal), the individual to whom the PII relates. The DPDP analogue; the GDPR analogue is "data subject".
• Information security policy, the controller's or processor's documented commitments to protect the confidentiality, integrity and availability of its information assets, including PII.
• Topic-specific policy, a policy that addresses a specific security or privacy topic (access control; supplier management; retention; incident management; records management; cryptography; logging) in more detail than the overarching information security policy.
• Least privilege, the access-rights principle that grants a user only the access necessary to perform their function, and no more.
• Need to know, the access-rights principle that grants access to specific information only where the user's function requires knowledge of that specific information.
• Joiner-mover-leaver (JML), the identity lifecycle: the user joins the organisation (access provisioned); moves within the organisation (access adjusted); leaves the organisation (access de-provisioned).
• Access recertification, the periodic review of access rights to verify that each user's access remains appropriate.
• Privileged access management (PAM), the discipline of managing privileged accounts (administrators, root, service accounts) with stronger controls than standard accounts.
• Supplier agreement (DPA, data processing agreement), the contract between a controller and a processor (or between a processor and a sub-processor) that governs the processing of PII. Required by A.1.2.7 (controllers), A.2.2.x (processors), GDPR Article 28.
• Sub-processor, a processor engaged by another processor to process PII on its behalf. The chain propagation is governed by A.2.5.7 to A.2.5.9.
• Security-in-project-management gate, a checkpoint in the project lifecycle that triggers the security-and-privacy review for new processing activities or material changes.
• Personal data breach, a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The DPDP and GDPR definition; the trigger for the dual-clock pattern.
• Dual-clock breach pattern, the operational pattern of running multiple parallel breach-notification clocks: CERT-In six hours; DPDP without delay (seventy-two-hour detailed report); sector-regulator clocks (RBI, SEBI, IRDAI).
• Records protection, the discipline of protecting records (especially PIMS evidence records) against destruction, loss, falsification and unauthorised modification.
• Statement of Applicability (SoA), the documented statement of which A.3 controls are applicable to the PIMS scope and which are excluded (with justification).
• Security incident, an event that compromises or may compromise the confidentiality, integrity or availability of information. A subset of security incidents are personal-data breaches (where PII is affected).
• Significant Data Fiduciary (SDF), a controller designated by the Central Government under DPDP section 10 on the basis of prescribed thresholds (volume, sensitivity, risk).
• DPO (Data Protection Officer), the privacy role under DPDP section 10 (for SDFs) and ISO/IEC 27701:2025 clause 5.3.
• CISO (Chief Information Security Officer), the security role that owns the A.3 control framework (or the equivalent role in a growing company).

Relationship to Other Controls

Within the A.3 family (across the four themes)

The A.3 family is structured along the four ISO/IEC 27002:2022 themes. This guide covers the organisational theme (theme 5). The other three themes (people, theme 6; physical, theme 7; technological, theme 8) are covered in the three companion Singahi A.3-themed guides.

The organisational controls (this guide) are the governance scaffolding for the other three themes. The policies (A.3.3, A.3.16) and the roles (A.3.4) authorise the people-theme, physical-theme and technological-theme controls. The classification and labelling controls (A.3.5, A.3.6) tell those controls which data to protect most tightly, and the incident pair (A.3.11 preparation, A.3.12 response) drives the cross-theme discipline.

To the A.1 controller privacy controls

Every A.1 controller control traces back to A.3 organisational controls for the security backstop. The densest interlocks:

• A.1.2.5 (obtain and record consent) depends on A.3.9 (access rights to the consent ledger) and A.3.14 (records protection for the consent ledger).
• A.1.2.6 (privacy impact assessment) is triggered by A.3.11 (security-in-project-management gate).
• A.1.2.7 (contracts with PII processors) is enforced through A.3.10 (supplier agreements).
• A.1.2.9 (records related to processing, the ROPA) depends on A.3.14 (records protection).
• A.1.3.x (obligations to principals, rights) depend on A.3.9 (access rights for rights-request handlers) and A.3.12 (incident response for rights-request breaches).
• A.1.4.10 (PII transmission controls) is enforced through A.3.9 (access rights for the transmission endpoints) and A.3.10 (supplier agreements for the transmission suppliers).
• A.1.5.x (sharing, transfer and disclosure) depends on A.3.10 (supplier agreements) and A.3.12 (incident response for cross-border incidents).

To the A.2 processor privacy controls

The A.2 processor controls also trace back to A.3 organisational controls, with the customer-controller's instructions as the boundary:

• A.2.2.5 (infringing instruction), when the customer's instruction infringes the law or the DPA, the processor's incident-response discipline (A.3.12) handles the escalation.
• A.2.2.x (processor conditions) depend on A.3.10 (supplier agreements) for the sub-processor chain.
• A.2.5.7 to A.2.5.9 (sub-processor chain, disclosure, engagement, change) depend on A.3.10 for the sub-processor DPA propagation.

To the MSS clauses

The A.3 organisational family is operated by the management system in clauses 4 to 10:

• Clause 4.4 (PIMS), the overall management system within which A.3 lives.
• Clause 5.1 (leadership and commitment), top management commits to the A.3 controls.
• Clause 5.2 (policy), the Privacy Policy cross-references the Information Security Policy (A.3.3).
• Clause 5.3 (roles, responsibilities, authorities), the privacy roles integrate with the security roles (A.3.4).
• Clause 6.1 (actions to address risks and opportunities), the privacy risk assessment selects the applicable A.3 controls and justifies them in the SoA.
• Clause 7.5 (documented information), the A.3 policies, procedures and records are documented information under the PIMS.
• Clause 8.1 (operational planning and control), the A.3 controls are operated under the PIMS's operational planning.
• Clause 9.1 (monitoring, measurement, analysis and evaluation), the A.3 KPIs (Section 12) feed the monitoring discipline.
• Clause 9.2 (internal audit), the A.3 controls are audited at the planned intervals.
• Clause 9.3 (management review), the A.3 KPIs and audit findings feed the management review.
• Clause 10.2 (nonconformity and corrective action), A.3 findings drive corrective action.
• Clause 10.1 (continual improvement), A.3 maturity improves over time.

Detailed Implementation Guidance, Control by Control

This section is the operational core of the guide. Each of the fourteen organisational controls is treated in three layers: the requirement (paraphrased), the PII-protection angle beyond the generic security baseline, and the DPDP-first implementation pointer (with cross-references to the Singahi ISO/IEC 27001 / 27002 library for the generic security depth). The treatments are deliberately condensed, the A.3 condensed series leans on the 27001 library for the security depth and adds the privacy overlay that makes each control PIMS-relevant.

A.3.3, Policies for information security

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.3, aligned to ISO/IEC 27002:2022 control 5.1, asks PII controllers and processors to issue, review and maintain a board-endorsed information security policy that defines the organisation's commitments to protect the confidentiality, integrity and availability of its information assets, and to communicate that policy to all employees, contractors and relevant third parties.

The PII-protection angle. A generic information security policy borrowed from a 27001 template is not sufficient in a PIMS scope. The policy must name PII as a protected-asset category; cross-reference the Privacy Policy (clause 5.2) and the topic-specific privacy policy (A.3.16); commit to the principal-rights dimension (treating rights requests as security-relevant events with their own SLA); address the privacy overlay for each A.3 control (least-privilege for PII under A.3.9; the DPA clauses under A.3.10; the incident-readiness discipline under A.3.11; the dual-clock pattern under A.3.12; the PIMS-evidence integrity under A.3.14). The policy should also state the scope clearly, the PIMS scope (clause 4.3) within which the policy applies, distinct from any broader ISMS scope.

DPDP-first implementation. The policy should explicitly invoke DPDP Act 2023 section 8(5) (reasonable security safeguards) as the Indian statutory anchor, with a clear statement of the dimensions covered (integrity, confidentiality, availability of personal data). It should commit to the section 8(6) breach-notification duty and reference the dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report). For SDFs, it should commit to the section 10 overlay (DPO, SDF DPIA, independent audit, algorithmic-software review). It should reference the relevant sector-regulator instruments (RBI Digital Lending; SEBI CSCRF; IRDAI Guidelines) where applicable.

A.3.4, Information security roles and responsibilities

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.4, aligned to ISO/IEC 27002:2022 controls 5.2 (with 5.3 segregation of duties and 5.4 management responsibility), asks PII controllers and processors to define and assign information security roles and responsibilities, segregated to reduce the risk of unauthorised or unintentional modification or misuse of PII, and clearly communicated.

The PII-protection angle. The security roles must integrate with the privacy roles under clause 5.3, the DPO, the privacy lead, the grievance officer. The integration is operational, not merely org-chart-deep: the joiner-mover-leaver workflow for the security team covers PII access (when an engineer joins a PII-touching team, the PII access is provisioned under A.3.9 with the privacy team's review); the segregation-of-duties analysis covers the high-PII-risk functions (the engineer who deploys a change to the customer database is not the same as the engineer who approves the change; the rights-request handler is not the same as the engineer who executes the deletion); the privileged-access management covers the PII stores (the customer database, the consent ledger, the rights-request queue, the breach register).

DPDP-first implementation. For SDFs, the DPO under DPDP section 10 is the privacy-role counterpart of the CISO (or equivalent). The two roles are distinct (the DPO owns the privacy dimension; the CISO owns the security dimension) but operationally integrated. The DPO must be based in India and accountable to the Board of Directors (section 10); the CISO has no statutory location requirement but should be operationally close to the PIMS scope. The integration is documented in a RACI that maps each A.3 control to the responsible security role and the consulted privacy role. The grievance officer under DPDP section 13 is a third privacy role that integrates with the incident-response discipline (rights-related complaints are security-relevant events under A.3.12).

A.3.5, Classification of information

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.5, aligned to ISO/IEC 27002:2022 control 5.12, asks PII controllers and processors to classify information according to its confidentiality, integrity and availability needs and the requirements of interested parties, and to keep that classification current.

The PII-protection angle. Classification is where the PIMS and the ISMS most often diverge. A security-only scheme (Public / Internal / Confidential / Restricted) does not distinguish personal data from commercially sensitive data, so PII inherits controls designed for trade secrets, sometimes over-protective, more often under-protective on the dimensions that matter for privacy (retention, principal rights, lawful basis). A PIMS-aware scheme adds a personal-data axis to the security axis: is this PII? Is it special-category or children's data (DPDP section 9)? What is the lawful basis and the retention bound? The classification feeds directly into A.1.4.8 retention, A.1.4.9 disposal and the A.3.9 access-rights model.

DPDP-first implementation. Classification is the practical mechanism for demonstrating section 8(5) proportionality, safeguards commensurate with the data. Anchor the scheme to the ROPA (A.1.2.9) so every processing activity's data categories carry a classification, and flag children's data and the sensitive categories that attract sector-regulator overlays (RBI financial data; IRDAI policyholder data; health data).

A.3.6, Labelling of information

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.6, aligned to ISO/IEC 27002:2022 control 5.13, asks PII controllers and processors to develop and implement procedures for labelling information in accordance with the classification scheme the organisation has adopted.

The PII-protection angle. Labelling is what makes classification enforceable by machines. Without labels, the A.3.9 access model, the A.3.25 logging discipline and the A.1.4.8 retention automation all fall back on human judgement at the point of use. In a PIMS the label must survive the data's journey, through exports, reports, analytics warehouses, model training sets and sub-processor transfers, because an unlabelled copy in a downstream system is precisely where erasure and correction propagation fails (A.1.3.7).

DPDP-first implementation. Prioritise labelling on the surfaces that carry principal-rights obligations: the primary store, the analytics warehouse, the data-export pipeline and the sub-processor feed. Where automated labelling is not yet feasible, document the compensating control (a maintained data map) and the roadmap, an auditor accepts a phased implementation with a plan; it does not accept silence.

A.3.7, Information transfer

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.7, aligned to ISO/IEC 27002:2022 control 5.14, asks PII controllers and processors to put transfer rules, procedures and agreements in place for all types of transfer of information within the organisation and to external parties.

The PII-protection angle. A.3.7 is the security dimension of transfer; A.1.4.10 / A.2.4.4 (PII transmission controls) and A.1.5.x / A.2.5.x (cross-border basis and records) are the privacy dimensions. They must be operated together: an encrypted channel to a recipient with no lawful transfer basis is a privacy failure with excellent security, and a lawful transfer over an unprotected channel is the reverse. The scope includes the unglamorous channels where Indian breaches actually originate, email attachments, shared drives, messaging apps used for operational handoffs, and the physical media covered by A.3.20.

DPDP-first implementation. Anchor the transfer rules to section 8(5) and cross-reference section 16 (the cross-border negative-list regime) for any transfer leaving India. Where a sector overlay applies, the RBI payment-data localisation directive being the marquee case, the transfer rules must encode it, because the DPDP Act does not displace it.

A.3.8, Identity management

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.8, aligned to ISO/IEC 27002:2022 control 5.16, asks PII controllers and processors to manage the full life cycle of identities, creation, change and removal, for the people and systems that access information.

The PII-protection angle. A.3.8 is upstream of A.3.9: identity management establishes who someone is, access rights establish what they may reach. For a PIMS the load-bearing requirements are unique attributable identities (no shared service accounts touching PII, the single most common Indian audit finding in this area), timely deprovisioning on exit or role change, and identity records good enough to make the A.3.25 logs evidentially useful. A log that attributes a PII access to "admin" cannot support a breach investigation or a principal's access request.

DPDP-first implementation. Attributable identity is what converts logging into evidence under section 8(5), and it is what allows a Data Fiduciary to answer the Board's inevitable question after a breach: who touched this data, and when. Include non-human identities (service accounts, API keys, integration users) in the life cycle, they are frequently the identities with the broadest PII reach and the weakest ownership.

A.3.9, Access rights

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.9, aligned to ISO/IEC 27002:2022 control 5.18 (Access rights), with 5.15 (Access control) as the upstream policy control, asks PII controllers and processors to implement a formal access-control regime that provisions, modifies and withdraws access rights to information assets (including PII stores) on the basis of least-privilege and need-to-know, with periodic review and timely de-provisioning.

The PII-protection angle. The least-privilege principle is enforced for PII specifically, not all data equally. The access-recertification cadence reviews PII access at higher frequency than non-PII access (typically quarterly for high-risk PII stores; semi-annually for medium-risk; annually for low-risk). The privileged-access management covers the PII stores (the customer database; the consent ledger; the rights-request queue; the breach register; the grievance log). The joiner-mover-leaver workflow covers the privacy overlay: when an engineer moves to a non-PII-touching team, the PII access is withdrawn within the documented SLA (typically 24 to 72 hours); when a contractor's engagement ends, the access is withdrawn the same day. The access rights support the principal-rights dimension: the rights-request handlers have access to the principal's PII for the rights request, with the access scoped to the specific request and time-boxed.

DPDP-first implementation. Section 8(5) of the DPDP Act (the confidentiality dimension of the safeguards duty) is the load-bearing Indian anchor. The access-rights audit trail must be complete enough to evidence, in a section 8(6) breach scenario, which users had access to the affected PII stores at the time of the breach (the first question the DPBI will ask). The access rights for the consent ledger must support the principal-rights dimension under section 11 (access) and section 12 (correction and erasure), the rights-request handlers must have read access for the access right, write access for the correction right, and delete access for the erasure right, each scoped to the specific principal and the specific request. The access rights for the grievance log must support the section 13 right (grievance redressal). For SDFs, the access-rights discipline is part of the independent data audit under section 10.

A.3.10, Supplier agreements (security in supplier relationships)

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.10, aligned to ISO/IEC 27002:2022 control 5.20 (within the 5.19 to 5.22 supplier family), asks PII controllers and processors to put in place a supplier-management process that identifies PII-touching suppliers; risk-tiers them; enters into supplier agreements that include the security controls, the privacy clauses (the DPA) and the audit-and-incidence clauses; and monitors supplier performance against the agreement.

The PII-protection angle. This is the densest privacy overlay in the A.3 organisational family. The supplier agreement for a PII-touching supplier must include:

• The DPA clauses required by A.1.2.7 (controllers) and A.2.2.x (processors), the subject-matter and duration of the processing; the nature and purpose of the processing; the type of personal data and categories of principals; the obligations and rights of the controller. For processor-to-sub-processor, the equivalent clauses propagate under A.2.5.7 to A.2.5.9.
• The security controls, the technical and organisational measures the supplier will implement (the A.3 controls in the supplier's PIMS scope; the ISO/IEC 27002:2022 controls selected through the supplier's risk assessment).
• The cross-border dimension, where the supplier processes PII outside India, the DPDP section 16 negative-list screen; the GDPR Chapter V transfer tools where EU personal data is processed (the SCCs; the BCRs; the adequacy decision).
• The incident clauses, the supplier's obligation to notify the controller of a personal-data breach within the time limit that lets the controller meet the dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report). The supplier's notification clock must be shorter than the controller's, typically the supplier notifies the controller within 24 to 48 hours of awareness, to give the controller the runway to assess and notify within 72 hours.
• The audit-and-evidence clauses, the supplier's obligation to provide evidence (audit reports; certifications; SOC 2 reports; ISO/IEC 27001 / 27701 certificates); the controller's audit right (or the controller's reliance on the supplier's independent audit); the sub-processor chain disclosure obligation.
• The deletion-and-return clauses, the supplier's obligation to delete or return the PII at the end of the contract, with the certificate-of-destruction chain.
• The instruction-handling clause, the supplier's obligation to process only on the controller's documented instructions, including the infringing-instruction escalation under A.2.2.5 (where the controller's instruction infringes the law or the DPA, the supplier escalates rather than executes).

DPDP-first implementation. The DPDP Act makes the supplier discipline statutory, not merely contractual. Section 8(5) of the Act extends the safeguards duty to the supplier chain (the controller is responsible for the processor's safeguards failure on the controller's PII). Section 8(6) makes the breach-notification duty operate through the supplier chain (the controller must notify the DPBI and the affected principals regardless of whether the breach originated at the supplier). The supplier agreement must therefore include the Indian-specific clauses: the dual-clock notification commitment; the cross-border supplier dimension under section 16 (the negative-list screen); the Consent Manager integration (where applicable); the SDF overlay (where the controller is an SDF, the supplier's SDF DPIA obligation propagates). The RBI Digital Lending Guidelines require the LSP-supplier clauses; the SEBI CSCRF requires the ICT-supplier discipline; the IRDAI Guidelines require the ICT-outsourcing data-protection clauses.

A.3.11, Information security incident management planning and preparation

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.11, aligned to ISO/IEC 27002:2022 control 5.24, asks PII controllers and processors to plan and prepare for information security incidents before they happen, defining the incident-management process, the roles and responsibilities that run it, the classification and escalation criteria, the reporting channels, and the readiness testing that proves the arrangement works.

The PII-protection angle. A.3.11 is the preparation half of the incident pair; A.3.12 is the response half. The distinction matters at audit: an organisation can respond competently to one incident and still fail A.3.11 because nothing was planned, rehearsed or resourced in advance. In a PIMS scope the preparation must be explicitly personal-data-aware:

• The incident classification scheme must carry a personal-data-breach determination as a first-class category, not a sub-case of "security incident" discovered late.
• The escalation criteria must name the DPO as a mandatory notification path for any incident with a PII dimension, and must fire on suspicion rather than on confirmation.
• The roles must pre-assign who makes the personal-data-breach call, who drafts the Board intimation, who owns the principal-notification decision, and who is the CERT-In point of contact.
• The readiness testing must exercise the dual-clock scenario end-to-end (see toolkit doc 08), including out-of-hours activation, the discipline that A.3.12 then depends on.

DPDP-first implementation. The preparation must make the two-stage Rule 7 clock operable before an incident occurs: the initial intimation to the Data Protection Board without delay on becoming aware, and the detailed report within 72 hours. That means the Board's notification channel, the CERT-In six-hour channel and the sector-regulator channels are identified, credentialled and tested in advance; the intimation content is pre-staged as a template; and the "becoming aware" trigger is defined in writing so the clock start is not argued about mid-incident. For SDFs, the section 10 DPO is named in the plan as the accountable role. The plan and its test records are part of the PIMS evidence base under A.3.14.

A.3.12, Response to information security incidents

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.12, aligned to ISO/IEC 27002:2022 control 5.26 (response to information security incidents), with 5.25 (assessment and decision on information security events) immediately upstream and the planning-and-preparation side at A.3.11 / 27002 5.24, asks PII controllers and processors to put in place an incident-management capability that detects, assesses, responds to and recovers from information security incidents, with documented procedures, defined responsibilities and a continuous-improvement cycle.

The PII-protection angle. This is the highest-risk organisational control in the Indian context, because the dual-clock breach pattern operates here. The Indian Data Fiduciary must run, in parallel:

• The CERT-In six-hour clock (Directions 20(3)/2022-CERT-In, 28 April 2022): prescribed cyber incidents, including data breach, unauthorised access to systems, identity-theft-related incidents, ransomware, must be reported to CERT-In within six hours of noticing. The CERT-In report covers the ICT-incident angle.
• The DPDP breach clock (intimation without delay, then a seventy-two-hour report; DPDP Act 2023 section 8(6); DPDP Rules 2025 Rule 7): a personal-data breach must be intimated to the Data Protection Board without delay on becoming aware, with the detailed Rule 7 report within seventy-two hours. Affected principals must be notified without undue delay in plain language describing the breach, its likely consequences, and the mitigation steps.
• The sector-regulator clocks: RBI incident norms for banks and NBFCs (typically two to six hours); SEBI CSCRF for SEBI Regulated Entities (six hours to SEBI/CERT-In); IRDAI Information and Cyber Security Guidelines for insurers (twenty-four to seventy-two hours).

The dual-clock pattern is the load-bearing operational discipline. The incident response plan must include: an event-detection capability (the SOC, the monitoring, the supplier-breach-notification flow); an assessment step (is the event a personal-data breach? which principals are affected? which jurisdictions?); a decision step (which notifications fire, in which order, on which clocks); a notification step (the CERT-In report; the DPBI Rule 7 intimation report; the principal notifications; the sector-regulator reports); an evidence-collection step (27002 control 5.27, collecting evidence for the regulator, for the principal claims, for the post-incident review); a recovery step; and a post-incident review that feeds Clause 10.2 corrective action and Clause 10.1 continual improvement.

DPDP-first implementation. Section 8(6) of the DPDP Act is the load-bearing Indian anchor, with penalty up to two hundred crore rupees for failure to notify. The incident response plan must operationalise the Rule 7 intimation content (the prescribed breach-notification content). The plan must address the principal-notification dimension (without undue delay; plain language; consequences; mitigation), this is operationally harder than the regulator notification, because the principal audience is large and untrained. The plan must address the SDF overlay (the SDF DPIA under section 10 may need to be updated after a breach; the independent data audit may need to be brought forward). The plan must address the cross-border dimension (where the breach affects principals in multiple jurisdictions, the multi-jurisdiction notification regime).

A.3.13, Legal, statutory, regulatory and contractual requirements

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.13, aligned to ISO/IEC 27002:2022 control 5.31, asks PII controllers and processors to identify, document and keep current the legal, statutory, regulatory and contractual requirements relevant to information security and the processing of PII, and the organisation's approach to meeting them.

The PII-protection angle. This is the control that makes the whole Indian regulatory stack auditable in one place. It is the A.3 counterpart of Clause 4.2 (interested parties) and it feeds the SoA at Clause 6.1.3: the requirement register is the evidence that an exclusion was reasoned rather than overlooked. In a PIMS scope the register must carry the statutory duties (DPDP Act and Rules), the sector overlays (RBI, SEBI, IRDAI), the horizontal incident regime (CERT-In), the extraterritorial exposure (GDPR where the organisation processes EU/EEA personal data), and, the part most often missing, the contractual privacy commitments in customer DPAs, which frequently impose clocks tighter than the statute.

DPDP-first implementation. Maintain the register with an owner, a review cadence and a change-trigger (a new notification, a sector circular, a DPA amendment). The register is the natural home for the DPDP commencement tracking, since the Rules commence in phases, a live register is how an organisation demonstrates it is tracking which obligations are already in force.

A.3.14, Protection of records

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.14, aligned to ISO/IEC 27002:2022 control 5.33, asks PII controllers and processors to protect records (including the PIMS evidence base) against destruction, loss, falsification, tampering and unauthorised modification, whether accidental or intentional.

The PII-protection angle. The records-protection discipline extends to the PIMS evidence base, the ROPA (A.1.2.9), the consent records (A.1.2.5), the DPIA records (A.1.2.6), the breach records (under A.3.12), the audit records (clause 9.2), the management-review minutes (clause 9.3), the training records (A.3.17, in the people theme), the policy version history. The integrity of the consent records is the integrity of the controller's lawful-basis claim, if the consent records can be altered, the controller cannot prove consent was given. The integrity of the breach records is the integrity of the controller's notification trail, if the breach records can be altered, the controller cannot prove the notification was timely.

DPDP-first implementation. The records-protection discipline implements DPDP section 8(5) (the integrity dimension of the safeguards duty). For SDFs, the records-protection discipline supports the independent data audit under section 10, the auditor must be able to trust the records. The records-protection discipline supports the principal-rights dimension, the principal's access request (section 11) and correction request (section 12) depend on the integrity of the records the controller holds. The records-protection discipline supports the breach-notification dimension, the controller's notification trail under section 8(6) must be tamper-evident.

A.3.15, Independent review of information security

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.15, aligned to ISO/IEC 27002:2022 control 5.35, asks PII controllers and processors to have the organisation's approach to managing information security, and its implementation, reviewed independently at planned intervals and when significant changes occur.

The PII-protection angle. Independence is the point: the review must be run by someone who does not own the controls under review. In a PIMS this complements, but does not duplicate, the Clause 9.2 internal audit, 9.2 tests conformity of the management system, A.3.15 tests the security approach itself, including its PII-protection dimension. For most growing Indian companies the practical model is an annual independent technical review (penetration testing, configuration review, access-model review) alongside the management-system audit.

DPDP-first implementation. For a Significant Data Fiduciary, A.3.15 aligns closely with the section 10 obligation to have a periodic independent data audit conducted by an independent data auditor. Running the two as one programme, with a scope that explicitly covers the PII-protection controls, avoids duplicated cost and produces a single evidence set for both the certification auditor and the regulator.

A.3.16, Compliance with policies, rules and standards for information security

Requirement (paraphrased). ISO/IEC 27701:2025 control A.3.16, aligned to ISO/IEC 27002:2022 control 5.36, asks PII controllers and processors to regularly review whether information processing and procedures within their area of responsibility actually comply with the organisation's information security policy, its topic-specific policies, its rules and its standards, and to act on the deviations.

The PII-protection angle. A.3.16 is the control that closes the gap between a policy set that exists and a policy set that is followed. It is deliberately distinct from A.3.3 (which asks the organisation to have policies) and from A.3.15 (which is an independent review): A.3.16 is line-management conformance checking, run by the people accountable for the processes. The privacy dimension is where it earns its keep, the recurring Indian findings are a retention policy that exists while data ages past its schedule, an access-control policy that exists while quarterly recertification has not run, and a DPA clause set that exists while onboarding bypasses it. Each of those is an A.3.16 failure before it is anything else.

DPDP-first implementation. Define, for each privacy-relevant topic-specific policy, who checks compliance, how often, against what evidence, and how deviations are escalated and closed. Route the deviations into the Clause 10.2 nonconformity and corrective-action loop so the evidence trail is continuous. Under section 8(5) the Board's question is not whether safeguards were documented but whether they were operating, A.3.16 is how an organisation answers that with records rather than assertions.

The topic-specific policy set (issued under A.3.3, tested under A.3.16). The policy set in a PIMS scope must include the privacy-relevant topics below. Note the division of labour: A.3.3 requires them to exist and be maintained; A.3.16 requires them to be checked for actual compliance.

• Privacy policy (cross-link to clause 5.2), the controller's or processor's privacy commitments.
• Access-control policy (the A.3.9 overlay), the least-privilege principle, the recertification cadence, the privileged-access discipline, with the PII-specific dimensions.
• Supplier-management policy (the A.3.10 overlay), the supplier-risk-tiering methodology, the DPA clause set, the sub-processor chain discipline, with the PII-specific dimensions.
• Retention policy (the A.1.4.8 overlay), the retention schedule, the deletion automation, the 48-hour pre-erasure notice.
• Incident-management policy (the A.3.12 overlay), the dual-clock pattern, the principal-notification decision tree, the post-incident review.
• Records-management policy (the A.3.14 overlay), the PIMS evidence base, the integrity controls, the version history.
• Cryptography policy (the A.3.26 overlay, in the technological theme), the encryption standards, the key-management discipline.
• Logging policy (the A.3.25 overlay), the log categories, the 180-day CERT-In retention, the PII-in-logs minimisation.

DPDP-first implementation. Each topic-specific policy should invoke the DPDP provisions it implements (section 8(5) for the security topics; section 8(6) for the incident topic; section 8(7) for the retention topic; section 10 for the SDF overlay). Each topic-specific policy should reference the relevant sector-regulator instrument where applicable.

The integration, fourteen controls as one operating model

The fourteen organisational controls form a single operating model. The policy layer (A.3.3, A.3.16) sets the commitments and then tests that they are actually followed. The governance layer (A.3.4, A.3.13, A.3.15) assigns the people, tracks the legal and contractual obligations, and subjects the whole approach to independent review. The data layer (A.3.5, A.3.6, A.3.7) classifies, labels and governs the movement of information. The access layer (A.3.8, A.3.9) establishes identity and then bounds what each identity may reach. The operational layer (A.3.10, A.3.14) runs supplier relationships and records in steady state. The incident layer (A.3.11 preparation, A.3.12 response) prepares for the breach and then handles it when it lands. A controller or processor that holds the stack as one coherent architecture will pass an A.3 audit; a controller that holds each control as a disconnected compliance duty will pass the paperwork but fail the operational test.

The Singahi recommended pattern is to operate the fourteen controls through a single security-and-privacy operating model, a unified governance committee that oversees the policy layer; a unified identity-and-access programme that runs A.3.9; a unified supplier-management programme that runs A.3.10; a unified incident-response programme that runs A.3.11 preparation and A.3.12 response with the dual-clock pattern. The operating model is documented in the RACI (toolkit doc 13) and the roles and responsibilities (toolkit doc 16).

Tools, Technologies, and Solutions

The A.3 organisational controls are largely process-and-people controls, but several tool categories are load-bearing. This section sketches the landscape; the vendor-evaluation questionnaire and the build-vs-buy framework are in toolkit doc 14.

Identity and access management (IAM), A.3.9 backbone

IAM tools provision, manage and de-provision access rights. The categories relevant to the A.3.9 privacy overlay:

• Privileged access management (PAM), the stronger controls for privileged accounts (administrators, root, service accounts) that have access to the PII stores. The PAM tool should support session recording for the high-PII-risk sessions (e.g. an administrative query against the customer database) and the just-in-time access pattern (the engineer requests access for the specific task; the access is granted for a time-boxed window; the access is withdrawn when the window closes).
• Attribute-based access control (ABAC), the access policy model that bases access decisions on attributes (user, resource, action, environment) rather than roles alone. ABAC is the privacy-friendly model for high-risk PII stores, the access policy can encode the purpose-limitation (the rights-request handler has access to the principal's PII for the rights-request purpose; the access is denied for the marketing purpose).

Supplier-management and third-party risk platforms, A.3.10 backbone

Third-party risk management (TPRM) platforms automate the supplier-risk-assessment workflow, the supplier-security-questionnaire distribution, the supplier-evidence-ingestion (the SOC 2 reports; the ISO/IEC 27001 / 27701 certificates), the supplier-performance-monitoring and the supplier-breach-notification intake. The TPRM platform should support the PII-specific supplier tiering (PII-touching suppliers in the high-risk tier; the DPA clause set automated; the sub-processor chain visible).

Incident response and security information and event management (SIEM), A.3.12 backbone

SIEM platforms aggregate logs, detect anomalies and trigger alerts. For the A.3.12 dual-clock pattern, the SIEM should be configured to:

• Detect the personal-data-breach indicators (anomalous access to PII stores; anomalous export of PII; PII in unexpected log locations).
• Trigger the incident-response workflow with the dual-clock timers (the CERT-In six-hour clock starts at the awareness event; the DPDP breach clock (intimation without delay; seventy-two-hour report) starts at the awareness event; the sector-regulator clocks where applicable).
• Produce the evidence chain for the regulator (the timeline, the affected PII stores, the affected principals, the access trail, the notification trail).

The SIEM should be operated by a SOC (internal or MSSP) on a 24/7 basis for high-risk PIMS scopes.

Records and document management, A.3.14 backbone

Records-management platforms with cryptographic-integrity controls (hashing; version control; tamper-evidence) are the A.3.14 backbone for the PIMS evidence base. The platform should support the documented-information discipline under clause 7.5, the version history, the access controls for the PIMS evidence (only the DPO and the auditors should have write access to the breach records), and the retention schedule for the evidence (typically aligned with the limitation period plus the audit cycle).

Policy management and GRC platforms, A.3.3 / A.3.16 backbone

Governance, risk and compliance (GRC) platforms operationalise the policy management (A.3.3, A.3.16), the risk register (clause 6.1), the SoA, the audit programme (clause 9.2) and the management-review pack (clause 9.3). The GRC platform should support the privacy-specific modules (the ROPA; the DPIA register; the consent register; the breach register; the rights-request queue).

The make-vs-buy decision

The A.3 organisational controls can be operated through a mix of make (in-house processes and tools) and buy (commercial platforms). The decision framework in toolkit doc 14 weighs: (a) the size and complexity of the PIMS scope (a growing company with five processing activities may run A.3.9 with a spreadsheet-based recertification; a mid-sized (250 to 2,000) firm with fifty processing activities needs an IGA); (b) the maturity target (L1 to L2 may run with spreadsheets; L3 and above needs the platforms); (c) the integration overhead (the platforms should integrate with the existing ISMS tooling, the HR system for the joiner-mover-leaver automation, the procurement system for the supplier-management automation); (d) the Indian-market context (the platforms should support the Indian regulatory specifics, the CERT-In formats; the DPDP Rule 7 intimation; the sector-regulator reporting formats).

Policy and Procedure Templates

The toolkit (this guide's companion artefact set) contains the full templates. The summaries below preview the load-bearing content.

The Information Security Policy with the privacy overlay (toolkit doc 01)

The Information Security Policy in a PIMS scope is the overarching policy that authorises the A.3 organisational controls and integrates with the Privacy Policy under clause 5.2. Singahi-authored sample "shall" clauses (drafting samples for the controller to adopt and own):

• The controller shall implement and maintain an Information Security Policy that defines the organisation's commitments to protect the confidentiality, integrity and availability of its information assets, including personally identifiable information.
• The Information Security Policy shall name personally identifiable information as a protected-asset category and shall cross-reference the Privacy Policy.
• The Information Security Policy shall address the principal-rights dimension (treating rights requests as security-relevant events).
• The Information Security Policy shall commit to the dual-clock breach-notification pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report; sector-regulator clocks).
• The Information Security Policy shall be reviewed at least annually and on material change to the PIMS scope.

The Access-Rights Privacy Overlay Procedure (toolkit doc 02)

The procedure covers: the PII store inventory (the customer database, the consent ledger, the rights-request queue, the breach register, the grievance log); the PII-specific least-privilege analysis (per role, per PII store); the joiner-mover-leaver workflow for PII access; the access-recertification cadence (quarterly for high-risk PII; semi-annually for medium-risk; annually for low-risk); the privileged-access management for PII stores; the rights-request-handler access pattern (scoped to the specific principal and time-boxed).

The Supplier-Agreement PII Schedule (toolkit doc 10)

The schedule is the standardised PII clause set attached to every PII-touching supplier contract. It includes the DPA clauses required by A.1.2.7 / A.2.2.x; the security controls; the cross-border dimension; the incident clauses (the supplier notifies the controller within 24 to 48 hours of awareness); the audit-and-evidence clauses; the deletion-and-return clauses; the instruction-handling clause (the A.2.2.5 escalation).

The Dual-Clock Incident Response Playbook (toolkit doc 08)

The playbook covers the event-detection capability, the assessment step, the decision step (which notifications fire, in which order, on which clocks), the notification step (the CERT-In report; the DPBI Rule 7 intimation report; the principal notifications; the sector-regulator reports), the evidence-collection step, the recovery step and the post-incident review. The playbook includes the tabletop scenarios and the drill programme.

The Records-Protection Procedure (toolkit doc 02 Part C)

The procedure covers the PIMS evidence base inventory (the ROPA, the consent records, the DPIA records, the breach records, the audit records, the management-review minutes); the integrity controls (hashing; version control; tamper-evidence); the access controls (only the DPO and the auditors have write access to the breach records); the retention schedule for the evidence; the cryptographic-erasure discipline at end of retention.

The Topic-Specific Policy Set (toolkit doc 01 Parts B to I)

The topic-specific policies: privacy (cross-link to clause 5.2); access control; supplier management; retention; incident management; records management; cryptography; logging. Each policy with the PII overlay and the DPDP anchor.

Risk Assessment and Treatment

The A.3 organisational controls are selected through the privacy risk assessment under clause 6.1, applied to the PIMS scope. The risk assessment identifies the threats to the PII in scope, the vulnerabilities in the controls, the likelihood and impact of the materialised risks, and the treatment plan (apply / accept / avoid / transfer). The toolkit risk-assessment template (doc 09) operationalises the assessment.

The A.3 organisational-family risk register

The risk register for the A.3 organisational family typically includes the following risks:

The treatment priorities

The treatment priorities for the A.3 organisational family, in rough descending order of risk:

1. A.3.12 incident response, the highest-priority treatment because the dual-clock pattern operates here and the penalty exposure is up to two hundred crore rupees for notification failure plus two hundred and fifty crore rupees for safeguards failure.
2. A.3.9 access rights, the next-highest because access is the most-frequent breach vector for PII (insider misuse; compromised accounts).
3. A.3.10 supplier agreements, the next-highest because the supplier chain is the most-frequent breach vector for cross-border PII exposure.
4. A.3.11 incident-management planning and preparation, high-priority because readiness is what makes the dual-clock achievable, and it prevents the privacy-by-design failures that are expensive to retrofit.
5. A.3.14 records protection, high-priority because the PIMS evidence base underpins every certification and regulatory engagement.
6. A.3.4 roles and responsibilities, medium-priority but foundational; the RACI underpins every other control.
7. A.3.3 information security policy, medium-priority; the policy authorises the operational discipline.
8. A.3.16 policy-compliance monitoring, medium-priority; the compliance checks turn the policy set into evidence and add the granularity.

The risk-based selection

The A.3 controls in this guide are typically all applicable to a PIMS scope that processes more than a minimal volume of PII. The SoA documents the selection. The exclusions (if any) are justified on the basis of the risk assessment, e.g. a controller with no PII-touching suppliers may justify excluding A.3.10 (rare in practice; most controllers have at least one PII-touching supplier).

Audit and Compliance Checklist

The Singahi A.3 organisational-family checklist (toolkit doc 04) covers 28 audit questions across the fourteen controls. The questions below are the recommended minimum examination set.

A.3.3, Policies for information security

1. Does the Information Security Policy exist, is it board-endorsed, and is it current (reviewed within the last 12 months or on material change)? Expected: the signed-off policy with the version history and the review record. Red flag: missing policy, stale policy, or unsigned policy.
2. Does the Information Security Policy name PII as a protected-asset category and cross-reference the Privacy Policy? Expected: explicit reference to PII and to the Privacy Policy under clause 5.2. Red flag: generic policy with no PII overlay.
3. Does the Information Security Policy commit to the dual-clock breach-notification pattern? Expected: explicit reference to CERT-In six hours, DPDP without delay (seventy-two-hour detailed report), sector-regulator clocks. Red flag: incident dimension silent on the DPDP clock.
4. Has the policy been communicated to all employees, contractors and relevant third parties? Expected: the communication record (training records; acknowledgement logs). Red flag: no communication evidence.

A.3.4, Roles and responsibilities

5. Is the security RACI documented and current? Expected: the RACI matrix mapping each A.3 control to the responsible security role and the consulted privacy role. Red flag: missing RACI or stale RACI.
6. Does the security RACI integrate with the privacy roles under clause 5.3 (the DPO, the privacy lead, the grievance officer)? Expected: explicit cross-references between the security roles and the privacy roles; the joiner-mover-leaver workflow covers the integration. Red flag: parallel RACIs with no integration.
7. For SDFs, is the DPO based in India and accountable to the Board of Directors (DPDP section 10)? Expected: the DPO appointment letter with the India location; the accountability clause. Red flag: DPO not based in India; accountability not documented.
8. Is the segregation-of-duties analysis documented for the high-PII-risk functions? Expected: the analysis identifying the functions where segregation is required (the engineer who deploys a change to the customer database is not the same as the engineer who approves the change; the rights-request handler is not the same as the engineer who executes the deletion). Red flag: no segregation analysis; same person performs both roles.

A.3.9, Access rights

9. Is the PII store inventory documented and current? Expected: the inventory listing every PII store (the customer database, the consent ledger, the rights-request queue, the breach register, the grievance log) with the data categories, the volume, the owner, the access pattern. Red flag: missing inventory or stale inventory.
10. Is the PII-specific least-privilege analysis documented per role per PII store? Expected: the analysis showing the access rights per role per PII store with the least-privilege rationale. Red flag: no least-privilege analysis; everyone with database access can read every principal's PII.
11. Is the access-recertification cadence documented and operated (quarterly for high-risk PII; semi-annually for medium-risk; annually for low-risk)? Expected: the cadence; the recertification records for the last cycle. Red flag: no cadence; no recertification records.
12. Is the joiner-mover-leaver workflow for PII access documented and operated? Expected: the workflow with the SLAs (the PII access is provisioned within the documented window when an engineer joins a PII-touching team; the PII access is withdrawn within 24 to 72 hours when the engineer moves to a non-PII-touching team; the access is withdrawn the same day when a contractor's engagement ends). Red flag: no workflow; stale access discovered at audit.
13. Is the privileged-access management covering the PII stores? Expected: the PAM discipline (session recording for high-PII-risk sessions; just-in-time access). Red flag: privileged access without stronger controls.

A.3.10, Supplier agreements

14. Is the supplier inventory documented and current, with the PII-touching suppliers identified? Expected: the inventory with the PII-touching flag. Red flag: missing inventory or PII-touching flag not set.
15. Does every PII-touching supplier have a current DPA that includes the A.1.2.7 / A.2.2.x clauses? Expected: the DPA per supplier with the clauses; the renewal dates. Red flag: generic NDA without the DPA clauses; expired DPAs.
16. Does the supplier DPA include the incident clauses (the supplier notifies the controller within 24 to 48 hours of awareness)? Expected: the incident clauses with the time limit. Red flag: no incident clauses; or the supplier's time limit is longer than the controller's notification clock.
17. Does the supplier DPA include the cross-border dimension (the DPDP section 16 negative-list screen; the GDPR Chapter V transfer tools)? Expected: the cross-border clauses where the supplier processes PII outside India. Red flag: no cross-border clauses for cross-border suppliers.
18. Is the sub-processor chain disclosed and propagated (A.2.5.7 to A.2.5.9)? Expected: the sub-processor list per supplier; the DPA clauses propagated to the sub-processor level. Red flag: opaque sub-processor chain.
19. Is the supplier-performance monitoring operated on cadence? Expected: the monitoring records (the supplier's SOC 2 reports or ISO/IEC certifications; the supplier's incident reports; the supplier's breach notifications). Red flag: no monitoring; or the monitoring is generic without the PII dimension.

A.3.11, Information security incident management planning and preparation

20. Is the project-management gate documented and operated for every new processing activity? Expected: the gate template; the gate records for the recent launches. Red flag: no gate; or the gate is not enforced for every launch.
21. Does the gate trigger the privacy impact assessment (A.1.2.6) and the SDF DPIA (DPDP section 10) where required? Expected: the trigger logic; the DPIA records for the high-risk launches. Red flag: no privacy trigger; or the trigger is not enforced.

A.3.12, Incident response

22. Is the incident response plan documented, current, and operable? Expected: the plan with the version history; the review record. Red flag: missing plan, stale plan, or unoperable plan.
23. Does the incident response plan address the dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report; sector-regulator clocks)? Expected: the dual-clock timers in the plan; the CERT-In format; the DPDP the Rule 7 intimation content. Red flag: incident plan silent on the DPDP clock.
24. Is the incident-response drill programme run on cadence (annually for growing companies; semi-annually for mid-sized (250 to 2,000) and enterprise; semi-annually plus tabletops between for SDFs)? Expected: the drill records; the tabletop records. Red flag: no drill programme; or the drill exists but does not trace the dual-clock pattern.
25. Is the incident-response evidence chain complete (the timeline, the affected PII stores, the affected principals, the access trail, the notification trail)? Expected: the evidence-chain template; the evidence from a recent incident or tabletop. Red flag: no evidence chain; or the chain is incomplete.

A.3.14, Records protection

26. Is the PIMS evidence base inventory documented and current (the ROPA, the consent records, the DPIA records, the breach records, the audit records, the management-review minutes)? Expected: the inventory with the integrity controls per record category. Red flag: missing inventory.
27. Are the integrity controls in place (hashing; version control; tamper-evidence; access controls)? Expected: the controls per record category; the access logs. Red flag: PIMS records in writable shared drives with no integrity log.

A.3.16, Compliance with policies, rules and standards for information security

28. Is the topic-specific policy set complete (privacy, access, supplier, retention, incident, records, cryptography, logging) and current? Expected: the policy set with the review dates. Red flag: missing topic-specific policies; or generic 27001 boilerplate with no PII overlay.

Metrics and KPIs

The Singahi A.3 organisational-family KPI set (toolkit doc 11) covers policy, roles, access, supplier, project, incident, records and topic-specific dimensions. The twelve KPIs below are the recommended minimum.

Policy and roles KPIs

1. Information Security Policy currency, the days since the last review. Target: less than 365 days. Frequency: monthly. Owner: CISO.
2. RACI currency, the days since the last RACI update. Target: less than 180 days. Frequency: monthly. Owner: CISO.
3. Security-and-privacy governance committee meeting cadence, the count of meetings in the period against the planned cadence. Target: 100%. Frequency: quarterly. Owner: CISO / DPO.

Access-rights KPIs

4. High-risk-PII-store access recertification attainment, the percentage of high-risk PII stores recertified in the quarter. Target: 100%. Formula: (high-risk PII stores recertified / high-risk PII stores due) × 100. Frequency: quarterly. Owner: IT Lead.
5. Stale-access-account count, the count of accounts with PII access where the account has been inactive for more than 90 days. Target: zero. Frequency: monthly. Owner: IT Lead.
6. Joiner-mover-leaver SLA attainment, the percentage of JML events completed within the documented SLA. Target: 100%. Formula: (JML events within SLA / total JML events) × 100. Frequency: monthly. Owner: IT Lead.

Supplier-management KPIs

7. Supplier DPA currency, the percentage of PII-touching suppliers with a current DPA. Target: 100%. Formula: (suppliers with current DPA / PII-touching suppliers) × 100. Frequency: quarterly. Owner: Procurement Lead.
8. Supplier incident-notification SLA attainment, the percentage of supplier breach notifications received within the contracted time limit. Target: 100%. Frequency: per incident. Owner: CISO.

Incident-response KPIs

9. Dual-clock notification attainment, the percentage of personal-data breaches in the period notified to CERT-In within six hours and to the DPBI without delay, with a detailed report within seventy-two hours. Target: 100%. Frequency: per incident. Owner: CISO.
10. Incident-response drill attainment, the count of drills in the period against the planned cadence. Target: 100%. Frequency: annually or semi-annually. Owner: CISO.
11. Incident-detection-to-awareness latency, the median time from incident occurrence to awareness. Target: less than 24 hours; trending down. Frequency: per incident. Owner: SOC Lead.

Records-protection KPI

12. PIMS-evidence integrity-control coverage, the percentage of PIMS evidence categories with documented integrity controls in place. Target: 100%. Frequency: quarterly. Owner: DPO.

Common Pitfalls and Audit Failures

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

The generic ISMS policy with no PII overlay

The Information Security Policy is borrowed from a 27001 template with no PII overlay, the policy does not mention PII, does not cross-reference the Privacy Policy, does not address the principal-rights dimension. Fails A.3.3 read with the PIMS scope. Remediation: rewrite the policy with the PII overlay (toolkit doc 01).

The parallel RACIs with no security-and-privacy integration

The security RACI and the privacy RACI are documented in parallel with no integration, the security roles do not reference the DPO; the privacy roles do not reference the CISO; the joiner-mover-leaver workflow covers one but not the other. Fails A.3.4. Remediation: integrated RACI (toolkit doc 13).

The "everyone with database access can read every principal's PII" gap

The access-rights discipline does not enforce least-privilege for PII specifically, every engineer with database access can query any principal's PII; the recertification cadence is uniform (typically annual) regardless of risk; the privileged-access management does not cover the PII stores. Fails A.3.9 read with DPDP section 8(5). Remediation: PII-specific least-privilege analysis; risk-based recertification cadence; PAM for PII stores.

The "NDA instead of DPA" failure

The PII-touching supplier has a generic NDA but no DPA, none of the A.1.2.7 / A.2.2.x clauses; no incident clauses; no cross-border clauses; no sub-processor chain. Fails A.3.10 read with A.1.2.7. Remediation: the Supplier-Agreement PII Schedule (toolkit doc 10).

The "supplier breach clock longer than the controller's clock" gap

The supplier DPA includes an incident clause but the supplier's notification time limit (e.g. 72 hours) is longer than the controller's notification clock (DPDP without delay plus a 72-hour detailed report), the controller cannot meet the dual-clock pattern because the supplier's notification lands after the controller's clock has expired. Fails A.3.10 read with A.3.12. Remediation: shorten the supplier notification SLA to 24 to 48 hours.

The project-management gate not enforced

New processing activities launch through the engineering release pipeline without the project-management gate firing. The DPIA trigger (A.1.2.6) and the feed into the SDF DPIA (DPDP section 10 for SDFs) are not enforced. Fails A.3.11 read with A.1.2.6. Remediation: implement and enforce the gate (toolkit doc 02 Part B).

The incident-response plan that addresses only the ICT incident

The incident response plan addresses the ICT incident (the detection, the containment, the recovery) but is silent on the DPDP section 8(6) clock, the CERT-In six-hour clock, the principal-notification dimension and the sector-regulator clocks. Fails A.3.12 read with DPDP section 8(6). Remediation: the dual-clock playbook (toolkit doc 08).

The drill never run

The incident response plan exists but the drill programme has never been run; the team does not know the dual-clock pattern; the CERT-In and DPBI credentials have not been tested; the Rule 7 intimation content is not pre-staged. Fails A.3.12 operational dimension. Remediation: the drill programme (annual for growing companies; semi-annual for mid-sized (250 to 2,000) and enterprise).

The PIMS records in writable shared drives

The PIMS evidence base, the ROPA, the consent records, the breach records, the audit records, sits in writable shared drives with no integrity controls. Anyone with access can alter the records. Fails A.3.14. Remediation: records-management platform with cryptographic-integrity controls; access controls per record category.

The topic-specific policies missing or stale

The topic-specific policy set is incomplete (no supplier-management policy; no incident-management policy) or stale (last reviewed three years ago) or generic (27001 boilerplate with no PII overlay). Fails A.3.16. Remediation: complete and refresh the topic-specific policy set (toolkit doc 01 Parts B to I).

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

The controller bought a SIEM and assumed compliance follows. The SIEM was not configured to detect the personal-data-breach indicators; the dual-clock timers are not configured; the evidence chain is not produced. Fails A.3.12 operational dimension. Remediation: configure the SIEM for the privacy dimension; document the playbooks.

The segregation-of-duties gap

The engineer who deploys a change to the customer database is the same as the engineer who approves the change; the rights-request handler is the same as the engineer who executes the deletion. Fails A.3.4 segregation dimension. Remediation: enforce segregation for the high-PII-risk functions.

The sub-processor chain opaque

The supplier's DPA discloses the immediate sub-processors but the chain below is opaque, the sub-processors' sub-processors are not disclosed; the DPA clauses do not propagate. Fails A.3.10 read with A.2.5.7 to A.2.5.9. Remediation: full sub-processor chain disclosure with the DPA clauses propagated.

The cross-border supplier without the negative-list screen

A new cross-border supplier is onboarded without the DPDP section 16 negative-list screen; the destination turns out to be on a future notified negative list. Fails A.3.10 read with DPDP section 16. Remediation: cross-border supplier dimension in the onboarding gateway.

The "policy-on-the-wall" maturity

The A.3 organisational family operates at the policy-on-the-wall maturity (Section 22, L1), the policies exist but are not operational; the roles are documented but not integrated; the access rights are not recertified; the supplier DPAs are not refreshed; the project-management gate is not enforced; the incident response is not drilled; the records are not integrity-protected. Fails the operational dimension of every control. Remediation: advance to L2 and L3 (the maturity model in Section 22).

Illustrative Scenario 1: Failure, Northarc Lending and the Six-Hour Miss (Illustrative)

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

Disclaimer: This is an illustrative scenario developed for educational purposes. The company name is fictional; the patterns are drawn from the publicly documented incident-response-failure patterns of multiple Indian digital-lending and consumer-fintech platforms. No specific real company is described.

The company is RBI-regulated (as an NBFC), and operates through Lending Service Providers for customer acquisition and a payment-processor partner for disbursements and collections. The platform processes principal data across the marketing, origination, underwriting, disbursement, repayment, collections and regulatory-reporting categories.

The A.3 architecture at the incident. At the time of the incident in late 2027, Northarc's A.3 organisational architecture was typical of an Indian growing company that had invested in the ICT security stack but had not built the PII-aware overlay:

• The Information Security Policy was a generic 27001-template policy with no PII overlay and no reference to the Privacy Policy. The topic-specific policy set was incomplete, the supplier-management policy and the incident-management policy were missing.
• The security RACI was documented but ran in parallel to the privacy RACI with no integration. The DPO (a part-time external consultant) was not consulted on security incidents; the CISO was not consulted on privacy complaints.
• The access-rights discipline was uniform, annual recertification regardless of risk; every underwriter could query any borrower's PII; the privileged-access management did not cover the customer database.
• The supplier DPAs were inconsistent, the payment-processor DPA included the incident clauses but the LSP DPAs had only a generic NDA. The sub-processor chain for the payment-processor was opaque below the first tier.
• The project-management gate existed on paper but was not enforced, a new WhatsApp-based collections-nudge feature had launched six weeks earlier without the gate firing, introducing a new PII flow to a new supplier (a messaging API provider) without a DPIA.
• The incident response plan was a 27001-template ICT-incident plan. It addressed the detection, containment and recovery of ICT incidents. It did not address the DPDP section 8(6) clock; it did not address the CERT-In six-hour clock; it did not address the principal-notification dimension; it did not address the RBI incident-norms clock (the two-to-six-hour NBFC clock). The plan had never been drilled.
• The PIMS evidence base (the ROPA, the consent records, the DPIA records) was in a writable shared drive with no integrity controls.

The trigger. On a Saturday in October 2027, the payment-processor notified Northarc (by email to the operations team, with no escalation path) that an upstream sub-processor had suffered an unauthorised-access incident affecting approximately 380,000 borrower records, including name, PAN, loan-account number, outstanding balance and repayment history. The notification landed at 11:42 AM Saturday. The operations team read the email at 9:15 AM Monday (the email was not flagged urgent; the operations team did not work weekends). The CISO was informed at 10:30 AM Monday. The DPO was informed at 2:00 PM Monday (after the CISO remembered to forward).

The six-hour miss. The CERT-In six-hour clock had started at 11:42 AM Saturday (the awareness event, when a responsible person at Northarc became aware, or in CERT-In's view, when a responsible person should have become aware). The notification to CERT-In was filed at 4:15 PM Monday, approximately 53 hours late. The RBI incident-norms clock (two to six hours for an NBFC) had also started at 11:42 AM Saturday and was filed in the same Monday window, approximately 53 hours late.

The seventy-two-hour miss. The DPDP breach clock (intimation without delay; seventy-two-hour report) had also started at 11:42 AM Saturday (the awareness event under section 8(6)). The notification to the Data Protection Board in the Rule 7 intimation content was filed at 6:30 PM Monday, approximately 55 hours late. The principal notifications (without undue delay; plain language; consequences; mitigation) were sent in batches over the following three weeks, substantially beyond the without-undue-delay standard.

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

• Major nonconformity, A.3.3 (generic policy with no PII overlay). The Information Security Policy did not address the PII dimension or the dual-clock pattern. Fails A.3.3 read with the PIMS scope.
• Major nonconformity, A.3.4 (parallel RACIs). The security and privacy RACIs ran in parallel; the DPO was not in the incident-response notification chain; the CISO was not in the rights-request escalation. Fails A.3.4 read with clause 5.3.
• Major nonconformity, A.3.10 (supplier DPA inadequate; supplier-notification SLA not met). The LSP DPAs had no incident clauses. The payment-processor DPA's incident clause required the supplier to notify Northarc "as soon as reasonably practicable", a non-specific time limit that gave Northarc no contractual lever. The supplier's actual notification landed approximately 36 hours after the supplier's awareness. The sub-processor chain was opaque below the first tier. Fails A.3.10 read with A.1.2.7.
• Major nonconformity, A.3.11 (project-management gate not enforced). The WhatsApp-collections-nudge feature had launched without the gate firing; the new PII flow to the messaging API supplier was not in the ROPA; no DPIA was run. Fails A.3.11 read with A.1.2.6.
• Major nonconformity, A.3.12 (incident response plan inadequate; drill never run). The plan did not address the DPDP, CERT-In or RBI clocks. The team's awareness-to-action latency (operations-to-CISO-to-DPO) was approximately 26 hours; the awareness-to-CERT-In latency was approximately 53 hours; the awareness-to-DPBI latency was approximately 55 hours. The drill had never been run. Fails A.3.12 read with DPDP section 8(6) and the CERT-In Directions.
• Major nonconformity, A.3.14 (records in writable shared drives). The PIMS evidence base had no integrity controls; the consent records were theoretically alterable. Fails A.3.14.
• Major nonconformity, A.3.3 (topic-specific policies missing) with A.3.16 (compliance not checked). The supplier-management and incident-management topic-specific policies were missing. Fails A.3.3, and A.3.16 because no compliance check surfaced the gap.

The regulatory outcome. The late CERT-In report also exposed the company to prosecution under section 70B(7) of the IT Act. The DPBI, on the principal complaints that followed the delayed principal notifications, opened an investigation in January 2028 and found Northarc in breach of DPDP section 8(5) (the supplier-chain safeguards failure; the project-management-gate failure; the records-integrity failure) and section 8(6) (intimation without delay and a seventy-two-hour report missed by approximately 55 hours). The RBI opened a parallel supervisory action under the digital-lending guidelines and the NBFC incident norms. The aggregate penalty exposure (DPDP section 8(5) up to two hundred and fifty crore rupees; section 8(6) up to two hundred crore rupees; CERT-In penalties; RBI supervisory action) was estimated by Northarc's legal counsel at approximately INR 60 to 180 crore. The reputational impact, covered in the business press, was substantial; the borrower base declined approximately 7 percent over the following quarter.

The lessons.

• The six-hour CERT-In clock is unforgiving. The operations-to-CISO-to-DPO latency of approximately 26 hours is the canonical A.3.12 failure pattern. The notification chain must run on the awareness event, not on the next business day.
• The supplier-notification SLA must be shorter than the controller's clock. A supplier "as soon as reasonably practicable" notification is not a contractual lever; the supplier DPA must specify 24 to 48 hours.
• The dual-clock pattern must be drilled. An unoperated incident response plan fails on the first real incident. The drill exposes the gap before the regulator does.
• The PII overlay is what makes the controls PIMS-relevant. A generic 27001 ISMS would not have surfaced these findings; the PII overlay (the dual-clock pattern; the supplier-chain dimension; the project-management gate; the records integrity) is what makes the A.3 family operate as a PIMS backstop.
• 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, Coralwave SaaS Builds the PII-Aware Security Backstop (Illustrative)

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

The setting. Coralwave Software Private Limited operates a B2B SaaS platform for HR-and-payroll processing, with approximately 4,800 enterprise customers across India and Southeast Asia and approximately 1.4 million employee-records under processing. Coralwave acts as a PII processor for its customers' employee data (the A.2 track) and as a controller for its own customer-contact and employee data (the A.1 track). The company sought ISO/IEC 27701:2025 certification ahead of a planned enterprise-customer expansion into EU markets, where the customers were increasingly asking for 27701 attestation as a procurement requirement.

The pre-remediation state. In early 2025, ahead of the ISO/IEC 27701:2025 publication and the DPDP Rules notification, Coralwave's A.3 organisational architecture was at a typical L2 maturity, a documented Information Security Policy (with a partial PII overlay), a documented RACI (with partial integration between security and privacy), an annual access-recertification discipline (uniform regardless of risk), supplier DPAs (mostly current but with inconsistent incident clauses), a project-management gate (inconsistent enforcement), an incident response plan (with the CERT-In clock but not the DPDP clock), and a shared-drive-based PIMS evidence base.

The trigger. Coralwave's board, on the recommendation of the CISO and the DPO, decided in mid-2025 to seek ISO/IEC 27701:2025 certification by Q2 2027, ahead of the DPDP Rules' full-enforceability window. The decision was driven by three considerations: (i) the EU expansion required the 27701 attestation as a procurement precondition; (ii) Coralwave was likely to be designated an SDF under the DPDP section 10 thresholds (approximately 1.4 million employee records); (iii) a recent near-miss incident (a misconfigured supplier-API endpoint exposing 8,200 records, detected and contained in 14 hours) had surfaced the A.3.12 gap.

The remediation programme (August 2025 to March 2027). The CISO and the DPO structured the programme in four quarters.

Quarter 1, Policy and roles integration. The team rewrote the Information Security Policy with the PII overlay (the policy names PII as a protected-asset category; cross-references the Privacy Policy; commits to the dual-clock pattern; addresses the principal-rights dimension). The team built the topic-specific policy set (privacy; access control; supplier management; retention; incident management; records management; cryptography; logging). The team built the integrated security-and-privacy RACI (the DPO is in the incident-response notification chain; the CISO is in the rights-request escalation chain; the joiner-mover-leaver workflow covers both dimensions). The team stood up the unified security-and-privacy governance committee (monthly meetings; the CISO and the DPO co-chair; the CIO, the Legal Lead, the Operations Lead, the Procurement Lead, the HR Lead and the Internal Audit Lead are members).

Quarter 2, Access-rights and supplier-agreement refresh. The team rolled out the PII store inventory (the customer-employee database; the payroll database; the consent ledger; the rights-request queue; the breach register; the grievance log; twelve distinct PII stores). The team ran the PII-specific least-privilege analysis per role per PII store; the analysis surfaced approximately 340 over-privileged accounts that were narrowed. The team rolled out the risk-based recertification cadence (quarterly for the high-risk PII stores, the customer-employee database and the payroll database; semi-annually for the medium-risk; annually for the low-risk). The team extended the privileged-access management to cover the high-risk PII stores with session recording. The team refreshed the supplier DPAs using the standardised Supplier-Agreement PII Schedule (toolkit doc 10), every PII-touching supplier (87 suppliers) received the new DPA clauses; the supplier-notification SLA was set at 24 hours; the sub-processor chain was disclosed and the DPA clauses propagated to the sub-processor level; the cross-border suppliers (approximately 22, across India, EU and the US) were screened against the DPDP section 16 negative list and equipped with the GDPR Chapter V transfer tools (the SCCs for the EU customers' data).

Quarter 3, Project-management gate and incident response. The team implemented the project-management gate (toolkit doc 02 Part B) with the privacy-and-security triggers, every new processing activity or material change passes the gate; the gate triggers the DPIA (A.1.2.6) and the SDF DPIA (DPDP section 10) where required. The team rewrote the incident response plan with the dual-clock pattern (the CERT-In six-hour timer; the DPDP timer (intimation without delay; seventy-two-hour report); the SEBI clock where applicable; the principal-notification decision tree). The team ran the first incident-response drill, a tabletop exercise in week 8 of the quarter; a full drill in week 12. The drill exposed two gaps, the CERT-In portal credentials had not been tested (and were stale); the DPBI the Rule 7 intimation content was not pre-staged. The gaps were closed before the live incident.

Quarter 4, Records protection and certification. The team migrated the PIMS evidence base (the ROPA, the consent records, the DPIA records, the breach records, the audit records, the management-review minutes) to a records-management platform with cryptographic-integrity controls (hashing; version control; tamper-evidence; access controls per record category, only the DPO and the auditors have write access to the breach records). The team ran the internal audit (clause 9.2) covering the fourteen organisational controls. The team ran the management review (clause 9.3) with the twelve KPIs (Section 12). The team went to the certification audit in March 2027. The Stage 1 audit passed without major nonconformities on the A.3 organisational family. The Stage 2 audit, conducted in May 2027, traced three sample incidents (a misconfigured supplier-API endpoint; a phishing-led account compromise; a lost laptop with cached PII) through the dual-clock pattern; verified the access-rights recertification for the affected PII stores; verified the supplier-agreement PII schedule for every processor in the chain; verified the integrity evidence for the consent ledger. Zero major nonconformities on the A.3 organisational family.

The return.

• Avoided penalty exposure. The pre-remediation pattern carried estimated DPDP penalty exposure of approximately INR 60 to 160 crore (supplier-chain safeguards failure on 87 suppliers; inconsistent incident clauses; project-management gate not enforced; records-integrity failure on the consent ledger). The remediation reduced the exposure by an estimated 90 percent.
• The near-miss dividend. Six months after the certification, a misconfigured bucket exposed approximately 22,000 employee records. The incident was detected by the SIEM within 90 minutes (the pre-remediation detection-to-awareness latency was approximately 14 hours for a similar incident); the dual-clock pattern fired cleanly (CERT-In within six hours; DPBI without delay, with a detailed report within seventy-two hours; principal notifications within seven days); the supplier-API endpoint was contained within 4 hours. The certification held; no penalty was imposed.
• Operational efficiency. The unified security-and-privacy RACI removed approximately 180 person-hours per quarter of duplicated governance effort. The IGA rollout removed approximately 240 person-hours per quarter of manual access administration. The supplier-DPA refresh standardised the clause library, removing approximately 120 person-hours per quarter of bespoke legal review.
• SDF readiness. When Coralwave was designated an SDF under the DPDP section 10 thresholds in late 2027, the A.3 organisational architecture was already SDF-ready, the DPO was in place; the SDF DPIA was integrated into the project-management gate; the independent-data-audit evidence base was the integrity-protected records platform.

The lessons.

• Treat the A.3 organisational family as the security backstop that makes every privacy commitment defensible. The fourteen controls form a single operating model.
• The dual-clock pattern is the load-bearing operational discipline. The CERT-In six-hour clock, the DPDP breach clock (intimation without delay; seventy-two-hour report) and the sector-regulator clocks run in parallel; the principal-notification dimension is operationally harder than the regulator notification.
• The drill makes the incident survivable. The first drill exposed the stale CERT-In credentials and the unstaged the Rule 7 intimation content; the gaps were closed before the live incident.
• The investment delivers enterprise-customer wins and avoided penalty exposure an order of magnitude greater than the build cost.

Multi-Framework Mapping

The detailed crosswalk

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

The DPDP Act section-by-section A.3 hooks:

• Section 4 grounds; section 7 legitimate uses, drives the privacy backdrop for A.3.3 (the policy commits to processing only on a lawful basis).
• Section 8(5) reasonable security safeguards, the load-bearing Indian anchor for the entire A.3 family (covers A.3.9 confidentiality; A.3.10 supplier chain; A.3.11 security-by-design; A.3.14 integrity and availability). Penalty up to INR 250 crore.
• Section 8(6) breach notification, the load-bearing Indian anchor for A.3.12 (intimation without delay and a seventy-two-hour report; the dual-clock pattern with CERT-In). Penalty up to INR 200 crore.
• Section 8(7) erasure, drives the records-destruction discipline in A.3.14.
• Section 9 children, layers a heightened duty on the A.3 controls for child-directed processing (tighter access controls under A.3.9; tighter supplier discipline under A.3.10; tighter project-management gate under A.3.11).
• Section 10 SDF, overlays the DPO (A.3.4 integration with clause 5.3), the SDF DPIA (A.3.11 trigger) and the independent data audit (third-line assurance on the A.3 evidence base).
• Section 16 cross-border negative list, the A.3.10 backdrop for cross-border suppliers.
• Section 33 + Schedule penalties, up to INR 250 crore for section 8(5) failure; up to INR 200 crore for section 8(6) failure; up to INR 200 crore for section 9 failure; up to INR 150 crore for section 10 failure.

The sector-regulator overlay (India-specific)

The Indian statutory-anchoring summary

The A.3 organisational family maps onto the DPDP Act in three dense clusters. Cluster 1, safeguards (A.3.3, A.3.4, A.3.9, A.3.10, A.3.11, A.3.14, A.3.16): anchored in section 8(5). Cluster 2, incident response (A.3.12): anchored in section 8(6) and the CERT-In Directions, with the sector-regulator clocks layered in. Cluster 3, SDF overlay (A.3.4, A.3.11): anchored in section 10. A controller or processor that implements the A.3 family has implemented the operational core of the DPDP safeguards duty.

Implementation Roadmap

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

The first 30 days, policy and quick wins

• Day 1 to 5, Sponsor and team. The CISO and the DPO confirm executive sponsorship (the CEO or the COO for a growing company; the board for an enterprise) and convene the cross-functional team (CISO, DPO, IT Lead, Procurement Lead, Legal Lead, Operations Lead, PMO Lead). The team adopts the Singahi A.3 readiness assessment (toolkit doc 12, Gap Analysis).
• Day 6 to 15, Policy and RACI inventory. The team inventories the Information Security Policy, the topic-specific policy set, the security RACI and the privacy RACI. The team identifies the PII-overlay gaps.
• Day 16 to 25, Supplier and access inventory. The team inventories the PII-touching suppliers and the PII stores. The team identifies the supplier-DPA gaps and the access-rights gaps.
• Day 26 to 30, Quick wins. The team implements the top-three highest-risk remediations (typically: rewriting the Information Security Policy with the PII overlay; integrating the security and privacy RACIs; refreshing the supplier-notification SLA in the highest-risk supplier DPA).

The 90-day milestone, operational disciplines

• Day 31 to 50, Policy and topic-specific set. The team finalises the rewritten Information Security Policy and the complete topic-specific policy set.
• Day 51 to 70, Access-rights rollout. The team rolls out the PII store inventory; the PII-specific least-privilege analysis; the risk-based recertification cadence; the privileged-access management extension.
• Day 71 to 90, Supplier DPA refresh. The team refreshes the supplier DPAs using the Supplier-Agreement PII Schedule; propagates the clauses to the sub-processor level; runs the cross-border negative-list screen.

The 180-day milestone, incident response and records

• Day 91 to 120, Incident response build. The team rewrites the incident response plan with the dual-clock pattern; configures the SIEM for the personal-data-breach indicators; pre-stages the CERT-In and DPBI templates; runs the first tabletop drill.
• Day 121 to 150, Project-management gate. The team implements the project-management gate with the privacy-and-security triggers.
• Day 151 to 180, Records protection. The team migrates the PIMS evidence base to the integrity-controlled records-management platform.

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

• Month 7, Drill programme. The team runs the full incident-response drill (tabletop first, then full drill) tracing the dual-clock pattern with the sector-regulator clocks layered in.
• Month 8, Internal audit and management review. The team runs the internal audit (clause 9.2) covering the fourteen organisational controls. The team runs the management review (clause 9.3) with the twelve KPIs (Section 12).
• Month 9, Certification Stage 1. The Stage 1 documentation review. The team closes the findings.
• Month 10, Certification Stage 2. The Stage 2 operational-effectiveness test. The A.3 walk-through (the auditor picks recent processing activities, suppliers and incidents and traces the fourteen controls).
• Months 11 to 12, SDF readiness (where applicable). Where the controller or processor is on track for SDF designation under DPDP section 10, the team integrates the DPO appointment, the SDF DPIA cycle and the independent-data-audit readiness into the A.3 architecture.

The ongoing cadence (post-certification)

• Weekly, KPI dashboard review (IT Lead for access; SOC Lead for incidents; DPO for records).
• Monthly, governance committee meeting; JML review; incident-review (where incidents occurred).
• Quarterly, high-risk PII store recertification; supplier DPA currency review; topic-specific policy review; drift detection.
• Semi-annually, full incident-response drill (mid-sized (250 to 2,000) and enterprise); management review of the A.3 KPIs.
• Annually, internal audit of A.3; full incident-response drill (growing companies); policy refresh; supplier-risk-tier review.
• Event-driven, project-management gate for each new processing activity; SDF DPIA every 12 months; corrective action on each finding.

FAQ

Q1. We already have an ISO/IEC 27001 certificate. Do we still need to implement A.3?

Yes. The 2025 edition of ISO/IEC 27701 makes the security controls normative within the PIMS (Annex A.3), even if you have a separate 27001 certificate, the A.3 controls must be implemented within the PIMS scope with the PII-protection overlay. The good news: where the 27001 ISMS scope subsumes the PIMS scope, the 27001 evidence base can be cross-referenced rather than duplicated. The A.3 audit will look for the PII overlay (the privacy-specific dimensions of each control) that distinguishes a PIMS scope from a generic ISMS scope.

Q2. We are a processor for our customer controllers. Does A.3 apply to us?

Yes, and unlike A.1 (controllers) and A.2 (processors), A.3 binds both roles. Table A.3 is the single security-control set for the PIMS, regardless of whether you act as controller or processor. The privacy overlay varies by role (a processor's A.3.10 supplier agreements propagate the customer-controller's instructions down the sub-processor chain; a controller's A.3.10 supplier agreements include the A.1.2.7 DPA clauses), but the underlying security discipline is the same.

Q3. What is the dual-clock breach pattern, and why does it matter?

The dual-clock pattern is the operational reality that an Indian Data Fiduciary must run multiple parallel breach-notification clocks when a personal-data breach occurs: CERT-In within six hours (Directions 20(3)/2022-CERT-In, 28 April 2022); DPDP without delay, with a detailed report within seventy-two hours (DPDP Act 2023 section 8(6) + DPDP Rules 2025 Rule 7); sector-regulator clocks where applicable (RBI two-to-six hours for NBFCs; SEBI six hours for SEBI Regulated Entities; IRDAI twenty-four to seventy-two hours for insurers). The clocks run in parallel from the awareness event. The pattern matters because missing any one clock carries penalty exposure, CERT-In penalties, DPDP penalties (up to INR 200 crore for section 8(6) failure), and sector-regulator supervisory action.

Q4. What is the supplier-notification SLA we should set in our DPAs?

The supplier-notification SLA must be shorter than your own notification clock. If DPDP expects your intimation to the Board without delay and your CERT-In clock is six hours, the supplier must notify you as soon as it is aware, and within 24 hours at the latest, to give you the runway to assess and notify within the clocks. A supplier "as soon as reasonably practicable" notification is not a contractual lever, make it specific.

Q5. Do we need an IGA / PAM / TPRM / SIEM / GRC tool to conform to A.3?

No specific tool is mandated, the A.3 controls are technology-neutral. At low maturity (L1 to L2) and small PIMS scope, the controls can be operated through spreadsheets, email and basic identity services. At higher maturity (L3 and above) and larger scope, the platforms become operationally necessary. The make-vs-buy decision (Section 8.6; toolkit doc 14) weighs the size, complexity, maturity target, integration overhead and Indian-market context.

Q6. How often should we run the incident-response drill?

Annually for growing companies (50 to 250 staff); semi-annually for mid-sized (250 to 2,000) and enterprise; semi-annually plus tabletops between for SDFs under DPDP section 10. The drill traces the dual-clock pattern (CERT-In six hours; DPDP without delay plus a seventy-two-hour detailed report; sector-regulator clocks where applicable). The drill exposes the gap between the documented playbook and the operational reality (stale credentials; unstaged templates; missing escalations); the gap is closed before the regulator does it for you.

Q7. We use a generic 27001-template Information Security Policy. Is that enough for A.3.3?

No. A generic 27001-template policy is the canonical A.3.3 audit finding in the Indian growing-company segment. The policy must name PII as a protected-asset category; cross-reference the Privacy Policy; commit to the dual-clock pattern; address the principal-rights dimension; commit to the PII-specific access, supplier, project-management, records and topic-specific policies. See toolkit doc 01 for the rewritten template.

Q8. What is the relationship between A.3.10 (supplier agreements) and A.1.2.7 (contracts with PII processors)?

A.1.2.7 is the controller-side privacy control that requires the DPA clauses; A.3.10 is the security control that operationalises the supplier relationship (risk tiering, agreement, monitoring) with the DPA clauses layered in. The two are mutually reinforcing: A.1.2.7 specifies the privacy clauses; A.3.10 specifies the supplier-management discipline that delivers the clauses. The Singahi A.1.2.7 guide covers the DPA clause library in depth; this guide cross-references.

Q9. We are likely to be designated an SDF under DPDP section 10. What does A.3 require of us that is additional?

The SDF overlay layers four additional duties: (a) the DPO based in India and accountable to the Board (A.3.4 integration with clause 5.3); (b) the SDF DPIA every 12 months (fed by the A.3.11 project-management gate); (c) the periodic independent data audit (third-line assurance on the A.3 evidence base); (d) the algorithmic-software review covering the algorithmic software used on personal data (Rule 13(3)). The A.3 organisational architecture should be SDF-ready before the designation takes effect, retrofitting the DPO and the SDF DPIA after designation is operationally harder.

Q10. Our security team and our privacy team are separate. How do we integrate them for A.3.4?

The integrated RACI is the load-bearing artefact. The CISO owns the security dimension; the DPO owns the privacy dimension; the two roles are peers, not subordinates. The integration is documented in a RACI that maps each A.3 control to the responsible security role and the consulted privacy role. The joiner-mover-leaver workflow covers the integration (when an engineer joins a PII-touching team, both the security and privacy access provisions fire). The governance committee meetings are co-chaired. See toolkit doc 13 for the RACI template.

Q11. How does A.3.14 (records protection) interact with clause 7.5 (documented information)?

Clause 7.5 governs the documentation-control discipline across the PIMS; A.3.14 adds the integrity dimension specifically, protection of records against destruction, loss, falsification and unauthorised modification. The PIMS evidence base (the ROPA, the consent records, the DPIA records, the breach records, the audit records) is the load-bearing A.3.14 surface. The conformant pattern is a records-management platform with cryptographic-integrity controls (hashing; version control; tamper-evidence) and per-category access controls.

Q12. Do we need a separate topic-specific policy for each topic, or can we combine them?

Either is conformant. A single integrated policy with topic-specific chapters is acceptable; a set of separate topic-specific policies is also acceptable. The choice is driven by the organisation's documentation conventions and the audit-readiness preference. The eight load-bearing topic-specific policies in a PIMS scope are: privacy, access control, supplier management, retention, incident management, records management, cryptography, logging.

Q13. We outsource our SOC to an MSSP. Does A.3.12 still apply?

Yes, and the MSSP is a PII-touching supplier under A.3.10, with the DPA clauses (the supplier-notification SLA; the incident clauses; the audit-and-evidence clauses; the cross-border clauses if the MSSP is offshore). The MSSP's incident-detection capability must feed your dual-clock pattern within the contracted SLA. The drill programme must include the MSSP in the test.

Q14. We process PII across India, the EU and the US. How does A.3.10 handle the cross-border dimension?

The cross-border dimension in A.3.10 layers three things: (a) the DPDP section 16 negative-list screen for cross-border suppliers; (b) the GDPR Chapter V transfer tools (the SCCs; the BCRs; the adequacy decision) where EU personal data is processed; (c) the US-sector rules (CCPA/CPRA and the state laws) where US personal data is processed. The supplier DPA must address each applicable jurisdiction. The supplier-risk-tiering should reflect the cross-border dimension.

Q15. How do we justify the cost of the A.3 organisational build to our board?

The business case has three pillars: (a) avoided penalty exposure (the DPDP penalties up to INR 250 crore for section 8(5) failure; up to INR 200 crore for section 8(6) failure, an order of magnitude larger than the build cost); (b) revenue enablement (enterprise customers increasingly require 27701 attestation as a procurement precondition; the certification is a market-access asset); (c) operational efficiency (the unified operating model removes duplicated governance, manual access administration and bespoke legal review per supplier). The Coralwave scenario (Section 15) illustrates the three pillars in practice.

Industry-Specific Requirements

BFSI (banking, financial services, insurance)

BFSI is the most prescriptively regulated Indian sector for the A.3 organisational family. The load-bearing instruments:

• RBI Digital Lending Guidelines (2 September 2022), LSP-supplier data-protection clauses (A.3.10); restriction on device-data access by lending apps (A.3.9 access-rights overlay); mandatory privacy policy (A.3.3); grievance-redressal (clause 5.3 integration).
• RBI Storage of Payment System Data (6 April 2018), payment-data localisation (A.3.10 cross-border supplier overlay); the data-residency precedent.
• RBI incident norms, six-hour NBFC incident reporting under the RBI Cybersecurity Directions 2026 (A.3.12 sector-regulator clock layered into the dual-clock pattern).
• SEBI CSCRF (20 August 2024), six-hour incident reporting to SEBI/CERT-In (A.3.12 sector-regulator clock); third-party data-handling (A.3.10); data-locality.
• SEBI KRA Master Circular (May 2024), KYC data handling (A.3.9, A.3.14).
• IRDAI Information and Cyber Security Guidelines (24 April 2023), policyholder-data confidentiality (A.3.9, A.3.14); ICT-outsourcing data-protection clauses (A.3.10); twenty-four-to-seventy-two-hour incident reporting (A.3.12).

A.3 emphasis for BFSI. The supplier-discipline (A.3.10) is non-negotiable (LSPs, payment processors, credit bureaus, ICT outsourcers, all PII-touching suppliers with prescriptive regulatory duties). The incident-response discipline (A.3.12) must layer the RBI, SEBI and IRDAI clocks alongside CERT-In and DPDP. The records discipline (A.3.14) must support the sector-specific retention rules (typically five to seven years post-policy-termination for IRDAI; KYC retention for SEBI).

Healthcare

Healthcare data is sensitive (DPDP Rules' sensitive-PDP categories; GDPR Article 9 special categories). The A.3 organisational overlay:

• Access rights (A.3.9), tightened least-privilege for clinical-record access; the clinical-staff role-based access; the access-recertification at higher frequency for the clinical databases.
• Supplier agreements (A.3.10), diagnostic labs, pharmacies, insurers, telemedicine platforms, each a PII-touching supplier with the DPA clauses.
• Records protection (A.3.14), clinical-record integrity is safety-critical; the records-protection discipline is non-negotiable.
• Project management (A.3.11), new clinical-data processing activities trigger the DPIA under A.1.2.6.

The Digital Information Security in Healthcare Act (DISHA) remains a draft bill as of mid-2026; the DPDP Act and the clinical-establishment regulations of the states are the operative instruments.

IT-ITeS and SaaS

IT-ITeS and SaaS companies typically operate across multiple jurisdictions (DPDP, GDPR, US-state, sectoral) and act as both controller (for their own employee and customer data) and processor (for their customers' end-user data). The A.3 scope covers both roles:

• Access rights (A.3.9), the processor-side access for the customer-controller's end-user data (multi-tenant access segregation; per-customer access controls); the controller-side access for the company's own employee and customer data.
• Supplier agreements (A.3.10), the cloud providers, the analytics providers, the support providers, each a PII-touching supplier with the DPA clauses propagated through the sub-processor chain.
• Project management (A.3.11), the SaaS product roadmap introduces new PII flows routinely; the gate must be enforced.
• Incident response (A.3.12), the SaaS incident response must coordinate across the customer-controllers (each with their own notification duties), the MSSP and the sub-processors, a multi-party incident-response pattern.
• Records protection (A.3.14), the SaaS must support the customer-controller's records (the per-tenant ROPA; the per-tenant consent records; the per-tenant DPIA records).

E-commerce and retail

E-commerce and retail are the most-audited sectors for the access-rights and supplier-discipline dimensions. The A.3 emphasis:

• Access rights (A.3.9), the customer-support access to the principal's PII; the marketing-access to the marketing database; the analytics-access to the warehouse; each with the PII-specific least-privilege analysis.
• Supplier agreements (A.3.10), the logistics partners, the payment partners, the marketing partners, the recommendation-engine partners, each a PII-touching supplier with the DPA clauses. The joint-controller analysis under A.1.2.8 may apply.
• Incident response (A.3.12), the high-volume consumer-facing incident scenarios (account-takeover; payment-card compromise; third-party-tracker compromise); the dual-clock pattern.

Edtech

Edtech is the sector where DPDP section 9 dominates. The A.3 emphasis for child-directed processing:

• Access rights (A.3.9), tightened least-privilege for children's PII; the access-recertification at higher frequency for the student databases.
• Supplier agreements (A.3.10), the school partners, the educational-board partners, the analytics providers, each with the heightened children's-PⅡ duties.
• Project management (A.3.11), the learning-analytics pipelines; the proctoring biometrics; the ADM pipelines, each a DPIA trigger under A.1.2.6 and an input to the SDF DPIA under DPDP section 10.
• Records protection (A.3.14), the student-record integrity is sensitive; the retention schedule (typically five to seven years post-programme-completion; longer for transcript-grade records).

Manufacturing

Manufacturing companies typically process less consumer-principal data than BFSI, healthcare, IT-ITeS, e-commerce or edtech, but they do process substantial employee, supplier-contact and channel-partner data. The A.3 emphasis:

• Access rights (A.3.9), the employee-record access; the supplier-contact access; the IIoT-data access (operator-identification; shift-rotation; safety-incident records).
• Supplier agreements (A.3.10), the supplier-chain is operationally deep; the supplier-risk-tiering should reflect the PII-touching layer.
• Project management (A.3.11), the connected-manufacturing initiatives; the IIoT deployments, each a potential PII trigger.
• Records protection (A.3.14), the long-tail retention dimension for safety and product-liability records (typically ten to fifteen years).

Maturity Model

Figure · Tiers

Maturity levels for organisational controls

Level 1, Initial / Ad-hoc

Characteristics. A generic 27001-template Information Security Policy with no PII overlay. Security RACI documented in parallel to the privacy RACI with no integration. Access rights with no PII-specific least-privilege analysis; uniform annual recertification. Supplier DPAs inconsistent, generic NDAs without the DPA clauses. Project-management gate inconsistent. Incident response plan addressing only the ICT incident. PIMS records in writable shared drives with no integrity controls. Topic-specific policies missing or stale.

Typical artefacts. The generic ISMS policy; the parallel RACIs; the supplier NDA folder; the shared-drive PIMS evidence.

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

The investment covers the policy rewrite, the RACI integration, the supplier DPA refresh and the access-rights baseline.

Level 2, Repeatable / Defined

Characteristics. A rewritten Information Security Policy with the PII overlay. An integrated security-and-privacy RACI. The PII store inventory. The PII-specific least-privilege analysis documented per role per store. Supplier DPAs refreshed with the DPA clauses (the Supplier-Agreement PII Schedule). The project-management gate documented and partially enforced. The incident response plan rewritten with the dual-clock pattern. The first tabletop drill run. The topic-specific policy set complete.

Typical artefacts. The rewritten Information Security Policy; the integrated RACI; the Supplier-Agreement PII Schedule; the dual-clock playbook; the topic-specific policy set.

The investment covers the access-recertification rollout, the IGA / PAM implementation, the full drill programme, the records-management platform migration.

Level 3, Managed / Measured

Characteristics. The access-recertification cadence operated (quarterly for high-risk PII; semi-annually for medium-risk; annually for low-risk). The privileged-access management extended to the PII stores. The project-management gate enforced for every new launch. The full incident-response drill programme (annual for growing companies; semi-annual for mid-sized (250 to 2,000)). The PIMS evidence base migrated to the integrity-controlled records-management platform. The twelve KPIs reporting; the first management-review pack produced.

Typical artefacts. The access-recertification records; the drill reports; the integrity-controlled PIMS evidence base; the KPI dashboard; the first internal-audit report on A.3.

The investment covers the SDF DPIA integration (where applicable), the SIEM reconfiguration for the personal-data-breach indicators, the supplier-performance-monitoring programme, the algorithmic-software review (where ADM in scope).

Level 4, Quantitatively Managed

Characteristics. The IGA / PAM platforms operating with the PII-specific recertification. The SIEM configured for the personal-data-breach indicators; the dual-clock timers automated. The supplier-performance-monitoring programme operating with quarterly reviews. The SDF DPIA integrated into the project-management gate (where the controller is an SDF). The drift-detection discipline firing quarterly; each drift feeding Clause 10.2 corrective action. The KPI targets consistently met; the management-review pack driving Clause 10.1 improvement.

Typical artefacts. The IGA / PAM evidence; the SIEM evidence; the supplier-performance reports; the SDF DPIA records; the drift-detection log; the management-review minutes with KPI trend analysis.

Level 5, Optimising

Characteristics. The A.3 organisational architecture operates as a unified security-and-privacy operating model. The access-rights discipline is continuous (real-time recertification through identity governance; just-in-time access for the high-PII-risk sessions). The supplier-discipline is integrated (the TPRM platform automates the supplier-risk-tiering, the DPA refresh, the sub-processor chain, the performance monitoring). The incident response is drilled quarterly with multi-incident scenarios; the dual-clock pattern is automated through the SIEM. The records-protection discipline uses cryptographic-integrity controls with predictive analytics (drift prediction; tamper-attempt detection). The A.3 architecture is integrated with the broader privacy engineering practice and the security engineering practice.

Typical artefacts. The continuous-improvement log; the predictive-analytics dashboard; the automated SIEM evidence; the integrated GRC dashboard.

Maturity-model quick-reference

Emerging Trends

The DPDP Rules' phased commencement

The DPDP Rules 2025 (notified 13 November 2025) phase in through 2026 and 2027. The breach-notification format (Rule 7 intimation) and the breach clock (intimation without delay, then a seventy-two-hour report; Rule 7) are the A.3.12-relevant slices; the SDF thresholds and the SDF DPIA format are the A.3.11-relevant slices; the verifiable-parental-consent mechanism is the A.3.9-relevant slice. Controllers that build the dual-clock incident-response capability, the project-management gate and the children's-data access controls ahead of the full-enforceability window (estimated May 2027) will have a multi-year advantage over those that retrofit in 2027 and 2028.

The SDF overlay under DPDP section 10

For controllers designated as Significant Data Fiduciaries, the section 10 overlay (DPO, SDF DPIA, independent audit, algorithmic-software review) layers additional A.3 duties, the DPO integrates with A.3.4; the SDF DPIA integrates with A.3.11; the independent audit is the third-line assurance on the A.3 evidence base; the algorithmic-software review integrates with A.3.9 and A.3.14. The first SDF designations (expected through 2026 and 2027) will shape the operational practice.

The convergence of security and privacy governance

The A.3 organisational family is the leading edge of a broader convergence between security governance and privacy governance. The integrated RACI, the unified governance committee, the joint incident-response drill and the shared KPI dashboard are operational patterns that treat the two disciplines as one. The Singahi view: the convergence should be operational, not org-chart-deep, the CISO and the DPO remain distinct roles with distinct accountabilities, but they operate through a unified governance and operating model.

The 27002:2022 PII correction (load-bearing)

ISO/IEC 27002:2022 has only one PII-specific control, 5.34 (Privacy and protection of PII). The other 27002 controls are general security controls that 27701 adopts with the PII-protection overlay. The privacy load is carried by the A.1 / A.2 annex controls and the MSS clauses, with 27002 providing the security backstop.

The convergence of A.3 with AI governance

The Rule 13(3) algorithmic-software overlay is the leading edge of a broader convergence between the A.3 organisational family and AI governance. The access-rights dimension for ADM pipelines (A.3.9); the supplier-discipline for AI-service providers (A.3.10); the project-management gate for AI deployments (A.3.11); the records-integrity for the algorithmic-software evidence (A.3.14), all are A.3 questions applied to AI pipelines.

The cloud-supplier dimension under A.3.10

The cloud suppliers are the largest PII-touching supplier category for most controllers and processors. The cloud-supplier DPA must include the security controls, the privacy clauses, the incident clauses, the cross-border dimension, the audit-and-evidence clauses, the deletion-and-return clauses. The cloud-supplier's certifications (ISO/IEC 27001; ISO/IEC 27017; ISO/IEC 27018; ISO/IEC 27701; SOC 2) form the audit-and-evidence base.

The convergence of privacy-by-design and security-by-design

Privacy by design (the A.1.4 family) and security by design (the A.3.11 project-management gate) are converging in the engineering practice. The Singahi recommended pattern is a single project-management gate that covers both the privacy dimension (the DPIA trigger; the minimisation objective; the principal-rights design) and the security dimension (the threat model; the attack-surface analysis; the security controls; the incident-response hooks).

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; controls 5.1, 5.2, 5.9, 5.15, 5.18, 5.19 to 5.22, 5.24 to 5.27, 5.33 are the security-backstop controls referenced in this guide).
• 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 29134:2017, Guidelines for privacy impact assessment.
• ISO/IEC 27706:2025, PIMS certification-scheme competence (Ed 1, October 2025; replaces ISO/IEC TS 27006-2:2021).
• ISO/IEC 17021-1:2015, Management-system certification-body requirements.
• ISO/IEC 27006 (current edition), ISMS certification-body requirements.

Indian regulatory instruments

• Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023, enacted 11 August 2023; eGazette notification 247847). Source: meity.gov.in.
• Digital Personal Data Protection Rules, 2025 (notified 13 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). Source: meity.gov.in.
• CERT-In Directions No. 20(3)/2022-CERT-In (28 April 2022), issued under section 70B(6) of the IT Act 2000. Source: cert-in.org.in.
• RBI, Storage of Payment System Data (circular DPSS.CO.OD.No.1098/06.08.005/2017-18, 6 April 2018). Source: rbi.org.in.
• RBI, Digital Lending Guidelines (circular DOID.CO.PPG.SEC.09/14.14.001/2022-23, 2 September 2022). Source: rbi.org.in.
• RBI, Tokenisation of Card transactions (circular DPSS.CO.RPPD.No.S-35/07.01.005/2021-22, 22 September 2021; full effect 1 October 2022). Source: rbi.org.in.
• SEBI, Cybersecurity and Cyber Resilience Framework (CSCRF) (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024). Source: sebi.gov.in.
• SEBI, KYC Registration Agencies Master Circular (May 2024). Source: sebi.gov.in.
• IRDAI, Information and Cyber Security Guidelines, 2023 (24 April 2023). Source: irdai.gov.in.
• K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (nine-judge Bench, judgment 24 August 2017).
• Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1 (five-judge Bench, judgment 26 September 2018).

Global regulatory instruments

• Regulation (EU) 2016/679 (General Data Protection Regulation), OJ L 119, 4.5.2016, p. 1 (in force 24 May 2016; application 25 May 2018). Source: eur-lex.europa.eu.
• European Commission Implementing Decision (EU) 2021/914 of 4 June 2021 (modernised Standard Contractual Clauses).
• European Commission adequacy decision for the EU-US Data Privacy Framework (10 July 2023).
• Case C-311/18, Data Protection Commissioner v. Facebook Ireland Limited, Maximillian Schrems (Schrems II), CJEU Grand Chamber, judgment 16 July 2020.
• NIST Privacy Framework v1.0: A Tool for Improving Privacy Through Enterprise Risk Management (NIST.CSWP.01162020, 16 January 2020). Source: nist.gov.
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (with 2022 Points of Focus update).

Other national privacy instruments

• Brazil, Lei Geral de Proteção de Dados (LGPD), Lei nº 13.709/2018.
• Canada, Personal Information Protection and Electronic Documents Act (PIPEDA), S.C. 2000, c. 5.
• China, Personal Information Protection Law (PIPL), effective 1 November 2021.
• Singapore, Personal Data Protection Act 2012 (No. 26 of 2012), as amended.
• Japan, Act on the Protection of Personal Information (APPI), Act No. 57 of 2003, as amended.
• Australia, Privacy Act 1988 (Cth), Schedule 1 (Australian Privacy Principles); Notifiable Data Breaches scheme (Part IIIC).
• South Korea, Personal Information Protection Act (PIPA), Act No. 10469 (2011), as amended.
• United Kingdom, Data Protection Act 2018; UK GDPR.
• United Arab Emirates, Federal Decree-Law No. 45 of 2021.
• Kingdom of Saudi Arabia, Personal Data Protection Law (Royal Decree No. M/19, in force 14 September 2023).
• South Africa, Protection of Personal Information Act (POPIA), Act 4 of 2013.
• United States, California Consumer Privacy Act / California Privacy Rights Act (Cal. Civ. Code 1798.100 et seq.); Virginia Consumer Data Protection Act; Colorado Privacy Act; Connecticut Data Privacy Act; Utah Consumer Privacy Act; and the growing list of state laws.