ISO 27701 Clause 5.2: Privacy Policy

Quick Reference (60 Seconds)

If you only read one thing: Clause 5.2 is where the PIMS stops being a programme and becomes an institution. A 5.2-conformant PIMS is one in which the organisation possesses a fit-for-purpose, sponsored, communicated, available, and maintained privacy policy that demonstrably drives downstream artefacts, and an external privacy notice that accurately describes the actual processing and the rights of data principals, not one in which a template sits on a shared drive. The certification auditor will examine this distinction ruthlessly, and so will the Data Protection Board of India and overseas regulators after a real breach. Get 5.2 wrong, a generic, undated, uncommunicated template plus a boilerplate notice that does not match the processing, and however strong the ROPA, the DPIA and the security controls, the certificate will be at risk and the DPDP penalty exposure will be live. Get it right, and every other clause becomes easier to evidence because the policy is the spine that runs through them.

What the Standard Actually Requires

Figure · Process

What Clause 5.2 asks you to do

The paraphrased requirement

ISO/IEC 27701:2025 Clause 5.2 asks organizations to set, communicate, and maintain a privacy policy appropriate to the organization. Four ideas do the work in that paraphrase. The privacy policy must be set, authored, sponsored, and authorised by top management as a strategic instrument of the PIMS. The privacy policy must be appropriate to the organisation's purpose, context, scale, structure, products, services, processing activities, and its declared role(s) as PII controller and/or processor. The privacy policy must be communicated, to all persons doing work under the organisation's control and to relevant interested parties, in language and formats they can receive, understand, and act on. The privacy policy must be maintained, reviewed at planned intervals (typically at the management review) and on event trigger, kept current with the organisation's actual processing, the regulatory landscape, and the needs of PII principals.

ISO/IEC 27701:2025 Clause 5.2 is short, the harmonized-structure Clause 5.2 has been deliberately written to fit alongside every other ISO management-system policy clause. The depth lives not in the clause text but in the architectural decisions an organisation must make to satisfy it. The standard requires the privacy policy to do four jobs at once.

First, the privacy policy is the apex artefact of the PIMS, every other PIMS document (scope statement, privacy risk assessment, ROPA, DPIA, consent records, data-principal-rights workflow, breach playbook, processor DPA register, transfer impact assessments, internal audit reports, management review minutes, corrective-action log) is downstream of, and consistent with, the policy.

Second, the privacy policy is the commitment instrument, it binds the organisation, by top management's signature, to its applicable privacy requirements, to the framework that drives privacy objectives, and to ongoing PIMS improvement. The four commitment statements that anchor every HS Clause 5.2 policy (commitment to applicable requirements; commitment to provide the framework for objectives; commitment to continual improvement; the additional commitments that contextualise the system) apply in full, but with the privacy-specific content load that DPDP, GDPR and the other major privacy laws attach.

Third, the privacy policy is the communication instrument, it tells persons doing work under the organisation's control (employees, contractors, interns, volunteers, processors' staff where contractually obligated) and relevant interested parties (PII principals, regulators, customers, partners) what the organisation will do with personal data, why, on what basis, and how it will be held accountable.

Fourth, the privacy policy is the available instrument, it is hosted, retrievable, version-controlled, and accessible in formats and languages that its audiences can use. For the external notice dimension of the policy, availability means publication on the public website, in-product surfaces, and through the Consent Manager (DPDP section 2(1)(g)) in machine-readable, layered, plain-language form.

The dual nature: internal PIMS policy + external privacy notice

This is the single most important conceptual move in this guide, and the place where most competitor content fails. ISO/IEC 27701:2025 Clause 5.2 reads as a single requirement for a "privacy policy." In practice, the artefact set that satisfies it is dual-natured.

The internal PIMS policy is the management-system instrument. It is addressed to the organisation itself, to its top management, and to its auditors. It contains the four commitment statements. It binds top management. It is reviewed at the management review. It is the structural analogue of the ISMS policy (ISO/IEC 27001:2022 Clause 5.2), the BCMS policy (ISO 22301:2019 Clause 5.2), the QMS policy (ISO 9001:2015 Clause 5.2) and the AIMS policy (ISO/IEC 42001:2023 Clause 5.2). If your organisation already runs one of those management systems, the internal PIMS policy can be either a separate instrument or an integrated single policy with a clearly labelled privacy sub-section.

The external privacy notice is the disclosure instrument addressed to PII principals / data principals / data subjects. It is the artefact that DPDP Act 2023 section 5, GDPR Articles 12 to 14, the IT Act SPDI Rules 2011, RBI Master Direction Digital Lending 2022, and every other major privacy law require. It is the public-facing "Privacy Policy" link in the website footer, the in-app notice displayed before consent collection, the just-in-time disclosure on a form, and the layered summary served through a Consent Manager. It must, at a minimum, tell the data principal who you are, what you collect, why, on what basis, with whom you share it, where you transfer it, how long you keep it, what rights they have, how to exercise them, and how to complain. Under DPDP and GDPR it must be in plain language; under DPDP section 9 (children) and the DPDP Rules 2025 it must be in a form that a child's parent or guardian can understand; under DPDP section 13 it must disclose the grievance redressal mechanism.

The two artefacts are not interchangeable. The internal PIMS policy is not the notice, putting the internal policy on the public website fails DPDP section 5 and GDPR Article 13 because it does not address the principal and does not contain the required disclosures. The external notice is not the PIMS policy, putting the website notice in the management review pack fails Clause 5.2 because it does not contain the four commitment statements and does not bind top management. Most Indian growing companies keep them as two separate but tightly aligned documents; large enterprises with mature privacy programmes may use a three-tier model (internal PIMS policy, employee privacy notice, external customer/user privacy notice) or a four-tier model (add a processor-facing privacy commitment). The Singahi toolkit for Clause 5.2 contains ready-to-customise templates for all four tiers; the default deployment is the two-tier model.

The four commitment statements (with privacy content load)

ISO/IEC 27701:2025 Clause 5.2 inherits the harmonized-structure commitment set. The wording below is Singahi's paraphrase; the standard's own formulation is not reproduced.

1. A commitment to meeting applicable privacy requirements. "Applicable privacy requirements" is a deliberately broad phrase: it includes applicable legal and regulatory requirements (for an Indian firm this typically spans the DPDP Act 2023, the DPDP Rules 2025, the IT Act 2000 sections 43A and 72A and the SPDI Rules 2011, sectoral requirements from RBI, SEBI, IRDAI, TRAI, MeitY and the relevant state-level regulations, and, for firms with overseas data principals, GDPR, CCPA/CPRA, LGPD, PIPL, PDPA Singapore, and the other major instruments listed in Section 16), contractual and customer requirements (DPAs, processor schedules, customer privacy commitments, BCR-equivalent undertakings), and the organisation's own self-imposed requirements (voluntary standards, public privacy commitments, codes of conduct, certifications, parent-company policies). The policy commits the organisation to process personal data in accordance with these requirements, which is a stronger commitment than merely complying in normal operations, because it binds the organisation to maintain the capability to comply across the processing lifecycle. The DPDP Act section 4 grounds-for-processing requirement, the section 6 consent standards (free, specific, informed, unconditional, unambiguous, clear affirmative action, withdrawable as easily as given), and the section 7 legitimate-uses catalogue must be reflected here.

2. A framework that drives how privacy objectives are defined and revisited. Privacy objectives live in Clause 6.2, but the framework that produces them is a policy commitment. The framework specifies who sets objectives (typically the DPO with the PIMS Steering Committee), on what cadence (annually at minimum, reviewed at the management review), against what dimensions (consent-record completeness, DSAR turnaround time, grievance resolution time, breach-detection-to-notification time, DPIA coverage, training completion, third-party privacy assessment scores, retention-deletion compliance), how they are approved, how they are cascaded to process owners, and how they are revised when context changes. Without the framework, objectives are arbitrary; the policy commits the organisation to a discipline.

3. A commitment to ongoing PIMS improvement. Improvement is operationalised by Clauses 9.1 (monitoring), 9.2 (internal audit), 9.3 (management review), 10.2 (corrective action) and 10.1 (continual improvement). The policy binds top management to maintain and improve the PIMS, not to build it once. The commitment is what the management review agenda (Clause 9.3) tests against. For a 27701:2025 transition from the 2019 edition, the improvement commitment also covers the structural consolidation (the move from 2019's clause 5 framework, clause 6 security extension, Annex A controllers, Annex B processors, to the 2025 Clause 4 to 10 HS plus the consolidated Annex A.1 / A.2 / A.3 plus the now-normative Annex B implementation guidance), the policy must author the post-transition shape.

4. A commitment to additional privacy-specific commitments that contextualise the PIMS. This is where the privacy content load lives. Well-formed Indian PIMS policies typically commit to: (a) lawful, fair and transparent processing (the DPDP section 4 grounds for processing, GDPR Article 5(1)(a)); (b) purpose limitation (DPDP section 4; GDPR Article 5(1)(b)); (c) data minimisation (DPDP section 8 implied; GDPR Article 5(1)(c)); (d) accuracy (DPDP section 11 right to correction; GDPR Article 5(1)(d)); (e) storage limitation (DPDP section 8(7) erasure; GDPR Article 5(1)(e)); (f) integrity, confidentiality and availability (DPDP section 8(5) reasonable security safeguards; GDPR Article 5(1)(f) and Article 32); (g) accountability (DPDP section 8 general obligations; GDPR Article 5(2)); (h) privacy by design and by default (ISO/IEC 27701:2025 Annex A.1.4 and Annex A.2.4; GDPR Article 25; DPDP section 2(1)(g) Consent Manager interoperability and revocability); (i) lawful cross-border transfer (DPDP section 16 negative-list; GDPR Chapter V Articles 44 to 49; ISO/IEC 27701:2025 Annex A.1.5.2 and A.2.5.2); (j) data principal rights and grievance redressal (DPDP sections 11 to 14; GDPR Articles 15 to 22); (k) the protection of children's and vulnerable persons' data (DPDP section 9; GDPR Article 8); (l) breach notification capability (DPDP section 8(6) and Rule 7; GDPR Articles 33 to 34; CERT-In 6-hour clock).

What the standard does NOT require (the demarcation competitors miss)

Clause 5.2 is widely misread as a paperwork exercise, download a template, fill in the blanks, sign it, publish it on the website. That misreading produces the single most common 5.2 nonconformity in the Indian growing-company segment. Being explicit about what 5.2 does not require protects against two failure modes: under-investing (treating the policy as a template and the notice as boilerplate) and over-reaching (treating the policy as the entire PIMS).

• 5.2 does not require a specific policy length. Some of the best Indian internal PIMS policies are two pages; some are eight. The external notice may be a layered short-form notice plus a long-form notice. The test is whether the artefact set does its four jobs (apex, commitment, communication, available), not whether it hits a word count. Templates that pad to a length should be edited down.
• 5.2 does not require the policy to contain the ROPA. The ROPA is a Clause 8 / Annex A activity; the policy references the ROPA (it commits to maintaining it) but does not reproduce it. The external notice summarises the ROPA's content for data principals; it does not reproduce it.
• 5.2 does not require the policy to contain the DPIA results. The DPIA is a Clause 6.1.2 / 8.2 activity; the policy commits to performing DPIAs where required (especially for SDF processing under DPDP section 10) but the DPIA register is a separate artefact.
• 5.2 does not require a specific governance structure. ISO/IEC 27701:2025 does not mandate a Privacy Committee, a DPO reporting line, or any particular named forum. The policy typically names the governance bodies the organisation has chosen, but the structure itself is not standardised. DPDP section 10 (for SDFs) does require a DPO based in India accountable to the board, but that is a regulatory overlay, not a 5.2 requirement per se.
• 5.2 does not require board approval of the policy. Top-management approval is required (Clause 5.1); for SDFs under DPDP section 10, board-level accountability for the DPO is additionally required; for listed entities the Companies Act 2013 section 134(3)(n) and SEBI LODR Regulation 21 overlay may require board or board-committee visibility. But that is regulatory overlay, not a baseline 5.2 requirement. For most growing companies, the CEO/MD signature plus the DPO/Privacy Lead co-signature suffices.
• 5.2 does not require variable-pay linkage to policy compliance. Pay linkage is a leading-practice signal of L4 to L5 maturity, not a standard requirement.
• 5.2 does not require a separate "Privacy Manual." Many Indian firms maintain a PIMS Manual that bundles the policy with the scope, roles, ROPA, and process map; this is permitted but not required. The policy can stand alone.
• 5.2 does not require translation of the internal policy into every workforce language. It requires the policy to be available to its audiences; for a multilingual Indian workforce, this means a policy-on-a-page summary translated into the dominant workplace languages and accessible formats. The external notice has a stronger translation expectation under DPDP Rules 2025 (plain-language and child-readable where relevant) and under GDPR Article 12 (plain and intelligible form).
• 5.2 does not require public publication of the internal policy. "Available to relevant interested parties" does not mean the internal PIMS policy is published on the open internet. The external notice is published on the open internet because DPDP, GDPR and other laws require it; the internal policy is hosted on the intranet, on the vendor portal, on the customer trust portal on request, and provided to regulators on request. Conflating the two produces both an audit failure (internal policy published with management-system detail that should not be public) and a regulatory failure (external notice is internal-policy-shaped and does not meet the disclosure standard).
• 5.2 does not require the notice to be a single document. Layered notices (short-form plus long-form), contextual just-in-time notices, child-readable summaries, and machine-readable consent-manager payloads are all legitimate. The test is whether the principal receives the information they need, when they need it, in a form they can use, not whether a single canonical document exists.

The companion guidance, Annex B is normative in 2025

The clause text is short; the method lives in the now-normative Annex B (Implementation Guidance for PII Controllers and Processors), a load-bearing 2025 change. In ISO/IEC 27701:2019 the equivalent material sat in informative Annex F; auditors could treat it as guidance. In ISO/IEC 27701:2025, Annex B is normative, auditors will test against it. For Clause 5.2 specifically, the Annex B guidance (numbered B.5.2 to mirror the clause) explains how the policy and notice should be structured, what they should contain, and how they should be made available. The Annex B guidance should be treated as testable, not optional.

Five external anchors are most relevant for Clause 5.2.

• ISO/IEC 27001:2022 Clause 5.2 is structurally identical. If your organisation runs an integrated ISMS+PIMS, a single integrated information-security-and-privacy policy can satisfy both clauses (with a clearly labelled sub-section for each), or two aligned policies can sit side-by-side. Indian growing companies commonly pursue both standards concurrently (often alongside ISO 22301:2019 and increasingly ISO/IEC 42001:2023); the policy is the natural point of integration. The Singahi policy architecture treats the four HS Clause 5.2 policies (ISMS, PIMS, BCMS, AIMS) as a coordinated set.
• ISO/IEC 29100:2011, the privacy framework with its 11 privacy principles (consent and choice; purpose legitimacy and specification; data minimisation; use, retention and disclosure limitation; accuracy and quality; openness, transparency and notice; individual participation and access; accountability; security safeguards; privacy compliance) is the conceptual ancestor of the A.1/A.2 control themes and the natural vocabulary for the policy's privacy-specific commitments.
• GDPR Articles 12 to 14 (transparency and notice) and Article 5 (principles) are the densest external content standard for the external notice, and they are the reference point most overseas customers will test against. Article 12's "plain and intelligible form, using clear and plain language" standard is the global notice benchmark.
• EDPB Guidelines 4/2019 on Article 25 (data protection by design and by default) and EDPB Guidelines 05/2020 on consent are the operational reference for the policy's privacy-by-design commitment and the notice's consent-collection design.
• NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020), the Govern-P function (governance structure, privacy roles, risk-management strategy, policy) and Communicate-P function (data-review, reporting, training, transparency) are the US-flavoured structural analogue of Clause 5.2's commitments.

What auditors actually check

The certification auditor's Clause 5.2 examination has eight predictable moves. Preparing for them is the most efficient way to convert a Stage 1 visit into a Stage 1 pass.

First, the auditor opens the internal policy and reads the four commitment statements. If any of (a) applicable privacy requirements, (b) the framework for objectives, (c) continual improvement, (d) the privacy-specific commitments is missing, major nonconformity. If the commitment to applicable privacy requirements is generic ("we comply with applicable privacy laws") without naming the regulator landscape and the controller/processor role declaration, minor nonconformity, corrected on the day.

Second, the auditor opens the external notice and tests it against the ROPA. The auditor picks a processing activity from the ROPA, opens the notice, and checks: is the purpose accurately described? Is the lawful basis or DPDP ground correct? Are the recipients or categories of recipients listed? Is the retention period or criterion stated? Are the cross-border destinations and the transfer mechanism named? Are the data principal rights and the exercise mechanism disclosed? If the notice does not match the ROPA, major nonconformity. This is the audit move most Indian growing companies fail.

Third, the auditor checks the controller/processor role declaration. The notice must accurately reflect whether the organisation is acting as a controller (Data Fiduciary under DPDP), a processor (Data Processor under DPDP), or both, in relation to the principal. A notice that says "we are the controller" when the organisation is in fact a processor for some processing activities is a structural finding. The policy must declare the role(s) across the PIMS scope.

Fourth, the auditor asks the DPO/Privacy Lead to describe how the policy and notice are "appropriate to the organisation's purpose." This is the fit-to-purpose test. The DPO must be able to connect the policy content to the organisation's context (Clause 4.1 outputs), its interested parties (Clause 4.2 outputs), its scope (Clause 4.3 output), and the privacy risk assessment (Clause 6.1.2 / 8.2 outputs). A DPO who cannot answer this question has signed a policy they did not author; that is a Clause 5.1 finding but it surfaces first under 5.2.

Fifth, the auditor checks the version history and the review trail. Is the policy dated? Is the notice dated? Is the next review date set? Has the policy been reviewed within the last 12 months (or sooner if an event trigger fired)? Are both versions of the artefacts traceable through the Documented Information system (Clause 7.5) so that, for any past consent, the version of the notice that was in force at the time of consent can be retrieved? A notice with no version history cannot support consent records and fails the audit.

Sixth, the auditor samples staff. "Have you seen the Privacy Policy? Where is it? What does it commit the organisation to? What are your privacy responsibilities?" Five randomly-sampled staff in different functions and locations. If three out of five cannot answer, the communication commitment is failed, minor nonconformity. If four out of five cannot answer, major nonconformity.

Seventh, the auditor checks the consent-and-notice record. Can the organisation produce, for a sampled data principal, the version of the notice that was displayed to them, the consent record (with timestamp, version, scope of consent, and the Consent Manager reference if applicable), and any subsequent withdrawal? DPDP section 6 consent requirements (free, specific, informed, unconditional, unambiguous, clear affirmative action, withdrawable as easily as given) are tested here.

Eighth, the auditor traces the policy into downstream artefacts. Do the privacy objectives (Clause 6.2) operationalise the policy's framework commitment? Does the ROPA reflect the policy's processing commitments? Do the DPIAs reflect the policy's risk commitment? Does the breach playbook (Clause 8 and Annex A.3 incident controls) reflect the policy's breach-notification commitment, hitting both the CERT-In 6-hour clock and the DPDP 72-hour clock? Does the management review agenda (Clause 9.3) include policy review? Do the corrective-action and continual-improvement logs (Clauses 10.2 and 10.1) close against policy commitments? A policy that is not traced downstream is decoration.

