ISO 27701 Clause 5.3: Roles, Responsibilities and Authorities

Quick Reference (60 Seconds)

If you only read one thing: Clause 5.3 is where the PIMS stops being a programme and becomes a set of named people with real authority. A 5.3-conformant PIMS is one in which every privacy job is owned by a named, competent, authorised role-holder whose name is on the intranet, on the public notice, on the regulator Point of Contact form, and in the management-review pack, not one in which "the company" owns privacy in the abstract. The certification auditor will trace a privacy event from trigger to role-holder to action, and the Data Protection Board of India will ask who the DPO is, who the Grievance Officer is, and who made the breach-notification decision. Get 5.3 wrong, unnamed roles, ungranted authorities, an SDF without a statutory DPO, a Grievance Officer who is an inbox, and however strong the policy, the ROPA, the DPIA and the security controls, the certificate will be at risk and the DPDP section 10 exposure will be live. Get it right, and every other clause becomes easier to evidence because the people are in place.

What the Standard Actually Requires

The paraphrased requirement

ISO/IEC 27701:2025 Clause 5.3 asks organizations to assign and communicate privacy roles, responsibilities, and authorities. Three verbs do the work in that paraphrase.

The roles must be assigned. Specific, named people hold specific privacy jobs. The standard does not enumerate the jobs, that is left to the organisation's structural-model choice (Section 7 Move 1), but the standard's companion guidance, the Annex B normative implementation guidance, and the cross-framework anchors (DPDP section 10; GDPR Articles 37 to 39; NIST Privacy Framework Govern-P; ISO/IEC 27001:2022 Clause 5.3) converge on a small set of jobs every PIMS needs: an executive sponsor, a privacy lead (the DPO where the role is statutory or where the organisation elects to name one), a governance body (the PIMS Steering Committee or equivalent), data owners, processor-relationship owners, and an internal auditor. The DPDP overlay adds the Grievance Officer, the CERT-In Point of Contact, the Consent Manager liaison, and the SDF officer for section 10 designees.

The responsibilities must be communicated. The people in the roles know what they own. The people who depend on them know who to go to. The auditor can find the role set in writing. The communication has three audiences, internal (staff, contractors, interns, processors' staff where contractually obligated), external (PII principals, the Data Protection Board of India, the CERT-In authority, sector regulators, customers), and the board / Risk Management Committee for governance visibility. The internal communication is the intranet publication of the role-on-a-page, the induction briefing, and the awareness programme reference. The external communication is the disclosure of the DPO and Grievance Officer contacts in the privacy notice (DPDP section 5; GDPR Articles 13 to 14), the filing of the CERT-In Point of Contact with CERT-In, and the regulator-facing identification of the DPO for SDF registration under DPDP section 10. The board communication is the role set in the management-review pack and, for SDFs and listed entities, the formal board or RMC noting.

The authorities must be assigned and communicated in the same breath. This is the part most Indian growing companies miss. A role is not a job description; it is a job description plus the authority to do the job. The DPO must have the authority to halt infringing processing (DPDP section 8 read with the section 10 SDF DPO function; GDPR Article 38(3) analogue, the DPO cannot receive instructions on how to exercise the role). The Grievance Officer must have the authority to issue substantive responses under DPDP section 13 within the prescribed period, not to forward every grievance to a manager. The Consent Manager liaison must have the authority to integrate with registered Consent Managers and to honour withdrawal signals across systems. The processor-relationship owner must have the authority to invoke the infringing-instruction process under Annex A.2.2.5, to push back on a controller's instruction that infringes DPDP, GDPR or another law. The internal auditor must have the authority to access any PIMS artefact without permission-filtering. Without the authorities, the role set is names on a page.

The triplet: assign, communicate, authorise

The three verbs are not a checklist. They are a triplet that must be delivered together. The most common 5.3 failure is to deliver one or two of the three and omit the third.

• Assignment without communication produces the "phantom DPO", the executive sponsor appointed a DPO in 2022, signed the appointment letter, and filed it. Nobody else in the organisation knows who the DPO is. The auditor samples staff and finds zero awareness. Major nonconformity.
• Assignment without authorities produces the "DPO in name only", the DPO is named and communicated, but has no authority to halt infringing processing, no seat on the product-launch committee, no escalation path to the board for SDFs. When a real breach happens, the DPO cannot act. Major nonconformity, and the post-incident regulatory examination will name the gap.
• Communication without assignment produces the "policy says we have a DPO" pattern, the privacy policy and the public notice name a DPO, but no appointment letter exists, no charter exists, no competency profile exists. The DPO is a marketing claim. Major nonconformity, and a misrepresentation exposure to the Data Protection Board.
• Authorities without assignment is rarer but appears in matrix organisations where a generic "Privacy Function" is granted authority but no named person holds it. The auditor asks "who exercises this authority?" and gets no answer.

A 5.3-conformant PIMS has all three: a named role-holder with a charter (assignment), an intranet and notice disclosure (communication), and an explicit grant of authority (authorisation). All three are evidenced in writing; all three are version-controlled; all three are reviewed at the management review.

The structural-model question the standard does not answer

This is the marquee conceptual point in this guide and the place where most competitor content either asserts a single answer or skips the question. ISO/IEC 27701:2025 Clause 5.3, like its harmonized-structure siblings, does not prescribe a single privacy organisational model. It does not say whether the DPO should be senior to, peer to, or junior to the CISO. It does not say whether the privacy programme should sit in Legal, in Compliance, in Security, in Risk, or as a standalone function. It does not say whether the DPO must be a single named individual (GDPR Article 37 does, for the formal DPO role; DPDP section 10 does, for the SDF DPO; ISO/IEC 27701:2025 itself does not). The practitioner research base is explicit that the answer depends on the organisation's context (Clause 4.1), its interested parties (Clause 4.2), its scope (Clause 4.3), its risk assessment (Clause 6.1.2), and its size and structure.

This guide therefore presents three structural models in Section 7 Move 1, with a decision framework for choosing among them, rather than asserting one. The three models are: the DPO-centred model (a standalone privacy function with the DPO at its head, common in SDFs, BFSI, healthcare and large enterprise); the privacy-team-centred model (a cross-functional privacy team with a Privacy Lead, common in growing SaaS, ITeS and digital-first firms where privacy is distributed across engineering, product and legal); and the CISO-extended model (the CISO extends the ISMS to cover PIMS, common in growing companies where the CISO is the senior security-and-privacy officer and a dedicated privacy function is not yet warranted). Each model has a profile, a fit profile, a risk profile, and a cost profile; each is defensible under Clause 5.3 if the role charter set is complete and the authorities are granted. The DPDP section 10 overlay constrains the choice for SDFs (a statutory India-based DPO accountable to the board is non-negotiable) but does not remove the structural choice around that role.

The DPDP overlay: where Indian law prescribes what the standard leaves open

The DPDP Act 2023 and the DPDP Rules 2025 (notified 13 November 2025) prescribe four privacy roles that ISO/IEC 27701:2025 Clause 5.3 leaves to the organisation's discretion. For an Indian Data Fiduciary, these are not optional.

DPDP section 10 SDF DPO. A Significant Data Fiduciary designated by the Central Government under section 10 must appoint a Data Protection Officer based in India, accountable to the Board of Directors or the governing body. The DPO is the point of contact for the Data Protection Board of India and for Data Principals. The SDF DPO overlays the ISO/IEC 27701:2025 role set with a statutory role that cannot be devolved, offshored, or structurally subordinated. The DPO's accountability runs to the board, not to the executive sponsor, this is a stricter independence standard than ISO/IEC 27701:2025 itself sets. The role-appointment letter, the board-minute noting the accountability, and the India-based office evidence are the three artefacts the Data Protection Board will ask for first.

DPDP section 13 Grievance Officer. Every Data Fiduciary (not only SDFs) must provide a readily available means for Data Principals to lodge grievances and must respond within the period prescribed under the DPDP Rules 2025. The Grievance Officer is the role that owns this. ISO/IEC 27701:2025 Clause 5.3 does not name a Grievance Officer; the DPDP Act does. For an Indian Data Fiduciary, the Grievance Officer is part of the PIMS role set, with a charter, a contact channel disclosed in the privacy notice, and a tracked response-time KPI.

DPDP section 2(1)(g) Consent Manager liaison. A Consent Manager 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 multiple Data Fiduciaries. The Consent Manager is a distinctive Indian construct with no clean GDPR, NIST or SOC 2 analogue. The Data Fiduciary's role set must include a Consent Manager liaison, the role that owns the API integration with registered Consent Managers, the honouring of withdrawal signals, the interoperation testing, and the consent-record synchronisation. For most growing companies this is a Privacy Lead or Product Engineer role with the Consent Manager liaison as a designated responsibility; for SDFs and consumer-facing firms it may warrant a dedicated role.

CERT-In Point of Contact. The CERT-In Directions 20(3)/2022-CERT-In (28 April 2022), issued under section 70B(6) of the IT Act 2000, apply horizontally to every ICT operator in India. Among the six headline obligations is the appointment of a Point of Contact for CERT-In. The Point of Contact is the role that receives CERT-In communications, files the 6-hour prescribed cyber incident report, coordinates with CERT-In during investigations, and is reachable 24x7. ISO/IEC 27701:2025 Clause 5.3 does not name this role; CERT-In does. For an Indian Data Fiduciary, the CERT-In Point of Contact is part of the PIMS role set, with a 24x7 reachability design (typically a role-pair or a follow-the-sun arrangement) and a documented handover protocol.

The DPDP overlay also creates sector-specific role obligations. The RBI Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 (31 July 2026) require a Chief Information Security Officer for banks and NBFCs. The SEBI Cybersecurity and Cyber Resilience Framework (20 August 2024) requires a Chief Information Security Officer and a Privacy Officer for SEBI Regulated Entities. The IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023) requires a CISO for insurers. These sectoral role obligations layer onto the PIMS role set for firms in those sectors.

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

Clause 5.3 is widely misread as a job-description exercise. That misreading produces the single most common 5.3 nonconformity: organisations that author role descriptions and stop. Being explicit about what 5.3 does not require protects against both under-investing (a role description in a drawer) and over-reaching (an organisational redesign in the name of privacy).

• 5.3 does not require a specific organisational structure. ISO/IEC 27701:2025 does not mandate a Privacy Department, a DPO reporting line, a Privacy Committee composition, or any particular named forum. DPDP section 10 constrains the choice for SDFs (DPO based in India, accountable to the board); GDPR Articles 37 to 39 constrain the choice for organisations subject to GDPR (DPO designation criteria, position, tasks). For most other organisations, the structural choice is the organisation's to make. The Singahi three-model decision framework in Section 7 Move 1 is a way through that choice.
• 5.3 does not require the DPO to be full-time. For SDFs under DPDP section 10, the DPO must be a real role with real accountability, but the statute does not say "full-time." For non-SDFs, the DPO/Privacy Lead is commonly fractional (0.2 to 0.8 FTE) in growing companies and may be an external DPO-as-a-service. The test is whether the role has the time, the competency and the authority to do the job, not whether the role-holder has a single employer.
• 5.3 does not require a Privacy Committee. Many Indian firms maintain a PIMS Steering Committee; this is permitted and encouraged, but not required. The required artefact is the role set, the RACI and the authorities register. A Privacy Committee is one of several governance bodies that can deliver those artefacts.
• 5.3 does not require the DPO to be a lawyer. GDPR Article 37(5) refers to "expert knowledge of data protection law and practices", that can be acquired through experience, certification or training, not only through a law degree. DPDP section 10 does not prescribe a professional qualification for the DPO. The competency profile per Clause 7.2 is the artefact that evidences competence, not a particular degree. For SDFs with algorithmic-AI fairness review obligations, the DPO is well-advised to have or to have access to technical/AI literacy, not only legal literacy.
• 5.3 does not require every role to be a separate person. At small sizes, one person may hold multiple privacy roles, the DPO may also be the Grievance Officer, the Privacy Lead may also be the Consent Manager liaison. The constraint is conflict of interest: the internal auditor cannot also be the DPO (independence); the role that grants consent cannot also be the role that audits consent (segregation of duties); the role that processes personal data of staff cannot also be the role that hears staff grievances about that processing. The segregation-of-duties map (Section 7 Move 4) makes the integration explicit and the reasons recorded.
• 5.3 does not require board approval of every appointment. Top-management assignment is required (Clause 5.1). For SDFs under DPDP section 10, board 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 executive sponsor's signature plus the HR onboarding record suffices.
• 5.3 does not require the role set to be public. The internal role set is hosted on the intranet. The external notice must disclose the DPO contact and the Grievance Officer contact (DPDP section 5; GDPR Articles 13 to 14) because the law requires it; the broader internal role set is private. Conflating the two is a 5.3 failure mode, publishing every role-holder's name on the internet exposes staff to social engineering and undermines the role architecture.
• 5.3 does not require a specific DPO reporting line for non-SDFs. GDPR Article 38(3) says the DPO cannot receive instructions on how to exercise the role; that is an independence standard, not a reporting-line mandate. For non-SDFs, the DPO can report to the CEO, the COO, the General Counsel, the CISO (with caveats) or the board, the test is independence, not hierarchy. For SDFs, the board-accountability requirement (DPDP section 10) sets the floor.
• 5.3 does not require variable-pay linkage to role performance. Pay linkage is a leading-practice signal of L4 to L5 maturity, not a standard requirement.

The companion guidance, Annex B is normative in 2025

The clause text on roles is short across all harmonized-structure standards. 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.3 specifically, the Annex B guidance (numbered B.5.3 to mirror the clause) explains how the role set should be structured, what the role communication should cover, and how the authorities should be evidenced. The Annex B guidance should be treated as testable, not optional.

Five external anchors are most relevant for Clause 5.3.

• ISO/IEC 27001:2022 Clause 5.3 is structurally identical. If your organisation runs an integrated ISMS+PIMS, a single integrated role charter set can satisfy both clauses (with clearly labelled sub-sections for ISMS-relevant and PIMS-relevant responsibilities), or two aligned charter sets can sit side-by-side. The CISO and the DPO are sibling roles; the Singahi decision framework in Section 7 Move 1 helps an organisation decide whether to combine them at small sizes or separate them at scale.
• GDPR Articles 37 to 39 are the densest external content standard for the DPO role. Article 37 sets the designation criteria (when a DPO is required, public authority, core activities of large-scale regular and systematic monitoring, core activities of large-scale processing of special categories). Article 38 sets the position (no conflict of interest, no instructions on how to exercise the role, direct reporting to the highest management level, voice in PIMS-relevant decisions). Article 39 sets the tasks (advice, monitoring, cooperation with the supervisory authority, point of contact for data subjects). For Indian firms with EU data subjects, GDPR Articles 37 to 39 and DPDP section 10 jointly shape the DPO role; the SDF DPO obligation is in many respects stricter (India-based, board-accountable).
• NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020), the Govern-P function (governance structure, privacy roles, risk-management strategy, policy) is the US-flavoured structural analogue of Clause 5.3. The NIST PF does not prescribe a structure either; it asks the organisation to articulate its roles explicitly.
• SOC 2 (AICPA TSC 2017, with 2022 points of focus), Common Criteria CC1 (Control Environment) and the Privacy criteria P1.0, P5.0, P8.0, CC1.0 to CC1.5 set the control-environment expectations (board oversight, structure, accountability, human-resources policies, performance); P5.0 (Access) requires a designated role to handle data-subject access requests; P8.0 (Monitoring and enforcement) requires roles for monitoring and enforcement.
• ISO/IEC 27002:2022 control 5.34 (Privacy and protection of PII), the only PII-specific control in 27002, explicitly identifies the roles and responsibilities for PII processing. This is the operational bridge between the ISMS Clause 5.3 role set and the PIMS Clause 5.3 role set.

