# DPDP for a corporate group: one programme across many entities

> Under the DPDP Act every company in a group that decides why and how personal data is processed is its own Data Fiduciary; there is no group exemption. A group should run one programme, with shared policy, platform, contracts and assurance, while each entity owns its notices, legal bases, grievances and breach reports. Large groups should prepare for Significant Data Fiduciary duties (an India-based DPO, an independent data auditor and an annual DPIA under Rule 13) before any notification. Most duties start on 13 May 2027.

Source: https://dpdp.commons.inc/dpdp-for-corporates · Updated 25 October 2026 · By the Commons Trust team (commons.inc)

For a single company, the DPDP Act means the same duties as for any Data Fiduciary: a basis and a notice for each purpose, Rule 6 security, breach notices, rights handling and retention, with most duties starting on 13 May 2027 (see [the DPDP Act and Rules guide](/dpdp-act-guide) and the [compliance checklist](/dpdp-compliance-checklist)). For a group, the harder part is that every company deciding why and how personal data is processed is a separate fiduciary (s. 2(i)), the Act has no group exemption, and data moving between group companies needs a basis or a contract like data moving to anyone else. The workable answer is one programme, with policy, platform, contracts and assurance at the centre, and each entity owning its notices, legal bases, grievances and breach reports. The largest groups should also prepare for the extra duties of a Significant Data Fiduciary: an India-based DPO, an independent data auditor and an annual DPIA (s. 10, Rule 13).

Like the Act (s. 2(y)), we say "she" and "her" for every person.

**Jump to what you need:**