Why This Control Matters

The policy as the spine of the PIMS

Every other clause and annex of ISO/IEC 27701:2025 inherits its legitimacy from Clause 5.2. The privacy risk assessment (Clause 6.1.2 and 8.2) is justified because the policy commits to identifying and treating privacy risks. The ROPA (Clause 8 and Annex A.1.2.x / A.2.2.x) is justified because the policy commits to documenting processing activities. The DPIA (Annex A.1.2.5) is justified because the policy commits to assessing high-risk processing. The data-principal-rights workflow (Annex A.1.3.x) is justified because the policy commits to honouring rights. The processor DPA regime (Annex A.2 and Clause 8) is justified because the policy commits to processor oversight. The breach playbook (Clause 8 and Annex A.3) is justified because the policy commits to breach notification. The internal audits (Clause 9.2) and management review (Clause 9.3) are justified because the policy commits to continual improvement. Without 5.2, the rest of the PIMS is unsponsored effort. With a strong 5.2, every other clause has a defensible origin.

This is not a stylistic observation. It is the operational reality that the certification auditor and the Data Protection Board of India converge on. A PIMS without a fit-for-purpose policy is, in auditor language, a "system without top-management authorisation", which is the most serious structural nonconformity a PIMS can carry. A PIMS with a fit-for-purpose policy whose external notice does not match the actual processing is, in DPDP language, a Data Fiduciary in breach of its section 5 notice obligation and its section 8 general obligations, exposing the organisation to penalties up to 250 crore rupees per the Schedule.

The Indian regulatory weight behind 5.2

In India, Clause 5.2 has a regulatory weight that goes far beyond the ISO standard itself. The DPDP Act 2023 (Act 22 of 2023, enacted 11 August 2023) and the DPDP Rules 2025 (notified 13 November 2025, with phased commencement) make the dual-natured privacy policy a statutory requirement for every Data Fiduciary. The lineage is the wedge: Puttaswamy v. Union of India, (2017) 10 SCC 1 (judgment delivered 24 August 2017 by a nine-judge Bench of the Supreme Court) declared the right to privacy, including informational privacy, a fundamental right under Articles 14, 19 and 21 of the Constitution. The Aadhaar judgment, Justice K.S. Puttaswamy (Retd.) v. Union of India, (2019) 1 SCC 1 (26 September 2018, five-judge Bench) set the proportionality test. After multiple draft Bills (2019, 2022, 2023), the DPDP Act was enacted on 11 August 2023. The DPDP Rules 2025 were notified on 13 November 2025 with phased commencement (Rules 1, 2 and 17 to 21 in force on notification; other provisions commencing on later dates, with the core data-fiduciary obligations widely read as reaching full enforceability approximately 18 months from notification, around May 2027, confirm the exact date in the notified commencement rule). ISO/IEC 27701:2025 was published on 14 October 2025, twelve days before the DPDP Rules were notified. The two instruments were, in effect, made for each other.

The DPDP Act and Rules bear on Clause 5.2 across at least eleven provisions.

DPDP section 4 (grounds for processing). Personal data may be processed only for a lawful purpose, with the data principal's consent (or for certain legitimate uses under section 7). The policy commits to processing only on a section 4 ground; the notice discloses the specific ground.

DPDP section 5 (notice). Before or at the time of collecting personal data, the Data Fiduciary must give the Data Principal (or the Consent Manager) a clear, plain-language notice describing the personal data to be collected, the purpose of processing, the rights of the Data Principal, the manner of exercising those rights, the grievance-redressal mechanism, and the consequence of non-consent. The DPDP Rules 2025 prescribe the notice's content, language and format. This is the external-notice content standard.

DPDP section 6 (consent). Consent must be free, specific, informed, unconditional, unambiguous, and given by a clear affirmative action. Consent must be withdrawable as easily as it was given. The notice and the consent flow must operationalise these standards. The Consent Manager (section 2(1)(g)) is the registered single point of contact through which a Data Principal gives, manages, reviews and withdraws consent across Data Fiduciaries, a distinctive Indian construct with no clean GDPR analogue. The notice must integrate with the Consent Manager ecosystem.

DPDP section 8 (general obligations of Data Fiduciary). Section 8(5) requires reasonable security safeguards to maintain the integrity, confidentiality and availability of personal data. Section 8(6) requires breach notification to the Board and to each affected Data Principal in the prescribed form and manner, operationalised by Rule 7 of the DPDP Rules 2025 as 72 hours of becoming aware, with the prescribed intimation content, extendable by the Board. Section 8(7) requires erasure when the purpose is met or retention is no longer lawful. The policy's commitments to availability, breach notification and retention-deletion must reflect these provisions; the notice must describe the retention practice and the breach-notification commitment.

DPDP section 9 (children and persons with disability). Processing of a child's data requires verifiable parental or legitimate-guardian consent. The Data Fiduciary must not undertake processing likely to cause detriment to a child, behavioural monitoring, targeted advertising, or tracking of children. The DPDP Rules 2025 prescribe the verifiable-parental-consent mechanism and the notice-format requirements for processing children's data. The policy commits to the section 9 safeguards; the notice must be in a form the parent or guardian can understand, with a separate child-readable layer where appropriate.

DPDP section 10 (Significant Data Fiduciary). The Central Government designates Data Fiduciaries meeting prescribed thresholds (volume, sensitivity, risk to data principals, impact on sovereignty, electoral democracy) as Significant. SDFs must appoint a Data Protection Officer based in India, accountable to the Board of Directors or governing body; perform a Data Protection Impact Assessment (the Act's term, DPIP) for each new processing activity; perform periodic independent data audits; and conduct an algorithmic-AI fairness review where AI or statistical inference affects data principals. The SDF obligations are the densest overlap with ISO/IEC 27701:2025, Clause 6.1.2, Clause 8.2, Annex A.1.2.5, and Clause 5.3 (the DPO role) collectively implement the SDF overlay. An Indian SDF implementing 27701 satisfies most of section 10 with minimal additional work; the policy is where the SDF designation and its obligations are formally declared.

DPDP sections 11 to 14 (rights of Data Principals). Section 11: right to access. Section 12: right to correction, completion, updating and erasure. Section 13: right of grievance redressal, the Data Fiduciary must provide a readily available means and respond within the prescribed period. Section 14: right to nominate. The notice must disclose all four rights; the policy commits to operating the rights-handling workflow.

DPDP section 16 (cross-border transfer). Personal data may be transferred to any country except those notified by the Central Government as restricted, the negative-list approach. This is structurally different from GDPR's adequacy-or-safeguards model. The notice must disclose the destinations or categories of destinations; the policy commits to screening transfers against the negative list.

DPDP section 18 and the Data Protection Board of India. The Board is the regulator, body corporate, constituted by the Central Government, the DPDP analogue of a GDPR supervisory authority. The Board is an interested party under Clause 4.2; the policy commits to engaging with the Board; the notice discloses the right to complain to the Board.

DPDP section 33 and the Schedule (penalties). Failure to take reasonable security safeguards under section 8(5) exposes the Data Fiduciary to a Board-imposed penalty of up to 250 crore rupees; failure to notify a breach under section 8(6), up to 200 crore rupees; failure to meet the section 9 children's-data obligations, up to 200 crore rupees; failure to fulfil the section 10 SDF additional obligations, up to 150 crore rupees. These are the largest monetary exposures in Indian privacy regulation. A policy and notice that mis-state the processing or omit a commitment can contribute directly to penalty exposure.

DPDP Rules 2025 (notified 13 November 2025). The Rules operationalise the Act: the 72-hour breach clock and the Rule 7 intimation content (Rule 7); the consent-notice content and language and the verifiable-parental-consent mechanism (Rules under section 9); the SDF designation thresholds and the DPIP/audit cadence; the data retention and erasure timelines including the 48-hour pre-erasure notice to the Data Principal; the Consent Manager registration conditions; the grievance-redressal response periods under section 13. Every one of these rules bears on Clause 5.2 because the notice and the consent flow must operationalise them.

CERT-In Directions 20(3)/2022-CERT-In of 28 April 2022 apply horizontally to every ICT operator in India. The six headline obligations include reporting prescribed cyber incidents (including personal-data breaches) to CERT-In within 6 hours of noticing, maintaining 180-day ICT logs within Indian jurisdiction, syncing ICT clocks to NIC NTP, maintaining KYC of VPN, data-centre, cloud and anonymous-service customers for five years, appointing a CERT-In Point of Contact, and cooperating with investigations. The DPDP-CERT-In dual clock (72 hours to the Board and 6 hours to CERT-In, running in parallel from the same awareness event) is a uniquely Indian compliance pattern the breach-notification commitment must address.

RBI Master Direction on Digital Lending (2 September 2022) is India's most prescriptive sectoral privacy-by-design instrument. It mandates explicit borrower consent, restriction on device-data access by lending apps (contacts, location, media), data-collection minimisation, a mandatory privacy policy, grievance redressal, and restrictions on storage and sharing. Any Regulated Entity lending digitally must reflect these in both the internal policy and the borrower-facing notice.

RBI Tokenisation circular (22 September 2021; full effect 1 October 2022) requires card-on-file to be replaced by tokens, with consent for tokenisation. A concrete data-minimisation commitment the policy can name.

SEBI KRA Regulations 2011 (as amended 2024; Master Circular May 2024) govern KYC data handling by KRAs and market intermediaries, privacy-angle: KYC data is SPDI under the IT Act and personal data under DPDP.

SEBI Cybersecurity and Cyber Resilience Framework (CSCRF, 20 August 2024) requires board-approved cyber-resilience policy spanning five goals and six operational functions, with incident reporting within 6 hours to SEBI and CERT-In.

IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023) embed policyholder-data confidentiality, data locality for policyholder data, incident reporting to IRDAI and CERT-In, ICT-outsourcing data-protection clauses. Insurers are Data Fiduciaries under DPDP for policyholder PII.

IT Act 2000 sections 43A and 72A and the SPDI Rules 2011 are the pre-DPDP baseline. Section 43A requires reasonable security practices and procedures for sensitive personal data or information (SPDI); section 72A creates criminal liability for disclosure in breach of a lawful contract. The DPDP Act now governs the substantive obligations, but the IT Act/SPDI framework remains on the statute book and is still cited for the narrower SPDI definition.

Companies Act 2013 section 134(3)(n) requires the Board's Report to include a statement on the development and implementation of a risk management policy. Section 177 and SEBI LODR Regulation 21 require a Risk Management Committee with cyber, operational, privacy and continuity risk coverage. The Privacy Policy is a natural input to that risk-management statement.

In aggregate: in India, a fit-for-purpose privacy policy and notice are not optional, they are multi-regulator requirements with monetary penalties attached (DPDP up to 250 crore rupees; RBI enforcement; SEBI penalties; IRDAI direction; CERT-In action). The ISO/IEC 27701:2025 Clause 5.2 policy-and-notice set is the natural single artefact set that satisfies all of these regimes simultaneously, which is one of the strongest commercial arguments for pursuing ISO/IEC 27701:2025 certification in the Indian market, and one of the strongest reasons the 2025 edition's standalone-PIMS framing matters for India.

The cost of non-compliance

The cost of a Clause 5.2 failure breaks down into four bands.

Direct DPDP penalty exposure is the most visible. The Schedule maxima run to 250 crore rupees for failure on security safeguards and 200 crore rupees for failure on breach notification or children's data, and 150 crore rupees for failure on the SDF obligations. But the Schedule is the headline ceiling, and the policy-and-notice quality directly informs the Board's "adequate safeguards" analysis under section 8(5) and the "adequate notification" analysis under section 8(6).

Indirect regulatory consequences are larger and slower. A privacy policy that misrepresents the processing or omits a category of recipients can support a finding of unfair trade practice under the Consumer Protection Act 2019, a section 43A compensation claim, and parallel proceedings by sector regulators (RBI ombudsman scheme, SEBI investor grievance mechanism, IRDAI grievance redressal). For listed entities, a material privacy-policy failure triggers disclosure obligations under SEBI LODR and may constitute a price-sensitive event.