What auditors actually check

The certification auditor's Clause 5.3 examination has eight predictable moves.

First, the auditor opens the role charter set. Is there a charter for each privacy role? Does each charter name a role-holder? Is each charter signed (assigned)? Does each charter include the authorities granted? If any of the six core roles (sponsor, DPO/Privacy Lead, Steering Committee, data owners, processor-relationship owners, internal auditor) lacks a charter, minor nonconformity. If the DPO role lacks a charter for an SDF, major nonconformity.

Second, the auditor asks for the DPDP overlay roles. Is the section 10 SDF DPO appointed? Is the appointment letter on file? Is the board-minute noting the accountability on file? Is the DPO based in India (evidence of India-based office, India-based reporting line)? Is the section 13 Grievance Officer named and contactable? Is the CERT-In Point of Contact filed with CERT-In? Is the Consent Manager liaison identified?

Third, the auditor traces the RACI. The auditor names a privacy event, a DSAR, a breach, a Consent Manager withdrawal, a sub-processor change, a new processing activity, and traces it through the RACI to a named role-holder. If the chain breaks (an activity unassigned, an R/A ambiguity, a role that does not exist), minor or major nonconformity depending on the break.

Fourth, the auditor tests the authorities. Can the DPO describe the authority to halt infringing processing? Has that authority ever been exercised (incident log)? Can the Grievance Officer describe the authority to issue section 13 responses? Can the internal auditor describe the authority to access any PIMS artefact? Can the processor-relationship owner describe the authority to invoke the infringing-instruction process under A.2.2.5? If the authorities are in the charter but have never been exercised and cannot be articulated, minor nonconformity.

Fifth, the auditor samples staff. "Who is the DPO? Who is the Grievance Officer? If you spotted a privacy problem, who would you tell?" Five randomly-sampled staff across functions and locations. If three out of five cannot answer, communication failure, minor nonconformity. If four out of five cannot answer, major nonconformity.

Sixth, the auditor checks the external disclosure. Does the privacy notice disclose the DPO and Grievance Officer contacts (DPDP section 5; GDPR Articles 13 to 14)? Is the contact channel live (an email that gets answered; a phone number that gets picked up)? Is the CERT-In Point of Contact filed and current?

Seventh, the auditor checks the competency evidence. For each named role-holder, is there a competency profile per Clause 7.2? Is there evidence of continuing competence (training records, certifications, experience log)? For the DPO, is there evidence of "expert knowledge of data protection law and practices" (GDPR Article 37(5) language, relevant for firms with EU data subjects; useful for all DPOs as a competency benchmark)?

Eighth, the auditor traces the role set into the management review (Clause 9.3), the internal audit programme (Clause 9.2), and the HR system. Is the role set reviewed at the management review? Is the internal audit testing the role set every cycle? Are the role descriptions in the HR system, linked to performance reviews, and tracked for succession? A role set that is not traced into the management system is decoration.

Why This Control Matters

The roles as the operating system of the PIMS

Every other clause and annex of ISO/IEC 27701:2025 is delivered by the role set Clause 5.3 names. The privacy policy (Clause 5.2) is authored, signed, communicated and maintained by named role-holders. The privacy risk assessment (Clause 6.1.2 and 8.2) is performed by the DPO/Privacy Lead with the data owners. The ROPA (Clause 8 and Annex A.1.2.x) is maintained by the data owners. The DPIAs (Annex A.1.2.5) are performed by the DPO with the process owners. The consent management (Annex A.1.2.3 / A.1.2.4) is owned by the Consent Manager liaison with Product. The data-principal-rights workflow (Annex A.1.3.x) is owned by the Grievance Officer. The processor oversight (Annex A.2) is owned by the processor-relationship owners. The breach playbook (Clause 8 and Annex A.3) is activated by the CERT-In Point of Contact with the DPO and the executive sponsor. The internal audit (Clause 9.2) is run by the internal auditor. The management review (Clause 9.3) is convened by the executive sponsor with the DPO. Corrective action (Clause 10.2) and continual improvement (Clause 10.1) are driven by the role set. Without 5.3, the rest of the PIMS has no hands.

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 with an unnamed or unauthorised role set is, in auditor language, a "system without assigned ownership", which is one of the most serious structural nonconformities a PIMS can carry. A PIMS with a named and authorised role set whose Grievance Officer is uncontactable or whose DPO is not based in India is, in DPDP language, a Data Fiduciary in breach of section 10 (for SDFs) or section 13 (for the Grievance Officer), exposing the organisation to penalties up to 150 crore rupees per the Schedule.

The Indian regulatory weight behind 5.3

In India, Clause 5.3 has a regulatory weight that goes 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 through approximately May 2027 for full enforceability of the core obligations) make the role set a statutory requirement for every Data Fiduciary, with a stricter overlay for Significant Data Fiduciaries. 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 and struck down section 57 of the Aadhaar Act (private-body use of Aadhaar for commercial purposes). 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. ISO/IEC 27701:2025 was published on 14 October 2025, twelve days before the DPDP Rules were notified. The two instruments are, in effect, made for each other; the role set is where they connect most directly.

The DPDP Act and Rules bear on Clause 5.3 across at least eight provisions.

DPDP section 5 (notice) requires the Data Fiduciary to disclose, in the notice to the Data Principal, the means by which the Data Principal can exercise their rights and the mechanism for grievance redressal. This is a role-disclosure obligation: the Grievance Officer must be named, with a contact channel.

DPDP section 8 (general obligations of Data Fiduciary) places the reasonable-security-safeguards duty (section 8(5)), the breach-notification duty (section 8(6), operationalised by Rule 7 as the 72-hour clock to the Board), and the erasure duty (section 8(7)) on the Data Fiduciary. These duties are owned by named role-holders, the DPO/Privacy Lead, the CISO (for safeguards), the breach-notification role-pair (the DPO and the CERT-In Point of Contact).

DPDP section 10 (Significant Data Fiduciary) is the marquee 5.3 overlay. SDFs must appoint a DPO based in India accountable to the board; 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. Each of these obligations attaches to a named role, the DPO owns the DPIP programme; the internal auditor or an external auditor owns the independent data audit; a designated role owns the algorithmic-fairness review.

DPDP section 13 (grievance redressal) requires every Data Fiduciary to provide a readily available means for Data Principals to lodge grievances and to respond within the prescribed period. The Grievance Officer is the role that owns this.

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 DPO is the Board's primary point of contact with the Data Fiduciary; the DPO and the executive sponsor are the role-pair that handles Board proceedings.

DPDP section 2(1)(g) Consent Manager. The Consent Manager ecosystem is expected to emerge through 2026 and 2027 as the Board registers the first Consent Managers. The Data Fiduciary's Consent Manager liaison is the role that owns the integration, the withdrawal-signal honouring, and the interoperation testing.

CERT-In Directions 20(3)/2022-CERT-In (28 April 2022). Apply horizontally to every ICT operator in India. The Point of Contact role is mandatory. The 6-hour prescribed-incident-report clock runs from noticing; the Point of Contact must be reachable 24x7.

Sectoral overlays. The RBI Cybersecurity Directions 2026 (31 July 2026) require a Chief Information Security Officer for banks and NBFCs (this role often co-holds the PIMS privacy lead for non-SDF BFSI firms). The SEBI CSCRF (20 August 2024) requires a CISO and a Privacy Officer for SEBI Regulated Entities. The IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023) requires a CISO for insurers and ICT-outsourcing data-protection clauses. The IT Act 2000 sections 43A and 72A and the SPDI Rules 2011 (the pre-DPDP baseline) place body-corporate obligations that survive alongside DPDP. The 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 privacy risk in scope, the role set must be visible to the Audit Committee and the RMC.

In aggregate: in India, an assigned, communicated, authorised privacy role set is not optional, it is a multi-regulator requirement with monetary penalties attached (DPDP up to 250 crore rupees for section 8(5) failure; up to 200 crore rupees for section 8(6) or section 9 failure; up to 150 crore rupees for section 10 failure; RBI enforcement; SEBI penalties; IRDAI direction; CERT-In action). The ISO/IEC 27701:2025 Clause 5.3 role set is the natural single architecture that satisfies all of these regimes simultaneously.

The cost of non-compliance

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

Direct DPDP penalty exposure for SDFs that fail the section 10 DPO appointment is up to 150 crore rupees per the Schedule. But the Schedule is the headline ceiling, and the role-set 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 role-set failure that produces a delayed breach notification, a mishandled DSAR, or an unanswered grievance can support a finding of inadequate governance under section 8 general obligations, a section 43A compensation claim, and parallel proceedings by sector regulators (RBI ombudsman, SEBI investor grievance, IRDAI grievance redressal). For listed entities, a material role-set failure (the DPO resigns and is not replaced; the Grievance Officer is uncontactable for an extended period) 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, 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), MobiKwik (contested allegations, denied by the company), all carried commercial costs in churn, brand damage, customer-acquisition drag, and regulatory scrutiny. In every case the post-incident regulatory and litigation examination tested the role set: who knew what, who decided what, who notified whom. A role set that cannot withstand that examination amplifies the commercial cost.

Certification cost is the most immediate for ISO/IEC 27701:2025 candidates. A Clause 5.3 minor nonconformity at Stage 2 delays the certificate issue by 4 to 12 weeks. 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 role set is increasingly a board-level artefact, not a management artefact. Section 134(3)(n) of the Companies Act 2013 places the risk-management policy statement in the Board's Report; section 177 and SEBI LODR Regulation 21 place 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 role set 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 role charter set must be board-presentable. That means short (typically a one-page summary charter for each role; the full charter in appendices), well-structured, free of jargon, dated, version-controlled, and accompanied by a one-page executive summary suitable for the board pack. The DPO presents the role set at the management review (Clause 9.3); the board reviews it through the Risk Management Committee at minimum annually and on event trigger (DPO change, SDF designation change, M&A, audit nonconformity).

Scope and Applicability

By organisation size

Growing companies (50 to 250 staff). A compact role set: an executive sponsor (typically the CEO/MD or COO), a DPO/Privacy Lead (often fractional, 0.2 to 0.6 FTE, or an external DPO-as-a-service), a small PIMS Steering Committee (the sponsor, the DPO, the CISO, the Head of Legal, the Head of HR, five people meeting monthly), a handful of data owners (one per major processing domain, customer, employee, vendor), a processor-relationship owner (often the Head of Delivery or the COO), and an internal auditor (often shared with the ISMS internal auditor or co-sourced). The DPDP overlay adds the Grievance Officer (often the DPO wearing a second hat), the CERT-In Point of Contact (often the CISO wearing a second hat), and the Consent Manager liaison (often a Product Engineer). The structural model is typically CISO-extended or Privacy-lead-centred; the SDF overlay, if applicable, requires a statutory India-based DPO. The first cycle (assign, communicate, authorise) is deliverable in 4 to 8 weeks of internal effort plus optional external advisory.

Mid-market (250 to 2,000 staff). A fuller role set: the DPO is typically a full-time role (or a fractional role at the upper end of the band with a Deputy DPO); the PIMS Steering Committee expands (sponsor, DPO, CISO, Heads of Legal, Compliance, HR, Product, Marketing, plus business-unit representatives); data owners are named per processing domain; processor-relationship owners are named per major customer or vendor segment; the internal auditor is dedicated or co-sourced with audit-firm independence. The DPDP overlay roles are typically dedicated or pair-held. The structural model is typically privacy-team-centred or DPO-centred.

Multi-entity enterprise (2,000-plus staff or multi-site). A group role taxonomy typically sits above entity-level roles. The group DPO leads a privacy function with entity-level DPOs or Privacy Leads; the group PIMS Steering Committee includes group-level executives; data owners are matrix-managed across entity and function; the internal audit is a dedicated privacy audit team or a co-sourced audit firm. The DPDP overlay is dense: for SDFs, the group DPO is the board-accountable role; entity-level DPOs cascade the obligations locally. Multi-jurisdiction role architecture is required for firms with overseas data subjects (a GDPR Article 27 representative for non-EU firms serving EU data subjects; entity-level DPOs for jurisdictions that require local presence).

By controller/processor role

The single most consequential scoping decision for Clause 5.3 (after the structural-model decision in Section 7 Move 1) is the controller/processor role declaration, are you a PII controller (Data Fiduciary under DPDP), a PII processor (Data Processor under DPDP), or both across the PIMS scope? The RACI differs by role.

PII controller only. The role set emphasises the principal-facing roles: the DPO owns the Annex A.1 controls (conditions, notice, consent, rights, transfer); the Grievance Officer owns the section 13 grievance workflow; the Consent Manager liaison owns the Consent Manager integration; the data owners own the principal-data processing activities. The processor-relationship owner role is light (controllers have processors but the work is oversight, not delivery). The role set carries the full DPDP penalty exposure under the Schedule.

PII processor only. The role set emphasises the controller-facing roles: the DPO/Privacy Lead owns the Annex A.2 controls (processor conditions, infringing-instruction process, sub-processor management); the processor-relationship owner owns the customer-DPA execution and the breach-notification SLA to the controller; the breach-notification role is the role that notifies the controller (who then notifies the Board and the principal). The Grievance Officer role is light, the processor does not generally have a direct principal-facing grievance duty under DPDP; grievances route through the controller. The Consent Manager liaison is light unless the processor's customers elect Consent Manager use. The penalty exposure runs through the controller but the processor has its own DPDP section 8 obligations (reasonable security, breach notification to the controller, processing only on documented instructions).

Both controller and processor. Most Indian growing companies of any scale are both. The role set covers both Annex A.1 and Annex A.2; the RACI splits into controller activities, processor activities and shared activities. The DPO is typically common across both tracks; the data owners and processor-relationship owners differ. 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 role set covers the DPDP Act, DPDP Rules, IT Act/SPDI, sectoral regulation if any, and the relevant state-level instruments. The DPO is India-based (statutory for SDFs; recommended for all). The CERT-In Point of Contact is reachable during Indian business hours and on-call.

Pan-India operations. The role set covers DPDP Act + Rules, IT Act/SPDI, CERT-In Directions, sectoral regulation, and multi-state operations. The DPO is India-based; the CERT-In Point of Contact is 24x7 (typically a follow-the-sun arrangement across Indian offices). Multi-state data-owner coverage.

India-plus-overseas operations. The role set must reconcile ISO/IEC 27701:2025 with the overseas regulator regime, GDPR for EU/EEA data subjects (Article 27 representative for non-EU firms; DPO per Articles 37 to 39 where required), 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 DPO is typically the global privacy role-holder for Indian-parent firms; entity-level DPOs or Privacy Leads operationalise locally. The role set must address the cross-border transfer impact assessment owner (DPDP section 16 negative-list; GDPR Chapter V).

Key Definitions and Terminology

Clause 5.3 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.

Role, responsibility, authority