- **Group general counsel and privacy leads:** [Each entity is a fiduciary](#each-company-is-its-own-fiduciary), [Sharing inside the group](#sharing-data-inside-the-group), [Where the law is unclear](#where-the-law-is-unclear).
- **CEOs, CFOs and company secretaries:** [Operating model](#a-group-operating-model-what-sits-at-the-centre), [Listed companies](#listed-company-obligations), [Effort estimates](#how-much-effort-our-estimates).
- **CISOs and internal audit:** [Evidence and internal audit](#evidence-and-internal-audit), [Vendors](#vendors-what-changes-at-group-scale).
- **HR, M&A and sector teams:** [Employee data](#employee-data-what-changes-at-group-scale), [Deals and restructuring](#mergers-acquisitions-and-restructuring), [Sector overlaps](#sector-regulators-and-the-dpdp-act).

## Each company is its own fiduciary

The Act places its duties on the "person" who determines the purpose and means of processing, and a person includes a company (s. 2(i), 2(s)). A holding company, its NBFC, its retail arm, its shared services company and its foundation are each a separate person. Each needs:

- notices that name it and meet Rule 3 for what it collects;
- a basis for each purpose: consent, or a named clause of section 7;
- published contact details of a person who can answer questions about its processing (s. 8(9), Rule 9);
- a grievance route with a published response period of no more than 90 days (s. 8(10), Rule 14(3));
- breach notices to the Board and affected people for incidents involving its data (s. 8(6), Rule 7);
- valid contracts with its processors (s. 8(2)).

Each is separately exposed to penalties on its own breach (s. 33). A Significant Data Fiduciary notification can name one company or a class of companies (s. 10(1)), so one entity can carry duties its siblings do not. The group's foundation is a fiduciary too, with its own beneficiary and partner data; see [DPDP for CSR foundations](/dpdp-for-csr-foundations).

Start with an entity register, because the basis decisions, contracts and breach routes all hang off it.

| Field | Example |
|---|---|
| Legal entity | Example Finance Ltd (NBFC) |
| Data Principals | Borrowers, guarantors, applicants, employees, website visitors |
| Role | Fiduciary for lending and HR; processor for none |
| Systems | Loan origination, core lending, collections dialler, group HRIS (hosted by group services company) |
| Sector rules | RBI directions; CERT-In Directions |
| Contact under s. 8(9) | Group privacy office, for this entity |
| Grievance period published | 30 days |
| SDF exposure | Moderate: volume and financial data (s. 10(1)(a)) |

This table is illustrative.
{: .note }

## Sharing data inside the group

Intra-group data flows follow one of the patterns below. Identify which one each flow is before you write any contract, because the law treats them differently.

| Pattern | Example | What the law requires |
|---|---|---|
| A group company processes on another's behalf | Shared services company runs payroll, IT or a call centre for its siblings | It is a processor; a valid contract (s. 8(2)) with security terms (Rule 6(1)(f)), erasure (s. 8(7)(b)) and breach notice back |
| Two or more companies decide the purpose together | A group loyalty programme; a group CRM used by several brands for shared campaigns | Joint fiduciaries ("alone or in conjunction", s. 2(i)); agree in writing who gives notice, takes consent, answers requests and reports breaches |
| One company hands data to another for the recipient's own purpose | Insurance arm receives the bank's customer list to cross-sell | The recipient needs its own basis, almost always consent; the discloser must keep the data accurate (s. 8(3)(b)) and list the recipient on an access request (s. 11(1)(b)) |

Cross-selling needs the most care. A customer who gave her details to the bank for a loan did so for that loan. Whether the bank relies on her consent or on s. 7(a), that basis does not extend to cross-selling by the group's insurance company. Our view: a consent to share with "group companies" for "products and offers" is not specific enough for s. 6(1). Name each company and each purpose, and let her choose separately.

**The paperwork.** We recommend one intra-group data agreement signed by every entity, with schedules: one for each processing service, one for each joint-fiduciary arrangement, and a register of the fiduciary-to-fiduciary disclosures allowed and on what basis. New entities sign an accession letter. A group of thirty companies then needs one document instead of several hundred bilateral contracts, and internal audit has one thing to test. Groups that already run intra-group data transfer agreements or binding corporate rules for European data (GDPR Art. 46, 47) can extend them; the DPDP Act requires neither, but needs the processing contracts in s. 8(2).

## A group operating model: what sits at the centre

The Act does not say how a group should organise. It does say who answers: each fiduciary. A model that works puts standards and tools at the centre and accountability in each entity.

| Activity | Group privacy office | Entity |
|---|---|---|
| Policy, standards, notice templates | Owns | Adopts; adds entity detail |
| Legal basis for each purpose | Sets method; reviews hard cases | Decides and records |
| Consent and preference platform | Owns and runs | Configures its purposes and notices |
| Data map and retention schedule | Sets format; consolidates | Maintains its own |
| Rights requests and grievances | Runs the shared desk, if used | Answers for its data; meets its published period |
| Breach response | Runs the playbook and incident lead rota | Makes its own notices to the Board and people |
| Processor contracts | Owns templates; negotiates group-wide vendors | Signs; manages its own vendors |
| Training | Builds material | Delivers role-wise; tracks completion |
| Assurance | Runs internal audit plan and DPIA method | Produces evidence |
| SDF duties | Prepares DPO, auditor and DPIA capability | Appoints its own DPO if notified |

**The DPO-type role.** Only a Significant Data Fiduciary must appoint a Data Protection Officer: an individual based in India, responsible to its board, who represents it under the Act and is the point of contact for grievances (s. 10(2)(a)). Every other fiduciary needs only a published contact (s. 8(9)). We recommend appointing a group privacy head now, with authority across entities and a reporting line to the parent's audit or risk committee, and naming an accountable owner in each entity with a material data footprint.

**Shared desks.** A single grievance and rights desk is efficient. Each entity must still publish its own means of making a request and its response period (Rule 14(1), 14(3)), and each reply must carry that entity's contact details (Rule 9).

## Significant Data Fiduciary readiness

No Significant Data Fiduciary has been notified as of 25 October 2026. The government will assess volume and sensitivity of data, risk to people's rights, impact on sovereignty and integrity, risk to electoral democracy, security of the State and public order (s. 10(1)), and from 13 May 2027 may call for information to make that assessment (Rule 23, Seventh Schedule, item 3). Large lenders, insurers, telecom and health businesses, platforms with crores of users and large employers should plan as if notification may come with little notice. The duties start once a company is notified, and not before 13 May 2027; the first DPIA and audit are due within twelve months of notification (Rule 13(1)).

| Duty | Source | What to have ready | Lead time we would plan for |
|---|---|---|---|
| DPO based in India, responsible to the board, point of contact for grievances | s. 10(2)(a) | Candidate, role charter, board reporting line, grievance desk wired to the DPO | 2–4 months |
| Independent data auditor to evaluate compliance | s. 10(2)(b) | Auditor shortlisted, independence criteria, scope, evidence index | 2–3 months |
| DPIA and audit every twelve months | s. 10(2)(c), Rule 13(1) | DPIA method, a first DPIA on the riskiest processing, audit programme | 3–6 months for the first cycle |
| Report of significant observations to the Board | Rule 13(2) | Engagement terms requiring the assessor to report; a process to respond | With the auditor contract |
| Due diligence on algorithmic software | Rule 13(3) | Register of models and rules engines; test records | 2–4 months |
| Specified data and its traffic data kept in India | Rule 13(4) | Hosting and vendor map showing where each data set and its flows sit | Depends on what is specified |

The lead times are our estimates, not the law's.
{: .note }

**The DPIA.** The Act defines it as a process that describes the rights of Data Principals and the purposes of processing, and assesses and manages the risk to their rights (s. 10(2)(c)(i)). Build the method once at group level and run it per entity, with one assessment per high-risk activity, such as credit decisions, collections calling, health claims or location tracking.

**The auditor.** The data auditor must be independent (s. 10(2)(b)). Our view: your internal audit team can prepare the ground but cannot be that auditor, and nor can the firm that designed the controls being tested.

**Algorithms.** Credit models, fraud engines, HR screening tools and recommendation systems belong in the Rule 13(3) register; see [DPDP and AI](/dpdp-and-ai).

The penalty for breaching SDF duties is up to ₹150 crore (Schedule, item 4).

## Listed-company obligations

A listed parent carries disclosure and governance duties that DPDP incidents feed into.

- **BRSR.** The top 1,000 listed companies by market capitalisation file a Business Responsibility and Sustainability Report. Under Principle 9 they report the number of data breaches with their impact and the percentage involving customers' personally identifiable information (SEBI Listing Regulations, Reg. 34(2)(f); SEBI's BRSR format, Principle 9, Essential Indicator 7). From 13 May 2027, every DPDP breach goes to the Board, so the BRSR count and the Board filings should come from the same register.
- **Event disclosure.** A penalty or order of the Board against a listed entity or its subsidiary is a deemed-material event under Regulation 30 of the SEBI Listing Regulations (Schedule III, Part A, Para A, item 20). Whether a breach itself must be disclosed depends on materiality (Reg. 30(4)). Our position: treat any of these, and any blocking direction under s. 37, as a candidate for disclosure, and have the company secretary assess materiality the same day, so that disclosure timelines are not missed while facts are being gathered.
- **Directors' responsibility statement.** The board's report must state that the directors devised proper systems to ensure compliance with all applicable laws, and that those systems were adequate and operating effectively (Companies Act s. 134(5)(f)). From the financial year that includes 13 May 2027, the DPDP Act's main duties become part of those laws (parts are already in force).
- **Committees.** For the top 1,000 listed entities, the Risk Management Committee's role includes a framework for information and cyber security risks (SEBI Listing Regulations, Reg. 21 and Schedule II, Part D; [Vinod Kothari summary of the 2021 amendment](https://vinodkothari.com/wp-content/uploads/2021/05/LODR-Amendments-.pdf)). We recommend writing DPDP oversight into that committee's charter, or the audit committee's where there is no RMC, with the group privacy head reporting to it quarterly.
- **Cyber insurance.** Check that cover follows the group structure, names every entity that is a fiduciary, and responds to processor-caused incidents.

What the board itself should ask and see is in [DPDP for boards](/dpdp-for-boards). The group-specific addition to that list: readiness and incidents reported by entity, so that a weak subsidiary cannot hide inside a group average.

## Employee data: what changes at group scale

Employment is a legitimate use (s. 7(i)); the detail is in [DPDP for employee data](/dpdp-employee-data). In a group the differences are these.

- **Group HR systems.** A group HRIS run by the parent or a services company on the employers' instructions is their processor, under contract. Where the parent uses the data for its own purposes, such as talent analytics across companies, our view is that it is a fiduciary for those purposes, and each employing company needs a basis to share.
- **Moves between companies.** An employee transferring from one group company to another moves to a new fiduciary. The new employer needs its own notice and records; the old one keeps only what a law or its purpose requires (s. 8(7)).
- **Monitoring beyond employees.** Our view: s. 7(i) is a weak basis for monitoring visitors and contractors' staff on group premises; the text does not confine its safeguarding limb to employees, but nor does it clearly reach them. Treat their CCTV and monitoring as an open question, with clear notices at the point of capture.
- **Dependants.** Group medical cover brings in children's data, which needs a parent's verifiable consent (s. 9(1)). The employee is usually that parent, and the employer already holds reliable details of her identity and age (Rule 10(1)(a)), so capture her consent as a step in the benefits flow.

## Vendors: what changes at group scale

Each fiduciary answers for its processors "irrespective of any agreement to the contrary" (s. 8(1)). Tiering, clauses and negotiating positions are in [Data fiduciary or processor?](/dpdp-processor-contracts). At group scale:

- **One master agreement** for vendors used by several entities, with each entity acceding to it, so terms are negotiated once and every entity can enforce them.
- **One vendor register** across the group, showing which entities each vendor serves, so a vendor incident can be traced to every affected fiduciary within hours. The 72 hours for the detailed Board report run from each fiduciary becoming aware (Rule 7(2)(b)).
- **Sub-processor lists** held centrally, because each entity must be able to name everyone it shared a person's data with (s. 11(1)(b)).

## Mergers, acquisitions and restructuring

Section 17(1)(e) lifts most of the Act for processing "necessary for" a scheme of compromise or arrangement, a merger or amalgamation, a demerger or other reconstruction, a transfer of undertaking, or a division of companies, "approved by a court or tribunal or other authority competent to do so". It lifts Chapter II (except s. 8(1) and 8(5)), Chapter III and section 16. Security safeguards and responsibility for processors stay. The clause speaks only of companies, so restructurings of trusts, societies and LLPs do not benefit from it.

| Deal type | Does s. 17(1)(e) apply? | What we recommend |
|---|---|---|
| Merger, amalgamation or demerger under a scheme sanctioned by the NCLT, or a fast-track merger confirmed by the Regional Director (Companies Act s. 233) | Yes, for processing necessary for the scheme | Keep transfers to what the scheme needs; give notices from the successor after it takes effect |
| Share acquisition | No exemption needed for the target's own processing: the same company stays the fiduciary | Disclosure to the buyer in diligence needs care (below) |
| Business or asset transfer by contract, with no approval by a court, tribunal or authority | No | The seller needs a basis to disclose; the buyer needs its own basis to use the data |
| Due diligence before any approval | Unclear | Use aggregated or anonymised data; give personal data only to a clean team, under confidentiality and use-restriction terms |

**Diligence.** Personal data in a virtual data room is disclosed to a third party. We recommend putting employee and customer data in only in aggregated or anonymised form, with identifiable records limited to what the buyer genuinely needs, such as key employment contracts, and shown to a named clean team under confidentiality and use-restriction terms. The buyer is not your processor, so processing terms do not fit.

**After closing.** The exemption covers processing necessary for the scheme. Once integration starts, the successor is fully covered. Send a notice to customers and employees of the acquired business naming the new fiduciary, and do not assume that consents given to the target cover the buyer's other businesses.

**Questions for the target.** Ask for its data map, its bases for processing, its consent records and how they can be proved (s. 6(10)), its breach register, its processor contracts, open grievances, any Board proceedings, and whether it is or may become an SDF. If it is a registered Consent Manager, a change of control needs the Board's prior approval (First Schedule, Part B, item 13).

## Sector regulators and the DPDP Act

The DPDP Act adds to other laws and prevails only where there is a genuine conflict (s. 38). A stricter law on transfers abroad survives it (s. 16(2)). A diversified group runs several regimes at once.

| Group business | Rules to map beside DPDP |
|---|---|
| Bank, NBFC, payments | RBI directions, including its 2018 directive on storing payment system data in India; KYC record-keeping |
| Insurance | IRDAI's Maintenance of Information Regulations, 2025 and its Information and Cyber Security Guidelines |
| Broking, asset management | SEBI's cyber security framework for regulated entities |
| Hospitals, diagnostics, health apps | The Ayushman Bharat Digital Mission's policies where you connect to it |
| Every body corporate | CERT-In Directions: six-hour incident reporting. The Directions require 180 days of ICT logs within Indian jurisdiction. CERT-In's non-binding FAQs (18 May 2022, Q35) have been read as allowing storage abroad if logs can be produced promptly, but commentators disagree, and Q36 keeps financial-transaction records in India. Our recommendation: keep a copy in India. The SPDI Rules until 13 May 2027 |

Retention schedules must show which law requires each record to be kept, because that is what allows you to keep it after a withdrawal or erasure request (s. 8(7), 12(3)). The group breach playbook must start every clock that applies, from CERT-In's six hours ([CERT-In](https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf)) to the Board's 72 hours to the sector regulator's own timeline; see [DPDP breach response](/dpdp-breach-response).

## Evidence and internal audit

A group's evidence is scattered: consent records in one entity's app, logs in a shared data centre, processor contracts in three procurement systems, grievance replies in a shared desk. When the Board asks one entity to show its notice and consent (s. 6(10)) or its safeguards (s. 8(5)), someone has to find that entity's slice of each, fast.

What internal audit should be able to pull, per entity, within a day:

| Control | Evidence |
|---|---|
| Notice and consent | Notice versions by date and language; consent records per person, per purpose, with withdrawals |
| Legal basis | Purpose register with the clause relied on and the reasoning |
| Security | Rule 6 control map; access reviews; one year of logs (Rule 6(1)(e)) |
| Processors | Signed contracts; sub-processor lists; last security review |
| Rights and grievances | Request tracker with dates, outcomes and response times against the published period |
| Breach | Incident register, notices sent, Board reports, drill reports |
| Retention | Retention schedule; erasure job logs; records kept under Rule 8(3) |
| Children | Parent verification method and records (Rule 10) |

Build DPDP controls into the existing internal audit plan: test each material entity once a year, and test group-wide controls such as the platform and the playbook centrally. For an SDF, the same evidence index serves the independent data auditor. One caution on breach investigations: in-house counsel's advice is not covered by legal professional privilege under BSA s. 132 (s. 134 gives narrower protection to communications made to the employer's legal adviser), as the Supreme Court held on 31 October 2025 (In re Summoning Advocates, 2025 INSC 1275), so engage external counsel where you want the investigation's legal advice protected.

Our baseline is a structured assessment run per entity and rolled up, with gaps ranked by penalty exposure. The control list it produces is in the [DPDP compliance checklist](/dpdp-compliance-checklist).

## How much effort: our estimates

These are our planning estimates of internal and adviser effort, not figures from any source, and they vary with how much each entity already has in place. Our [timeline guide](/dpdp-timeline) estimates 57 to 118 person-weeks for one large organisation with roughly 20 to 60 systems holding personal data. For a group:

| Workstream | Estimate (person-weeks) |
|---|---|
| Group core, built once: policy and standards, notice templates, intra-group agreement, vendor master terms, playbook, platform configuration, training material | 25–45 |
| Each entity with a large consumer or employee footprint | 20–50 |
| Each entity with a small footprint, such as a holding or investment company | 3–8 |
| SDF preparation, per entity likely to be notified | 15–30 |

A group with a parent, three operating companies with large footprints and four small entities would, on these estimates, need roughly 100 to 230 person-weeks. With six and a half months to 13 May 2027, that is four to nine people working full time from November.

## Where the law is unclear

These are our positions until the Board or the courts decide otherwise.

**Can one person be DPO for several notified group companies?** Possibly, if she can genuinely discharge the role for each. *Why:* the Act requires an individual based in India, responsible to each SDF's board, and the point of contact for its grievances (s. 10(2)(a)); it does not forbid holding several such roles. *Would change if:* rules or the Board require a dedicated DPO per SDF. *Confidence:* low.

**Is a group shared services company a processor?** Yes, for services it runs on instructions; a fiduciary for any purpose it decides, such as group analytics. *Why:* the role follows who decides purpose and means (s. 2(i), 2(k)). *Would change if:* the Board treats a group as a single decision-maker. *Confidence:* high.

**Does a group services company's knowledge of a breach start the 72-hour clock for the sibling?** Treat it as starting the clock. *Why:* Rule 7(2)(b) runs from the fiduciary becoming aware; whether a processor's knowledge counts as the fiduciary's is unsettled, and inside a group the argument that the sibling "knew" through shared staff and systems is stronger. *Would change if:* the Board says the clock starts only when the fiduciary itself is told. *Confidence:* medium.

**Can a group take one consent for all its companies?** Only if each company and each purpose is named and can be refused separately. *Why:* consent must be specific and unconditional (s. 6(1)). *Would change if:* the Board accepts group-level consents with clear disclosures. *Confidence:* medium.

**Does s. 17(1)(e) cover diligence disclosures?** Treat it as not covering them. *Why:* the exemption is for processing necessary for an approved scheme; diligence often happens before any scheme exists, and in deals that never get one. *Would change if:* the Board reads "necessary for" a scheme to include preparatory work. *Confidence:* low.

**Does s. 9(1) apply when an employee gives her child's data for a benefit?** Yes. *Why:* s. 9(1) applies "before processing any personal data of a child", whatever the basis. *Would change if:* the Board reads s. 7(i) as displacing it. *Confidence:* medium.

## A plan for the next six months

1. **By Friday 13 November 2026.** Appoint a group privacy head with a line to the parent board's audit or risk committee. Approve the programme and budget.
2. **By Friday 4 December 2026.** Complete the entity register. Start the baseline in each entity with a material footprint.
3. **By Friday 22 January 2027.** Finish the data maps. Classify every intra-group flow as processing, joint or disclosure.
4. **By Friday 26 February 2027.** Sign the intra-group data agreement. Decide the basis for each purpose in each entity, including employee monitoring and dependants' data.
5. **By Friday 2 April 2027.** Issue notices and consent flows; sign processor terms with the largest data holders; build the evidence index for internal audit; agree the Reg. 30 materiality process with the company secretary.
6. **By Friday 16 April 2027.** Run a group breach drill that crosses at least two entities and two regulators.
7. **By Wednesday 12 May 2027.** Re-run the baseline, accept residual risks in writing at entity boards, and load the section 5(2) notice campaign for data you already hold ([our guide](/dpdp-existing-data)).
8. **In parallel.** For entities likely to be notified as SDFs, shortlist the DPO and the auditor and run a first DPIA on the riskiest processing.

**How we wrote this guide.** We worked from the text of the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), the CERT-In Directions of 28 April 2022 and CERT-In's FAQs of 18 May 2022, and the linked sources on BRSR and the SEBI Listing Regulations, last checked 25 October 2026. Effort figures and lead times are our estimates. Statements marked "our view", "our position" or "we recommend" are our judgement, not the law. This guide explains the law; it is not legal advice.
{: .note }

## Questions people ask

### Can one group privacy policy cover every company?

A group-wide privacy policy can explain shared practices, but it does not replace the notice each fiduciary must give. A Rule 3 notice must be understandable on its own, itemise the data, give the specific purpose and the service it enables, and give the means to withdraw consent, exercise rights and complain to the Board (Rule 3). It should name the entity collecting the data. Where a form collects for two group companies, say so, and ask for consent to each company's purpose separately.

### Can our foreign parent see data on Indian employees and customers?

Yes, if there is a basis for the parent's purpose and the transfer is allowed. Sending data abroad is permitted from 13 May 2027 unless the government restricts the destination country (s. 16(1)), subject to Rule 15 and any stricter sector law (s. 16(2)); until then, SPDI Rule 7 governs sensitive personal data. Where the parent processes on the Indian company's behalf, a processing contract is needed (s. 8(2)). Where it uses data for its own purposes, such as global talent analytics, it is a fiduciary for those purposes, and the Indian entity needs a basis to disclose the data.

### Is a joint venture inside or outside the group programme?

A joint venture company is its own fiduciary. Each JV partner that receives personal data from it needs its own basis, and the JV's notices must name the JV, not a partner's brand. We recommend that the shareholders' agreement or a data schedule settle which partner's policies and platform the JV uses, who signs its processor contracts, who acts as its contact under s. 8(9), and what data, if any, flows to each partner.

### Does cyber insurance cover DPDP penalties?

Read the policy wording. Many cyber policies cover incident response, forensics, notification costs and third-party claims, and cover regulatory fines only where the law allows them to be insured. Whether a DPDP penalty, credited to the Consolidated Fund of India (s. 34), is insurable has not been tested. We recommend asking your broker three questions in writing: does the policy cover DPDP penalties, does it cover the cost of notifying every affected person under Rule 7(1), and does it cover incidents caused by processors.

### Are independent directors protected if a group company is penalised?

The DPDP Act creates no officer liability, so the question mostly arises under other laws. Companies Act s. 149(12) limits the liability of independent directors and non-executive directors who are not promoters or key managerial personnel to acts with their knowledge, consent or connivance, or lack of diligence, but only for Companies Act matters. It does not apply to the IT Act, where s. 85 can make persons in charge of a company liable for offences such as non-compliance with CERT-In's directions, though s. 85 itself excuses a person who proves lack of knowledge or due diligence.

## About Commons Trust

Commons Trust is a DPDP compliance programme and consent management platform from commons.inc that takes nonprofits, foundations, startups and corporates from wherever they are to fully compliant with India's Digital Personal Data Protection Act. Contact: hello@commons.inc · https://dpdp.commons.inc/#start