Commercial cost is the largest single category. The Indian incidents most cited in board rooms, MobiKwik (approximately 110 records allegedly exposed in 2021 per the researcher's disclosure, contested by the company), Juspay (approximately 35 million records in 2021, publicly acknowledged), BigBasket (approximately 20 million records alleged in 2020), Air India/SITA (approximately 4.5 million customers affected by the SITA breach disclosed in February-May 2021), the Lukup cyber event, all carried commercial costs in churn, brand damage, customer-acquisition drag, and regulatory scrutiny. None was a Clause 5.2 failure in isolation, but in every case the post-incident regulatory and litigation examination tested the privacy policy and notice. A policy and notice that cannot withstand that examination amplify the commercial cost.

Certification cost is the most immediate for ISO/IEC 27701:2025 candidates. A Clause 5.2 minor nonconformity at Stage 2 delays the certificate issue by 4 to 12 weeks and costs a surveillance-visit verification. Both are recoverable; both are entirely avoidable with the discipline this guide sets out.

The board-level angle

For Indian listed companies and BFSI, and for any organisation designated as a Significant Data Fiduciary under DPDP section 10, the privacy policy and notice are increasingly board-level artefacts, not management artefacts. Section 134(3)(n) of the Companies Act 2013 places the risk-management policy statement in the Board's Report; SEBI LODR Regulation 21 places privacy risk within the Risk Management Committee mandate; DPDP section 10 makes the SDF DPO accountable to the Board. The board-level angle is not theoretical: a policy and notice the board has not seen, or has not reviewed, is a governance gap a regulator will name.

The practical implication for the DPO/Privacy Lead: the internal PIMS policy must be board-presentable. That means short (typically two to five pages for the policy itself, with appendices for the commitment expansion), well-structured (the eight-section anatomy in Section 7 of this guide), free of jargon, dated, version-controlled, and accompanied by a one-page executive summary suitable for the board pack. The external notice must be principal-presentable: plain language, layered, in the principal's language, accessible on every digital surface, and machine-readable for the Consent Manager. The DPO presents the policy at the management review (Clause 9.3); the board reviews it through the Risk Management Committee at minimum annually and on event trigger.

Scope and Applicability

By organisation size

Growing companies (50 to 250 staff). A single internal PIMS policy plus a single external privacy notice covers the whole organisation for a single controller role. The executive sponsor is typically the CEO/MD or COO; the DPO/Privacy Lead (whether or not the formal SDF designation applies) co-drafts. The internal policy is communicated via all-hands briefing, intranet, and new-joiner induction. The external notice is published on the public website, in the product or app, and in the consent flow. Multilingual translation is typically a one-page summary in the dominant workplace language for the internal policy, and a layered short-form notice in English plus one regional language for the external notice. The first cycle (author, approve, communicate, make available) is deliverable in 6 to 10 weeks of internal effort plus optional external advisory.

Mid-market (250 to 2,000 staff). The internal PIMS policy still suffices as a single instrument, but is typically supported by a small set of subordinate policy instruments (employee privacy notice, processor-facing privacy commitment, vendor privacy schedule, child-readable notice where relevant) and a PIMS Manual that bundles the policy with scope, roles and the ROPA summary. The external notice typically splits into a customer notice, a website visitor notice, and a candidate/employee notice. Communication runs through departmental cascades, multilingual summaries (typically English plus two regional languages), and an annual policy-refresh cycle.

Multi-entity enterprise (2,000-plus staff or multi-site). A group privacy policy typically sits above entity-level policies, with a defined parent-subsidiary hierarchy. Group-level policy covers minimum standards, group-wide commitments, and the global regulator landscape; entity-level policies operationalise for the local context, language and sectoral regulation. The external notice typically exists in jurisdiction-specific versions (an India notice reflecting DPDP, an EU notice reflecting GDPR, a California notice reflecting CCPA/CPRA, a Brazil notice reflecting LGPD, and so on). Communication is typically managed through a privacy-management platform, with multilingual translation across multiple states or countries and Consent Manager integration. For SDFs (DPDP section 10), this band is the typical floor, the SDF DPO, DPIP and audit obligations add cost on top.

By controller/processor role

The single most consequential scoping decision for Clause 5.2 is the role declaration, are you a PII controller (Data Fiduciary under DPDP), a PII processor (Data Processor under DPDP), or both across the PIMS scope?

PII controller only. Your policy commits to the full Annex A.1 control set; your notice is the principal-facing disclosure required by DPDP section 5 and GDPR Articles 13 to 14; you are the decision-maker on purposes and means; you carry the full penalty exposure under the DPDP Schedule.

PII processor only. Your policy commits to the Annex A.2 control set (the processor-side controls, about 18 controls in the 2025 consensus count); your "external notice" is in fact a processor-facing privacy commitment addressed to the controllers you serve (telling them what you do, on whose instructions, with what sub-processors, what security, what breach-notification SLA, what cross-border transfers, what deletion-on-termination commitment). You do not generally have a direct data-principal-facing notice obligation under DPDP, the controller carries that, but you may need to surface a processor privacy commitment to your enterprise customers as part of their DPA due diligence. Many Indian IT/ITeS and BPO firms fall here.

Both controller and processor. Most Indian growing companies of any scale are both, controller for employee data, customer CRM data, finance data; processor for the customer data they handle under SaaS or BPO contracts. The policy must declare both roles and commit to both control sets; the notice set splits into a controller-facing notice for principals and a processor-facing privacy commitment for controller customers. The role declaration drives the Statement of Applicability (Clause 6.1.3 e), the risk assessment scope (Clause 6.1.2), and the audit programme (Clause 9.2).

By industry (summary, full detail in Section 21)

By geographic footprint

Single-state Indian operations. The policy covers the DPDP Act, DPDP Rules, IT Act/SPDI, sectoral regulation if any, and the relevant state-level instruments. Communication in English plus the state language.

Pan-India operations. The policy covers DPDP Act + Rules, IT Act/SPDI, CERT-In Directions, sectoral regulation (RBI/SEBI/IRDAI as applicable), and multilingual communication across major Indian languages. Geographic diversity of operations is a fit-to-purpose input.

India-plus-overseas operations. The policy must reconcile ISO/IEC 27701:2025 with the overseas regulator regime, GDPR for EU/EEA data subjects, UK GDPR for UK data subjects, CCPA/CPRA for California, LGPD for Brazil, PIPL for China, PDPA for Singapore and other APAC instruments. The Indian parent policy typically commits to meeting the most stringent of these, and entity-level policies and jurisdiction-specific notices operationalise locally. The Annex A.1.5.2 / A.2.5.2 cross-border transfer controls require a documented transfer basis, for DPDP that is the negative-list screen, for GDPR that is adequacy, SCCs, BCRs or derogations, post-Schrems II with a transfer impact assessment. The policy commits to operating the transfer basis; the notice discloses the destinations.

Key Definitions and Terminology

Clause 5.2 uses a small number of terms precisely. The ISO/IEC 27000 vocabulary family, the ISO/IEC 29100:2011 privacy framework definitions, and the GDPR Article 4 definitions are the international sources; the DPDP Act 2023 section 2 definitions are the Indian source. Where Indian regulatory usage diverges from ISO, both are given.

Privacy policy

In ISO/IEC 27701:2025 usage, the privacy policy is the apex statement of intentions, principles, and commitments authorised by top management of the PIMS. A policy is strategic, not operational: it says what the organisation commits to and why, not how the commitment is delivered. The how lives in procedures, ROPA entries, DPIAs, processor DPAs, the breach playbook, and the data-principal-rights workflow. The 5.2 privacy policy is therefore a strategic instrument; the ROPA, DPIA, processor DPA schedule, breach playbook, and rights-handling procedure are operational instruments that operationalise the policy. As Section 2 explains, the ISO/IEC 27701:2025 "privacy policy" reads as a single instrument but evidences as a dual artefact set: the internal PIMS policy (the strategic apex) and the external privacy notice (the disclosure to data principals). Both are needed.

PII controller / Data Fiduciary

A PII controller (ISO/IEC 27701:2025 / ISO/IEC 29100) is the organisation that determines the purposes and means of processing personally identifiable information. The DPDP analogue is the Data Fiduciary (DPDP Act section 2(1)(i)). The GDPR analogue is the controller (Article 4(7)). The controller carries the principal-facing notice obligation, the consent-collection obligation, the rights-handling obligation, and the bulk of the regulatory penalty exposure. Annex A.1 of ISO/IEC 27701:2025 sets out the controller control objectives and controls, about 31 in the 2025 consensus count.

PII processor / Data Processor

A PII processor (ISO/IEC 27701:2025 / ISO/IEC 29100) is the organisation that processes PII on behalf of a controller. The DPDP analogue is the Data Processor (DPDP Act section 2(1)(k)). The GDPR analogue is the processor (Article 4(8)). The processor's notice obligation is to the controller (the DPA terms, the sub-processor disclosure, the breach-notification SLA), not generally to the data principal directly. Annex A.2 of ISO/IEC 27701:2025 sets out the processor control objectives and controls, about 18 in the 2025 consensus count.

PII principal / Data Principal

A PII principal (ISO/IEC 27701:2025 / ISO/IEC 29100) is the individual to whom the PII relates. The DPDP analogue is the Data Principal (DPDP Act section 2(1)(h)). The GDPR analogue is the data subject (Article 4(1)). The principal is the audience of the external privacy notice; the principal's rights are what the notice must disclose.

Personal data / personal information / PII

Personal data (GDPR Article 4(1); DPDP Act section 2(1)(o)) is any information relating to an identified or identifiable natural person. PII (ISO/IEC 29100) is information that can be used to distinguish or trace an individual's identity. The terms are broadly equivalent in scope. DPDP applies to digital personal data, paper-only records are outside the DPDP scope but may remain within the IT Act/SPDI Rules scope. Sensitive categories attract additional protections: DPDP section 9 (children); GDPR Article 9 (special categories); IT Act SPDI Rules (sensitive personal data or information, passwords, financial data, health, biometric, etc.).

Consent

Consent under DPDP section 6 must be free, specific, informed, unconditional, unambiguous, and given by a clear affirmative action. Consent must be withdrawable as easily as it was given. The GDPR Article 7 standard is similar (freely given, specific, informed, unambiguous). The notice must operationalise consent: clear affirmative action means no pre-ticked boxes, no bundled consents, no consent-as-condition-of-service unless the condition is necessary. The consent record must be retrievable per principal, per purpose, per version, per timestamp.

Consent Manager

The Consent Manager (DPDP Act section 2(1)(g)) is a person or entity registered with the Board that acts as a single point of contact through which a Data Principal gives, manages, reviews and withdraws consent across Data Fiduciaries. The Consent Manager must be interoperable (so a principal can move between Consent Managers) and must make consent as easy to withdraw as to give. This is a distinctive Indian construct with no clean GDPR/NIST/SOC2 analogue. The 2011 EU "consent dashboard" concept and the GDPR Article 7(3) withdrawal-as-easy-as-to-give principle are the closest external cousins. The notice and consent flow must support Consent Manager interoperation; the policy commits to Consent Manager integration where registered. The Consent Manager registration conditions (Indian entity, minimum net worth, technical and operational conditions) are prescribed in the DPDP Rules 2025.

Significant Data Fiduciary (SDF)

The Significant Data Fiduciary (DPDP Act section 10) is a Data Fiduciary designated by the Central Government on the basis of prescribed thresholds (volume and sensitivity of personal data processed, risk to data principals, impact on sovereignty, integrity and electoral democracy, etc.). An SDF must appoint a DPO based in India accountable to the board; perform a DPIP/DPIA for each new processing activity; perform periodic independent data audits; and conduct algorithmic-AI fairness review where relevant. The SDF overlay is the densest overlap with ISO/IEC 27701:2025 (Clauses 5.3, 6.1.2, 8.2, Annex A.1.2.5).

Data Protection Board of India (DPBI / the Board)

The Board (DPDP Act section 18) is the independent regulatory authority established by the Central Government, the DPDP analogue of a GDPR supervisory authority. The Board adjudicates, imposes penalties up to the Schedule maxima, and is the recipient of the 72-hour breach notification under section 8(6) and Rule 7. The Board is an interested party under Clause 4.2.

Privacy notice (external)

The external privacy notice is the disclosure instrument addressed to PII principals. It is the operational artefact that satisfies DPDP section 5, GDPR Articles 12 to 14, and equivalent provisions worldwide. The notice is not the internal PIMS policy. The notice's content is legally prescribed; the policy's content is management-system prescribed. The two must align, the notice must describe the actual processing the policy authorises.

Documented Information

Documented Information is the ISO term for information the organisation must create, control and maintain to run the management system. Clause 7.5 governs Documented Information generally. The privacy policy and notice are apex artefacts of PIMS Documented Information. Documented Information controls (Clause 7.5.2, creating and updating; Clause 7.5.3, control) require: identification (title, date, author, version, language); format (paper, electronic, audio, machine-readable); review and approval (who signs, when); distribution (who has access); retrieval (how to find it, including the version in force at any past date for consent-reconstruction); retention (how long to keep); disposition (how to dispose of superseded versions). The privacy policy and notice must satisfy each of these, and the auditor will test each.

Applicable privacy requirements

Applicable privacy requirements is the phrase the 5.2 commitment statement uses. It is deliberately broad. It includes: (a) legal and regulatory requirements, DPDP Act, DPDP Rules, IT Act/SPDI Rules, sectoral regulation (RBI, SEBI, IRDAI, TRAI, MeitY), employment law, foreign privacy laws (GDPR, CCPA/CPRA, LGPD, PIPL, PDPA Singapore, etc.); (b) contractual requirements, DPAs, customer privacy commitments, processor schedules, BCR-equivalent undertakings, insurer warranties; (c) self-imposed requirements, voluntary standards (ISO/IEC 27701:2025 itself, ISO/IEC 27001, ISO/IEC 27018 for cloud PII processors, ISO/IEC 29100, ISO/IEC 29134 for DPIA), industry codes, public privacy commitments, certifications, parent-company policies.

Privacy policy vs privacy notice vs ROPA vs DPIA

These four documents are routinely conflated. The distinctions matter for Clause 5.2.

• Privacy policy (internal, Clause 5.2), the apex strategic statement of intentions, principles and commitments. Short (two to five pages). Board-level. Stable (reviewed annually or on event trigger). This is what 5.2 requires internally.
• Privacy notice (external, Clause 5.2 read with DPDP section 5 / GDPR Articles 12 to 14), the disclosure to data principals. Layered (short-form plus long-form), jurisdiction-tailored, in plain language, machine-readable. This is what 5.2 requires externally.
• ROPA, Records of Processing Activities (Clause 8, Annex A.1.2.x, Annex A.2.2.x; GDPR Article 30), the operational inventory of processing activities: purpose, categories of data and principals, recipients, cross-border transfers, retention, security measures. Internal artefact. The notice summarises the ROPA; the policy commits to maintaining it.
• DPIA / DPIP, Data Protection Impact Assessment (Clause 6.1.2 / 8.2, Annex A.1.2.5; GDPR Article 35; DPDP section 10 for SDFs), the risk assessment for high-risk processing activities. Internal artefact. The policy commits to performing DPIAs where required; the notice does not generally disclose DPIA results but may disclose their existence for sensitive processing.

A common 5.2 failure is to substitute the ROPA for the notice, or the website notice for the internal policy. Both substitutions fail the audit.

Relationship to Other Clauses and Frameworks

Relationship to other ISO/IEC 27701:2025 clauses

Clause 5.2 is the apex document clause of the PIMS. Its relationships to the other clauses are the spine of the system.

• Clause 4.1 (Context). The privacy policy must be appropriate to the organisation's purpose, which means the policy content must reflect the internal and external issues (Clause 4.1 outputs) the organisation identified, including its role as PII controller and/or processor. A policy that does not reference context is not fit-for-purpose.
• Clause 4.2 (Interested parties). The policy's commitments must reflect the needs and expectations of interested parties, PII principals, regulators (DPBI, RBI, SEBI, IRDAI, CERT-In, EDPB national DPAs), customers, processors, sub-processors, employees, and the policy must be available to relevant interested parties. The interested-party register (Clause 4.2 output) is therefore an input to policy authoring and a constraint on policy availability and notice content.
• Clause 4.3 (Scope of the PIMS). The policy must align to the PIMS scope (Clause 4.3 output). The scope defines what the policy covers, which parts of the organisation, which products, which services, which processing activities, which geographies, which controller/processor roles.
• Clause 4.4 (PIMS). The policy is the apex instrument of the PIMS the organisation establishes, implements, maintains, and continually improves.
• Clause 5.1 (Leadership). Top management establishes the policy. The executive sponsor signs it. Without 5.1 sponsorship, the policy is unsigned.
• Clause 5.3 (Roles, Responsibilities, Authorities). The policy is operationalised by the roles assigned under 5.3, the DPO/Privacy Lead, the PIMS Steering Committee, the data owners, the processor-relationship owners, the internal audit. For SDFs under DPDP section 10, the DPO is a section 10 statutory role based in India and accountable to the board, the policy is the natural place to declare the DPO role and reporting line.
• Clause 6.1 (Risks and opportunities). The policy's risk-based commitments reflect the privacy risk assessment (Clause 6.1.2) and treatment (Clause 6.1.3), including the SoA's applicability decisions on Annex A.1 / A.2 / A.3 controls.
• Clause 6.2 (Privacy objectives). The policy provides the framework for setting and reviewing privacy objectives. The objectives register (6.2 output) is therefore downstream of, and consistent with, the policy.
• Clause 6.3 (Change). Planned PIMS changes (6.3) may trigger policy review, a new processing activity, a new product, a new sub-processor, a new geography.
• Clause 7.1 (Resources). The policy's commitments imply the resourcing commitment (7.1), including the DPO resourcing and the consent-management infrastructure.
• Clause 7.2 (Competence). The policy is operationalised by competent people (7.2), the DPO, the privacy analysts, the engineers implementing privacy by design, the legal team.
• Clause 7.3 (Awareness). The 5.2 communication commitment is operationalised by the 7.3 awareness programme, staff awareness of the policy, of their role, of consequences of non-conformance.
• Clause 7.4 (Communication). 5.2 policy communication is a specific instance of the broader 7.4 communication discipline (what, when, to whom, how, by whom).
• Clause 7.5 (Documented Information). The 5.2 availability commitment is operationalised by the 7.5 Documented Information controls (version history, approval, distribution, retrieval including version-at-consent reconstruction, retention, disposition).
• Clause 8.1 (Operational planning and control). The policy authorises and binds the operational processes.
• Clause 8.2 (Privacy risk assessment). The detailed privacy risk assessment feeds back into the policy's risk commitments and the notice's accuracy. For SDFs, the DPIP register is the operational evidence the policy commitment points to.
• Clause 8.3 (Privacy risk treatment). Treatment decisions, including the SoA, must align with the policy.
• Annex A.1 (PII controllers). The controller controls, A.1.2.x (conditions for collection and processing, including the purpose, lawful-basis and consent controls A.1.2.2 to A.1.2.5 and the privacy-impact-assessment control A.1.2.6), A.1.3.x (obligations to PII principals, rights handling), A.1.4.x (privacy by design and default), A.1.5.x (sharing, transfer and disclosure), are the operational expression of the policy's controller commitments.
• Annex A.2 (PII processors). The processor controls, A.2.2.x (processor conditions, including the infringing-instruction control A.2.2.5 and the records control A.2.2.7), A.2.5.x (sharing, transfer and disclosure), are the operational expression of the policy's processor commitments.
• Annex A.3 (Information security controls, both controllers and processors, aligned to ISO/IEC 27002:2022). A.3.3 policies for information security; A.3.21 secure disposal; A.3.22 user endpoint devices; A.3.23 secure authentication; A.3.24 information backup; A.3.25 logging; A.3.26 cryptography; A.3.27 secure development; A.3.30 outsourced development. The privacy policy's commitment to reasonable security safeguards (DPDP section 8(5); GDPR Article 32) is operationalised through A.3.
• Clause 9.1 (Monitoring and measurement). Policy and notice performance is monitored and measured, acknowledgement rates, DSAR turnaround, grievance resolution, breach-detection-to-notification, consent-revocation latency.
• Clause 9.2 (Internal audit). The internal audit programme tests policy and notice conformance every cycle.
• Clause 9.3 (Management review). The management review agenda explicitly includes policy review for continuing suitability, adequacy and effectiveness.
• Clauses 10.2 and 10.1 (Improvement). Corrective action and continual improvement close against policy commitments.

Relationship to other ISO management-system standards

ISO/IEC 27701:2025 uses the Harmonized Structure shared by ISO/IEC 27001:2022, ISO 22301:2019, ISO 9001:2015, ISO/IEC 42001:2023, ISO/IEC 20000-1:2018 and others. Clause 5.2 in each of these standards is the policy clause. An organisation running more than one of these systems has an integration opportunity: a single integrated policy or a tightly-aligned policy set can satisfy all of them.

• ISO/IEC 27001:2022 Clause 5.2, the ISMS policy. Structurally identical to ISO/IEC 27701:2025 Clause 5.2. Common Indian integration: an "Information Security and Privacy Policy" with sub-sections for ISMS-relevant and PIMS-relevant commitments. ISO/IEC 27002:2022 control 5.34 (Privacy and protection of PII) is the only PII-specific control in 27002, it is the bridge between the ISMS and the PIMS.
• ISO 22301:2019 Clause 5.2, the BCMS (business continuity) policy. Structurally identical. The intersection with the PIMS is the DPDP section 8(5) availability duty, the BC policy commits to continuity of processing, the privacy policy commits to availability of personal data; the two reinforce each other.
• ISO/IEC 42001:2023 Clause 5.2, the AIMS (AI management system) policy. Structurally identical. The intersection with the PIMS is the DPDP section 10 SDF algorithmic-AI fairness review, the privacy policy commits to AI fairness, the AI policy commits to AI governance; the two reinforce each other. A leading global certification body's 2025 framing of "managing personal data within AI and digital ecosystems" makes this intersection explicit.
• ISO 9001:2015 Clause 5.2, the QMS policy. Indian manufacturers running ISO 9001 commonly extend the quality policy into a combined Quality and Privacy policy where the data dimension is light.
• ISO/IEC 20000-1:2018 Clause 5.2, the SMS (service management) policy. Integration opportunity for IT-service firms.

The full multi-framework mapping (Clause 5.2 row)

The detailed mapping with marquee IDs and dates is in Section 16. The headline cross-framework anchors for Clause 5.2 are:

• ISO/IEC 27701:2025 Clause 5.2, the requirement itself.
• Annex B (normative) section B.5.2, the implementation guidance auditors test against.
• ISO/IEC 27001:2022 Clause 5.2 and Clause 5.34, the ISMS policy and the PII-protection control.
• ISO/IEC 27002:2022 control 5.34, the only PII-specific control in 27002; the privacy bridge.
• ISO/IEC 29100:2011, the 11 privacy principles, the conceptual ancestor of the policy's privacy commitments.
• ISO/IEC 29134:2017, the DPIA guidance that operationalises the policy's DPIP commitment.
• ISO/IEC 27018:2019, the code of practice for PII protection in public clouds acting as PII processor (mapped in 27701:2025 Annex E).
• GDPR Article 5 (principles), Article 6 (lawful bases), Article 7 (consent conditions), Articles 12 to 14 (transparency and notice), Article 24 (controller responsibility), Article 25 (data protection by design and by default), the EU privacy-policy and notice substantive standards.
• NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020), Govern-P and Communicate-P functions.
• SOC 2 (AICPA TSC 2017, with 2022 points of focus), P1.0 (Notice and communication of objectives), P2.0 (Choice and consent), P8.0 (Monitoring and enforcement).
• DPDP Act 2023 (Act 22 of 2023), sections 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 18, 33 + Schedule.
• DPDP Rules 2025 (notified 13 November 2025), Rule 7 (breach), Rule 7, the section 9 children's rules, the section 10 SDF rules.
• IT Act 2000 sections 43A, 72A and SPDI Rules 2011, the legacy baseline.
• RBI Master Direction Digital Lending (2 September 2022), the borrower notice content standard for REs.
• RBI Tokenisation circular (22 September 2021), consent for tokenisation.
• SEBI KRA Regulations 2011 as amended 2024, KYC data handling.
• SEBI CSCRF (20 August 2024), incident reporting within 6 hours.
• IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023), policyholder-data handling.
• CERT-In Directions 20(3)/2022-CERT-In (28 April 2022), 6-hour incident report.
• Companies Act 2013 section 134(3)(n), risk-management statement.
• SEBI LODR Regulation 21, Risk Management Committee mandate includes privacy.

Detailed Implementation Guidance, The Eight Policy Moves

This section sets out the eight policy moves a growing company in India must execute to satisfy Clause 5.2 in a form that survives both an IAF-accredited certification audit under the new ISO/IEC 27706:2025 scheme and a post-incident regulatory inspection by the Data Protection Board of India. Each move has an input, an output, an owner, an indicative effort, and a list of common failure modes. Treat them as a sequence for the first cycle and as a parallel cadence thereafter.

Move 1, Author the dual-natured privacy policy: internal PIMS policy + external privacy notice

Input. Clause 4.1 context register, Clause 4.2 interested-party register, Clause 4.3 scope statement, the controller/processor role declaration, the privacy risk assessment (Clause 6.1.2) outputs, the ROPA (Clause 8 / Annex A.1.2.x), the DPIA register for high-risk processing (Annex A.1.2.5), the regulatory landscape (Section 3.2 of this guide), and the executive sponsor's strategic narrative for the year.

Output. Two paired artefacts.

1. The internal PIMS policy with eight sections in the following order.

a. Title, version, approval. Policy title (for example, "Privacy Policy of [Organisation Name], Internal PIMS Policy"), version number, issue date, next review date, approved-by (executive sponsor signature, name, role, date; DPO/Privacy Lead co-signature where applicable), document owner (DPO/Privacy Lead), classification (typically Internal / Confidential, never Public-on-Internet for the internal policy).

b. Purpose and scope. Two to three paragraphs stating why the policy exists (to establish, maintain, and continually improve a PIMS that enables the organisation to process personal data lawfully, fairly and transparently and to honour data principal rights), what it covers (the Clause 4.3 scope, the role declaration, controller / processor / both), and what it does not cover (typically operational detail, which lives in subordinate instruments). Include the fit-to-purpose paragraph, a short statement connecting the policy to the organisation's purpose, context, role declaration, and the principal categories of PII processed. This is the paragraph the auditor will quote back to the DPO.