In ISO management-system usage, a role is a defined set of responsibilities and authorities assigned to a person or group. A responsibility is an obligation to perform a task or achieve an outcome. An authority is the right, granted explicitly, to make decisions, take actions, and direct resources within the role's scope. The triplet is the operating unit of any management system. Clause 5.3 requires the organisation to assign all three: name the role-holder, document the responsibilities, grant the authorities.

Data Protection Officer (DPO)

The Data Protection Officer is the role-holder responsible for the organisation's privacy compliance programme. GDPR Article 37 sets the designation criteria (when required), Article 38 sets the position (independence, reporting line, no conflict of interest), Article 39 sets the tasks (advice, monitoring, cooperation with the supervisory authority, point of contact for data subjects). DPDP section 10 makes the DPO a statutory role for Significant Data Fiduciaries, based in India, accountable to the Board of Directors. ISO/IEC 27701:2025 Clause 5.3 does not itself require a DPO but the role is the natural operational owner of the PIMS in most organisations and is mandatory for organisations in the DPDP-SDF and GDPR-Article-37 categories. The DPO is the natural point of contact with the Data Protection Board of India.

Privacy Lead

The Privacy Lead is a role-title variant used by organisations that do not formally designate a DPO under GDPR Article 37 or DPDP section 10 but assign a person to lead the privacy programme. The Privacy Lead typically has the same operational responsibilities as a DPO without the statutory designation. For Indian growing companies that are not SDFs and do not have EU operations triggering GDPR Article 37, the Privacy Lead is the default role. For SDFs the role-title is DPO (not Privacy Lead) and the statutory obligations apply.

PIMS Steering Committee

The PIMS Steering Committee (also called the Privacy Committee or the Data Protection Committee) is the cross-functional governance body that oversees the PIMS. Its composition varies; a typical composition is the executive sponsor (chair or co-chair), the DPO, the CISO, the Heads of Legal, Compliance, HR, Product, and Marketing, and representatives from each major business unit. Its accountabilities typically include endorsing policy and notice versions, reviewing the privacy KPI dashboard, reviewing the privacy risk register, deciding event-trigger invocations, and approving minor amendments. The Committee is permitted but not required by ISO/IEC 27701:2025; most Indian growing and enterprise firms maintain one.

Data owner

A data owner is the role-holder accountable for a defined set of personal-data processing activities, typically the customer data owner for CRM and customer-support processing, the employee data owner for HR processing, the vendor data owner for procurement processing, the finance data owner for billing and payment processing. The data owner maintains the ROPA entries for their domain, performs or commissions DPIAs for new activities in their domain, ensures consent and notice accuracy, handles DSARs for their domain's data, and coordinates with the DPO on privacy-by-design for new products in their domain. The data-owner model is the operational backbone of the PIMS.

Processor-relationship owner

The processor-relationship owner is the role-holder accountable for the relationship with one or more PII processors (where the organisation is a controller) or with one or more controller customers (where the organisation is a processor). The role owns the DPA execution, the sub-processor list and change-notification, the breach-notification SLA, the cross-border transfer impact assessment, and the infringing-instruction process (A.2.2.5). For SaaS and ITeS firms serving enterprise customers, the processor-relationship owner is often the most operationally consequential privacy role after the DPO.

Grievance Officer

The Grievance Officer is the DPDP Act 2023 section 13 role responsible for receiving, investigating and responding to Data Principal grievances within the period prescribed under the DPDP Rules 2025. The Grievance Officer is mandatory for every Data Fiduciary under DPDP, not only for SDFs. ISO/IEC 27701:2025 Clause 5.3 does not name the role but the operational handling of grievances under Annex A.1.3.x obliges the organisation to designate the role. For most organisations the Grievance Officer is the DPO wearing a second hat or a Customer Excellence role-holder with privacy training. The contact channel must be disclosed in the privacy notice.

Consent Manager liaison

The Consent Manager liaison is the role responsible for the organisation's integration with Consent Managers registered under DPDP Act 2023 section 2(1)(g). The Consent Manager 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 multiple Data Fiduciaries. The liaison role owns the API integration, the withdrawal-signal honouring across systems, the interoperation testing, and the consent-record synchronisation. For most growing companies this is a Privacy Lead or Product Engineer role with the liaison as a designated responsibility; for SDFs and consumer-facing firms it may warrant a dedicated role. The Consent Manager is a distinctive Indian construct with no clean GDPR/NIST/SOC2 analogue.

CERT-In Point of Contact

The CERT-In Point of Contact is the role designated under the CERT-In Directions 20(3)/2022-CERT-In (28 April 2022), issued under section 70B(6) of the IT Act 2000, as the liaison with the Indian Computer Emergency Response Team. The role receives CERT-In communications, files the 6-hour prescribed-cyber-incident report, coordinates with CERT-In during investigations, and must be reachable 24x7. The Point of Contact is typically a role-pair or a follow-the-sun arrangement; a single-person PoC fails the 24x7 reachability expectation.

SDF officer

The SDF officer is the role responsible for the Significant Data Fiduciary's enhanced obligations under DPDP section 10, the DPO, the DPIP programme owner, the independent-data-audit liaison, and the algorithmic-AI fairness review owner. For most SDFs the DPO is the senior SDF officer; the other roles cascade from the DPO.

Independence (DPO)

Independence in the DPO context means the DPO does not receive instructions on how to exercise the role (GDPR Article 38(3) language, relevant for firms with EU data subjects; useful as a benchmark for all DPOs). DPDP section 10 sets a stricter standard for SDFs, the DPO is accountable to the board, not to the executive sponsor or any function with a conflict of interest. The DPO cannot hold a role that creates a conflict (the DPO cannot also be the Head of Marketing; the DPO cannot also be the Head of Product for products that process personal data; the DPO cannot also be the CISO if the CISO role is structurally responsible for security failures the DPO would have to investigate). The independence evidence, reporting line, conflict-of-interest declaration, board-minute accountability, is part of the role charter.

Segregation of duties

Segregation of duties is the control principle that no single role should both perform and audit the same activity, or both authorise and execute the same transaction. In the PIMS, segregation of duties requires the internal auditor to be independent of the DPO; the role that grants consent to be separate from the role that audits consent; the role that processes personal data of staff to be separate from the role that hears staff grievances about that processing. The segregation-of-duties map (Section 7 Move 4) records where privacy roles are deliberately separated and where they are integrated with reasons recorded.

Competency profile

A competency profile is the Clause 7.2 artefact that evidences the role-holder's competence for the role. The profile includes the required qualifications (formal degree, professional qualification), experience (years, type, sector), training (specific courses, certifications), and evidence of continuing competence (refresher training, certification maintenance, recent experience log). For the DPO, GDPR Article 37(5) refers to "expert knowledge of data protection law and practices"; DPDP section 10 does not prescribe a qualification. The International Association of Privacy Professionals credentials (CIPM for privacy managers; CIPP/E for European privacy; CIPT for privacy technologists) are widely recognised competency benchmarks; equivalent national credentials and on-the-job experience are also valid evidence. The competency profile is reviewed annually and on role-holder change.

Relationship to Other Clauses and Frameworks

Relationship to other ISO/IEC 27701:2025 clauses

Clause 5.3 is the people-and-authority clause of the PIMS. Its relationships to the other clauses are the spine of the system.

• Clause 4.1 (Context). The role set must be appropriate to the organisation's context, its size, structure, sector, processing footprint, regulatory landscape. A role set that does not reflect context is not fit-for-purpose.
• Clause 4.2 (Interested parties). The role set must satisfy the needs and expectations of interested parties, PII principals (who need a Grievance Officer), regulators (who need a DPO and a CERT-In Point of Contact), customers (who need a processor-relationship owner), processors and sub-processors (who need a controller-side contact). The interested-party register is an input to role design.
• Clause 4.3 (Scope). The role set must align to the PIMS scope. The scope defines what the role set covers, which processing activities, which products, which geographies, which controller/processor roles.
• Clause 4.4 (PIMS). The role set is the operating system of the PIMS the organisation establishes, implements, maintains, and continually improves.
• Clause 5.1 (Leadership). Top management assigns the roles. The executive sponsor signs the role charters. Without 5.1 sponsorship, the role set is unsponsored.
• Clause 5.2 (Policy). The role set operationalises the privacy policy. The policy commits the organisation to the role architecture; the role set delivers on the commitment. The DPO is named in the policy and in the notice.
• Clause 6.1 (Risks and opportunities). The privacy risk assessment identifies the risks the role set must address. A role set that does not address the risk profile is incomplete.
• Clause 6.2 (Privacy objectives). Privacy objectives cascade to role-owners. Each role-owner is accountable for the objectives within their scope.
• Clause 6.3 (Change). Planned PIMS changes may trigger role changes, a new processing activity may require a new data owner; a new sub-processor may require a new processor-relationship owner.
• Clause 7.1 (Resources). The role set must be resourced. Under-resourced roles fail.
• Clause 7.2 (Competence). Every privacy role must have a competency profile and evidence of continuing competence. This is the most directly linked clause, 7.2 is where 5.3's "assignment" is operationalised as "competent assignment".
• Clause 7.3 (Awareness). The 5.3 communication commitment is operationalised by the 7.3 awareness programme, staff awareness of the role set, of who to contact for privacy questions, of consequences of non-conformance.
• Clause 7.4 (Communication). 5.3 role communication is a specific instance of the broader 7.4 communication discipline.
• Clause 7.5 (Documented Information). The role charters, the authorities register, the competency profiles, and the RACI are controlled documents under Clause 7.5. Version history, approval, distribution, retrieval, retention, disposition apply.
• Clause 8.1 (Operational planning and control). The role set runs the operational processes.
• Clause 8.2 (Privacy risk assessment). The DPO with the data owners performs the detailed privacy risk assessment. For SDFs, the DPIP register is the operational evidence the role set produces.
• Clause 8.3 (Privacy risk treatment). Treatment decisions, including the Statement of Applicability, are taken by the role set.
• Annex A.1 (PII controllers). The DPO owns the controller controls; the data owners own the per-domain controls; the Grievance Officer owns the rights-handling controls.
• Annex A.2 (PII processors). The processor-relationship owner owns the processor controls; the infringing-instruction process (A.2.2.5) requires the owner to have the authority to push back on controllers.
• Annex A.3 (Information security controls). The interface with the CISO role. The CISO typically owns the A.3 controls; the DPO owns the privacy overlay.
• Clause 9.1 (Monitoring and measurement). Role-set performance is monitored, DSAR turnaround, grievance response time, breach-detection-to-notification, role-holder turnover.
• Clause 9.2 (Internal audit). The internal audit programme tests the role set every cycle.
• Clause 9.3 (Management review). The management review agenda explicitly includes role-set review for continuing suitability, adequacy and effectiveness.
• Clauses 10.2 and 10.1 (Improvement). Corrective action and continual improvement close against role-set performance.

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.3 in each of these standards is the roles clause. An organisation running more than one of these systems has an integration opportunity: a single integrated role charter set or a tightly-aligned charter set can satisfy all of them.

• ISO/IEC 27001:2022 Clause 5.3, the ISMS roles clause. Structurally identical. Common Indian integration: an "Information Security and Privacy Role Charter" with sub-sections for ISMS-relevant and PIMS-relevant responsibilities. The CISO and the DPO are sibling roles.
• ISO 22301:2019 Clause 5.3, the BCMS (business continuity) roles clause. The intersection with the PIMS is the breach-response role set, the BC coordinator and the DPO co-own the breach playbook.
• ISO/IEC 42001:2023 Clause 5.3, the AIMS (AI management system) roles clause. The intersection with the PIMS is the algorithmic-fairness review role for SDFs.
• ISO 9001:2015 Clause 5.3, the QMS roles clause. The intersection with the PIMS is light; manufacturers running ISO 9001 commonly extend the quality role taxonomy into a combined Quality and Privacy role set where the data dimension is light.
• ISO/IEC 20000-1:2018 Clause 5.3, the SMS (service management) roles clause. Integration opportunity for IT-service firms.

The full multi-framework mapping (Clause 5.3 row)

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

• ISO/IEC 27701:2025 Clause 5.3, the requirement itself.
• Annex B (normative) section B.5.3, the implementation guidance auditors test against.
• ISO/IEC 27001:2022 Clause 5.3, the ISMS sibling; combined or aligned role charters satisfy both.
• ISO/IEC 27002:2022 control 5.34, the only PII-specific control in 27002; identifies roles and responsibilities for PII processing.
• ISO/IEC 29100:2011, Accountability principle, the conceptual ancestor of the role-set requirement.
• GDPR Articles 37, 38, 39, the DPO designation, position and tasks.
• GDPR Articles 13(1)(b), 14(1)(b), the disclosure of the DPO contact in the privacy notice.
• NIST Privacy Framework v1.0 (NIST.CSWP.01162020, 16 January 2020), Govern-P function (governance structure, privacy roles, risk-management strategy).
• SOC 2 (AICPA TSC 2017, with 2022 points of focus), Common Criteria CC1.1 to CC1.5 (Control Environment) plus Privacy criteria P5.0 (Access) and P8.0 (Monitoring and enforcement).
• DPDP Act 2023 (Act 22 of 2023), sections 5, 8, 10, 13, 18, 33 + Schedule.
• DPDP Rules 2025 (notified 13 November 2025), Rule 7 (breach; the breach-notification role); the section 9 children's rules (the verifiable-parental-consent owner); the section 10 SDF rules (the DPO, DPIP, audit, algorithmic-fairness roles); the section 13 grievance-redressal response period (the Grievance Officer).
• CERT-In Directions 20(3)/2022-CERT-In (28 April 2022), the Point of Contact role.
• RBI Cybersecurity Directions 2026 (31 July 2026), the CISO role for banks and NBFCs.
• SEBI CSCRF (20 August 2024), the CISO and Privacy Officer for SEBI Regulated Entities.
• IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023), the CISO role for insurers.
• IT Act 2000 sections 43A, 72A and SPDI Rules 2011, the body-corporate obligations that sit alongside DPDP.
• Companies Act 2013 section 134(3)(n) and section 177; SEBI LODR Regulation 21, the board-level role-accountability overlay.

Detailed Implementation Guidance, The Six Role Moves

Figure · Process

What Clause 5.3 asks you to do

This section sets out the six role moves a growing company in India must execute to satisfy Clause 5.3 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, Decide the structural model (DPO-centred, privacy-team-centred, or CISO-extended)

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 regulatory landscape, and the executive sponsor's organisational-design intent.

Output. A documented structural-model decision, recorded in the role-charter preamble, naming the chosen model and the reasons for the choice. Three models are presented here. The research base is explicit that there is no single answer, the choice depends on the organisation's context, scope, risk profile, size and structure. The DPDP section 10 SDF overlay constrains the choice (a statutory India-based DPO accountable to the board is non-negotiable) but does not remove it.

Model A, the DPO-centred model. A standalone privacy function with the DPO at its head. The DPO reports to the executive sponsor (for non-SDFs) or to the board (for SDFs and listed entities). The function may include a Deputy DPO, Privacy Analysts, a Privacy Engineer, a Grievance Officer (sometimes a dedicated role), and administrative support. The CISO is a sibling role; the interface is at the breach-response playbook and at the A.3 security controls.

Fit profile. SDFs under DPDP section 10; BFSI; healthcare; large enterprise; organisations with substantial cross-border processing; organisations where privacy is a board-level risk; organisations where the DPO is a statutory role.

Risk profile. Strong independence; clear accountability; clean interfaces with Legal, Security, Product. Risks: cost (a standalone function is expensive for small firms); isolation (the DPO function can become a "compliance island" detached from product and engineering).

Model B, the privacy-team-centred model. A cross-functional privacy team with a Privacy Lead (or DPO if SDF) as the coordinator. Privacy responsibilities are distributed across Legal (the DPO/Privacy Lead often sits here), Engineering (a Privacy Engineer role), Product (a Privacy-by-Design owner per product line), Operations (data owners per processing domain), and Customer Excellence (the Grievance Officer). The Privacy Lead coordinates; the team delivers.

Fit profile. Growing SaaS, ITeS, digital-first firms; organisations where privacy is engineering work and product work, not only legal work; organisations with a strong cross-functional culture; organisations where a standalone privacy function is not yet warranted.

Risk profile. Strong privacy-by-design execution (privacy is embedded in product and engineering); cost-effective (responsibilities are spread across existing roles); resilience (turnover of one role-holder does not break the programme). Risks: coordination overhead (the Privacy Lead must be empowered to convene); role ambiguity (a Privacy Engineer in Product reports to the Head of Product and to the Privacy Lead, clarity of authority matters); communication friction across functions.

Model C, the CISO-extended model. The CISO extends the ISMS to cover the PIMS. The CISO is the senior security-and-privacy officer; a Privacy Lead (often a Deputy CISO or a dedicated Privacy Manager) reports to the CISO and runs the PIMS day-to-day. The DPO function (where statutorily required) is a separate role; for non-SDFs without GDPR Article 37 triggers, the Privacy Lead under the CISO is the operational owner.

Fit profile. Growing companies (50 to 250) where the CISO is the senior officer and a dedicated privacy function is not yet warranted; organisations with a strong security-engineering culture; organisations where the privacy programme is early-stage and benefits from security's existing infrastructure.

Risk profile. Strong integration with security (the CISO owns both the A.3 controls and the privacy overlay); cost-effective (no separate privacy function at small sizes). Risks: conflict of interest (the CISO cannot independently investigate security failures the CISO is responsible for, the DPO independence overlay requires a separate reporting line for SDFs and for organisations with EU data subjects); privacy-as-security conflation (privacy is broader than security and includes notice, consent, rights, transfer, the CISO may not have the legal literacy); under-resourcing of the privacy half of the role.

The SDF overlay or GDPR trigger adds a separate DPO cost on top.

The decision framework. The choice among the three models is a Clause 4.1 / 4.2 / 4.3 / 6.1.2 decision, driven by context, interested parties, scope and risk. The decision factors:

1. Are you an SDF under DPDP section 10? If yes, the DPO is statutory (India-based, board-accountable). The structural choice is around the DPO, not whether to have one. Models A and B fit; Model C requires a separate statutory DPO alongside the CISO.
2. Are you subject to GDPR Article 37? If yes (public authority; core activities of large-scale regular and systematic monitoring; core activities of large-scale processing of special categories), a DPO is required. Same constraint as the SDF overlay.
3. What is your size and complexity? Growing companies typically fit Model C; growing firms typically fit Model B; large enterprise and regulated firms typically fit Model A.
4. Is privacy primarily legal work, engineering work, or operations work in your organisation? Primarily legal → Model A (suits a Legal-rooted DPO). Primarily engineering → Model B (suits a Privacy Engineer-led team). Primarily security-operations → Model C (suits a CISO extension).
5. What is your existing management-system footprint? Organisations running ISO/IEC 27001 already have a CISO; Model C is a natural extension. Organisations without an ISMS but with strong Legal/Compliance functions fit Model A or B.
6. What is your budget? Model A is the most expensive; Model C is the least expensive at small sizes; Model B is in between.

The decision is recorded in writing; the executive sponsor signs it; the auditor sees it on day one. The decision is reviewed annually at the management review and on event trigger (SDF designation change; scope change; M&A; audit nonconformity).

Owner. Executive sponsor with the DPO/Privacy Lead and the CISO.

Indicative effort. A 90-minute workshop with the sponsor, the proposed DPO, the CISO, the Head of Legal and the Head of HR; followed by 1 to 2 days of DPO drafting time to record the decision.

Common failure modes. (a) Defaulting to Model C without considering whether the SDF or GDPR overlay applies, produces a nonconformity if a statutory DPO is required and not separately appointed. (b) Defaulting to Model A at a size where it is not affordable, produces an under-resourced DPO and the programme fails. (c) Recording the decision verbally, fails the audit traceability test. (d) Recording the decision once and never reviewing, fails the Move 6 event-trigger discipline. (e) Choosing a model that does not match the organisation's actual privacy work (e.g., choosing Model C for a SaaS firm where privacy is primarily engineering work, the CISO lacks the legal literacy and the programme underperforms).

Move 2, Author the role charter set

Input. The structural-model decision from Move 1; the DPDP overlay assessment (are you an SDF? subject to GDPR Article 37? a BFSI CISO-mandated entity? a SEBI RE Privacy-Officer-mandated entity?); the existing organisation chart; the role-description library in HR.

Output. A role-charter set of typically six core charters plus the DPDP overlay charters. Each charter is a one-to-three-page document with the following sections.

a. Role title and reporting line. The role title (e.g., "Data Protection Officer"); the reporting line (e.g., "Reports to the Board of Directors for SDF accountability; operationally to the executive sponsor"); the grade and any statutory designation (e.g., "Statutory role under DPDP Act 2023 section 10").

b. Role-holder. The named person; the appointment date; the appointment-letter reference; the end date or review date (for fixed-term or fractional appointments).

c. Purpose of the role. A two-to-three-sentence statement of why the role exists and what it is accountable for.

d. Responsibilities. A list of the specific responsibilities, mapped to the PIMS clauses and annex controls the role delivers. For the DPO: drafting and maintaining the privacy policy (Clause 5.2); running the privacy risk assessment (Clause 6.1.2 / 8.2); maintaining the ROPA (Clause 8 / Annex A.1.2.x); commissioning DPIAs (Annex A.1.2.5); overseeing the data-principal-rights workflow (Annex A.1.3.x); overseeing processor management (Annex A.2); overseeing the breach playbook (Clause 8 / Annex A.3); coordinating with the Grievance Officer, the Consent Manager liaison, the CERT-In Point of Contact; engaging with the Data Protection Board; presenting at the management review.

e. Authorities. The explicit authorities granted to the role. For the DPO: the authority to halt infringing processing (subject to escalation to the executive sponsor for material actions); the authority to commission DPIAs; the authority to refuse new processing that fails a DPIA; the authority to escalate to the board (for SDFs); the authority to engage external counsel; the authority to communicate with the Data Protection Board. For the Grievance Officer: the authority to issue substantive section 13 responses within the prescribed period; the authority to commission investigations; the authority to escalate to the DPO. For the internal auditor: the authority to access any PIMS artefact without permission-filtering; the authority to issue findings; the authority to require corrective-action plans.

f. Competencies. The required qualifications, experience, training, and continuing-competence expectations. Reference to the competency profile in Clause 7.2 (see Move 5).

g. Independence and conflict-of-interest declarations. For the DPO, the Grievance Officer, and the internal auditor: a declaration of independence and a record of any conflict-of-interest review.

h. Time commitment. The expected time commitment (full-time, fractional, on-call). For fractional roles, the basis (days per month, hours per week).

i. Performance review and accountability. How the role-holder is performance-reviewed (typically annually, with privacy KPIs in the review); to whom the role-holder is accountable.

j. Change protocol. What happens on role-holder change (succession plan; re-appointment within a defined period; handover protocol; event-trigger under Move 6).

The six core charters.

1. Executive Sponsor (CEO/MD/COO) charter, top-management ownership; signs the privacy policy; chairs or sponsors the PIMS Steering Committee; presents at the management review; receives the board/RMC noting; owns the role-set budget.
2. DPO / Privacy Lead charter, the operational owner of the PIMS; the statutory role for SDFs; the point of contact with the Data Protection Board; runs Moves 1 to 6 day-to-day.
3. PIMS Steering Committee charter, composition, cadence, accountabilities; endorses policy and notice versions; reviews the privacy KPI dashboard; decides event-trigger invocations.
4. Data Owner charter (per processing domain), maintains the ROPA entries; performs DPIAs; ensures consent and notice accuracy; handles DSARs for the domain; coordinates with the DPO on privacy-by-design.
5. Processor-Relationship Owner charter, owns the DPA execution; the sub-processor list and change-notification; the breach-notification SLA; the cross-border transfer impact assessment; the infringing-instruction process (A.2.2.5).
6. Internal Audit charter, includes Clause 5.3 in the annual internal audit plan; runs the role-set audit checklist; reports findings to the Audit Committee and the PIMS Steering Committee; tracks corrective action to closure.

The DPDP overlay charters.

7. Grievance Officer charter (DPDP section 13), receives, investigates, responds to Data Principal grievances within the prescribed period; the contact channel disclosed in the privacy notice; tracked response-time KPI.
8. CERT-In Point of Contact charter (CERT-In Directions 28 April 2022), receives CERT-In communications; files the 6-hour prescribed-cyber-incident report; coordinates with CERT-In during investigations; 24x7 reachability (typically a role-pair or follow-the-sun arrangement).
9. Consent Manager Liaison charter (DPDP section 2(1)(g)), owns the API integration with registered Consent Managers; honours withdrawal signals across systems; interoperation testing; consent-record synchronisation.
10. SDF Officer charter (where designated), for SDFs: the DPO is typically the senior SDF officer; additional roles include the DPIP programme owner, the independent-data-audit liaison, the algorithmic-AI fairness review owner.

Sectoral overlay charters.

11. CISO charter (RBI Cybersecurity Directions 2026 / SEBI CSCRF / IRDAI ICS), where applicable; typically co-holds the breach-response role with the DPO.
12. Privacy Officer charter (SEBI CSCRF), for SEBI Regulated Entities.

Owner. DPO/Privacy Lead drafts the charters; executive sponsor signs each charter; HR records the charters in the HR system and links them to the role-holder's file; Company Secretary schedules the board/RMC noting for SDFs, BFSI and listed entities.

Indicative effort. One-time authoring of 2 to 4 person-weeks for the six core charters; 1 to 2 person-weeks for the DPDP overlay charters; 1 person-week for the sectoral overlay charters.

Common failure modes. (a) Charters that name the role but not the role-holder, fails the assignment test. (b) Charters that name the role-holder but do not grant authorities, fails the authority test. (c) Charters that are signed by the DPO alone, not the executive sponsor, fails the 5.1 ownership test. (d) Competency section left blank, fails the 7.2 competence test. (e) Independence declaration omitted for the DPO/Grievance Officer/internal auditor, fails the independence test. (f) SDF charters without the board-accountability reference, fails the DPDP section 10 test. (g) Charters in a drawer, not in HR, fails the integration test.

Move 3, Build the controller-processor-shared RACI

Input. The role charter set from Move 2; the PIMS activity list (the activities the role set must execute, ROPA maintenance, DPIA, consent management, DSAR handling, grievance handling, breach notification, processor oversight, sub-processor change, cross-border transfer review, internal audit, management review, corrective action, continual improvement); the controller/processor role declaration.

Output. A RACI matrix cross-walking the PIMS activities against the role set, in three sections.

Section 1, Controller activities (Annex A.1). Activities owned by the controller-side role set: notice authoring and maintenance; consent collection and management; DSAR intake and response; grievance intake and response; rights handling (access, correction, erasure, restriction, portability, objection, automated-decision-making); cross-border transfer decision; retention and erasure; privacy-by-design for new products.

Section 2, Processor activities (Annex A.2). Activities owned by the processor-side role set: DPA execution; processing-only-on-document-instructions; sub-processor management and change notification; breach notification to the controller; cross-border transfer impact assessment; the infringing-instruction process (A.2.2.5); the customer trust portal publication.

Section 3, Shared activities. Activities owned jointly: the privacy risk assessment (Clause 6.1.2 / 8.2); the ROPA maintenance (controllers and processors each maintain their slice); the internal audit (Clause 9.2); the management review (Clause 9.3); the corrective action log (Clause 10.2); the continual-improvement register (Clause 10.1); the breach playbook (controllers and processors each have their role).

For each activity, the RACI names one R (Responsible, does the work), one A (Accountable, owns the outcome, the single point of accountability), one or more C (Consulted, input before the work), and one or more I (Informed, told after the work). The discipline is one A per row; the discipline is no A-C ambiguity (the Accountable role can be Consulted but the Consulted role is not Accountable).

The eight activities most often broken in the RACI (auditor focus):

1. DSAR intake and response, often no A; the Customer Excellence team receives, the DPO coordinates, Legal reviews, but no one is Accountable. Fix: DPO is A.
2. Breach notification, the dual clock, the CERT-In Point of Contact files the 6-hour CERT-In report; the DPO files the 72-hour DPDP Board notification; the executive sponsor approves the principal notification. Often the A is unclear. Fix: DPO is A for the overall response; CERT-In PoC is R for the CERT-In clock; executive sponsor is A for the principal notification.
3. Consent withdrawal (Consent Manager liaison), when a Data Principal withdraws consent via a Consent Manager, who acts? Often no A. Fix: Consent Manager liaison is R; DPO is A.
4. Infringing-instruction process (A.2.2.5), when a controller instructs infringing processing, the processor-relationship owner must push back. Often the A is the DPO; in practice the A is the processor-relationship owner (who escalates to the DPO and to Legal). Fix: processor-relationship owner is A.
5. Sub-processor change notification, when a sub-processor is added or changed, the controller must be notified within the contractual SLA. Often no A. Fix: processor-relationship owner is A.
6. DPIA commissioning, for new high-risk processing, who commissions the DPIA? Often the DPO; in practice the data owner commissions (the DPO supports). Fix: data owner is A.
7. Cross-border transfer impact assessment, who performs the TIA? Often no A. Fix: DPO is A; processor-relationship owner is R.
8. Internal audit programme inclusion, the internal audit must include Clause 5.3 every cycle. Often the A is the DPO; in practice the A is the Head of Internal Audit (independent). Fix: Head of Internal Audit is A.

Owner. DPO/Privacy Lead drafts; PIMS Steering Committee reviews; executive sponsor approves.

Indicative effort. 2 to 4 person-weeks for the first RACI; ongoing maintenance of 1 to 2 person-days per month.

Common failure modes. (a) RACI in a spreadsheet that no one updates, fails the recency test. (b) RACI with multiple As per row, fails the single-point-of-accountability test. (c) RACI without the DPDP overlay roles, fails the regulatory overlay test. (d) RACI not wired into HR, the role-holders do not see their RACI assignments in their role descriptions. (e) RACI not tested in an actual privacy event, the RACI is theoretical; the first real DSAR or breach reveals the chain breaks. Run a tabletop exercise (Move 6) to test the RACI in a simulated event.

Move 4, Write the authorities register and the segregation-of-duties map

Input. The role charter set from Move 2; the RACI from Move 3; the existing delegation-of-authority matrix (if any); the conflict-of-interest register.

Output. Two artefacts.

1. The authorities register, a one-to-three-page document listing the explicit authorities granted to each privacy role. The register is the auditor's primary evidence that authorities are not only assigned but formally granted. Sample authorities (Singahi's own drafting for adaptation):