c. The four commitment statements in plain language, in numbered form: (i) to meeting applicable privacy requirements, with the regulatory landscape named (DPDP Act + Rules, IT Act/SPDI as relevant, RBI/SEBI/IRDAI/CERT-In as applicable, GDPR/CCPA/CPRA for overseas principals); (ii) to providing the framework that drives how privacy objectives are defined and revisited (reference the Clause 6.2 objectives register); (iii) to ongoing PIMS improvement; (iv) the privacy-specific additional commitments (lawful and fair processing; purpose limitation; data minimisation; accuracy; storage limitation; integrity, confidentiality and availability; accountability; privacy by design and default; lawful cross-border transfer; data principal rights and grievance redressal; protection of children's and vulnerable persons' data; breach notification capability).

d. PIMS framework. A short paragraph or table identifying the PIMS scope (Clause 4.3), the governance structure (executive sponsor, DPO/Privacy Lead, PIMS Steering Committee, data owners, see Clauses 5.1 and 5.3), and the PIMS processes at a high level (Plan-Do-Check-Act cycle).

e. Privacy objectives framework. A statement that the organisation will set, review and revise privacy objectives (Clause 6.2) at defined intervals, against defined dimensions (consent-record completeness, DSAR turnaround, grievance resolution, breach-detection-to-notification, DPIA coverage, training completion, third-party privacy assessment scores, retention-deletion compliance), cascaded to process owners, and reported to the Risk Management Committee or board.

f. Communication and availability. A statement that the internal policy will be communicated to all persons doing work under the organisation's control (via induction, awareness programme, intranet publication), to relevant contractors and processors (via the vendor portal and contract schedules), and to relevant interested parties on request (regulators, customers, insurers). A statement that the external privacy notice will be published on the public website, in-product, in the consent flow, and via the Consent Manager (where registered), in plain language and accessible formats. A statement that the policy and notice will be available as Documented Information (Clause 7.5), in accessible formats, on the intranet and on the public website respectively, in the dominant principal languages (with layered and child-readable versions where applicable).

g. Breach notification commitment. A specific statement of the dual-clock commitment: to maintain the capability to intimate the Data Protection Board of India without delay on becoming aware of a personal data breach and file the detailed report within 72 hours (DPDP section 8(6) + Rule 7), to notify affected Data Principals without undue delay, and to notify CERT-In within 6 hours of noticing a prescribed cyber incident (CERT-In Directions 20(3)/2022-CERT-In). For BFSI: add the RBI six-hour clock and the SEBI RE 6-hour clock as applicable.

h. Review and maintenance. A statement that the policy and notice will be reviewed by top management at the management review (Clause 9.3) at minimum annually, and on event trigger (new processing activity, regulatory change, breach, SDF designation, M&A, new product or geography, audit nonconformity, scope change, sponsor or DPO change). The version history is appended for both artefacts.

2. The external privacy notice with twelve content elements (mapped to DPDP section 5 and GDPR Articles 12 to 14).

a. Identity and contact of the Data Fiduciary (legal name, registered address, contact email/phone, website). Where the Data Fiduciary is part of a group, the specific entity that controls the processing.

b. DPO / Grievance Officer contact (name or role, email, phone, postal address). For SDFs, the DPO is a statutory role; the notice must name the role and contact channel.