• The DPO shall have the authority to halt infringing processing, subject to escalation to the executive sponsor where the halt is material in financial or operational impact.
• The DPO shall have the authority to commission DPIAs for any new or materially changed processing activity.
• The DPO shall have the authority to refuse new processing that fails a DPIA, subject to escalation.
• The DPO shall have the authority to escalate to the Board of Directors or the Risk Management Committee (for SDFs and listed entities).
• The DPO shall have the authority to engage external counsel and external privacy advisors at the PIMS budget.
• The DPO shall have the authority to communicate directly with the Data Protection Board of India and with sector regulators (RBI, SEBI, IRDAI, CERT-In).
• The Grievance Officer shall have the authority to issue substantive section 13 responses within the prescribed period without prior approval from the executive sponsor for non-material responses.
• The Grievance Officer shall have the authority to commission investigations into grievances.
• The Consent Manager liaison shall have the authority to integrate with Consent Managers registered under DPDP Act 2023 section 2(1)(g) and to honour withdrawal signals across systems.
• The processor-relationship owner shall have the authority to invoke the infringing-instruction process under Annex A.2.2.5 and to escalate to the DPO and to Legal.
• The processor-relationship owner shall have the authority to notify controllers of sub-processor changes within the contractual SLA.
• The internal auditor shall have the authority to access any PIMS artefact (policies, ROPA, DPIAs, consent records, DSAR records, breach records, processor DPAs) without permission-filtering.
• The internal auditor shall have the authority to issue findings and to require corrective-action plans from role-owners.
• The CERT-In Point of Contact shall have the authority to file the 6-hour prescribed-cyber-incident report under the CERT-In Directions 20(3)/2022-CERT-In without prior approval from the executive sponsor.
• The CISO shall have the authority to invoke the breach-response playbook and to coordinate the technical response.

Each authority is signed by the executive sponsor; the date of grant is recorded; the authority is reviewed annually.

2. The segregation-of-duties map, a one-page matrix showing where privacy roles are deliberately separated from other roles, and where they are integrated with reasons recorded. The map is the auditor's primary evidence that conflict-of-interest is managed. Sample segregation rules:

• The internal auditor cannot also be the DPO (independence, the auditor cannot audit their own work).
• The role that grants consent (the Consent Manager liaison or the Product Engineer) cannot also be the role that audits consent (the internal auditor).
• The role that processes personal data of staff (the Head of HR) cannot also be the role that hears staff grievances about that processing (the Grievance Officer for staff data should be a different person, typically the DPO or a senior HR-person outside the processing chain).
• For SDFs, the DPO cannot also be the Head of Marketing, the Head of Product, or any role that determines the purposes and means of processing (DPDP section 10 independence).
• For organisations subject to GDPR Article 38, the DPO cannot hold any other role that creates a conflict of interest (Article 38(6)).

Where roles are integrated (e.g., the DPO is also the Privacy Lead; the CISO is also the Privacy Lead for non-SDFs in Model C), the integration is recorded with reasons.

Owner. DPO drafts; executive sponsor signs the authorities register; Head of Legal reviews the segregation-of-duties map for conflict-of-interest compliance; PIMS Steering Committee endorses.

Indicative effort. 1 to 2 person-weeks.

Common failure modes. (a) Authorities register omitted, the charters name responsibilities but not authorities; the auditor cannot find the explicit grants. (b) Authorities written but never exercised, the DPO has the authority on paper but has never halted processing, commissioned a DPIA, or escalated to the board; in the auditor interview, the DPO cannot describe how the authority would be exercised. (c) Authorities inconsistent with the RACI, the RACI names the DPO as Accountable for breach notification but the authorities register does not grant the DPO the authority to file the notification. (d) Segregation-of-duties map omitted, the auditor cannot tell whether the internal auditor is independent of the DPO. (e) Segregation of duties breached, the internal auditor is also the DPO; the Grievance Officer for staff data is also the Head of HR.

Move 5, Write the competency profiles and capture the evidence

Input. The role charter set from Move 2; the existing role-description library in HR; the certifications and training records of the role-holders.

Output. A competency profile per named role-holder, per Clause 7.2. The profile is a one-to-two-page document with the following sections.

a. Role title and role-holder. Match to the charter.

b. Required qualifications. Formal degrees, professional qualifications, statutory designations. For the DPO: GDPR Article 37(5) refers to "expert knowledge of data protection law and practices"; DPDP section 10 does not prescribe a qualification. For most Indian DPOs, the relevant competency benchmarks are the International Association of Privacy Professionals credentials, CIPM (Certified Information Privacy Manager) for privacy managers, CIPP/E (Certified Information Privacy Professional / Europe) for European privacy law, CIPT (Certified Information Privacy Technologist) for privacy engineering, or equivalent national credentials.

c. Required experience. Years, type, sector. For the DPO: typically 5-plus years in privacy, compliance, legal or a related field; sector-specific experience for regulated sectors.

d. Required training. Specific courses (e.g., a DPDP Act 2023 deep-dive; a CERT-In Directions workshop; a sectoral regulation course; an ISO/IEC 27701:2025 Lead Implementer or Lead Auditor course).

e. Evidence of competence. Copies of degrees, certifications, training records, experience log.

f. Continuing-competence plan. Refresher training cadence; certification maintenance; reading list; conference attendance; participation in industry bodies.

g. Annual review. Date of the last competency review; competency-review outcome; any competency gaps and the plan to close them.

The competency profiles are linked to performance reviews (Move 6); role-holders with competency gaps are enrolled in training; role-holders with material competency gaps that cannot be closed are reassigned.

Owner. DPO with HR; executive sponsor reviews the DPO profile; PIMS Steering Committee reviews the profiles for the privacy team.

Indicative effort. One-time authoring of 2 to 4 person-weeks for the full role set; ongoing maintenance of 1 to 2 person-days per role per year.

Common failure modes. (a) Competency profiles omitted, fails the 7.2 test directly. (b) Profiles that list qualifications but no evidence, fails the evidence test. (c) Profiles that are never reviewed, fails the continuing-competence test. (d) DPO profile without any privacy-specific credential or training, fails the expert-knowledge test. (e) Profiles not linked to performance reviews, competency gaps do not surface; training plans are not produced.

Move 6, Communicate, wire into HR, and review

Input. The role charter set, the RACI, the authorities register, the segregation-of-duties map, the competency profiles.

Output. Six artefacts and integrations.

1. Intranet publication of the role-on-a-page. A one-page summary per role, in plain language, published on the corporate intranet. Includes the role title, the role-holder's name and photograph, the contact channel, the responsibilities in plain language, the authorities in plain language. The intranet publication is the internal communication fulfilment.

2. External notice disclosure. The privacy notice (Clause 5.2) discloses the DPO contact and the Grievance Officer contact per DPDP section 5 and GDPR Articles 13 to 14. The CERT-In Point of Contact is filed with CERT-In. The Consent Manager liaison is identified to the registered Consent Managers.

3. Induction briefing. Every new joiner receives the role-on-a-page in their induction pack; the DPO or a delegate briefs new joiners in the first 30 days; the role-holders with privacy responsibilities receive a deeper briefing.

4. HR integration. The role descriptions are in the HR system; the RACI assignments are linked to each role-holder's file; the performance review includes privacy KPIs for the role-holder; the succession plan identifies successors for each role.

5. Management review and internal audit wiring. The role set is on the management review agenda (Clause 9.3) annually; the internal audit programme (Clause 9.2) tests the role set every cycle.

6. Event-trigger review discipline. A defined list of triggers that require interim role-set review: (a) role-holder change (DPO resignation, role-holder departure, role-holder transfer); (b) scope change (Clause 4.3); (c) SDF designation change; (d) M&A or major organisational change; (e) audit nonconformity on Clause 5.3; (f) regulatory change (DPDP Rules amendment; new sectoral instrument); (g) breach or near-miss (any activation of the breach playbook triggers a role-set review); (h) annual review at the management review.

Owner. DPO/Privacy Lead; HR; Internal Audit; Company Secretary (for board noting).

Indicative effort. First cycle: 3 to 6 person-weeks. Ongoing: 2 to 4 person-days per month.

Common failure modes. (a) Role set published on the intranet once and never refreshed, staff see stale information. (b) External notice disclosure missing the Grievance Officer contact, fails the DPDP section 5 test. (c) HR integration absent, role-holders do not see their RACI assignments in their files; performance reviews do not include privacy KPIs; succession plans do not exist. (d) Event triggers defined but never invoked, the DPO is not monitoring for triggers; a DPO resignation is not flagged as a trigger. (e) Management review without a role-set agenda item, fails the 9.3 test.

The six moves in aggregate

The six moves together convert a "phantom DPO" or a "DPO in name only" into a "named-people" PIMS. The first cycle (Moves 1 to 6) takes 8 to 14 weeks for a typical Indian growing company; the steady-state cycle (Move 6 in recurrence plus Moves 1 to 5 on event trigger) is a continuous management discipline that produces the role-set evidence base the certification auditor, the Data Protection Board and overseas regulators all want to see. The Singahi toolkit for Clause 5.3 contains 17 ready-to-customise documents that operationalise each move.

Tools, Technologies, and Solutions

Clause 5.3 is a document-heavy, workflow-heavy and people-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.

HR systems and role-description libraries

The baseline tool is the HR system (HRIS or HCM) that holds the role-description library. Required capabilities for Clause 5.3: role-description storage; competency-profile storage; training-record storage; performance-review integration; succession-planning module; RACI visualisation per role-holder. For most growing companies the HRIS is already in place; the question is configuration to hold the privacy role charter set, not procurement.

GRC platforms with PIMS role modules

For Mid-market (250 to 2,000) and enterprise, integrated GRC platforms with PIMS modules host the role charters, the RACI, the authorities register, the segregation-of-duties map, and the competency profiles alongside the policy library, the risk register, the SoA, the audits and the corrective-action log, providing end-to-end traceability across the integrated management system. Selection criteria for Clause 5.3: RACI module with conflict-of-interest checking; competency-profile module with training-record integration; role-on-a-page rendering; segregation-of-duties visualisation.

Privacy management platforms

For organisations that want a privacy-specific platform (rather than a GRC platform with privacy features), enterprise privacy platforms (a category-level descriptor) combine role management with ROPA, DPIA, DSAR, consent management, processor management, breach response, and policy/notice workflow. Selection criteria for Clause 5.3: role-charter storage with version control; RACI module; competency-profile module; Consent Manager API integration; DSAR workflow with Grievance Officer role; breach-response workflow with role-pair (DPO + CERT-In PoC).

Document management systems for the charter set

For growing companies that do not need a full GRC or privacy platform, the document management system (Microsoft SharePoint Online, Google Workspace, Confluence) suffices. Required capabilities: version history; approval workflow; distribution control; full-text search; access logging; metadata for charter version, signatory, role-holder. The charter set is a folder in the DMS with sub-folders for charters, RACI, authorities register, segregation-of-duties map, competency profiles, and the review log.

Consent Manager integration tooling

For the Consent Manager liaison role, the tool stack is a Consent Manager API client integrated with the consent-management platform and the upstream systems that hold personal data. The Consent Manager (DPDP section 2(1)(g)) ecosystem is expected to emerge through 2026 and 2027 as the Board registers the first Consent Managers and the interoperability specification is published. Forward-looking organisations procure consent-management platforms that are 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.

Awareness and training platforms

For the communication programme (Move 6), awareness and training platforms with role-aware modules are the standard Indian stack. Required capabilities: assign role-specific training (DPO training differs from data-owner training differs from staff awareness); capture completion; support multilingual content; automate annual refresh; generate audit reports; integrate with the HR system; deliver role-specific briefings (the Grievance Officer training, the CERT-In PoC training, the Consent Manager liaison training).

Indicative cost bands for the Clause 5.3 tool stack

These bands are indicative. Actual costs depend on existing stack, integration complexity, number of role-holders, 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 role-charter set in template form. The full ready-to-customise templates are in the Clause 5.3 toolkit (17 documents); this section previews the apex templates, the role-charter skeleton and the RACI skeleton.

Role-charter skeleton (preview, full template in toolkit doc 01)

[PIMS ROLE CHARTER]
[Organisation Name]
Role title: [Data Protection Officer / Privacy Lead / Grievance Officer / ...]
Role-holder: [Name], [Employee ID]
Appointment date: [DD Month YYYY] | Appointment-letter ref: [AL-2026-NNN]
Reporting line: [Reports to: Board of Directors for SDF accountability; operationally
to the executive sponsor (CEO/MD).]
Grade and statutory designation: [Statutory role under DPDP Act 2023 section 10 / GDPR
Article 37 / RBI Cybersecurity Directions 2026 CISO / etc. — or "None (operational role)"]
Charter version: [X.Y] | Issue date: [DD Month YYYY] | Next review: [DD Month YYYY]
Approved by: [Executive Sponsor name, role, signature]

1. Purpose of the role
   [Two-to-three-sentence statement of why the role exists and what it is
   accountable for.]

2. Responsibilities (mapped to PIMS clauses and annex controls)
   - [Clause 5.2 — drafting and maintaining the privacy policy]
   - [Clause 6.1.2 / 8.2 — running the privacy risk assessment]
   - [Clause 8 / Annex A.1.2.x — maintaining the ROPA]
   - [Annex A.1.2.5 — commissioning DPIAs]
   - [Annex A.1.3.x — overseeing the data-principal-rights workflow]
   - [Annex A.2 — overseeing processor management]
   - [Clause 8 / Annex A.3 — overseeing the breach playbook]
   - [DPDP section 13 — Grievance Officer duties, if applicable]
   - [DPDP section 10 — SDF DPO duties, if applicable]
   - [CERT-In Directions — Point of Contact duties, if applicable]
   - [DPDP section 2(1)(g) — Consent Manager liaison duties, if applicable]

3. Authorities (explicit grants)
   - [The authority to halt infringing processing, subject to escalation...]
   - [The authority to commission DPIAs...]
   - [The authority to refuse new processing that fails a DPIA...]
   - [The authority to escalate to the board...]
   - [The authority to engage external counsel...]
   - [The authority to communicate with the Data Protection Board of India...]

4. Competencies (see competency profile in toolkit doc 07)
   - [Required qualifications; experience; training; continuing competence]

5. Independence and conflict-of-interest declarations
   - [For DPO, Grievance Officer, internal auditor: independence declaration
     and conflict-of-interest review record]

6. Time commitment
   - [Full-time / fractional / on-call; basis]

7. Performance review and accountability
   - [Annual review with privacy KPIs; accountable to: ...]

8. Change protocol
   - [Succession plan; re-appointment within X days; handover protocol;
     event-trigger under Move 6]

9. Signatures
   - Role-holder: [Name, Signature, Date]
   - Executive Sponsor: [Name, Signature, Date]
   - HR: [Name, Signature, Date]
   - (For SDFs) Board / RMC noting: [Minute reference, Date]

RACI matrix skeleton (preview, full template in toolkit doc 13)

Risk Assessment and Treatment

Clause 5.3 is itself a control on role-set integrity; the risks that bear on it are risks to role-set integrity. The Singahi Clause 5.3 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: dual-hat CISO-Privacy-Officer conflict risk; Healthcare: Clinical Operations vs DPO consent-handling conflict; SaaS: processor-relationship owner commercial conflict; Edtech: verifiable-parental-consent owner gap).

Audit and Compliance Checklist

The Clause 5.3 audit checklist below contains 28 questions across the six 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 RACI-trace worksheet) is in toolkit doc 04.