c. Categories of personal data collected (identifiers, contact data, financial data, location, online identifiers, biometric, health, children's data, sensitive categories). Distinguish between data collected directly from the principal and data collected from other sources.

d. Purposes of processing (specific, explicit and legitimate, not "improving our services" boilerplate). Map purposes to categories.

e. Lawful basis or DPDP ground (consent under section 6; legitimate use under section 7; specify which). For GDPR purposes, the Article 6 lawful basis and the Article 9 condition where special categories apply.

f. Recipients or categories of recipients (processors, sub-processors, group companies, partners, regulators, courts). For processors, name them or describe the categories clearly enough for the principal to understand.

g. Cross-border transfers, the countries or categories of countries of transfer, and the transfer mechanism (DPDP negative-list screen; GDPR adequacy / SCCs / BCRs / derogations). The principal must know where their data goes.

h. Retention period or criteria (how long the data is kept, or the criteria used to determine the period, for example, the duration of the customer relationship plus the limitation period under the Indian Contract Act or the Limitation Act).

i. Data principal rights, access (section 11); correction, completion, updating, erasure (section 12); grievance redressal (section 13); nomination (section 14); and, for GDPR, the rights under Articles 15 to 22 (access, rectification, erasure, restriction, portability, objection, automated decision-making).

j. How to exercise rights, the contact channel, the form (online form, email, letter), the response period (per the DPDP Rules for grievances), and the right to escalate to the Data Protection Board of India.

k. Right to withdraw consent and the consequence of withdrawal (consent must be as easy to withdraw as to give; withdrawal does not affect the lawfulness of processing before withdrawal). The Consent Manager flow where registered.

l. Automated decision-making and profiling, whether the processing involves automated decisions with legal or similarly significant effects, and if so, the logic involved (DPDP section 10 SDF algorithmic fairness; GDPR Article 22). For most growing companies this is "no"; for SaaS using AI for credit scoring, hiring, content moderation, or marketing, this requires substantive disclosure.

The notice should also include: the existence of the policy commitment to privacy by design; the existence of the breach-notification commitment; and any additional disclosures required by sectoral regulation (RBI Digital Lending borrower rights; IRDAI policyholder rights; SEBI investor rights).

Owner. DPO/Privacy Lead drafts both artefacts; executive sponsor signs the internal policy; PIMS Steering Committee endorses; Legal and Compliance review for regulatory fit; Risk Management Committee / board receives (per Companies Act section 134(3)(n) / SEBI LODR Reg. 21 / DPDP section 10 SDF as applicable).

Indicative effort. Two-day workshop with the DPO, the executive sponsor, Legal, Product and a representative from Compliance, plus 5 to 10 days of DPO drafting time, plus 1 to 2 days of sponsor iteration. First cycle: 4 to 6 person-weeks.

Common failure modes. (a) Skipping the fit-to-purpose paragraph, the policy reads as a template and fails the 5.2 "appropriate to purpose" test. (b) Padding the internal policy with notice content or vice versa, the artefacts blur. (c) Naming the regulatory landscape generically ("we comply with applicable privacy laws"), fails the applicable-requirements commitment test. (d) Omitting the breach-notification commitment or naming only one of the two clocks, fails the DPDP section 8(6) evidence test. (e) Notice does not match the ROPA, fails the auditor's ROPA-to-notice trace test (Move 5 below). (f) Signing the internal policy without dating it or setting the next review date, fails the 7.5 Documented Information test. (g) Authoring the notice in English only for a multilingual principal population, fails the DPDP Rules 2025 plain-language requirement in spirit. (h) Using a single bundled consent for multiple purposes, fails the DPDP section 6 "specific" and "unconditional" consent test. (i) Omitting the automated-decision-making disclosure where AI is used, fails GDPR Article 22 and DPDP section 10 SDF algorithmic-fairness evidence.

Move 2, Authorise the policy and notice through the correct governance chain

Input. The drafted artefacts from Move 1; the governance-chain matrix for the organisation (see toolkit doc 16 for role definitions).

Output. An internal PIMS policy signed by the executive sponsor (CEO/MD or COO typically) and co-signed by the DPO/Privacy Lead, endorsed by the PIMS Steering Committee, reviewed by Legal and Compliance, and, for Indian SDFs, BFSI, listed entities and insurers, approved or noted by the board or board Risk Management Committee. The external privacy notice approved by the DPO and Legal for publication. The signature block names the sponsor, the role, the date and the version. For multi-entity groups, the parent policy is signed by the group executive sponsor and entity-level policies are signed by entity-level MDs; entity-level notices are localised and approved by the entity DPO.

Owner. Executive sponsor signs; DPO/Privacy Lead prepares the signature pack; Company Secretary schedules board/RMC noting for entities that require it.

Indicative effort. Two to four weeks of calendar time (the bottleneck is the board/RMC cycle, not the drafting).

Common failure modes. (a) Signature by the DPO alone, fails the 5.1 ownership test. (b) Board approval claimed but no minute reference captured, fails the audit traceability test. (c) Approval cycle missed (notice published before internal approval is complete), fails the 7.5 version-control test. (d) Wrong governance chain (CEO signature for an SDF where the DPO accountability-to-board under DPDP section 10 has not been formally stood up), fails the regulatory overlay test. (e) Notice approved by Marketing without Legal or DPO sign-off, fails the regulatory-substantiation test.

Move 3, Build the layered notice, the policy-on-a-page, and the multilingual summaries

Input. The signed policy and notice; the dominant principal and workforce languages identified by HR and by Product (typically English plus Hindi plus one regional language for pan-Indian operations, plus the principal's first language for overseas operations).

Output. A set of communication artefacts.

1. The layered external notice, a short-form (typically one screen, 200 to 400 words) for the website footer and the in-product consent surface, linking to the long-form notice. The short-form is what most principals read; the long-form is what the auditor and the regulator test.

2. The just-in-time notices, short contextual disclosures at the point of collection (form field hints, pre-consent microcopy, cookie banners with per-purpose granularity, in-app permission explanations).

3. The child-readable notice, where children's data is processed under DPDP section 9, a notice in a form the parent or guardian can understand, and, where appropriate, a child-readable layer (age-appropriate language, simple icons, audio versions).

4. The policy-on-a-page for the internal policy, a one-page summary containing the four commitment statements in plain language, the scope, the governance bodies, the reporting clocks staff should know, the policy's location on the intranet, and the sponsor's and DPO's names. Translated into the dominant workplace languages. Audio versions for accessibility. A poster version for physical locations.

5. The processor-facing privacy commitment, for organisations acting as processors, a separate one-to-three-page commitment addressed to controller customers, summarising the processor's privacy posture, the DPA terms, the sub-processor list, the breach SLA, and the cross-border handling.

Owner. DPO/Privacy Lead drafts; Communications and HR own translation and design for the policy-on-a-page; Product owns the layered notice and just-in-time notices; Legal owns regulatory substantiation across all artefacts.

Common failure modes. (a) No layered notice, the principal sees a 5,000-word notice and clicks "accept" without reading; the auditor tests comprehension and finds none. (b) Translation done by machine without human review, meaning errors undermine credibility and may breach the DPDP Rules' plain-language requirement. (c) No child-readable layer where children's data is processed, fails the DPDP section 9 / DPDP Rules requirement. (d) No accessible versions for visually impaired principals, fails the accessibility and the "available to relevant interested parties" commitment for principals with disabilities, and may breach the Rights of Persons with Disabilities Act 2016. (e) Just-in-time notices not aligned with the long-form notice, inconsistent disclosure across surfaces. (f) Processor-facing commitment not refreshed when sub-processor list changes, fails the A.2.5.x sub-processor change-notification control.

Move 4, Publish in the right locations

Input. The signed internal policy, the signed external notice, the layered notice, the multilingual summaries, the policy-on-a-page, the hosting infrastructure.

Output. Publication in five locations.

1. Corporate intranet, internal PIMS policy plus policy-on-a-page plus multilingual summaries plus acknowledgement form. Searchable. Linked from the home page or the compliance/policies section. Available to all staff with intranet access.

2. Public website, external privacy notice published in the footer of every page that collects personal data or that principals are likely to visit (homepage, account-creation pages, contact pages, checkout pages). The short-form layered notice is the click-through surface; the long-form notice is the destination. Version-controlled and date-stamped per Documented Information requirements.

3. In-product and in-consent-flow surfaces, the layered notice and the just-in-time notices embedded in the product or app. The consent collection point displays the notice elements the principal needs to make an informed decision at the moment of consent. The Consent Manager API surfaces the notice and the consent scope machine-readably.

4. Vendor portal, the internal policy (or an extracted "processor-relevant" version) published to all contracted processors and sub-processors, with acknowledgement required at processor onboarding and renewal. Specifically addresses the processor-oversight commitment.

5. Board archive and customer trust portal, for the board/RMC, the internal policy sits in the management review pack (Clause 9.3) and the board archive. For B2B SaaS, BFSI, healthcare, ITeS, typically a redacted version of the internal policy plus the full external notice and the processor-facing privacy commitment is published on a customer trust portal. This is increasingly a sales asset, Indian customers and overseas customers ask for it in security questionnaires.

Owner. IT (intranet); Marketing/Digital (public website and product surfaces); Product (in-product surfaces, Consent Manager API); Procurement/Vendor Management (vendor portal); Sales/Customer Success/Trust (customer trust portal); Company Secretary (board archive).

Indicative effort. Two to three weeks of IT/Marketing/Product/Procurement time to publish, plus ongoing maintenance.

Common failure modes. (a) Intranet publication only for the internal policy, fails the interested-party availability test. (b) Website publication only for the notice, fails the in-product and Consent Manager availability test. (c) No acknowledgement mechanism on the intranet, the auditor cannot evidence that staff have read the internal policy. (d) Customer-facing version is generic marketing, fails the substantive-availability test. (e) No version-sync across the locations, the intranet has version 4 but the website has version 3, an obvious 7.5 finding that also breaks the consent-version-reconstruction capability.

Move 5, Run the communication programme

Input. The published policy and notice; the awareness programme plan (Clause 7.3); the ROPA (for the notice-to-ROPA accuracy check).

Output. A five-strand communication programme.

1. New-joiner induction, every new joiner receives the internal policy-on-a-page and the full internal policy in their induction pack, acknowledges it, and is briefed by HR or the DPO in the first 30 days.

2. Annual awareness refresh, every staff member acknowledges the internal policy annually; the DPO runs a 30 to 45-minute refresh session covering any policy and notice changes, the reporting clocks, and the year's privacy incidents and learnings.

3. Process-owner and engineer briefing, process owners, product managers and engineers receive a deeper briefing on how the policy binds their processing activity, their DPIA obligations, their privacy-by-design responsibilities, their data-handling duties, and the consent-flow design they own. This is where privacy by design is operationalised (Annex A.1.4 / A.2.4).

4. Executive sponsor briefing, the executive sponsor is briefed annually on the internal policy, the notice, the PIMS performance, the regulatory landscape changes, and the management review agenda. The sponsor must be able to articulate the policy and answer auditor questions.

5. Board / RMC briefing, at the management review (Clause 9.3), the executive sponsor and the DPO present the policy, the notice, the PIMS performance, and any proposed changes. The board / RMC notes and approves.

6. Principal awareness, for the external notice, the communication strand is the notice's own visibility: prominent placement on the website, in-product, and in the consent flow; notification to principals on material notice changes (an email or in-app notification pointing to the changes); annual reminders where retention extends beyond active engagement.

Owner. DPO/Privacy Lead and HR co-own the internal awareness programme; Marketing/Digital and Product co-own the principal-facing notice visibility; executive sponsor and Company Secretary own the board briefing.

Indicative effort. Ongoing, typically 1 to 2 person-weeks per quarter for the DPO; 0.5 to 1 person-week per year for the executive sponsor.

Common failure modes. (a) No new-joiner induction component, staff onboarded in the gap between annual refreshes are missed. (b) No acknowledgement mechanism, the auditor cannot evidence communication. (c) Sponsor not briefed, the sponsor fails the auditor interview. (d) Annual refresh is a click-through e-learning module with no comprehension check, staff click and forget. (e) Process-owner briefing absent, process owners cannot connect the policy to their processing activity. (f) Principal notification on notice change absent, the principal's consent is deemed to be against the version in force when consent was given, but if the notice changed materially and the principal was not notified, the consent may be invalid for the new processing.

Move 6, Capture and maintain the acknowledgement and consent-and-notice records

Input. The published policy and notice; the awareness programme; the HR system; the consent-management platform or Consent Manager.

Output. Two records.

1. Staff acknowledgement record, per staff member: name, role, location, language version acknowledged, date, version acknowledged, manager. Updated on every policy version change and on every annual refresh. Target: 95 percent-plus acknowledgement at any given point (100 percent for executives, process owners and engineers with access to PII). The acknowledgement record is the auditor's primary evidence that the communication commitment has been met.

2. Data principal consent-and-notice record, per principal: identity (pseudonymised), the version of the notice in force at the time of consent (retrievable per Documented Information Clause 7.5), the timestamp, the scope of consent (purposes, categories of data, recipients, cross-border destinations), the Consent Manager reference if applicable, any subsequent withdrawal or modification. This record is the operational evidence for the consent controls (Annex A.1.2.3 / A.1.2.4) and the rights-handling controls (A.1.3.x). It is also the evidence the Data Protection Board will request in any section 8(6) breach or section 13 grievance proceeding.

Owner. HR (staff acknowledgement system of record); DPO/Privacy Lead (completeness monitoring); Product/IT (consent-management platform).

Indicative effort. One-time setup of 2 to 4 person-weeks for the staff record; one-time setup of 4 to 12 person-weeks for the consent-and-notice record (depending on whether a Consent Manager is integrated); ongoing maintenance of 1 to 2 person-days per month.

Common failure modes. (a) No acknowledgement mechanism, fails the 7.3 awareness test. (b) Paper-based acknowledgements that are not digitised, fails the audit traceability test. (c) No target/threshold, the DPO cannot tell whether 95 percent or 50 percent of staff have acknowledged. (d) Acknowledgements not refreshed on policy version change, staff are tracked against an obsolete version. (e) Consent record does not capture the version of the notice in force at the time of consent, fails the consent-reconstruction test (the auditor will ask: show me the notice that principal X saw when they consented on date Y). (f) Consent scope bundled across multiple purposes, fails the DPDP section 6 "specific" test. (g) Consent withdrawal latency exceeds the "as easy to withdraw as to give" standard, fails DPDP section 6 / GDPR Article 7(3).

Move 7, Define the review cadence and the event triggers

Input. The signed policy and notice; the PIMS event-trigger taxonomy; the regulatory horizon-scanning feed.

Output. A documented review schedule with two components.

1. Calendar review. Annual review at the management review (Clause 9.3). The DPO prepares the review pack, the executive sponsor approves any changes, the board/RMC notes. For most Indian growing companies, the review sits on the same cadence as the financial-year audit cycle.

2. Event-trigger review. A defined list of triggers that require interim policy or notice review: (a) new processing activity or material change to an existing activity; (b) regulatory change (DPDP Rules amendment, new RBI/SEBI/IRDAI/CERT-In instrument, GDPR amendment, new overseas privacy law); (c) personal data breach or near-miss (any activation of the breach playbook); (d) SDF designation or material change in SDF thresholds; (e) M&A, divestiture, or major organisational change; (f) new product, service, geography or processor; (g) audit nonconformity (internal or external) on the policy or notice; (h) scope change (Clause 4.3); (i) sponsor or DPO change (Clause 5.1 / 5.3 turnover); (j) DPIA revealing a material privacy risk; (k) significant change in the principal population (for example, beginning to process children's data); (l) Consent Manager registration or change in Consent Manager.

Owner. DPO maintains the schedule; executive sponsor approves event-trigger reviews.

Indicative effort. Calendar review: 1 to 2 person-weeks of DPO preparation, 1 to 2 days of sponsor iteration. Event-trigger reviews: variable; typically 0.5 to 1 person-week each.

Common failure modes. (a) Calendar review only, no event triggers, the policy and notice go stale between annual reviews. (b) Event triggers defined but never invoked, the DPO is not monitoring for triggers. (c) Event-trigger review without version update, the policy is reviewed but the version history does not reflect it (7.5 finding). (d) No documented review schedule, the auditor cannot find when the next review is due. (e) Regulatory horizon-scanning absent, the DPO is not watching for DPDP Rules amendments or new overseas instruments.

Move 8, Wire the policy into the management review, the audit programme, and Documented Information

Input. The published policy and notice; the management review agenda (Clause 9.3); the internal audit programme (Clause 9.2); the Documented Information system (Clause 7.5).

Output. Three integration points.

1. Management review agenda. The management review (Clause 9.3) explicitly includes policy and notice review, continuing suitability, adequacy and effectiveness. The agenda item is non-negotiable; the DPO prepares a short paper (the policy and notice, the year's performance, the proposed changes, the regulatory horizon) and the sponsor presents it. The review minute records the decision (confirmed, amended, re-issued).

2. Internal audit programme. The internal audit (Clause 9.2) tests policy and notice conformance every cycle, usually annually. The audit checklist includes: policy authorisation (signed, dated, version, co-signed by DPO); notice authorisation; fit-to-purpose (alignment with 4.1 / 4.2 / 4.3 / role declaration); the four commitments present and substantive; the twelve notice elements present and accurate; notice-to-ROPA accuracy; staff acknowledgement record; principal consent-and-notice record; review cadence (last review, next review); downstream traceability (objectives, ROPA, DPIA, breach playbook, processor DPAs consistent with the policy).

3. Documented Information control. Per Clause 7.5, the policy and notice are registered in the document control system with all metadata (title, version, date, author, approver, distribution, retention, disposition, language). Superseded versions are archived and retrievable, for the notice, this includes the version-reconstruction capability that supports the consent record. The auditor will ask to see the previous version of both artefacts.

Owner. DPO/Privacy Lead; Internal Audit; Company Secretary.

Indicative effort. Annual cycle, 1 to 2 person-weeks of DPO preparation, 1 to 2 person-weeks of Internal Audit.

Common failure modes. (a) Policy and notice not on the management review agenda, fails the 9.3 test. (b) Internal audit does not test notice-to-ROPA accuracy, fails the 9.2 test on the marquee audit move. (c) Documented Information metadata incomplete, fails the 7.5 test. (d) Superseded versions discarded, fails the 7.5 retention test and the consent-version-reconstruction test.

The eight moves in aggregate

The eight moves together convert a "compliance-only" policy-and-notice set into a "living-policy" PIMS. The first cycle (Moves 1 to 8) takes 10 to 16 weeks for a typical Indian growing company; the steady-state cycle (Moves 4 to 8 in recurrence plus Moves 1 to 3 on event trigger) is a continuous management discipline that produces the policy-and-notice evidence base the certification auditor, the Data Protection Board and overseas regulators all want to see. The Singahi toolkit for Clause 5.2 contains 17 ready-to-customise documents that operationalise each move.

Tools, Technologies, and Solutions

Clause 5.2 is a document-heavy, workflow-heavy and consent-data-heavy clause. Tooling falls into six categories. The tooling discussion below uses category-level descriptors only; no vendor is named or endorsed. All third-party pricing is indicative and must be verified against candidate providers' official domains at the time of selection.

Document management and policy hosting

The baseline tool is a document management system (DMS) or content management system (CMS) that satisfies the Clause 7.5 Documented Information controls. Required capabilities: version history (with the ability to retrieve the version in force at any past date, critical for the notice because of the consent-version-reconstruction requirement), approval workflow, distribution control, full-text search, retention policy, disposition, access logging, multi-format hosting (HTML, PDF, audio, machine-readable JSON for the Consent Manager API). Most growing companies already have one of these; the question is configuration, not procurement.

For growing companies that have outgrown a basic DMS, dedicated policy management software (a category-level descriptor; multiple Indian and global vendors serve this) adds policy-specific features: acknowledgement tracking, e-signature, multilingual hosting, policy-on-a-page rendering, policy expiry alerts, attestation reporting.

Consent management platforms vs the DPDP Consent Manager

This is the marquee tooling distinction in the Indian market and the place where most category-level advice fails.

A consent management platform (CMP) is the cookie-banner / consent-collection software used on websites and in apps. It is a familiar category with many global and Indian vendors. Required capabilities: granular per-purpose consent, consent-record storage, withdrawal flow, jurisdiction-aware behaviour (GDPR versus CCPA versus DPDP), audit log.

The DPDP Consent Manager is a fundamentally different construct. Under DPDP Act 2023 section 2(1)(g), a Consent Manager is a person or entity registered with the Data Protection Board of India that acts as a single point of contact through which a Data Principal gives, manages, reviews and withdraws consent across multiple Data Fiduciaries. The Consent Manager must be interoperable, must support consent withdrawal as easily as consent is given, and must meet the registration conditions prescribed in the DPDP Rules 2025 (Indian entity, minimum net worth, technical and operational conditions). A CMP is software you buy and run; a Consent Manager is a registered intermediary you integrate with via API.

For most growing companies, the immediate need is a CMP that supports DPDP-compliant consent records (free, specific, informed, unconditional, unambiguous, clear affirmative action; per-purpose granularity; withdrawal-as-easy-as-to-give; version-controlled notice). As the Consent Manager ecosystem matures through 2026 and 2027 (the Consent Manager registration conditions and the first Consent Manager registrations are expected in this window), the CMP should be Consent-Manager-API-ready so that principals who choose to use a Consent Manager can move their consent dashboard there. This is a vendor-selection question, when procuring a CMP, ask whether the vendor supports the emerging Consent Manager API specification; if not, plan for a migration.

Privacy management platforms / enterprise privacy software

For Mid-market (250 to 2,000) and enterprise, dedicated enterprise privacy platforms (a category-level descriptor) combine ROPA management, DPIA workflows, DSAR/data-principal-rights request handling, consent vaulting, processor/sub-processor management with DPA clause libraries, cross-border transfer tracking, breach incident response, website-notice hosting, cookie-banner management, and policy/notice workflow. The Indian market is served by global privacy-platform vendors with substantial Indian delivery footprints, by global SaaS privacy vendors selling through partner networks, and by India-HQ privacy/GRC vendors.

Pricing is per-fulfiller-user (DPO, privacy analysts, legal, processor-relationship managers); data-principal-facing surfaces (notice, DSAR portal, consent vault) are typically priced by record volume or by active-principal count. Implementation is typically 16 to 40 weeks depending on scope and integration complexity.

The selection question for a Clause 5.2 buyer is whether the platform supports: the dual-natured policy-and-notice model (internal policy plus layered external notice); multilingual and accessible hosting; notice-version-reconstruction tied to the consent record; Consent Manager API readiness; DSAR workflow with the DPDP-section-11-to-14 rights set; sub-processor change notification; cross-border transfer tracking with negative-list screen for DPDP; breach playbook with the dual-clock CERT-In 6-hour and DPDP 72-hour countdowns.

GRC platforms with PIMS modules

For organisations running multiple management systems (27001 + 27701 + 22301 + 42001), integrated GRC platforms with PIMS modules host the privacy policy alongside the ISMS policy, the BCMS policy, the AIMS policy, the ROPA, the risk register, the SoA, the audits and the corrective-action log, providing end-to-end traceability across the integrated management system.

Awareness and training platforms

For the communication programme (Move 5), awareness and training platforms with policy-acknowledgement modules are the standard Indian stack. Required capabilities: assign policy reading by user group, capture e-signature acknowledgements, track completion, support multilingual content, automate annual refresh, generate audit reports, integrate with the HR system, deliver privacy-specific training (DPDP awareness, consent handling, DSAR intake, breach reporting).

Translation, accessibility, and content design tools

For Move 3 (layered notice, policy-on-a-page, multilingual summaries), the tool stack is content design plus translation plus accessibility. Content design tools (Canva, Adobe Express, Figma, Microsoft PowerPoint) produce the layered notice and the policy-on-a-page. Machine translation alone is not adequate for notice content, meaning errors and tone-deaf translations undermine credibility and may breach the DPDP Rules plain-language requirement. Accessibility tooling (screen-reader compatibility, audio versions, plain-language validators) is required to meet the availability commitment for principals and staff with disabilities.

Indicative cost bands for the Clause 5.2 tool stack

These bands are indicative. Actual costs depend on existing stack, integration complexity, number of languages, number of fulfilment users, principal-record volume, and vendor selection. The Singahi advisory team can assist with vendor-neutral selection tailored to the organisation's stack and scale.

Policy and Procedure Templates

This section reproduces the dual-natured artefact set in template form. The full ready-to-customise templates are in the Clause 5.2 toolkit (17 documents); this section previews the apex templates, the internal PIMS policy skeleton and the external notice skeleton.

Internal PIMS policy skeleton (preview, full template in toolkit doc 01)

[INTERNAL PRIVACY POLICY — PIMS]
[Organisation Name]
Version: [X.Y] | Issue Date: [DD Month YYYY] | Next Review: [DD Month YYYY]
Approved by: [Name, Role, Signature] | DPO/Privacy Lead: [Name, Co-signature]
Classification: Internal / Confidential — NOT FOR PUBLIC PUBLICATION
Controller/Processor role declaration: [Controller / Processor / Both — see Appendix A]

1. Purpose and Scope
   [Purpose paragraph: the organisation commits to establishing, maintaining,
   and continually improving a PIMS that enables it to process personal data
   lawfully, fairly and transparently and to honour data principal rights, in
   line with ISO/IEC 27701:2025, the DPDP Act 2023 + DPDP Rules 2025, the
   IT Act 2000 / SPDI Rules 2011, [sectoral regulation], and applicable
   overseas privacy laws.]

   [Scope paragraph: this policy applies to [Clause 4.3 scope summary]. It
   covers [processing activities, products, services, geographies]. It does
   not cover [explicit exclusions]. The role declaration in Appendix A drives
   which Annex A.1 (controller) / A.2 (processor) controls apply.]

   [Fit-to-purpose paragraph: this policy is appropriate to the organisation's
   purpose of [strategic purpose], its context [Clause 4.1 summary], its
   interested parties [Clause 4.2 summary], its scope [Clause 4.3 summary],
   its role declaration, and the principal categories of PII it processes
   [ROPA summary — customer PII, employee PII, etc.]]

2. The Four Commitment Statements
   2.1 Applicable privacy requirements. The organisation commits to meeting
       the DPDP Act 2023 + DPDP Rules 2025, the IT Act 2000 section 43A and
       the SPDI Rules 2011, [sectoral regulation — RBI/SEBI/IRDAI/CERT-In],
       the Companies Act 2013 section 134(3)(n), and [overseas — GDPR/CCPA/
       LGPD/PIPL/PDPA where applicable].
   2.2 Framework for privacy objectives. The organisation will set, review
       and revise privacy objectives (Clause 6.2) at defined intervals,
       against defined dimensions, cascaded to process owners.
   2.3 Continual PIMS improvement.
   2.4 Additional privacy-specific commitments:
       (a) lawful, fair and transparent processing;
       (b) purpose limitation;
       (c) data minimisation;
       (d) accuracy;
       (e) storage limitation and timely erasure;
       (f) integrity, confidentiality and availability (DPDP section 8(5)
           reasonable security safeguards);
       (g) accountability;
       (h) privacy by design and by default;
       (i) lawful cross-border transfer (DPDP section 16 negative-list
           screen; GDPR Chapter V where applicable);
       (j) data principal rights and grievance redressal (DPDP sections
           11 to 14; GDPR Articles 15 to 22 where applicable);
       (k) protection of children's and vulnerable persons' data (DPDP
           section 9);
       (l) breach notification capability — DPDP section 8(6) 72-hour
           clock to the Board; CERT-In Directions 6-hour clock;
           [sectoral clocks].

3. PIMS Framework (governance, scope, PDCA cycle, references to subordinate
   instruments — ROPA, DPIA register, processor DPA register, breach
   playbook, SoA)

4. Privacy Objectives Framework (dimensions, cadence, cascade, reporting
   to RMC/board)

5. Communication and Availability (intranet publication; notice publication
   on public website, in-product, in consent flow, via Consent Manager API;
   layered and child-readable versions; multilingual and accessible formats)

6. Breach Notification Commitment (dual-clock: DPDP 72 hours to Board and
   without undue delay to Principals; CERT-In 6 hours; [sectoral clocks])

7. Review and Maintenance (annual at management review Clause 9.3; event-
   trigger list)

8. Appendices
   Appendix A: Controller/Processor role declaration by processing activity
   Appendix B: Regulatory landscape register
   Appendix C: Sub-processor list and DPA reference
   Appendix D: Version history

External privacy notice skeleton (preview, full template in toolkit doc 01)

[PRIVACY NOTICE — for Data Principals]
[Organisation Legal Name]
Last updated: [DD Month YYYY] | Version: [X.Y]

[Layered short-form notice — typically one screen, 200 to 400 words, with
links to the long-form sections below]

1. Who we are and how to contact us
   [Legal name, registered address, contact details, DPO/Grievance Officer
   name and contact]

2. What personal data we collect
   [Categories: identifiers, contact, financial, location, online
   identifiers, biometric, health, children's, sensitive categories.
   Directly collected vs sourced from others.]

3. Why we process it (purposes)
   [Specific, explicit, legitimate purposes — not "improving our services"
   boilerplate. Map purposes to categories.]

4. On what basis (lawful ground)
   [DPDP: section 6 consent and/or section 7 legitimate use; specify which
   per purpose. GDPR: Article 6 lawful basis; Article 9 condition where
   applicable.]

5. With whom we share it (recipients)
   [Processors, sub-processors, group companies, partners, regulators,
   courts. Name or describe categories clearly.]

6. Where we transfer it (cross-border)
   [Countries or categories of countries. Transfer mechanism: DPDP
   section 16 negative-list screen; GDPR adequacy/SCCs/BCRs/derogations
   where applicable.]

7. How long we keep it (retention)
   [Period or criteria. Limitation period reference.]

8. Your rights and how to exercise them
   [DPDP: access (s 11); correction/erasure (s 12); grievance (s 13);
   nomination (s 14). GDPR: Articles 15 to 22 where applicable.
   Contact channel, form, response period, escalation to Board.]

9. Withdrawing consent
   [Right to withdraw; mechanism (Consent Manager link where applicable);
   consequence of withdrawal; does not affect lawfulness of pre-withdrawal
   processing.]

10. Automated decision-making and profiling
    [Whether used; if so, the logic involved. For most: "We do not use
    automated decision-making with legal or similarly significant effects."
    For credit/hiring/content/AI use: substantive disclosure.]

11. Children's data
    [If children's data is processed: verifiable parental consent under
    DPDP section 9; no behavioural monitoring/targeted advertising of
    children; child-readable notice layer.]

12. Grievance redressal
    [Grievance Officer name and contact; response period per DPDP Rules;
    right to escalate to the Data Protection Board of India.]

13. Changes to this notice
    [Material-change notification approach; version-control reference.]

[Long-form details for each section above, linked from the short-form
layered notice on the website footer and consent surface.]

Risk Assessment and Treatment

Clause 5.2 is itself a control on policy-and-notice integrity; the risks that bear on it are risks to the policy-and-notice integrity. The Singahi Clause 5.2 risk register seeds 15 risks. Each risk is scored on a 1-to-5 likelihood and 1-to-5 impact scale (1 = negligible; 5 = severe), with the product giving a 1-to-25 inherent risk score. Treatment options follow the ISO 31000 hierarchy (avoid, reduce, transfer, accept).

The risks above are the seed register. The full risk-assessment template (toolkit doc 09) includes sector-specific risks (BFSI: borrower-notice RBI Digital Lending risk; Healthcare: consent-to-treat versus consent-to-process risk; SaaS: customer DPA processor-terms risk; Edtech: verifiable-parental-consent risk; E-commerce: cookie/SDK consent risk).

Audit and Compliance Checklist

The Clause 5.2 audit checklist below contains 28 questions across the eight moves. Each question lists the evidence the auditor will request and a red flag indicating the failure mode. The full checklist (with the sampled-staff script, the sponsor/DPO interview script, and the notice-to-ROPA trace worksheet) is in toolkit doc 04.

Stage 1, Document and context review

Stage 2, Operating effectiveness

Metrics and KPIs

The Clause 5.2 KPI set spans process metrics (is the work being done?), outcome metrics (is the work producing the right result?), and assurance metrics (are we confident the result will hold up under audit?). The Singahi Clause 5.2 dashboard (toolkit doc 11) operationalises 15 KPIs.

Process KPIs

Outcome KPIs

Assurance KPIs

The dashboard rolls into the management review (Clause 9.3) pack. The DPO presents the metrics; the sponsor and the board/RMC review trends and approve any corrective actions. Failure patterns to watch: P1 below 80 percent (communication commitment failed); O3 trending up (rights-handling workflow degraded); A1 below 100 percent (notice drift from ROPA, the marquee audit-failure signal).

Common Pitfalls and Audit Failures

Eight named anti-patterns account for the bulk of Clause 5.2 nonconformities observed in the Indian growing-company segment. Each is named, described, traced to the audit move it fails, and paired with a treatment.

Pitfall 1, Template policy, template notice. The organisation downloaded a privacy policy template from the internet, signed it once, and copied a privacy notice from another website. The fit-to-purpose paragraph is absent; the regulatory landscape is generic; the notice describes processing the organisation does not do (and omits processing it does). Fails Move 1, audit questions 5 and 8. Treatment: author the eight-section anatomy and the twelve-element content model from the ROPA; sponsor workshop; Legal review.

Pitfall 2, The internal/external conflation. The organisation published the internal PIMS policy on the public website (exposing management-system detail that should not be public) and used the website notice in the management review pack (no four commitment statements, no top-management signature). Both fail. Fails Move 4, audit questions 1, 6, 8. Treatment: maintain the two artefacts separately; classify the internal policy Confidential; publish only the external notice on the website.

Pitfall 3, The notice-ROPA drift. The ROPA was updated as new processing activities were added; the notice was not. The notice now describes a smaller processing footprint than the ROPA. The auditor picks a new activity from the ROPA, opens the notice, and finds the activity is not disclosed. Major nonconformity. Fails Move 7, audit question 8. Treatment: tie the notice to the ROPA via the Move 7 event-trigger "new processing activity"; quarterly notice-to-ROPA accuracy check (KPI A1).

Pitfall 4, Bundled consent. The consent flow bundles multiple purposes into one "I agree" click (marketing, analytics, third-party sharing, profiling). DPDP section 6 requires consent to be "specific" and "unconditional"; the bundle fails both. The GDPR standard is the same (Article 4(11); Article 7). Fails Move 6, audit question 11. Treatment: redesign the consent flow with per-purpose granularity; legal review of the consent record schema.

Pitfall 5, Consent withdrawal harder than consent. Giving consent is one click; withdrawing it requires sending an email to support, waiting five business days, and following up. DPDP section 6 and GDPR Article 7(3) require withdrawal to be as easy as giving. Fails Move 6, audit question 22. Treatment: implement one-click withdrawal; Consent Manager integration; monitor KPI O2.

Pitfall 6, The single-clock breach commitment. The policy commits to the DPDP 72-hour clock but not the CERT-In 6-hour clock (or vice versa). In a real breach, the organisation misses one of the two. Fails Move 1, audit question 13. Treatment: name both clocks in Section 2.4(l) of the policy; design the breach playbook with parallel countdowns; tabletop exercise semi-annually (KPI A2).

Pitfall 7, No notice version reconstruction. The organisation retains only the current version of the notice. When the auditor asks for the version in force at the time a sampled principal consented six months ago, it cannot be produced. Consent validity is at risk. Fails Move 8, audit question 17. Treatment: Documented Information control with notice-version-reconstruction capability; consent records tied to notice version.

Pitfall 8, Children's data without child-readable notice or verifiable parental consent. The organisation processes children's data (an Edtech, a gaming app, a healthcare portal treating minors) but has no child-readable notice layer and no verifiable parental consent mechanism. DPDP section 9 failure with direct penalty exposure up to 200 crore rupees. Fails Move 3, audit question 10. Treatment: design the verifiable-parental-consent flow; author the child-readable notice layer; commit to no behavioural monitoring / targeted advertising / tracking of children in the policy.

Illustrative Scenario 1: Failure, MobiKwik-style Data Fiduciary (Illustrative)

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

Disclaimer. This illustrative scenario is a fictional composite of multiple real Indian fintech and payments-company cases observed in the market between 2021 and 2026, drawing on the public researcher disclosures around the MobiKwik 2021 event, the Juspay 2021 event, the BigBasket 2020 event, and the Air India / SITA 2021 event. It is illustrative; any resemblance to a specific named firm is coincidental. The MobiKwik case in particular involved contested allegations, the company disputed the researcher's claims; numbers below are illustrative for teaching purposes and do not assert the contested figures as fact.

The organisation

The firm was regulated by the RBI under the Payment and Settlement Systems Act 2007 and operated as a Payment System Operator; it also held a Payment Aggregator authorisation. Madhur was pursuing ISO/IEC 27701:2025 certification (transitioning from the 2019 edition which it had certified in 2022) and had self-declared as a Data Fiduciary under the DPDP Act 2023.

The policy failure

Madhur's internal PIMS policy was authored in 2021 for the first ISO/IEC 27701:2019 certification push. It was a 17-page document, signed by the then-COO (who had left the firm in 2024), last reviewed in March 2023 for a surveillance audit, and not refreshed since. It committed generically to "compliance with applicable data protection laws including the IT Act 2000 and the SPDI Rules 2011", the DPDP Act 2023 (enacted 11 August 2023) and the DPDP Rules 2025 (notified 13 November 2025) were not reflected. The CERT-In Directions 20(3)/2022-CERT-In (28 April 2022) were named, but the policy committed only to the 6-hour CERT-In clock and was silent on the DPDP section 8(6) 72-hour clock to the Board.

The external privacy notice was a single 4,200-word document on the website, in English only, last updated in February 2023. It bundled consent across "marketing, analytics, service improvement, fraud detection and third-party partnerships" into one "I agree" click at signup. It described cross-border transfer in the boilerplate form ("we may transfer your information to countries where we operate") with no destination list and no negative-list screen. It did not mention Madhur's use of a third-party AI-based fraud-scoring engine that produced semi-automated decisions affecting wallet limits and onboarding outcomes. It did not address the existence of children's accounts (minors with parental-supervised wallets, a feature Madhur had launched in 2024). The notice did not match the ROPA: the ROPA listed 14 categories of recipients including four sub-processors in three countries; the notice named none of them specifically and described recipients only as "trusted partners."

The disruption

On 9 March 2026, a researcher disclosed that a database containing approximately 110 million Madhur user records was being offered for sale on a dark-web market. The disclosure was contested by Madhur (which issued a public statement asserting no breach had occurred); subsequent forensic review by an IR retainer confirmed that an exposed Elasticsearch cluster had leaked user records including names, email addresses, mobile numbers, hashed passwords, partial KYC data, and wallet-balance snapshots. The exposure window was approximately 19 days. Approximately 92 million records were in the exposed dataset.

Madhur's incident-response process detected the exposure only after the researcher's disclosure (the cluster misconfiguration had not triggered internal alerting). The dual clock began running from the moment of awareness:

• CERT-In 6-hour clock. Madhur's CERT-In Point of Contact filed the prescribed cyber incident report 11 hours after awareness, 5 hours late.
• DPDP 72-hour clock. Madhur's DPO (a Deputy General Manager in the Legal function) prepared the section 8(6) notification to the Board in the Rule 7 intimation content, but the executive sponsor deferred filing pending the forensic review's confirmation. The notification was filed 96 hours after awareness, 24 hours late. Affected Data Principals were notified over the following 14 days, in batches by email.

The regulatory inspection

The Data Protection Board of India opened a proceeding on 14 March 2026 under DPDP section 18 read with section 33. The Board's first request was the internal PIMS policy and the external privacy notice. The Board's findings, in summary:

1. The PIMS policy did not reflect the DPDP Act 2023 or the DPDP Rules 2025 (in force since 13 November 2025). Material non-conformance with the policy's commitment to applicable privacy requirements.
2. The PIMS policy did not commit to the DPDP section 8(6) 72-hour clock to the Board. Material inadequacy in the breach-notification commitment.
3. The PIMS policy committed to the CERT-In 6-hour clock but the firm missed the clock by 5 hours. Material operational failure.
4. The external privacy notice did not accurately describe the recipients of personal data (the ROPA listed 14 categories; the notice named none). Material non-conformance with DPDP section 5 notice content.
5. The notice bundled consent across multiple purposes. Material non-conformance with DPDP section 6 (consent must be specific and unconditional).
6. The notice did not disclose the AI-based fraud-scoring engine or its logic. Material non-conformance with DPDP section 5 (notice must describe processing) and with the algorithmic-fairness overlay if designated as SDF.
7. The notice did not address children's accounts or provide a child-readable layer or verifiable parental consent. Material non-conformance with DPDP section 9 (penalty exposure up to 200 crore rupees).
8. The notice did not disclose the cross-border destinations or the negative-list screen. Material non-conformance with DPDP section 16 read with section 5.
9. The notice was in English only for a 92-million-user base that was majority non-English-speaking. Material non-conformance with the DPDP Rules 2025 plain-language requirement.
10. The policy and notice had not been refreshed on event trigger (the DPDP Act enactment in August 2023, the DPDP Rules notification in November 2025, the launch of children's accounts in 2024, the onboarding of the AI fraud-scoring engine in 2025). Material failure of the Move 7 event-trigger discipline.

CERT-In opened a parallel proceeding under the 28 April 2022 Directions for the 5-hour delay in the prescribed cyber incident report. RBI opened a parallel supervisory review under the Payment and Settlement Systems Act 2007 and the Storage of Payment System Data directive (6 April 2018), the data-locality implications of the cross-border transfer disclosure failure were material.

The consequence

The Data Protection Board of India imposed a penalty of approximately 85 crore rupees on Madhur under section 33 read with the Schedule, with the headline finding articulated as failure to take reasonable security safeguards under section 8(5) and failure to notify the breach under section 8(6), with the policy and notice failures cited as aggravating factors in the "adequate safeguards" analysis. CERT-In imposed a separate monetary penalty under the IT Act for the reporting delay. RBI referred the matter to its supervisory ladder, requiring Madhur to commission an external IT audit, remediate the data-locality gaps, and report quarterly to the Senior Supervisory Manager for 12 months.

Madhur's ISO/IEC 27701:2025 transition surveillance audit (due in April 2026) was reclassified as a special audit. The certifying body issued a major nonconformity on Clause 5.2 (notice-ROPA drift; missing DPDP and DPDP Rules reflection; bundled consent; children's-data gap; ADM disclosure gap; cross-border disclosure gap) plus further majors on Clause 4.2 (interested parties, regulator landscape stale), Clause 5.1 (sponsor turnover not refreshed), Clause 7.5 (notice-version-reconstruction capability absent), and Annex A.1.2.3 / A.1.2.4 (consent controls, bundled and not specific). The certificate was suspended.

The commercial cost was larger. Madhur's monthly active user count dropped 19 percent over the following two quarters. The Madhur share price (listed parent) dropped 14 percent over the three weeks following the incident; sell-side analysts attributed the drop to "privacy and operational-risk concerns." Two class-action proceedings were filed under the Consumer Protection Act 2019; one was filed as a public-interest proceeding under Article 32 of the Constitution citing Puttaswamy.

The lessons

1. A signed policy is not a current policy. The signature in 2021 was the start; the staleness by 2026 was the failure. The calendar-plus-event-trigger review (Move 7) is not optional.
2. Notice-to-ROPA accuracy is the marquee audit move, and the marquee regulator move. The 14-recipient ROPA versus the zero-named-recipient notice was the single most-cited finding.
3. Bundled consent is a DPDP section 6 failure and a GDPR Article 7 failure. Most Indian growing companies are still bundling; the DPDP Rules 2025 make this a direct penalty exposure.
4. The dual-clock commitment is non-negotiable. A policy that names only one clock will produce a breach response that misses the other.
5. Children's data and automated decision-making are the two highest-impact disclosure gaps. Both attract 200-crore-rupee Schedule exposure under DPDP.
6. The cost of a 5.2 failure dwarfs the cost of 5.2 conformance. Madhur's 85-crore-rupee DPDP penalty plus the CERT-In penalty plus the RBI supervisory action plus the customer churn plus the share-price drop plus the class actions, versus a 4 to 8 lakh rupee external advisory cost for a proper Clause 5.2 cycle. The asymmetry is several orders of magnitude.

Illustrative Scenario 2: Success, Tarang Healthtech SDF (Illustrative, with ROI)

Disclaimer. Tarang Healthtech is a fictional composite of multiple real Indian healthtech and SDF-designated firms. It is illustrative; any resemblance to a specific named firm is coincidental. Numbers are illustrative for teaching purposes.

The organisation

Tarang offered telemedicine consultations, electronic health records, pharmacy delivery, chronic-care programmes, and an AI-based diagnostic-assist product for radiology images. The firm was designated a Significant Data Fiduciary under DPDP Act 2023 section 10 in March 2026 (on the basis of the volume and sensitivity of health data processed). Tarang was pursuing ISO/IEC 27701:2025 certification as the management-system lens for its SDF obligations.

The challenge

In January 2026, Tarang's newly appointed DPO (an India-based lawyer with CIPM and CIPP/E credentials, appointed to satisfy DPDP section 10) commissioned a Clause 5.2 review ahead of the SDF designation's effective date. The existing internal PIMS policy was an 11-page document last reviewed in 2024; it referenced the IT Act / SPDI Rules but not the DPDP Act; it did not commit to the section 10 SDF obligations; it did not name the algorithmic-fairness review. The external privacy notice was a single 3,800-word document in English only; it bundled consent; it did not differentiate consent to treat from consent to process; it did not disclose the AI diagnostic-assist product or its logic; it did not disclose the cross-border transfer of radiology images to a sub-processor in a third country for model training; it did not address the children's-data dimension (Tarang served pediatric patients through guardian-managed accounts). An internal gap assessment (using the toolkit doc 12 template) rated both artefacts at L1 (compliance-only).

The phased remediation

The DPO sponsored an eight-move remediation programme over 16 weeks, supported by external advisory.

Weeks 1 to 3: Move 1 (author the dual-natured artefacts). A workshop with the DPO, the CEO (executive sponsor), the CPO, the CISO, the Head of Legal, the Head of Clinical Operations, and the Head of Product produced the eight-section internal PIMS policy and the twelve-element external privacy notice. The fit-to-purpose paragraph connected the policy to Tarang's healthtech context (sensitive health data; mixed patient/doctor populations; AI diagnostic-assist; chronic-care programmes; pharmacy delivery), its interested parties (patients, doctors, the Data Protection Board, the Ministry of Health and Family Welfare, regulators, partner hospitals, pharmacy partners, sub-processors), its scope (the full platform, all products, all geographies), and its role declaration (controller for patient data; processor for partner-hospital data where contractually specified).

The four commitment statements named the DPDP Act 2023, DPDP Rules 2025, the IT Act 2000 / SPDI Rules 2011, the Digital Information Security in Healthcare Act (draft, in limbo), the Medical Council of India telemedicine guidelines, the Consumer Protection (E-Commerce) Rules 2020, the Companies Act 2013 section 134(3)(n), the SEBI LODR Regulation 21 (Tarang's parent was listed), and GDPR (Tarang served NRI patients). The privacy-specific additional commitments included all 12 items from Section 7 Move 1, with the SDF commitments (DPO, DPIP, independent audit, algorithmic fairness) explicit. The dual-clock breach commitment named DPDP 72 hours, CERT-In 6 hours, and the Ministry of Health notification expectation.

The external notice, authored as a layered short-form plus a long-form, addressed all twelve content elements. It split consent to treat (a Clinical Operations surface) from consent to process (a DPO/Legal surface). It disclosed the AI diagnostic-assist product, the logic at a high level, the human-in-the-loop requirement, and the patient's right to opt out of AI-assisted diagnosis. It disclosed the cross-border transfer of radiology images for model training (to a named sub-processor in a named country, with the negative-list screen confirmed and the standard contractual clauses in place). It addressed children's data via a guardian-managed account flow with verifiable parental consent and a child-readable notice layer. It was authored in English and translated into Hindi, Kannada, Tamil, Telugu, Bengali, and Marathi (the six dominant patient languages).

Weeks 4 to 5: Move 2 (authorise). The CEO and the DPO co-signed the internal policy; the PIMS Steering Committee endorsed; the Board's Risk Management Committee noted at its March 2026 sitting under the DPDP section 10 SDF DPO-accountability-to-board requirement. The Company Secretary recorded the minute. The DPO and Head of Legal approved the external notice for publication.

Weeks 6 to 8: Move 3 (layered notice, child-readable layer, multilingual summaries). Communications and Product co-produced the layered short-form notice (one screen, 380 words) for the website footer, the in-app consent surface, the just-in-time microcopy on each form, and the Consent Manager API payload. The child-readable notice layer was authored with simple icons, an audio version, and a 250-word primary-school-English summary translated into the six patient languages. The internal policy-on-a-page was produced in English, Hindi, and Kannada (the dominant workplace languages) with audio versions for accessibility. Posters were printed for the five physical clinic-partner sites.

Weeks 9 to 10: Move 4 (publish in the right locations). IT published the internal policy on the intranet with the acknowledgement form. Marketing/Digital published the layered notice and the long-form notice on the website in seven languages with the version-control metadata. Product embedded the layered notice and the just-in-time microcopy in the app and wired the Consent Manager API. Procurement published the processor-facing privacy commitment and the sub-processor list (now four named sub-processors in two countries) on the vendor portal. The Trust team published the customer-facing artefact set (redacted internal policy summary, full external notice, processor commitment, sub-processor list, latest DPIP summary, latest independent-audit summary) on the customer trust portal.

Weeks 11 to 13: Move 5 and Move 6 (communicate, acknowledge, and capture consent records). The awareness programme ran across the platform: the CEO and the DPO co-hosted a town-hall (recorded for staff in field sites); the DPO ran 45-minute briefing sessions in regional clusters; the CPO and the Head of Clinical received a deeper briefing on the consent-to-treat / consent-to-process split; the engineering teams received a deeper briefing on privacy-by-design; the new-joiner induction was updated. The acknowledgement record stood up in the HR system; by the end of week 13, 98 percent of staff had acknowledged the current version (100 percent of clinicians, 100 percent of engineers with PII access).

For the consent-and-notice record, Tarang stood up a consent-management platform with DPDP-compliant consent records (per patient, per purpose, per version, per timestamp, with the version of the notice in force at the time of consent retrievable per Documented Information Clause 7.5). Existing patients were re-noticed under a transition flow (the policy and the DPDP Rules 2025 commencement supported this for the SDF transition window); the re-consent rate exceeded 82 percent by the end of week 16.

Weeks 14 to 15: Move 7 (review cadence and event triggers). The calendar review was locked to the management review cadence (annually in March, aligned with the financial-year close). The event-trigger list included: new processing activity; regulatory change; breach; SDF threshold change; M&A; new product or geography; new sub-processor; audit nonconformity; scope change; DPO or sponsor change; DPIA revealing material risk; significant change in patient population; Consent Manager change.

Week 16: Move 8 (wire into management review and audit). The internal PIMS policy and the external privacy notice were placed on the management review agenda (Clause 9.3) and the internal audit programme (Clause 9.2). The internal audit team prepared a 5.2-specific audit checklist with the notice-to-ROPA trace worksheet. The first management review sitting in March 2026 reviewed the policy and notice and confirmed continuing suitability.

The quantified results

1. ISO/IEC 27701:2025 Stage 1 audit (May 2026). Zero major nonconformities on Clause 5.2; one minor nonconformity (a small Documented Information metadata gap in the notice-version-reconstruction test, fixed in 72 hours). The certifying body's auditor noted the policy-and-notice set as a benchmark example for the Indian healthtech SDF segment.

2. ISO/IEC 27701:2025 Stage 2 audit (July 2026). Zero nonconformities on Clause 5.2. Certification recommended.

3. Data Protection Board of India SDF designation review (June 2026). The Board's SDF compliance team reviewed Tarang's policy, notice, DPIP register, independent-audit report, and algorithmic-fairness review as part of the SDF designation's operationalisation. The artefacts were accepted without remediation.

4. Patient engagement. The re-consent flow's patient experience was measurably better than the legacy bundled-consent UX. The patient-Net-Promoter-Score for the onboarding flow improved by 11 points. Patient complaints about the consent flow dropped by 64 percent.

5. Internal culture. The annual staff engagement survey showed a 19-point improvement in the "I understand how we protect patient data" item, attributable (per the survey commentary) to the awareness programme and the layered notice's clarity.

The ROI

The Year-1 ROI on a purely financial basis (insurance saving alone, excluding revenue and penalty-avoidance) is 6x, modest but real. The expected-value ROI (including the avoided DPDP and SDF penalty exposure on a 1.1-million-user health-data base) is several orders of magnitude higher. The revenue wins are the upside of being a sectoral privacy benchmark, Tarang's customer trust portal publication is now referenced by other healthtech firms as the design standard.

The lessons

1. The dual-natured artefact set is commercially valuable. It is not just a compliance artefact; it is a sales asset, an insurance asset, a regulator-relations asset, and a brand asset.
2. The eight moves are sequential and deliverable in 16 weeks for a complex SDF healthtech. Most of the work is workshop time, translation, and consent-platform setup, not capital expenditure.
3. The SDF section 10 overlay is dense but manageable when ISO/IEC 27701:2025 Clause 5.2 is the lens. The DPO, DPIP, audit, and algorithmic-fairness obligations map cleanly onto the policy commitments.
4. The board cycle is the bottleneck for SDFs. Plan the board/RMC noting under the section 10 DPO-accountability requirement early; it sets the calendar for everything else.
5. The awareness programme is where the policy becomes living. Without it, the policy is decoration; with it, the policy is institutional.
6. The ROI frame is the executive sponsor's frame. The CEO commissioned the programme because the financial plus expected-value case was compelling; the compliance frame alone would have produced a slower decision.
7. Customer trust portal publication of the artefact set is the under-exploited Indian market opportunity. Most Indian growing companies treat the customer trust portal as an afterthought; Tarang treated it as a sales asset and won enterprise business as a result.

Multi-Framework Mapping

This section maps ISO/IEC 27701:2025 Clause 5.2 to the relevant controls, articles and sections in the major global and Indian frameworks. The mapping is structured to support a single integrated privacy policy and notice set that satisfies multiple regimes simultaneously, which is the marquee commercial argument for ISO/IEC 27701:2025 in the Indian market.

Mapping table

The DPDP-versus-GDPR transfer mechanism distinction

Two transfer mechanisms are commonly conflated in Indian PIMS policies. DPDP section 16 uses a negative-list approach, transfer is permitted to any country except those the Central Government notifies as restricted. GDPR Chapter V uses an adequacy-or-safeguards-or-derogation approach, transfer requires an adequacy decision (Article 45), appropriate safeguards (Article 46, SCCs, BCRs), or a derogation (Article 49), with a Schrems-II-aware transfer impact assessment. A PIMS policy that commits only to "adequacy" or only to "the negative list" mis-states one of the two regimes. The correct commitment is: "the organisation shall screen cross-border transfers against the DPDP section 16 negative list and, for transfers to non-adequate destinations under GDPR, shall implement appropriate safeguards (SCCs or BCRs) with a transfer impact assessment per Schrems II."

The DPDP section 2(1)(g) Consent Manager, no clean external analogue

The Consent Manager is a distinctive Indian construct. There is no direct GDPR, NIST PF or SOC 2 equivalent. The closest cousins are the GDPR Article 7(3) withdrawal-as-easy-as-to-give principle, the EU "consent dashboard" concept, and some sector-specific intermediary models (the Account Aggregator framework under RBI for financial data). PIMS policies should name the Consent Manager as a distinct DPDP construct and commit to integration with registered Consent Managers as the ecosystem matures.

Implementation Roadmap

This is the 30 / 90 / 180 / 365-day roadmap for a typical Indian growing company pursuing Clause 5.2 conformance from a cold start. The full version with milestones, owners and deliverables is in toolkit doc 05.

Days 0 to 30, Foundation

Week 1. Confirm the executive sponsor and the DPO/Privacy Lead. Open the Clause 5.2 workstream. Pull the Clause 4.1, 4.2, 4.3, the privacy risk assessment (6.1.2), and the ROPA outputs. Confirm the controller/processor role declaration. Identify the regulatory landscape (use Section 3.2 of this guide).

Weeks 2 to 3. Run the two-day policy-and-notice authoring workshop (Move 1). Produce the first drafts of the eight-section internal PIMS policy and the twelve-element external notice.

Week 4. Legal and Compliance review of the drafts. PIMS Steering Committee review. Notice-to-ROPA accuracy check.

Days 31 to 90, Communication and availability

Weeks 5 to 6 (Move 2 and Move 3). Executive sponsor approval. For SDFs, BFSI, listed entities and insurers, schedule the board/RMC noting. Communications produces the layered notice, the policy-on-a-page, the multilingual summaries, the child-readable layer (where applicable), the processor-facing privacy commitment.

Weeks 7 to 8 (Move 4). IT publishes on the corporate intranet. Marketing/Digital publishes the layered notice and the long-form notice on the public website in the principal languages. Product embeds the layered notice in the app and wires the Consent Manager API. Procurement publishes the processor-facing commitment and the sub-processor list on the vendor portal. The Trust team publishes the customer-facing artefact set on the customer trust portal.

Weeks 9 to 12 (Moves 5 and 6). Awareness programme launch: new-joiner induction updated; annual awareness refresh run; process-owner and engineer briefing run; executive sponsor briefed; board/RMC briefed at the management review. Acknowledgement record stood up in the HR system with a 95 percent target. Consent-and-notice record stood up in the consent-management platform with the version-reconstruction capability.

Days 91 to 180, Review, audit and integration

Weeks 13 to 16 (Move 7). Review cadence and event triggers defined and documented. Calendar review locked to the management review cycle. Event-trigger list operationalised. Regulatory horizon-scanning feed stood up (MeitY for DPDP Rules amendments; CERT-In for incident-directions updates; sectoral regulators; EDPB and national DPAs for GDPR changes).

Weeks 17 to 20 (Move 8). Internal audit runs the first 5.2-specific audit using the toolkit doc 04 checklist. The notice-to-ROPA trace worksheet is the marquee test. Findings closed. Management review (Clause 9.3) includes policy and notice review. Board/RMC notes the management review outcome.

Weeks 21 to 24. Traceability test: confirm the objectives (Clause 6.2) reference the policy framework; the ROPA (Clause 8) reflects the policy's processing commitments; the DPIAs reflect the policy's risk commitment; the breach playbook reflects the dual-clock policy commitment; the processor DPAs reflect the processor-facing privacy commitment; the corrective-action log (Clause 10.2) closes against policy commitments. Remediate any inconsistencies.

Days 181 to 365, Steady state and certification

Months 7 to 9. Run the awareness programme quarterly cycle. Monitor the acknowledgement record and the consent-and-notice record. Maintain the Documented Information controls. Run the first breach-tabletop exercise (KPI A2, dual-clock rehearsal). Prepare the certification audit pack.

Months 10 to 12. Stage 1 audit. Close any minor nonconformities. Stage 2 audit. Receive certification (or, for entities already certified on 27701:2019, complete the :2025 transition with the 5.2 finding closed before the 31 October 2028 organisation transition deadline).

Continuous. Monitor event triggers. Maintain the policy risk register (Section 10). Refresh the layered notice and multilingual summaries on notice version change. Refresh the policy-on-a-page on policy version change. Run the regulatory horizon-scanning cycle quarterly.

FAQ

Q1. We already have a privacy policy on our website. Do we need to redo it for ISO/IEC 27701:2025?

Almost certainly yes, for two reasons. First, the website notice is the external half of the dual-natured artefact set; ISO/IEC 27701:2025 Clause 5.2 also requires the internal PIMS policy with the four commitment statements, which most firms do not have. Second, most existing notices fail the DPDP section 5 / GDPR Article 13 specificity test (bundled consent; missing recipients; missing retention; missing transfer destinations; missing children's-data layer; missing ADM disclosure). Run the toolkit doc 12 gap assessment to decide.

Q2. How long should the internal PIMS policy be?

Two to five pages for the policy itself; up to ten pages with appendices. The test is whether the policy does its four jobs (apex, commitment, communication, available). A 60-page PIMS Manual fails the "strategic instrument" test; a half-page flyer fails the "substantive commitment" test.

Q3. How long should the external privacy notice be?

A layered notice works best: a short-form (one screen, 200 to 400 words) for the website footer and the in-product consent surface, linking to a long-form notice with the twelve content elements. The long-form notice can be 1,500 to 5,000 words depending on processing complexity. The test is whether the principal can find the information they need, in language they can use, when they need it.

Q4. Does the internal PIMS policy need board approval?

Top-management approval is required (Clause 5.1). For Significant Data Fiduciaries under DPDP section 10, board-level accountability for the DPO is additionally required. For listed entities, the Companies Act 2013 section 134(3)(n) and SEBI LODR Regulation 21 overlay may require board or board-committee visibility. For other growing companies, the CEO/MD signature plus the DPO co-signature suffices.

Q5. Should the internal PIMS policy and the ISMS Policy be the same document?

They can be. An integrated "Information Security and Privacy Policy" satisfies both ISO/IEC 27001:2022 Clause 5.2 and ISO/IEC 27701:2025 Clause 5.2 if it covers both sets of commitments. Many Indian growing companies integrate them; some keep them separate but aligned. The integration choice depends on the audience (a combined policy is broader; a separate PIMS policy is more focused on privacy outcomes). Singahi typically recommends two aligned policies for clarity, integrated at the management-review level.

Q6. How often should the internal policy and the external notice be reviewed?

Annually at the management review (Clause 9.3), plus on event trigger (new processing activity; regulatory change; breach; SDF designation or threshold change; M&A; new product or geography; new sub-processor; audit nonconformity; scope change; sponsor or DPO change; DPIA revealing material risk; significant change in principal population; Consent Manager change). See Move 7.

Q7. Do we need to translate the notice into Indian languages?

Yes, for the dominant principal languages, under the DPDP Rules 2025 plain-language requirement. The full notice can stay in English for legal and audit purposes; the layered short-form notice and a summary in the dominant principal languages are needed to satisfy the availability and communication commitments in spirit. Child-readable layers (where applicable) and accessible formats (audio, screen-reader-compatible) are needed to satisfy the availability commitment for principals with disabilities and children.

Q8. Does the internal PIMS policy need to be on the public website?

No. The internal PIMS policy should be classified Confidential and hosted on the intranet, the vendor portal, and (redacted) on the customer trust portal. The external notice is published on the public website, in-product, in the consent flow, and via the Consent Manager, because DPDP, GDPR and other laws require it. Conflating the two is Pitfall 2.

Q9. What is the difference between the internal PIMS policy and the ROPA?

The policy is the apex strategic statement (what we commit to and why). The ROPA (Clause 8 and Annex A.1.2.x) is the operational inventory of processing activities (purpose, categories of data and principals, recipients, transfers, retention, security). The notice summarises the ROPA for data principals; the policy commits to maintaining the ROPA.

Q10. What is the difference between the notice and the consent record?

The notice is the disclosure to the data principal. The consent record is the captured proof of the principal's decision (timestamp, version of the notice in force, scope of consent, withdrawal mechanism). The two are paired, every consent must be tied to a specific version of the notice.

Q11. What if our DPO leaves?

DPO change is an event trigger (Move 7). The policy is re-presented to the new DPO within 30 days of appointment; the new DPO co-signs the policy (version-update); the PIMS Steering Committee re-endorses. For SDFs, the section 10 DPO accountability-to-board must be re-confirmed. The DPO change is recorded in the version history.

Q12. Does the PIMS policy need to reference every Indian regulation?

The applicable-requirements commitment should name the material instruments for your sector. For a bank: DPDP, IT Act/SPDI, RBI Cybersecurity Directions 2026, RBI Digital Lending, CERT-In Directions, Companies Act, SEBI LODR. For an insurer: add IRDAI ICS. For an MII: add SEBI CSCRF and SEBI KRA. For an Edtech: add DPDP section 9 children's rules and the Consumer Protection E-Commerce Rules. Generic "applicable laws" wording fails the audit.

Q13. How do we evidence that the policy and notice are communicated?

For staff: the acknowledgement record (Move 6) is the primary evidence, per staff member, role, location, language version, date, version, manager. The awareness programme calendar (Move 5) is the secondary evidence. For principals: the consent-and-notice record is the primary evidence, per principal, per purpose, per version, per timestamp. The auditor's sampled-staff test and sampled-principal record test are the audit-evidence tests.

Q14. How do we run the dual-clock breach commitment?

Design the breach playbook with two parallel countdowns triggered by the same awareness event: the CERT-In 6-hour clock (file the prescribed cyber incident report to CERT-In within 6 hours of noticing); the DPDP 72-hour clock (file the section 8(6) intimation to the Data Protection Board of India without delay on becoming aware, with the detailed Rule 7 report within 72 hours; notify affected Data Principals without undue delay). Tabletop the playbook semi-annually (KPI A2). Add sectoral clocks as applicable (RBI six hours; SEBI RE 6 hours; IRDAI per guidelines).

Q15. Can we use a template to start?

Yes, as a starting point. Templates save drafting time. But the template must be adapted with the fit-to-purpose paragraph, the named Indian regulator landscape, the role declaration, the dual-clock breach commitment, the twelve-element notice content, and the consent-flow redesign. An unadapted template is Pitfall 1.

Industry-Specific Requirements

BFSI (banks, NBFCs, insurers, payment systems, MIIs)

BFSI is the most regulator-heavy Indian sector for Clause 5.2. The internal PIMS policy and the customer-facing notice must reference:

• DPDP Act 2023 + DPDP Rules 2025, the horizontal overlay. The BFSI entity is a Data Fiduciary for customer data; many BFSI entities are also processors for partner-bank or partner-insurer data. The role declaration must be precise.
• RBI Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 (31 July 2026), board-approved BCP/DR policy with documented RTO/RPO; board-approved cyber-security policy with Cyber Crisis Management Plan; incident reporting within six hours; data-locality expectations; ICT outsourcing oversight. The PIMS policy references the Cybersecurity Directions 2026 on the security and availability dimension, and its breach commitment names the RBI clock.
• RBI Master Direction on Digital Lending (2 September 2022), the most prescriptive sectoral privacy-by-design rule. The borrower-facing notice must address explicit borrower consent; restriction on device-data access by lending apps (contacts, location, media); data-collection minimisation; grievance redressal; restrictions on storage and sharing. Lending Service Providers must reflect the LSP-RE relationship in the notice.
• RBI Tokenisation circular (22 September 2021; full effect 1 October 2022), consent for tokenisation; no raw card-data storage. The PIMS policy's minimisation commitment names tokenisation where applicable.
• RBI Storage of Payment System Data (6 April 2018), end-to-end storage of payment data in India only. The PIMS policy's cross-border commitment reflects the payment-data locality rule for PSOs.
• RBI Managing Risks in Outsourcing Directions, 2025 (28 November 2025), outsourced/cloud-provider privacy and security inheritance; concentration-risk monitoring; exit plans; right-of-audit.
• SEBI CSCRF (20 August 2024), board-approved cyber resilience policy spanning five goals and six operational functions; incident reporting within 6 hours to SEBI and CERT-In.
• SEBI KRA Regulations 2011 (as amended 2024; Master Circular May 2024), KYC data handling by KRAs and market intermediaries. KYC data is SPDI under IT Act and personal data under DPDP.
• SEBI MII BCP-DR circular (22 March 2021), for MIIs: Near Site + DRS architecture; RTO 2 hours or less for critical systems.
• IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023), for insurers: board-approved Information and Cyber Security Policy including BCP/DR; CISO; 180-day log retention; DR drills; data locality for policyholder data; ICT outsourcing continuity oversight; annual compliance reporting within 90 days of FY end.

The BFSI PIMS policy typically includes an explicit "regulatory reporting clocks" commitment (CERT-In 6 hours; RBI six hours; SEBI RE 6 hours; IRDAI per guidelines; DPDP 72 hours). The board/RMC noting is mandatory, not optional. The customer-facing notice typically splits into a depositor/customer notice, a borrower notice (Digital Lending), a policyholder notice (IRDAI), and an investor notice (SEBI).

Healthcare (hospitals, pharma, devices, diagnostics, telemedicine)

Healthcare is the sector where the DPDP section 9 children's dimension, the consent-to-treat-versus-consent-to-process distinction, and the AI diagnostic-assist disclosure all intersect most acutely. The PIMS policy and patient-facing notice must address:

• DPDP Act 2023 + DPDP Rules 2025, health data is treated as sensitive; the section 9 children's dimension applies to pediatric patients (verifiable parental consent; no behavioural monitoring; no targeted advertising).
• The consent-to-treat-versus-consent-to-process distinction. Consent to treat is a Clinical Operations surface (consent to the medical procedure, governed by the Medical Council of India telemedicine guidelines and clinical-establishment law). Consent to process is a DPO/Legal surface (consent to the processing of the resulting health data). The notice must distinguish the two and the consent flow must collect them separately.
• AI diagnostic-assist disclosure. Where AI is used for radiology, pathology, or diagnostic assist (DPDP section 10 algorithmic-fairness overlay; GDPR Article 22), the notice must disclose the use, the logic at a high level, the human-in-the-loop requirement, and the patient's right to opt out.
• Cross-border transfer of health data. Telemedicine serving NRI patients; radiology-image sub-processing for AI model training. The notice must disclose destinations; the PIMS policy commits to the negative-list screen and, where relevant, GDPR Article 46 safeguards.
• The Digital Information Security in Healthcare Act (DISHA) draft remains in limbo, DPDP is the operative instrument. The PIMS policy references DPDP and notes the DISHA uncertainty where relevant.
• Clinical trial data adds the ICH-GCP / New Drugs and Clinical Trials Rules 2019 layer, the PIMS policy references the trial-specific consent regime and the difference between trial consent and DPDP consent.
• The Medical Council of India telemedicine guidelines (2020) govern the doctor-patient relationship in telemedicine; the notice reflects the telemedicine-specific disclosures.

IT / ITeS and SaaS

IT/ITeS and SaaS firms typically act as PII processors for their customers' data and as PII controllers for their own employee and customer-relationship data. The processor track is critical.

• The processor-facing privacy commitment addressed to controller customers, summarising the processor's privacy posture, the DPA terms, the sub-processor list with change notification, the infringing-instruction process (Annex A.2.2.5), the breach-notification SLA, the cross-border transfer mechanism, and the deletion-on-termination commitment.
• The customer DPA with the Article 28-style mandatory clauses (subject, duration, nature/purpose, type of data, categories of subjects, obligations).
• The sub-processor list with quarterly refresh and per-change notification to controllers.
• The infringing-instruction process, what the processor does when a controller instructs processing that infringes DPDP, GDPR or another law (the processor must inform the controller and may pause the processing).
• The cross-border transfer impact assessment for Schrems-II-aware transfers to non-adequate destinations.
• The customer trust portal publication of the processor-facing artefact set is a sales asset for SaaS and ITeS firms serving enterprise customers. Most enterprise security questionnaires ask for it.
• DPDP section 8(5) availability, for SaaS handling personal data, availability is a statutory obligation; the BCMS policy and the PIMS policy reinforce each other.

E-commerce and Retail

• Notice quality and consent for marketing, DPDP section 6 specific consent for marketing communications, separate from transactional communications; clear unsubscribe mechanism.
• Cookie and SDK consent, granular per-purpose consent; cookie banner with per-category granularity; no pre-ticked boxes.
• Behavioural advertising opt-out, and, where AI-based profiling produces legal/significant effects, the disclosure of the logic (DPDP section 10; GDPR Article 22).
• Children's data (DPDP section 9), verification mechanisms for age-restricted products; verifiable parental consent for minors' accounts.
• The marketplace-versus-seller roles, the notice must address which entity is the controller for which processing activity (the marketplace's own processing versus the seller's processing).
• Payment-data handling, RBI Tokenisation; RBI Storage of Payment System Data; the payment-aggregator relationship.
• Loyalty-programme data flows, separate consent for loyalty enrolment; cross-programme data sharing.
• The Consumer Protection (E-Commerce) Rules 2020, mandatory privacy policy and grievance redressal mechanism; the Advertising Standards Council of India code overlay.

Edtech

Edtech is the sector where DPDP section 9 (children) is the marquee challenge. The PIMS policy and the parent/student-facing notice must address:

• Verifiable parental consent under DPDP section 9 and the DPDP Rules 2025, the mechanism must verify the parent or guardian's identity and consent; the notice must be in a form the parent or guardian can understand.
• Child-readable notice layer, age-appropriate language, simple icons, audio versions, and a primary-school-English summary translated into the dominant student languages.
• No behavioural monitoring, no targeted advertising, no tracking of children, these are section 9 hard requirements, not aspirational commitments. The PIMS policy commits to them; the notice discloses them.
• The school-versus-Edtech processor relationship, many Edtech firms act as processors for schools (which are the controllers for student data). The role declaration must be precise per processing activity.
• The right to education and the Right of Children to Free and Compulsory Education Act 2009, context for processing in the education sector.
• The Protection of Children from Sexual Offences (POCSO) Act 2012, reporting obligations intersect with privacy obligations for child-safety disclosures.

Manufacturing

• Employee data, biometric access control, CCTV, vehicle and asset tracking, health-and-safety data. The employee-facing notice is critical.
• Vendor and contractor data, KYC, supplier-portal data, the vendor privacy schedule.
• OT/IT convergence, operational-technology data that may identify individuals (operator logs, shift data).
• The Factories Act 1948 and state-level factory rules, health-and-safety data, accident records, the workplace privacy overlay.
• The Rights of Persons with Disabilities Act 2016, accessibility requirements extend to the notice and the policy-on-a-page.
• Cross-border transfer for multi-site manufacturing groups, group-company data flows, the negative-list screen.

Maturity Model

The L1 to L5 maturity model for Clause 5.2. Each level is described by observable characteristics, indicative Indian-segment investment to achieve and sustain the level, and the typical audit outcome.

Level 1, Compliance-only

Characteristics. Template-downloaded internal policy; template website notice; signed once; not reviewed; not communicated; not available beyond a shared drive; no fit-to-purpose; no named Indian regulator landscape; no event triggers; bundled consent; no notice-version reconstruction; no dual-clock breach commitment; no children's-data safeguards; no ADM disclosure. The classic decoration.

Audit outcome. Major nonconformity on Clause 5.2 at Stage 1. Direct DPDP penalty exposure on sections 5, 6, 8(6), 9 and 10 as applicable.

Level 2, Authored but uncommunicated

Characteristics. Authored internal PIMS policy with most of the eight sections; signed by the executive sponsor; dated; reviewed annually; hosted on the intranet in English only; no policy-on-a-page; no multilingual summary; no acknowledgement record; external notice authored with most of the twelve elements; event triggers not defined; consent records incomplete; notice-version reconstruction weak.

Audit outcome. Typically a minor nonconformity at Stage 1; closeable before Stage 2. Some DPDP exposure on the consent and notice-quality dimensions.

Level 3, Living policy and notice

Characteristics. Authored internal PIMS policy with all eight sections; signed through the correct governance chain (including board/RMC noting for SDFs, BFSI, listed entities, insurers); external notice with all twelve elements, layered, multilingual; published on intranet, public website, in-product, consent flow, vendor portal, and (where applicable) customer trust portal; awareness programme run; staff acknowledgement record at 95 percent-plus; consent-and-notice record with version reconstruction; event triggers defined and operationalised; dual-clock breach commitment named; wired into management review and internal audit; notice-to-ROPA accuracy verified annually.

Audit outcome. Stage 1 pass; Stage 2 pass with zero or one minor nonconformity on 5.2.

Level 4, Integrated and platform-hosted

Characteristics. All L3 characteristics plus: the policy and notice are hosted on a privacy-management platform or GRC-with-PIMS module; the staff acknowledgement is automated with target completion tracking; the consent-and-notice record is integrated with the consent-management platform and Consent Manager API; the notice is integrated with the ROPA so that ROPA changes propagate to the notice under Move 7 event triggers; the policy and notice are integrated with the ISMS policy, BCMS policy and (where applicable) AIMS policy; the policy and notice are tested annually via the notice-to-ROPA trace worksheet and the dual-clock breach tabletop; the board/RMC dashboard includes privacy KPIs; the customer trust portal is a sales asset.

Audit outcome. Stage 2 pass with zero nonconformities on 5.2; typically supervisor-grade (the certifying body treats the policy and notice as a benchmark).

Level 5, Predictive and benchmark

Characteristics. All L4 characteristics plus: the policy and notice are sectoral benchmark (the firm shares its architecture with industry bodies, regulators, and standards committees); the policy and notice are predictive (event triggers are monitored via horizon-scanning for regulatory change, DPDP Rules amendments, GDPR developments, new overseas instruments, and via peer-incident learning); the policy and notice are part of the firm's commercial proposition (the customer trust portal publication is a sales asset; the architecture is referenced in tender proposals); the firm's architecture is referenced by other firms; Consent Manager integration is operational and the firm's notice serves machine-readable payloads; the algorithmic-fairness review is mature for SDFs; the firm participates in DPDP-rule-making consultation through industry bodies.

Audit outcome. Continual Stage 2 pass; the policy and notice are the certifying body's reference artefact for the sector.

Maturity progression

Most Indian growing companies start at L1 and aim for L3 within the first certification cycle. L4 is the typical target for the second surveillance cycle (year 2 to 3 after certification) or for SDFs from the outset. L5 is achieved by a small minority of firms and is a multi-year investment. The Singahi toolkit and advisory are scoped to take a firm from L1 to L3 in 12 to 16 weeks and from L3 to L4 in 6 to 12 months.

Emerging Trends

Seven trends are reshaping Clause 5.2 practice in India and globally over the 2025 to 2028 horizon.

The DPDP Rules 2025 full-enforceability window

The DPDP Rules 2025 were notified on 13 November 2025 with phased commencement. The core data-fiduciary/processor obligations are widely read as reaching full enforceability approximately 18 months from notification, around May 2027 (confirm the exact date in the notified commencement rule). The window between notification and full enforceability is the implementation window. Indian growing companies that use this window to refresh the PIMS policy and the external notice, redesign the consent flow, and stand up the dual-clock breach commitment will be ready; those that wait will face the Data Protection Board's first wave of proceedings. ISO/IEC 27701:2025 Clause 5.2 is the management-system lens through which the DPDP Rules operationalisation is most defensible.

The Consent Manager ecosystem emergence

The Consent Manager (DPDP section 2(1)(g)) ecosystem is expected to emerge through 2026 and 2027 as the Data Protection Board registers the first Consent Managers and the interoperability specification is published. The Consent Manager is a distinctive Indian construct, a registered, principal-side, interoperable intermediary through which a Data Principal gives, manages, reviews and withdraws consent across multiple Data Fiduciaries. Forward-looking PIMS policies commit to Consent Manager integration now, and forward-looking consent-management platforms are Consent Manager API-ready. This is the place where the GDPR Article 7(3) "as easy to withdraw as to give" principle and the Indian Consent Manager construct converge operationally.

The SDF algorithmic-fairness overlay

DPDP section 10 makes algorithmic-AI fairness review a statutory obligation for Significant Data Fiduciaries. Combined with GDPR Article 22 (automated decision-making), the EU AI Act (Regulation (EU) 2024/1689, in force 1 February 2025), and the NIST AI Risk Management Framework (1.0, 26 January 2023), the SDF overlay creates a new category of disclosure (the notice must disclose the AI use and the logic) and a new category of governance (the algorithmic-fairness review becomes a board-visible artefact). Indian firms designated as SDFs, and any firm using AI for credit, hiring, content moderation, healthcare diagnostic assist, or marketing, should refresh the notice to address ADM explicitly and stand up the algorithmic-fairness review. Singahi's AI-governance advisory helps firms anticipate this, in conjunction with ISO/IEC 42001:2023 (AI management system).

The cross-border transfer landscape after Schrems II and the negative list

The cross-border transfer landscape remains in flux. The DPDP negative-list approach (section 16) is structurally different from the GDPR Chapter V adequacy/safeguards/derogation model, but they coexist for Indian firms with EU data subjects. The EU-US Data Privacy Framework adequacy decision (10 July 2023) for certified US companies, the modernised SCCs (Implementing Decision (EU) 2021/914), and the UK IDTA / UK Addendum to EU SCCs are the current GDPR transfer tools. The DPDP negative list will be operationalised through Central Government notifications; the first negative-list countries are not yet notified at the time of writing. PIMS policies and notices should commit to screening transfers against the negative list and implementing GDPR safeguards for non-adequate destinations, with a Schrems-II-aware transfer impact assessment.

Children's data and verifiable parental consent

DPDP section 9 and the DPDP Rules 2025 make verifiable parental consent and the child-readable notice operative for any Data Fiduciary processing children's data. This is the highest-penalty-exposure area (Schedule: up to 200 crore rupees for section 9 failure). Combined with the UK Age Appropriate Design Code, the California Age Appropriate Design Code Act, and the global trend toward age-assurance, the children's dimension is reshaping notice design across Edtech, gaming, social media, healthcare (pediatric), and any platform accessible to minors. Forward-looking PIMS policies commit to verifiable parental consent, no behavioural monitoring or targeted advertising of children, no tracking, and a child-readable notice layer.

Integrated 27001 + 27701 + 42001 governance on the harmonized structure

The ISO harmonized structure (HS / Annex SL) makes integrated governance of ISO/IEC 27001:2022 (ISMS), ISO/IEC 27701:2025 (PIMS), and ISO/IEC 42001:2023 (AIMS) a practical reality. The three Clause 5.2 policies (ISMS policy, PIMS policy, AIMS policy) can be authored as a coordinated set with shared scope, integrated risk register, joint management review, and integrated audit. Indian firms pursuing multiple certifications, particularly SaaS firms serving enterprise customers, increasingly adopt the integrated approach to reduce total cost of ownership and improve governance coherence. Singahi's integrated-management-systems advisory is built around this convergence.

Privacy by design as a machine-readable discipline

Privacy by design (Annex A.1.4 / A.2.4; GDPR Article 25) is moving from a policy commitment to a machine-readable discipline. The Notice-and-Consent API payload, the Consent Manager interoperation, the Data-Catalogue-driven ROPA, the just-in-time notice at the point of collection, the automated DSAR workflow, the sub-processor change-notification webhook, these are the operational expressions of privacy by design in a modern stack. Forward-looking PIMS policies commit to privacy by design in implementable terms (the data catalogue, the consent vault, the DSAR API, the sub-processor webhook), not just in aspiration. This is where the L4-to-L5 maturity jump lives.

References and Further Reading

This guide draws on primary instruments (Tier 1), the ISO/IEC 27xxx family of standards, Indian regulatory instruments, and established global privacy frameworks. The standards' own clause text is not reproduced; the paraphrases are Singahi's own drafting, attributed per the manifest.

ISO/IEC standards and companions

• ISO/IEC 27701:2025 Information security, cybersecurity and privacy protection, Privacy information management systems, Requirements and guidance (2nd edition, published 14 October 2025; the standard). ISO/IEC JTC 1/SC 27. The Annex B implementation guidance (B.5.2 for Clause 5.2) is normative in 2025.
• ISO/IEC 27701:2019 (1st edition), the predecessor; the official 2019-to-2025 correspondence is in 27701:2025 Annex F.
• ISO/IEC 27001:2022 Information security management systems, Requirements (5th edition; Clause 5.2; control 5.34 in the Annex A reference controls).
• ISO/IEC 27002:2022 Information security controls (6th edition; control 5.34, Privacy and protection of PII, is the only PII-specific control).
• ISO/IEC 29100:2011 Information technology, Security techniques, Privacy framework (the 11 privacy principles; a newer edition may exist, verify on iso.org).
• ISO/IEC 29134:2017 Information technology, Security techniques, Guidelines for privacy impact assessment (the DPIA methodology).
• ISO/IEC 27018:2019 Information technology, Security techniques, Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors (2nd edition).
• ISO/IEC 27017:2015 Code of practice for information security controls based on ISO/IEC 27002 for cloud services.
• ISO/IEC 29151 Code of practice for personally identifiable information protection.
• ISO/IEC 27706:2025 Requirements for bodies providing audit and certification of privacy information management systems (1st edition; the new PIMS cert-scheme standard; publication date 2025, confirm the exact date on iso.org).
• ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system (the AIMS Clause 5.2 sibling).
• ISO 22301:2019 Security and resilience, Business continuity management systems (the BCMS Clause 5.2 sibling).
• ISO 9001:2015 Quality management systems (the QMS Clause 5.2 sibling).
• ISO/IEC 20000-1:2018 Information technology, Service management (the SMS Clause 5.2 sibling).
• ISO/IEC 27000 family vocabulary.
• ISO 31000 Risk management.

Indian regulatory instruments

• Digital Personal Data Protection Act 2023 (Act No. 22 of 2023, enacted 11 August 2023; eGazette notification 247847). meity.gov.in.
• Digital Personal Data Protection Rules 2025 (draft 3 January 2025; final notified 13 to 14 November 2025; phased commencement). meity.gov.in.
• Information Technology Act 2000 (Act 21 of 2000; amended 2008), sections 43, 43A, 72A. indiacode.nic.in.
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011 (notified 11 April 2011). meity.gov.in.
• Indian Computer Emergency Response Team, Directions under section 70B(6) of the IT Act 2000 (No. 20(3)/2022-CERT-In, 28 April 2022). cert-in.org.in.
• Reserve Bank of India, Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 (31 July 2026). rbi.org.in.
• Reserve Bank of India, Master Direction on Digital Lending (DOID.CO.PPG.SEC.09/14.14.001/2022-23, 2 September 2022). rbi.org.in.
• Reserve Bank of India, Tokenisation of card transactions (DPSS.CO.RPPD.No.S-35/07.01.005/2021-22, 22 September 2021; full effect 1 October 2022). rbi.org.in.
• Reserve Bank of India, Storage of Payment System Data (DPSS.CO.OD.No.1098/06.08.005/2017-18, 6 April 2018). rbi.org.in.
• Reserve Bank of India, Managing Risks in Outsourcing Directions, 2025 (28 November 2025). rbi.org.in.
• Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024). sebi.gov.in.
• Securities and Exchange Board of India, KYC Registration Agencies Regulations 2011 (as amended; Master Circular May 2024). sebi.gov.in.
• Securities and Exchange Board of India, Guidelines for Business Continuity Plan and Disaster Recovery of Market Infrastructure Institutions (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021). sebi.gov.in.
• Insurance Regulatory and Development Authority of India, Information and Cyber Security Guidelines 2023 (24 April 2023). irdai.gov.in.
• Companies Act 2013 (Act 18 of 2013), section 134(3)(n) and section 177; SEBI LODR Regulation 21. mca.gov.in; sebi.gov.in.
• Consumer Protection (E-Commerce) Rules 2020 (notified under the Consumer Protection Act 2019).
• Rights of Persons with Disabilities Act 2016.
• Right of Children to Free and Compulsory Education Act 2009.
• Protection of Children from Sexual Offences (POCSO) Act 2012.
• Medical Council of India telemedicine guidelines (2020).
• New Drugs and Clinical Trials Rules 2019.

Constitutional and jurisprudential foundations

• K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1 (nine-judge Bench, judgment delivered 24 August 2017), the right to privacy as a fundamental right under Articles 14, 19, 21.
• Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1 (five-judge Bench, judgment delivered 26 September 2018), upholding Aadhaar in large part; striking down section 57; the proportionality test.

Global frameworks

• Regulation (EU) 2016/679 (General Data Protection Regulation, GDPR). OJ L 119, 4.5.2016, p. 1; applies from 25 May 2018. eur-lex.europa.eu.
• Regulation (EU) 2024/1689 (EU AI Act). eur-lex.europa.eu; in force 1 February 2025.
• Commission Implementing Decision (EU) 2021/914 (modernised Standard Contractual Clauses). eur-lex.europa.eu.
• European Commission, EU-US Data Privacy Framework adequacy decision (10 July 2023).
• Case C-311/18, Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (Schrems II), CJEU Grand Chamber, judgment 16 July 2020.
• European Data Protection Board, Guidelines 4/2019 on Article 25 (data protection by design and by default); Guidelines 05/2020 on consent; Guidelines 9/2022 on personal data breach notification; Recommendations 01/2020 on supplementary measures.
• Article 29 Working Party, WP248 rev.01, Guidelines on Data Protection Impact Assessment.
• ICO (UK) Accountability Framework; CNIL (France) PIA methodology (which cross-references ISO/IEC 29134).
• UK GDPR; Data Protection Act 2018 (c. 12); UK International Data Transfer Agreement (IDTA) and UK Addendum to EU SCCs; UK Age Appropriate Design Code.
• NIST Privacy Framework v1.0, A Tool for Improving Privacy Through Enterprise Risk Management (NIST.CSWP.01162020, 16 January 2020). nist.gov/privacy-framework.
• NIST AI Risk Management Framework 1.0 (26 January 2023). nist.gov.
• NIST post-quantum cryptography standards, FIPS 203, 204, 205 (finalised August 2024).
• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (TSC 2017, with 2022 points-of-focus update). aicpa.org.
• California Consumer Privacy Act / California Privacy Rights Act, Cal. Civ. Code 1798.100 et seq.; California Age Appropriate Design Code Act.
• Virginia Consumer Data Protection Act, Va. Code section 59.1-575 et seq.
• Colorado Privacy Act, C.R.S. section 6-1-1301 et seq.
• Connecticut Data Privacy Act, Public Act 22-15.
• Utah Consumer Privacy Act, Utah Code section 13-61-101 et seq.
• Brazil, Lei 13.709/2018 (LGPD).
• Canada, Personal Information Protection and Electronic Documents Act, 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) + 2020 amendment.
• Japan, Act on the Protection of Personal Information (Act No. 57 of 2003, as amended).
• Australia, Privacy Act 1988 + Australian Privacy Principles + Notifiable Data Breaches scheme.
• South Korea, Personal Information Protection Act (Act No. 10469, 2011, as amended 2023).
• UAE, Federal Decree-Law No. 45 of 2021.
• Saudi Arabia, Personal Data Protection Law, Royal Decree M/19.
• South Africa, Protection of Personal Information Act, Act 4 of 2013.
• Israel, Protection of Privacy Law 5741-1981 + Protection of Privacy Regulations (Transfer of Data to Databases Abroad) 5774-2014.

Citable incident anchors (primary-sourced)

These are referenced in the guide for the lessons they teach. The reader is encouraged to consult the primary sources.

• MobiKwik 2021 event, researcher disclosure; contested by the company; the case is referenced as the marquee Indian payments-data controversy.
• Juspay 18 January 2021 event, approximately 35 million records; publicly acknowledged by the company.
• BigBasket 2020 event, approximately 20 million records alleged; reported in mainstream media.
• Air India / SITA breach (disclosed February-May 2021), approximately 4.5 million customers affected; reported in Reuters and the company's regulatory notifications.
• Lukup / other Indian cyber events.
• AIIMS Delhi ransomware (23 November 2022), healthcare-sector anchor.
• Infosys McCamish Systems LockBit (October 2023), approximately 6 million individuals affected; reported 17.5 million US dollar class-action settlement.

A reading note on contested attribution and unverified claims

In keeping with the accuracy rules in the standards-factory authoring contract: the MobiKwik 2021 event figures are contested (the company disputes the researcher's disclosure); the Madhur Payments illustrative scenario in Section 14 is illustrative and does not assert the contested MobiKwik figures as fact. Most Indian-firm rupee-loss figures are not publicly disclosed; specific numbers in this guide are attributed to primary sources (regulator orders, SEC filings, peer-reviewed studies, company disclosures) or marked illustrative. The Singahi authoring principle is to mark anything second-hand "reported" or "illustrative" and to present both positions where attribution is contested.

© Singahi. This guide is provided for the receiving organisation's internal use. The paraphrased requirement and the sample clauses are Singahi's own drafting. ISO/IEC 27701:2025's clause text is not reproduced. All framework references are to public instruments named; verify current versions on the issuing body's official portal before relying on them.