Stage 1, Document and context review

Stage 2, Operating effectiveness

Metrics and KPIs

The Clause 5.3 KPI set spans process metrics (is the role-set work being done?), outcome metrics (is the role set producing the right privacy outcomes?), and assurance metrics (are we confident the role set will hold up under audit?). The Singahi Clause 5.3 dashboard (toolkit doc 11) operationalises 14 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 100% (charters stale); O2 trending up (grievance workflow degraded); A2 missing activation targets (role-set fails under pressure, the marquee audit-failure signal).

Common Pitfalls and Audit Failures

Eight named anti-patterns account for the bulk of Clause 5.3 nonconformities observed in the Indian growing-company segment.

Pitfall 1, The phantom DPO. The executive sponsor appointed a DPO in 2022, signed the appointment letter, filed it, and never communicated. Nobody else in the organisation knows who the DPO is. The auditor samples staff and finds zero awareness. Major nonconformity. Treatment: intranet publication of the role-on-a-page (Move 6); induction briefing; annual awareness refresh.

Pitfall 2, DPO in name only. The DPO is named and communicated, but the authorities register is empty or never exercised. When a real breach happens, the DPO cannot act. Major nonconformity; the post-incident regulatory examination will name the gap. Treatment: authorities register with explicit grants (Move 4); tabletop exercise to test the authorities (Move 6).

Pitfall 3, The CISO wearing too many hats. A growing company appoints the CISO as the DPO, the Grievance Officer, and the CERT-In PoC. The arrangement is cost-efficient but creates multiple conflicts of interest, the CISO cannot independently investigate security failures the CISO is responsible for. Major nonconformity for SDFs (DPDP section 10 independence); minor nonconformity for non-SDFs but a structural weakness. Treatment: segregation-of-duties map (Move 4); separate at least the internal audit role from the operational privacy roles.

Pitfall 4, The Grievance Officer as inbox. The Grievance Officer is a generic "grievances@company.com" alias that nobody monitors. The DPDP section 13 response-period clock runs from grievance receipt; the inbox is unmonitored; the SLA is breached. Major nonconformity; direct DPDP penalty exposure. Treatment: named role-holder; tracked response-time KPI (O2); weekly review of the grievance log.

Pitfall 5, The single-person CERT-In PoC. The CERT-In PoC is one person. The 6-hour clock runs 24x7; the PoC sleeps. The first weekend incident misses the 6-hour clock. Treatment: role-pair or follow-the-sun arrangement; documented handover protocol; 24x7 reachability test.

Pitfall 6, The RACI that nobody uses. The RACI was authored at certification time, filed in a spreadsheet, and never refreshed. The first real DSAR reveals the chain breaks, the Accountable role-holder has left the organisation; the Responsible role has been reorganised into a different team; nobody knows who is Accountable. Treatment: RACI currency KPI (P6); quarterly RACI review; HR integration so departures trigger RACI updates.

Pitfall 7, The SDF without an India-based DPO. A firm is designated as an SDF under DPDP section 10. The DPO is the global Privacy Lead based in Singapore. The board has noted the appointment. The DPDP section 10 requirement is "based in India", the appointment is structurally non-conforming. Major nonconformity; direct DPDP section 10 penalty exposure up to 150 crore rupees. Treatment: appoint an India-based DPO (can be the same person if they relocate, or a separate India-based role-holder who reports to the global Privacy Lead).

Pitfall 8, The unchartered DPDP overlay roles. The core six roles are chartered. The Grievance Officer, the CERT-In PoC, the Consent Manager liaison are not. The auditor cannot find the charters. Major nonconformity. Treatment: charter the DPDP overlay roles (Move 2); the overlay roles are not optional for Indian Data Fiduciaries.

Illustrative Scenario 1: Failure, Juspay-style Processor with Diffuse Ownership (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 payments-processor and SaaS firms observed in the market between 2020 and 2026, drawing on the public disclosures around the Juspay 2021 event (approximately 35 million records, publicly acknowledged), the BigBasket 2020 event, and other processor-side incidents. It is illustrative; any resemblance to a specific named firm is coincidental. The Juspay event is referenced for the lessons it teaches; the company publicly disclosed the incident and the lessons have been widely discussed.

The organisation

Bharat Pay Solutions was a Bengaluru-based payments-orchestration processor serving Indian e-commerce and ride-hailing clients. Bharat Pay was a Data Processor under the DPDP Act 2023 (section 2(1)(k)) and a PII processor under ISO/IEC 27701:2025 Annex A.2. The firm was pursuing ISO/IEC 27701:2025 certification as a processor (its controller customers required it in their security questionnaires). Bharat Pay was not designated an SDF; its controller customers included two firms that were.

The role-set failure

Bharat Pay's PIMS role set was authored in early 2024 for the certification push. The CISO, Rohit Khanna, was named as the DPO. The Head of Customer Excellence, Priya Nair, was named as the Grievance Officer (although most grievances were forwarded to her by an unmonitored "grievances@" alias). The CERT-In Point of Contact was the CISO wearing a second hat. The Consent Manager liaison was unassigned. The processor-relationship owner role was distributed across the Head of Delivery (who had no charter), the Head of Customer Success (who had no charter), and the Head of Legal (who had a partial charter). The internal auditor was the Head of Compliance, who reported operationally to the CISO, creating a structural conflict of interest (the internal auditor could not independently audit the CISO's DPO work).

The role charters existed in a shared drive folder; the RACI was a spreadsheet last updated in March 2024; the authorities register was a one-page document that listed the DPO's responsibilities but did not explicitly grant authorities. The competency profiles were absent, the CISO/DPO had no privacy-specific credential and no record of privacy training. The induction briefing for new joiners did not include the role-on-a-page. The external privacy notice (Clause 5.2) named "our Data Protection Officer" without a specific name or a direct contact channel, only a generic "privacy@bharatpay.example" alias.

The structural-model decision had never been documented. The CISO/DPO wore seven hats; the Head of Compliance/internal auditor reported to the CISO/DPO; the Grievance Officer's inbox was unmonitored. The firm was, in ISO/IEC 27701:2025 language, a PIMS with named role-holders but without assigned authorities, without competency profiles, without segregation of duties, and without operational communication.

The disruption

On the night of 17 February 2026, a misconfiguration in an Elasticsearch cluster exposed approximately 28 million Bharat Pay user records, card fingerprints, masked card numbers, user PII, transaction metadata. The exposure window was approximately 11 days. The misconfiguration was detected not by Bharat Pay but by a third-party threat-intelligence firm on 28 February 2026.

The role-set failure became operational within minutes of detection.

• CERT-In 6-hour clock. The CISO/DPO was the Point of Contact. He was on a personal trip with limited connectivity. The Head of Compliance/internal auditor attempted to file the report but did not have the CERT-In PoC credentials. The 6-hour report was filed 22 hours after awareness, 16 hours late.
• DPDP 72-hour clock to the Board. The DPO began drafting the section 8(6) notification but had no authority to file it without the executive sponsor's approval. The executive sponsor was on the same personal trip. The notification was filed 96 hours after awareness, 24 hours late. Affected Data Principals were notified by the controller customers over the following 10 days, with Bharat Pay's breach-notification SLA to its controllers missed by 5 days.
• Controller notification. The processor-relationship owner role was distributed across three role-holders with no clear Accountability. The first controller customer was notified 36 hours after awareness; the last controller customer was notified 9 days after awareness. The customer DPAs required notification within 24 to 72 hours; multiple SLAs were breached.
• Infringing-instruction process. One controller customer instructed Bharat Pay to continue processing the breached data to "maintain service continuity." Bharat Pay had no documented infringing-instruction process and no role-holder authorised to push back. The instruction was followed. The processing continued for 8 days before the DPO intervened.

The regulatory inspection

The Data Protection Board of India opened a proceeding on 4 March 2026 under DPDP section 18 read with section 33. The Board's first request was the role charter set, the RACI, and the authorities register. The Board's findings, in summary:

1. The DPO/CISO role concentration created a conflict of interest and a single-point-of-failure; the 16-hour delay in the CERT-In 6-hour report was directly attributable to the unavailability of the single role-pair.
2. The Grievance Officer's contact channel (the unmonitored alias) failed the DPDP section 13 "readily available means" requirement.
3. The authorities register did not grant the DPO the authority to file the section 8(6) notification without the executive sponsor's approval; the 24-hour delay was directly attributable to the authority gap.
4. The processor-relationship owner role was distributed across three role-holders with no clear Accountability; the SLA breaches were directly attributable to the role-set ambiguity.
5. The infringing-instruction process was undocumented; the continued processing of the breached data on a controller's instruction was a direct A.2.2.5 failure.
6. The internal auditor's reporting line to the CISO/DPO was a structural conflict of interest; the internal audit's pre-incident review had not identified the Elasticsearch misconfiguration.
7. The competency profiles were absent; the CISO/DPO had no privacy-specific training and no evidence of "expert knowledge of data protection law and practices."

CERT-In opened a parallel proceeding under the 28 April 2022 Directions for the 16-hour delay. The controller customers opened contractual proceedings for the SLA breaches; one terminated the contract.

The consequence

The Data Protection Board of India imposed a penalty of approximately 18 crore rupees on Bharat Pay under section 33 read with the Schedule, with the headline finding articulated as failure on processor obligations (DPDP section 8 read with section 2(1)(k)) and failure on breach notification, with the role-set failures cited as aggravating factors. CERT-In imposed a separate monetary penalty under the IT Act for the reporting delay.

Bharat Pay's ISO/IEC 27701:2025 Stage 2 audit (due in April 2026) was reclassified. The certifying body issued a major nonconformity on Clause 5.3 (phantom DPO; absent authorities register; unchartered overlay roles; structural conflict of interest on internal audit; absent competency profiles) plus further majors on Clause 7.2 (competence), Clause 9.2 (internal audit independence), and Annex A.2.2.5 (infringing-instruction process). The certificate was not recommended.

The commercial cost was larger. Bharat Pay's pipeline of new controller customers contracted sharply; two pending bids were lost. The firm's cyber-insurance premium was increased 60 percent at renewal and the sublimit for incident-response costs was reduced. Two class-action proceedings were filed under the Consumer Protection Act 2019 on behalf of affected cardholders.

The lessons

1. A named DPO is not an assigned DPO. The appointment letter is the start; the charter, the authorities, the competencies, and the communication are the work. The CISO-as-DPO concentration failed on every test except the appointment itself.
2. The CERT-In 6-hour clock is unforgiving. A single-person Point of Contact cannot meet a 24x7 obligation. The role-pair or follow-the-sun arrangement is the minimum.
3. An authorities register is the artefact that converts a name into a role. Without the authority to file the section 8(6) notification, the DPO was a name on a charter.
4. The processor-relationship owner role is the marquee processor-side role. Ambiguity here produces SLA breaches; clarity produces reliable execution.
5. The infringing-instruction process (A.2.2.5) is not boilerplate. It requires a documented process and an authorised role-holder. The continued processing of breached data on a controller's instruction was a direct A.2.2.5 failure and an aggravating factor in the Board's penalty analysis.
6. The internal auditor's independence is non-negotiable. The reporting line to the CISO/DPO suppressed the pre-incident finding that would have caught the misconfiguration.
7. The cost of a 5.3 failure dwarfs the cost of 5.3 conformance. Bharat Pay's 18-crore-rupee DPDP penalty plus the CERT-In penalty plus the customer churn plus the insurance premium increase plus the class actions, versus a 4 to 8 lakh rupee external advisory cost for a proper Clause 5.3 cycle. The asymmetry is several orders of magnitude.

Illustrative Scenario 2: Success, Saffron Finserve SDF with ROI (Illustrative)

Disclaimer. Saffron Finserve is a fictional composite of multiple real Indian BFSI firms designated as Significant Data Fiduciaries under DPDP Act 2023 section 10. It is illustrative; any resemblance to a specific named firm is coincidental. Numbers are illustrative for teaching purposes.

The organisation

Saffron operated a universal-banking subsidiary, an NBFC lending digitally, a life insurance subsidiary, and a securities-broking subsidiary. The firm was designated a Significant Data Fiduciary under DPDP Act 2023 section 10 in January 2026 (on the basis of the volume and sensitivity of financial and credit data processed across the group). Saffron was pursuing ISO/IEC 27701:2025 certification as the management-system lens for its SDF obligations across the group.

The challenge

In November 2025, immediately after the DPDP Rules 2025 were notified, Saffron's Group Chief Risk Officer commissioned a Clause 5.3 readiness review across the four subsidiaries. The existing role set had been authored in 2023 for the ISO/IEC 27001 ISMS and extended sideways to cover privacy. The findings:

• The Group CISO was named as the DPO for the banking subsidiary; the Head of Compliance was named as the DPO for the NBFC; the insurance subsidiary had no DPO; the broking subsidiary had a fractional Privacy Lead.
• No subsidiary had a Grievance Officer dedicated to privacy grievances (existing grievance officers were customer-complaints roles regulated by the RBI ombudsman scheme, the IRDAI grievance rules, and the SEBI investor-grievance mechanism, not DPDP section 13).
• The CERT-In Point of Contact was a single person per subsidiary, all based in Mumbai, none with 24x7 follow-the-sun coverage.
• The Consent Manager liaison was unassigned across the group.
• The internal audit was the group's compliance-testing team, reporting to the Group Head of Compliance, who was also the NBFC DPO.
• The authorities register, the segregation-of-duties map, and the competency profiles were absent.
• The structural-model decision had never been made; the firm had drifted into Model C (CISO-extended) at the banking subsidiary and Model A (DPO-centred) nowhere.

The SDF designation under DPDP section 10 made the role-set gaps directly penalty-exposed (up to 150 crore rupees for section 10 failure).

The phased remediation

The Group CRO sponsored a 14-week Clause 5.3 remediation programme across the four subsidiaries, supported by external advisory.

Weeks 1 to 2: Move 1 (structural-model decision). A workshop with the Group CRO, the four subsidiary CEOs, the Group CISO, the Group Head of Legal, the Group Head of HR, and the external advisors produced a documented structural-model decision: Model A (DPO-centred) at the group level, with the Group DPO as the statutory SDF DPO based in India accountable to the Board; entity-level Privacy Leads at each subsidiary reporting operationally to the entity CEO and matrix-reporting to the Group DPO. The model was recorded in the role-charter preamble; the Board's Risk Management Committee noted the decision at its December 2025 sitting.

Weeks 3 to 6: Move 2 (role-charter authoring). The full role-charter set was authored across the group: the Group DPO charter (statutory SDF DPO; based in Mumbai; accountable to the Board; full-time); four entity-level Privacy Lead charters; four Grievance Officer charters (one per subsidiary, separate from the RBI ombudsman / IRDAI grievance / SEBI investor-grievance roles); the CERT-In PoC role-pair charters (each subsidiary staffed with a primary and a secondary PoC, with follow-the-sun coverage across Mumbai and Bengaluru offices); the Consent Manager liaison charter (a Group Privacy Engineer); the CISO charter (RBI IT Governance Master Direction CISO for the bank, a role the Cybersecurity Directions 2026 kept when they replaced it; SEBI CSCRF Privacy Officer for the broking subsidiary; IRDAI ICS CISO for the insurance subsidiary); the data-owner charters per processing domain (depositor data, borrower data, policyholder data, investor data, employee data, vendor data); the processor-relationship owner charters per major processor segment (cloud, core-banking, lending-platform, policy-administration, trading-platform, payments-processor, KYC-verification, credit-bureau).

Weeks 7 to 8: Move 3 (RACI) and Move 4 (authorities register and segregation-of-duties map). The group RACI was authored with separate sections for controller activities (depositor, borrower, policyholder, investor data), processor activities (the broking subsidiary's custody-processor role; the insurance subsidiary's TPAs), and shared activities. The authorities register granted the Group DPO the authority to halt infringing processing subject to escalation to the Group CRO and to the Board, the authority to commission DPIAs, the authority to refuse new processing that fails a DPIA, the authority to escalate to the Board, and the authority to communicate directly with the Data Protection Board of India. The segregation-of-duties map separated the internal audit (now reporting to the Audit Committee, not to the Group Head of Compliance) from the DPO and from the operational privacy roles.

Weeks 9 to 11: Move 5 (competency profiles) and Move 6 (communication, HR integration, review). The competency profiles were authored for each role-holder. The Group DPO (an India-based lawyer with CIPM and CIPP/E credentials and 12 years of privacy experience) had a complete profile. The entity-level Privacy Leads had profiles with CIPM-and-CIPP/E-in-progress training plans. The CERT-In PoCs had profiles with the CERT-In Directions training record. The Consent Manager liaison had a CIPT credential. The profiles were linked to performance reviews with privacy KPIs (DSAR turnaround, grievance response time, training completion, role-set review participation).

The intranet publication was launched in week 10 with role-on-a-page summaries in English and Hindi. The external privacy notice (Clause 5.2) was refreshed to disclose the Group DPO and the Grievance Officer contacts per DPDP section 5 and GDPR Articles 13 to 14. The CERT-In PoC filings were refreshed. The induction programme was updated. The management-review agenda was updated to include Clause 5.3 annually.

Weeks 12 to 14: tabletop exercise and audit preparation. A group-wide tabletop exercise tested the role set in three simulated scenarios: a borrower-data breach at the NBFC; a DSAR for an investor's full transaction history at the broking subsidiary; a Consent Manager withdrawal at the bank. The exercise identified two role-set gaps (the Consent Manager liaison's authority to honour withdrawal signals across the core-banking system was not explicit; the cross-subsidiary grievance routing for group customers was ambiguous). Both were closed in week 14 with authorities-register updates and a cross-subsidiary grievance-routing procedure.

The quantified results

1. SDF designation review (March 2026). The Data Protection Board of India's SDF compliance team reviewed Saffron's role charter set, the authorities register, the RACI, the competency profiles, and the segregation-of-duties map. The artefacts were accepted without remediation. The Group DPO was confirmed as the statutory SDF DPO.

2. ISO/IEC 27701:2025 Stage 1 audit (April 2026). Zero major nonconformities on Clause 5.3; one minor nonconformity (a small Documented Information metadata gap in the entity-level charter version-reconstruction test, fixed in 48 hours).

3. ISO/IEC 27701:2025 Stage 2 audit (June 2026). Zero nonconformities on Clause 5.3. The certifying body's auditor noted the role-charter set as a benchmark example for the Indian BFSI SDF segment.

4. RBI supervisory review (May 2026). The RBI's Senior Supervisory Manager reviewed the role set as part of the compliance review under the Master Direction on IT Governance (7 November 2023), since replaced by the Cybersecurity Directions 2026. The role set was accepted. The Group CISO/DPO separation was specifically commended.

5. SEBI CSCRF review (July 2026). The SEBI review accepted the Privacy Officer role at the broking subsidiary as compliant with the 20 August 2024 framework.

6. IRDAI ICS review (August 2026). The IRDAI review accepted the CISO role at the insurance subsidiary as compliant with the 24 April 2023 guidelines.

7. Internal culture. The annual staff engagement survey showed a 22-point improvement in the "I know who to contact for privacy questions" item, attributable (per the survey commentary) to the role-on-a-page intranet publication and the induction briefing refresh.

8. Breach readiness. A minor phishing-related incident at the NBFC in September 2026 (approximately 4,200 borrower records exposed for 36 hours) was handled within the role-set SLAs: the CERT-In 6-hour report was filed in 4 hours; the DPDP 72-hour Board notification was filed in 30 hours; the controller-side notification to the partner bank was filed in 12 hours; affected borrowers were notified within 5 days. The Board's compliance team noted the role-set execution as exemplary.

The ROI

The Year-1 ROI on a purely financial basis (insurance saving alone, excluding revenue and penalty-avoidance) is 1.2x, modest but real and recurring. The expected-value ROI (including the avoided DPDP section 10 penalty exposure on an 18-million-customer financial-data base) is several orders of magnitude higher. The revenue wins are the upside of being a sectoral role-set benchmark, Saffron's group role-on-a-page is now referenced by other BFSI firms as the design standard.

The lessons

1. The structural-model decision is the marquee Move 1 act. A documented Model-A-decision-at-the-group-level gave the four subsidiaries a coherent architecture to cascade from. Drift produced the original gaps; choice produced the remediation.
2. The DPDP section 10 SDF DPO is non-negotiable for SDFs. The India-based, board-accountable Group DPO was the artefact the Board's SDF compliance team asked for first.
3. The CERT-In PoC 24x7 reachability is a design problem, not a person problem. The role-pair with follow-the-sun coverage across Mumbai and Bengaluru solved the 24x7 problem at modest incremental cost.
4. The authorities register is the artefact that survives turnover. Names change; the authorities persist. Saffron's authorities register survived two DPO-team departures in 2026 without disruption.
5. The tabletop exercise is the test the auditor and the regulator respect. A RACI on paper is theoretical; a RACI tested in a simulated breach, DSAR, and Consent Manager withdrawal is evidence.
6. The role 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.
7. The SDF overlay is dense but manageable when ISO/IEC 27701:2025 Clause 5.3 is the lens. The DPO, DPIP, audit, and algorithmic-fairness obligations map cleanly onto the role charters.
8. 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.

Multi-Framework Mapping

This section maps ISO/IEC 27701:2025 Clause 5.3 to the relevant controls, articles and sections in the major global and Indian frameworks. The mapping supports a single integrated role-charter set that satisfies multiple regimes simultaneously.

Mapping table

The DPDP DPO versus the GDPR DPO

Both DPDP section 10 (for SDFs) and GDPR Articles 37 to 39 (for in-scope organisations) require a DPO. The two regimes converge on most points (the DPO is a designated role; the DPO advises, monitors, and is the point of contact with the supervisory authority). They diverge on three:

• Geography. DPDP section 10 requires the SDF DPO to be based in India. GDPR does not require the DPO to be based in the EU (Article 37 allows an EU-based representative to be distinct from the DPO).
• Board accountability. DPDP section 10 requires the SDF DPO to be accountable to the Board. GDPR Article 38(3) sets an independence standard but does not require board accountability (the DPO reports to the "highest management level", which can be the CEO or the board).
• Designation trigger. DPDP section 10 applies the DPO requirement to Significant Data Fiduciaries (designated by the Central Government). GDPR Article 37 applies the DPO requirement to public authorities and to organisations whose core activities involve large-scale regular and systematic monitoring or large-scale processing of special categories.

For Indian SDFs with EU data subjects, both regimes apply; the role-charter must satisfy both. For Indian non-SDFs with EU operations triggering Article 37, the GDPR DPO is required but the DPDP SDF DPO is not. For Indian non-SDFs without EU operations, neither statutory DPO is required; the Privacy Lead role is sufficient but a voluntary DPO designation is encouraged.

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

The Consent Manager liaison role has no direct GDPR, NIST or SOC 2 equivalent. The closest cousins are the GDPR Article 7(3) "withdrawal as easy as to give" principle and some sector-specific intermediary models (the Account Aggregator framework under RBI for financial data). Role-charter sets for Indian Data Fiduciaries should name the Consent Manager liaison as a distinct DPDP-overlay role 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.3 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 proposed DPO/Privacy Lead. Open the Clause 5.3 workstream. Pull the Clause 4.1, 4.2, 4.3 outputs and the privacy risk assessment (Clause 6.1.2). Confirm the DPDP overlay assessment (are you an SDF? subject to GDPR Article 37? a BFSI CISO-mandated entity?).

Weeks 2 to 3 (Move 1). Run the 90-minute structural-model workshop. Decide among Model A (DPO-centred), Model B (privacy-team-centred), Model C (CISO-extended). Record the decision in writing with the executive sponsor's signature.

Week 4. Begin Move 2 (role-charter authoring). Draft the six core charters (sponsor, DPO, Steering Committee, data owner, processor-relationship owner, internal auditor).

Days 31 to 90, Build-out

Weeks 5 to 8 (Move 2 continued). Author the DPDP overlay charters (Grievance Officer, CERT-In PoC, Consent Manager liaison, SDF officer if applicable). Author the sectoral overlay charters (CISO, Privacy Officer) if applicable. Author the authorities register (Move 4 first half).

Weeks 9 to 10 (Move 3). Build the controller-processor-shared RACI. Test against the eight activities most often broken (DSAR, dual-clock breach, Consent Manager withdrawal, infringing instruction, sub-processor change, DPIA commissioning, TIA, internal audit programme inclusion).

Weeks 11 to 12 (Move 4 continued). Complete the authorities register. Build the segregation-of-duties map. PIMS Steering Committee review. Executive sponsor approval.

Week 13 (Move 5). Author the competency profiles for each named role-holder. Identify competency gaps; enrol role-holders in training.

Days 91 to 180, Communication, integration, audit

Weeks 14 to 16 (Move 6 first half). Intranet publication of the role-on-a-page. External notice refresh to disclose the DPO and Grievance Officer contacts. CERT-In PoC filing refresh. Induction programme update.

Weeks 17 to 20 (Move 6 second half). HR integration, role descriptions in the HR system; RACI assignments linked to role-holder files; performance-review KPIs. Management-review agenda update. Internal-audit programme update.

Weeks 21 to 24 (Tabletop and audit). Run a tabletop exercise testing the role set in three scenarios (DSAR, breach, Consent Manager withdrawal). Run the first 5.3-specific internal audit using the toolkit doc 04 checklist. Findings closed. Management review (Clause 9.3) includes role-set review. Board / RMC notes the management-review outcome.

Days 181 to 365, Steady state and certification

Months 7 to 9. Run the awareness programme quarterly cycle. Monitor the role-set KPIs (P1 to P7, O1 to O4, A1 to A3). Maintain the Documented Information controls. Run the second tabletop exercise (semi-annual). 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.3 finding closed before the 31 October 2028 organisation transition deadline).

Continuous. Monitor event triggers. Maintain the role-set risk register (Section 10). Refresh the role-on-a-page and the competency profiles on role-holder change. Run the regulatory horizon-scanning cycle quarterly (DPDP Rules amendments; new sectoral instruments; overseas privacy-law developments).

FAQ

Q1. We already have a CISO running ISO/IEC 27001. Do we need a separate DPO for ISO/IEC 27701:2025?

It depends. If you are a Significant Data Fiduciary under DPDP section 10, the answer is yes, a statutory India-based DPO accountable to the board is non-negotiable. If you are subject to GDPR Article 37 (public authority; large-scale regular and systematic monitoring; large-scale special-category processing), the answer is yes. For other growing companies, the CISO may extend to cover the Privacy Lead role (Model C in Section 7 Move 1), but the segregation-of-duties map (Move 4) must record any conflict of interest and the internal audit must be independent. The Singahi decision framework helps you work through the choice.

Q2. Can the DPO also be the Grievance Officer?

Yes, in most cases. The Grievance Officer (DPDP section 13) is the role that owns the response to Data Principal grievances. In small firms the DPO often co-holds the Grievance Officer role. The exception is grievances about the DPO's own processing (typically staff grievances about HR processing where the DPO has advised HR), in those cases the Grievance Officer should be a different person to avoid conflict.

Q3. Can the internal auditor also be the DPO?

No. The internal auditor must be independent of the DPO (segregation of duties, Section 7 Move 4). The internal auditor audits the DPO's work; a dual role is a structural conflict of interest and a direct audit finding.

Q4. Does the DPO need to be a lawyer?

No. GDPR Article 37(5) refers to "expert knowledge of data protection law and practices", that can be acquired through experience, certification or training, not only through a law degree. DPDP section 10 does not prescribe a professional qualification. The competency profile per Clause 7.2 is the artefact that evidences competence. Many Indian DPOs are engineers, compliance professionals or risk professionals with privacy certifications (CIPM, CIPP/E) rather than lawyers.

Q5. Does the SDF DPO have to be physically based in India?

Yes. DPDP section 10 requires the SDF DPO to be based in India. The evidence includes an India-based office, an India-based reporting line, and India-based board accountability. A global Privacy Lead based abroad cannot satisfy section 10 even if they have a formal title. For Indian SDFs that are subsidiaries of foreign parents, the India-based DPO is typically a senior role-holder in the Indian entity who reports to the global Privacy Lead on technical matters and to the Indian board on statutory matters.

Q6. How often should the role set be reviewed?

Annually at the management review (Clause 9.3), plus on event trigger (role-holder change; scope change; SDF designation change; M&A; audit nonconformity; regulatory change; breach or near-miss). See Move 6.

Q7. Do we need a PIMS Steering Committee?

It is permitted but not required. Most growing and enterprise firms maintain one; most growing companies (50 to 250) substitute a sponsor-plus-DPO bilateral. The required artefact is the role charter set, the RACI and the authorities register. A Steering Committee is one of several governance bodies that can deliver those artefacts.

Q8. Do we have to publish the role set on the public website?

No. The internal role set is hosted on the intranet. The external notice must disclose the DPO contact and the Grievance Officer contact (DPDP section 5; GDPR Articles 13 to 14) because the law requires it. The CERT-In Point of Contact is filed with CERT-In. The broader internal role set is private, publishing every role-holder's name on the internet exposes staff to social engineering and undermines the role architecture.

Q9. How do we handle DPO resignation?

DPO change is a Move 6 event trigger. The re-appointment protocol is: (1) within 7 days, appoint an interim DPO (typically the Deputy DPO or the Head of Legal); (2) within 30 days, appoint a permanent replacement; (3) re-sign the role charter with the new DPO; (4) refresh the external notice with the new DPO contact; (5) re-note the board / RMC for SDFs (DPDP section 10 board accountability). The competency profile, the authorities, and the RACI persist through the change, the role survives the role-holder.

Q10. What is the difference between the DPO and the Privacy Lead?

A DPO is a formally designated role under GDPR Article 37 or DPDP section 10. A Privacy Lead is an operational role-holder who leads the privacy programme without the statutory designation. The responsibilities are often identical; the difference is the statutory status. For SDFs and GDPR-Article-37 firms, the title is DPO; for other firms, the title is Privacy Lead.

Q11. Do we need to file the CERT-In Point of Contact formally?

Yes. The CERT-In Directions 20(3)/2022-CERT-In (28 April 2022) require the designation of a Point of Contact and the filing of the contact details with CERT-In. The PoC must be reachable 24x7 (typically a role-pair or follow-the-sun arrangement). The filing is refreshed on role-holder change.

Q12. What is the Consent Manager liaison and do we need one?

The Consent Manager liaison (DPDP section 2(1)(g)) is the role that owns the API integration with Consent Managers registered with the Data Protection Board of India. Every Indian Data Fiduciary should designate a liaison (the role may be a Privacy Lead or Product Engineer wearing a second hat) so that when the Consent Manager ecosystem matures through 2026 and 2027 the organisation is ready. The liaison owns the API integration, the withdrawal-signal honouring across systems, the interoperation testing, and the consent-record synchronisation.

Q13. How do we evidence DPO independence for the audit?

Three artefacts: (1) the role charter's independence and conflict-of-interest declaration (Move 2); (2) the reporting-line evidence (for SDFs, the board-minute noting the accountability; for GDPR Article 38(3), the absence of any instruction on how to exercise the role); (3) the segregation-of-duties map showing the DPO is not in a conflict-of-interest position (Move 4).

Q14. Can we outsource the DPO?

Yes, for non-SDFs (the DPO-as-a-service model is widely used by Indian growing companies that do not have the scale to support a full-time DPO). For SDFs under DPDP section 10, the DPO must be India-based and accountable to the board, an outsourced DPO is permitted only if the outsourced role-holder satisfies these requirements (an India-based DPO-as-a-service firm with a named senior role-holder accountable to the client's board). GDPR Article 37 also permits an external DPO.

Q15. How do we link the role set to performance reviews?

The role-set KPIs in Section 12 are the link. Each named role-holder has privacy KPIs in their annual performance review: the DPO has KPIs on the privacy programme performance (DSAR turnaround, grievance response, training completion, role-set review participation); the Grievance Officer has KPIs on section 13 response time; the CERT-In PoC has KPIs on 6-hour report timeliness and 24x7 reachability; the processor-relationship owner has KPIs on sub-processor change-notification SLA and infringing-instruction response time. The HR integration (Move 6) wires these KPIs into the HR system.

Industry-Specific Requirements

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

BFSI is the most regulator-heavy Indian sector for Clause 5.3. The role-charter set must reflect:

• 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), require a Chief Information Security Officer for banks and NBFCs, a board-approved cyber-security policy and incident reporting within six hours. The CISO charter is statutory, and the breach-response role-pair is DPO + CISO; the CISO often co-holds the Privacy Lead role for non-SDF BFSI firms. For SDFs the DPO is a separate statutory role.
• RBI Master Direction on Digital Lending (2 September 2022), explicit borrower consent; device-data restriction; grievance redressal. The lending-product data owner role and the lending-product Grievance Officer role are charter requirements.
• RBI Tokenisation circular (22 September 2021; full effect 1 October 2022), consent for tokenisation; no raw card data storage. The tokenisation-programme role.
• RBI Storage of Payment System Data (6 April 2018), end-to-end storage of payment data in India only. The payments-data owner role with the locality-oversight responsibility.
• SEBI CSCRF (20 August 2024), Chief Information Security Officer and Privacy Officer for SEBI Regulated Entities. The Privacy Officer charter is statutory for SEBI REs.
• SEBI KRA Regulations 2011 (as amended 2024; Master Circular May 2024), KYC data handling by KRAs and market intermediaries. The KRA data owner role.
• IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023), for insurers: CISO; 180-day log retention; data locality for policyholder data; ICT outsourcing continuity oversight. The insurer CISO charter; the ICT-outsourcing processor-relationship owner role.

The BFSI role-charter set typically includes a "regulatory reporting clocks" set of role-pairs (CERT-In 6 hours; RBI six hours; SEBI RE 6 hours; IRDAI per guidelines; DPDP 72 hours). The board / RMC noting of the role-charter set is mandatory, not optional.

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

Healthcare is the sector where the consent-to-treat-versus-consent-to-process distinction and the algorithmic-fairness overlay intersect most acutely. The role-charter set must address:

• The consent-to-treat-versus-consent-to-process split. The Clinical Operations role (consent to treat) is governed by the Medical Council of India telemedicine guidelines and clinical-establishment law. The DPO/Legal role (consent to process) is governed by the DPDP Act and ISO/IEC 27701:2025. The two roles must be distinct in the charter set.
• AI diagnostic-assist disclosure and the algorithmic-fairness review role (DPDP section 10 SDF). Where AI is used for radiology, pathology, or diagnostic assist, the role-charter set must name the algorithmic-fairness review owner.
• Cross-border transfer of health data. Telemedicine serving NRI patients; radiology-image sub-processing for AI model training. The TIA-owning role.
• Pediatric patient data (DPDP section 9). The verifiable-parental-consent owner role; the no-behavioural-monitoring / no-targeted-advertising enforcement role; the child-readable notice owner.
• Clinical trial data. The ICH-GCP / New Drugs and Clinical Trials Rules 2019 layer. The trial-consent role (separate from DPDP consent).
• The Digital Information Security in Healthcare Act (DISHA) draft remains in limbo, DPDP is the operative instrument. The role-charter set references DPDP and notes the DISHA uncertainty where relevant.

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 the marquee.

• The processor-relationship owner role is the interface with controller customers. The role owns the DPA execution, the sub-processor list and change-notification, the breach-notification SLA, the cross-border transfer impact assessment, and the infringing-instruction process (Annex A.2.2.5).
• The Privacy Engineer role is critical for SaaS, privacy by design and by default is engineering work, not legal work. The Privacy Engineer owns 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.
• The customer trust portal publication role is a sales asset for SaaS and ITeS firms serving enterprise customers.
• DPDP section 8(5) availability, for SaaS handling personal data, availability is a statutory obligation. The SRE/DevOps role interface with the DPO.

E-commerce and Retail

• Cookie/SDK consent owner role, granular per-purpose consent; cookie banner with per-category granularity.
• Behavioural advertising opt-out owner, and, where AI-based profiling produces legal/significant effects, the algorithmic-fairness review owner.
• Age-verification role for restricted products; verifiable-parental-consent owner for minors' accounts.
• Marketplace-versus-seller role split, the notice must address which entity is the controller for which processing activity; the role-charter set must mirror the split.
• Loyalty-programme consent owner, separate consent for loyalty enrolment; cross-programme data sharing.
• The Consumer Protection (E-Commerce) Rules 2020 Grievance Officer, typically the same role-holder as the DPDP section 13 Grievance Officer.

Edtech

Edtech is the sector where DPDP section 9 (children) is the marquee challenge.

• Verifiable-parental-consent owner, DPDP section 9 and the DPDP Rules 2025. The mechanism must verify the parent or guardian's identity and consent.
• No-behavioural-monitoring / no-targeted-advertising / no-tracking enforcement role, section 9 hard requirements.
• Child-readable notice owner, age-appropriate language, simple icons, audio versions.
• School-versus-Edtech processor relationship role split, 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 Protection of Children from Sexual Offences (POCSO) Act 2012 reporting role intersects with privacy obligations for child-safety disclosures.

Manufacturing

• Employee-data role, biometric access control, CCTV, vehicle and asset tracking, health-and-safety data. The employee-data owner role with the workplace-privacy overlay.
• Vendor and contractor data role, KYC, supplier-portal data.
• OT/IT convergence role, operational-technology data that may identify individuals (operator logs, shift data).
• The Factories Act 1948 and state factory rules compliance role, health-and-safety data, accident records.
• Cross-border transfer role for multi-site manufacturing groups, group-company data flows, the negative-list screen.

Maturity Model

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

Level 1, Phantom roles

Characteristics. A privacy owner named in the organisation chart (often the CISO or Head of Legal wearing a second hat), no charter, no RACI, no documented authorities, no competency profiles, no DPO appointment letter even where the organisation is an SDF, the Grievance Officer is a generic customer-support inbox, the CERT-In PoC is an alias nobody monitors, the consent Manager liaison unassigned. The classic decoration.

Audit outcome. Major nonconformity on Clause 5.3 at Stage 1. Direct DPDP section 10 penalty exposure for SDFs that have not formally stood up the DPO; section 13 exposure for the unmonitored Grievance Officer.

Level 2, Chartered but uncommunicated

Characteristics. Role charters authored for the six core roles plus the DPDP overlay roles, signed by the executive sponsor, dated, hosted on the intranet in English only, no role-on-a-page, no induction briefing, RACI authored but not refreshed, authorities register authored but not exercised, competency profiles partially authored, the CERT-In PoC filed but single-person, the Consent Manager liaison unassigned or untested.

Audit outcome. Typically a minor nonconformity at Stage 1; closeable before Stage 2. Some DPDP exposure on the Grievance Officer and CERT-In PoC dimensions.

Level 3, Named-people PIMS

Characteristics. Role charters authored for the full role set (six core plus DPDP overlay plus sectoral overlay), signed through the correct governance chain (including board/RMC noting for SDFs, BFSI, listed entities, insurers), the authorities register with explicit grants exercised at least once, the RACI tested in a tabletop exercise, the segregation-of-duties map, the competency profiles complete with evidence, the role-on-a-page published on the intranet and acknowledged by staff, the external notice disclosing the DPO and Grievance Officer contacts, the CERT-In PoC filed as a role-pair with 24x7 coverage, the Consent Manager liaison designated with an API integration plan, wired into the management review and the internal audit programme, the HR integration with performance-review KPIs.

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

Level 4, Integrated and platform-hosted

Characteristics. All L3 characteristics plus: the role charter set is hosted on a privacy-management platform or GRC-with-PIMS module; the RACI is integrated with the HR system; the authorities register is exercised and the exercise is logged; the role-on-a-page is published in multiple languages and accessible formats; the tabletop exercise is run semi-annually with multiple scenarios; the role-set KPIs roll into the board / RMC dashboard; the Consent Manager API integration is operational; the role-charter set is integrated with the ISMS Clause 5.3 charter set, the BCMS Clause 5.3 charter set, and the AIMS Clause 5.3 charter set where multiple standards apply.

Audit outcome. Stage 2 pass with zero nonconformities on 5.3; typically supervisor-grade (the certifying body treats the role-charter set as a benchmark).

Level 5, Predictive and benchmark

Characteristics. All L4 characteristics plus: the role-charter set is sectoral benchmark (the firm shares its architecture with industry bodies, regulators, and standards committees); the role set is 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 role set is part of the firm's commercial proposition (the role-on-a-page and the role-charter set are referenced in tender proposals); the Consent Manager integration is operational across multiple Consent Managers; the algorithmic-fairness review role is mature for SDFs; the firm participates in DPDP-rule-making consultation through industry bodies.

Audit outcome. Continual Stage 2 pass; the role-charter set is 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 8 to 14 weeks and from L3 to L4 in 6 to 12 months.

Emerging Trends

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

The DPDP Rules 2025 full-enforceability window and the SDF designations

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 first Significant Data Fiduciary designations under section 10 are anticipated through 2026 and 2027, with the Central Government expected to notify large digital platforms, BFSI groups, health-data processors, and government databases as the first wave. Indian growing companies that use this window to stand up the role-charter set, particularly the SDF DPO with board accountability, will be ready; those that wait will face the Data Protection Board's first wave of proceedings.

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 liaison role is the operational bridge, the role that owns the API integration, the withdrawal-signal honouring, the interoperation testing, and the consent-record synchronisation. Forward-looking firms designate the liaison role now and procure consent-management platforms that are Consent-Manager-API-ready.

The SDF algorithmic-fairness overlay and the role of the Privacy Engineer

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 role category, the algorithmic-fairness review owner, and elevates the Privacy Engineer role for SaaS firms using AI. Indian firms designated as SDFs, and any firm using AI for credit, hiring, content moderation, healthcare diagnostic assist, or marketing, should stand up the role and link it to the AI management system under ISO/IEC 42001:2023.

Integrated 27001 + 27701 + 42001 governance on the harmonized structure

The ISO harmonized structure 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.3 role-charter sets can be authored as a coordinated set with shared scope, integrated RACI, 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.

DPO-as-a-service for growing companies

The DPO-as-a-service model, where an external firm provides a fractional DPO plus deputy coverage plus back-office privacy engineering, is maturing rapidly in India. For growing companies (50 to 250) that are not SDFs and do not have EU operations triggering GDPR Article 37, the DPO-as-a-service model is cost-effective and provides competency depth that an in-house fractional role cannot match. For SDFs the model works only if the external firm satisfies the section 10 India-based-and-board-accountable requirements.

The cross-border role architecture for multi-jurisdiction firms

Indian firms with overseas data subjects increasingly need a multi-jurisdiction role architecture: an India-based Group DPO plus entity-level Privacy Leads in the EU, the UK, the US, Brazil, China, Singapore as applicable. The role-charter set must address the GDPR Article 27 representative for non-EU firms serving EU data subjects, the various national DPO requirements (PDPA Singapore mandates a DPO; Saudi Arabia PDPL requires a similar role), and the cross-border transfer impact assessment owner. The architecture is more complex than the single-jurisdiction set but the principles (assign, communicate, authorise) are the same.

The board-level role accountability consolidation

For Indian BFSI, listed entities, and SDFs, the board-level role accountability is consolidating across the Companies Act 2013 (section 134(3)(n) risk-management statement; section 177 Audit Committee), SEBI LODR Regulation 21 (Risk Management Committee), RBI Cybersecurity Directions 2026 (board-approved role set), SEBI CSCRF (board-approved cyber-resilience policy), IRDAI ICS 2023 (board-approved Information and Cyber Security Policy), and DPDP section 10 (SDF DPO accountability to the board). Forward-looking boards are responding by consolidating the role-set review at a single board / RMC sitting per year, with a unified role-set dashboard that satisfies all the regimes simultaneously. The Singahi board-pack advisory is built around this consolidation.

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.3 for Clause 5.3) 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.3; 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; identifies roles and responsibilities for PII processing).
• ISO/IEC 29100:2011 Information technology, Security techniques, Privacy framework (the 11 privacy principles, including Accountability; a newer edition may exist, verify on iso.org).
• ISO/IEC 29134:2017 Information technology, Security techniques, Guidelines for privacy impact assessment.
• 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.3 sibling).
• ISO 22301:2019 Security and resilience, Business continuity management systems (the BCMS Clause 5.3 sibling).
• ISO 9001:2015 Quality management systems (the QMS Clause 5.3 sibling).
• ISO/IEC 20000-1:2018 Information technology, Service management (the SMS Clause 5.3 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, 70B. 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.
• 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 on DPOs (WP243 rev.01); Guidelines 4/2019 on Article 25; Guidelines 05/2020 on consent; Guidelines 9/2022 on personal data breach notification.
• UK GDPR; Data Protection Act 2018 (c. 12); UK International Data Transfer Agreement (IDTA) and UK Addendum to EU SCCs.
• 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.
• 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.
• 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.

• Juspay 5 January 2021 event, approximately 35 million records; publicly acknowledged by the company. juspay.in statement.
• BigBasket 2020 event, approximately 20 million records alleged; reported in mainstream media; threat-intel firm Cyble.
• Air India / SITA breach (disclosed February-May 2021), approximately 4.5 million customers affected; reported in Reuters and the company's regulatory notifications.
• MobiKwik 2021 event, contested allegations; denied by the company; referenced as the marquee Indian payments-data controversy.
• COVID-19 patient-data exposures (2020-2021), multiple state-government portals; the cumulative episode as one of the largest health-data exposures in India.

A reading note on contested attribution and unverified claims

In keeping with the accuracy rules in the standards-factory authoring contract: the Juspay event figures are publicly acknowledged by the company; the MobiKwik 2021 event figures are contested (the company disputes the researcher's disclosure); the Bharat Pay Solutions illustrative scenario in Section 14 is illustrative and does not assert any specific real firm's 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.