One Control Set, Five Rulebooks: DPDP and Sector Regulators

Executive summary

A regulated entity never meets the Digital Personal Data Protection Act, 2023 (the DPDP Act) on a blank page. An NBFC reports cyber incidents to the RBI, a stockbroker files with SEBI, an insurer keeps records under IRDAI rules, a telecom operator works under its DoT licence, and all answer to CERT-In. From 13 May 2027 the DPDP Act and the DPDP Rules, 2025 add a lawful ground for every use of personal data, individual rights, breach notices to the Data Protection Board and each affected person, and penalties of up to ₹250 crore for failed security safeguards.

Running DPDP as a separate project duplicates policies, incident processes and audits, though most DPDP controls already exist in sector form. This paper offers a framework instead:

1. 1.Read the bridge provisions first. Section 38 makes the Act additional to sector law, prevailing only on conflict; section 16(2) preserves stricter limits on sending data abroad.
2. 2.Map once. One table maps ten control areas across the DPDP Act, the RBI, SEBI, IRDAI, DoT and CERT-In.
3. 3.Resolve the four real conflicts: retention against erasure, regulator access against transparency, the RBI's "redundant" bureau consent, and TRAI consent against DPDP consent.
4. 4.Build one programme: a control library with parameters set by the strictest rule in scope, one incident desk filing in each entity's name, and evidence collected once.

A worked example applies it to an NBFC group with insurance-broking and stockbroking arms.

Background

This paper is for organisations that answer to a sector regulator as well as the Data Protection Board, from banks and NBFCs to brokers, insurers and telecom operators. Under the DPDP Act each is a data fiduciary, the person who decides why and how personal data is processed. Its customers are data principals, and vendors acting on its instructions are data processors.

Trayambic's impact studies on banks, insurance, telecom, fintech, capital markets and NBFCs cover each sector's rules in depth. This paper takes the compliance head's view instead, where one customer record is governed by several rulebooks at once.

Those rulebooks have been rewritten in the run-up to commencement. The RBI consolidated its Master Directions on 28 November 2025 and issued cyber resilience directions on 31 July 2026. SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF) of 20 August 2024 gained a new reporting circular on 24 August 2026. IRDAI replaced its records regulations in 2025, DoT added telecom cyber security rules in 2024, and TRAI redefined consent for commercial messages on 18 September 2026. None was written to fit the DPDP Act.

Legal framework

Section 38: additional, and prevailing only on conflict

Section 38(1) says the Act's provisions are "in addition to and not in derogation of any other law for the time being in force". Section 38(2) says that in a conflict the Act prevails "to the extent of such conflict".

So sector duties survive, and the entity must usually meet the stricter parameter of each regime. The override is narrow, because the Act removes most clashes itself:

• Section 6(6): after withdrawal, processing stops unless required or authorised under the Act or any other law.
• Section 7(d) and (e): legal duties to disclose information to the State, and compliance with judgments and orders, are legitimate uses.
• Sections 8(7) and 12(3): erasure yields where law requires retention.
• Section 11(2): the access summary need not reveal sharing with an authority, on its written request, about offences or cyber incidents.
• Section 17(1): processing to enforce legal claims, by bodies performing judicial, regulatory or supervisory functions, for offences or contraventions of law, or to ascertain a loan defaulter's finances is largely exempt; sections 8(1) and 8(5) still apply.

Section 16(2): stricter transfer rules survive

Section 16(1) lets the Centre restrict transfers to notified countries, and none has been notified. Section 16(2) preserves any law providing "a higher degree of protection for or restriction on transfer of personal data" outside India. Sector localisation rules therefore apply in full; Trayambic's article on cross-border transfers lists them.

Directions and licences as "law"

Sections 6(6), 8(7) and 12(3) defer to "law". Trayambic's retention paper sets out when an instrument qualifies: in our view binding regulations and directions made under a statutory power, such as RBI Master Directions and SEBI regulations, do; advisories, FAQs and good-practice notes do not. Licence conditions imposed under statute, such as the telecom licence, are a closer call that we would treat as law. Every register entry should therefore name its parent statute.

Analysis

Where the regimes overlap

Ten control areas recur across the rulebooks.

A dash means this paper maps no specific requirement for that cell, not that none exists. RBI entries cite the commercial bank or NBFC directions; other RBI-regulated entities have parallel instruments.

Three patterns stand out. Sector rules are usually stricter on clocks, locations and approval levels; the DPDP Act on purpose, audience and the individual. Clocks start at different moments: CERT-In on noticing, the RBI on detection, the DPDP Rules on awareness. And scopes differ: the RBI's storage rule covers payment system data, while the DPDP Act covers all digital personal data, employees included. A 2025 IRDAI direction is reported to require six-hour reporting to IRDAI itself.

A sector permission is not a DPDP ground

Confidentiality rules list when disclosure is allowed. The RBI's KYC directions for banks allow it under compulsion of law, a duty to the public, the bank's own interest, or the customer's express or implied consent. The DPDP Act asks instead which ground in sections 6, 7 or 17 supports the processing.

In our view, compulsion of law maps to s.7(d) where the State is the recipient, or s.7(e) for an order. A duty to the public maps to s.17(1)(c) only where offences are concerned, and the bank's own interest to s.17(1)(a) only where it is enforcing a legal right or claim. Implied consent fails the s.6(1) test of "a clear affirmative action". IRDAI's exceptions for risk assessment and claim settlement, and SEBI's written-consent rule, need the same translation.

In our view, where a sector rule permits a disclosure that no DPDP ground supports, the Act governs from 13 May 2027. Both can be obeyed by not disclosing, so there is no conflict for the sector rule to win.

Conflict 1: retention against erasure

The Act requires erasure once the purpose is served or consent is withdrawn, and on request, unless retention is necessary for compliance with law (ss.8(7) and 12(3)). Sector floors, shown in the table, differ by regulator and record.

Because the Act yields to law, the dispute is about how far the yield extends. Trayambic's retention paper sets out the general method; for regulated groups, in our view:

• The floor covers the record the rule names, nothing else. A KYC rule protects the KYC file, not the marketing segment built from it.
• A minimum is not a maximum. Once the longest applicable period and any legal hold have run, the record goes.
• Retention for compliance is not retention for use. Records kept only because a rule requires them belong in a restricted archive that business teams cannot query.
• Each entity's floor protects its own copy. A group data lake cannot keep everyone's data for ten years because one group company is an insurance intermediary.

The tool is a retention register: record class, governing rule and parent statute, trigger event, period, archive state and deletion method. The strictest rule wins, for that record class only.

Conflict 2: regulator access against transparency

Regulators and agencies take data the customer may never hear about, and sometimes must not: inspection samples, suspicious transaction reports to FIU-IND, interception orders and CERT-In's calls for information. The Act gives the customer a right to learn who received her data (s.11(1)(b)) and a notice when it is breached.

The Act settles most of this itself, as Trayambic's article on government data requests explains. A disclosure that law requires to the RBI, SEBI, IRDAI, FIU-IND or DoT fits s.7(d); in our view each is "the State" as the Act defines it by reference to Article 12. Section 5 notice attaches to consent requests, so a statutory disclosure needs no fresh notice, though a general line in the onboarding notice is good practice. Section 11(2) keeps written requests about offences or cyber incidents out of the access summary, and s.17(1)(c) removes Chapter III rights for processing that serves the prevention or investigation of offences, which covers suspicious transaction reports. The regulator's own supervisory processing falls within s.17(1)(b). On breach notices, Trayambic's breach-notification framework gives our view: never delay the Board, and defer individual notices only briefly on a written request.

That leaves routine supervisory sharing outside s.11(2). In our view an access summary can name the regulator without describing the inspection. A disclosure register should tag each outbound flow with its ground and its visibility in rights responses, with legal signing off every exclusion.

Conflict 3: the RBI's "redundant" bureau consent

Paragraph 11 of the RBI's NBFC Credit Information Reporting Directions, 2025 says that because the Credit Information Companies (Regulation) Act, 2005 (CICRA) backs the sharing of credit information, the consent clause has become redundant, and a lender "need not insist upon obtaining such consent from borrowers".

That is a statement about credit information law. From 13 May 2027 the lender also needs a DPDP ground, and none fits neatly. Credit bureaus are private companies, so s.7(d) does not apply; s.7(a) falls away once a borrower objects; and s.17(1)(f) reaches defaulters, not the whole book. Trayambic's credit bureau study sets out the analysis.

There is no s.38 conflict, because the RBI permits consent rather than forbidding it. The fix is to keep taking it: name every RBI-registered bureau and the reporting purpose in the loan notice, and rely on s.6(6) to carry reporting through any withdrawal, since CICRA requires it. Because reporting is a legal incident of the loan, in our view including it in the loan consent does not offend the "unconditional" standard in s.6(1). The s.5(2) notice to existing borrowers should say the same.

Conflict 4: TRAI consent is not DPDP consent

TRAI's commercial communications regulations, as amended on 18 September 2026, define consent as permission "either explicit or inferred" to receive commercial communications, inferred consent resting on the customer's existing dealings with the sender. Explanation 1 limits it to opening a channel; Explanation 3 preserves the sender's DPDP obligations; and TRAI's explanatory memorandum says revocation "does not, by itself, amount to withdrawal of consent under the DPDP Act". The consent changes commence 30 days after Gazette publication.

DPDP consent must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action", which an inferred permission cannot meet. An entity texting a loan customer about insurance needs a TRAI basis to use the channel and a DPDP basis, usually consent, to use her data to select her.

The answer is one preference centre with two ledgers: channel permissions, synced with the operators' consent register, and purpose consents. A DPDP withdrawal stops all marketing relying on it, on every channel. A TRAI revocation stops one channel, but in our view should prompt an offer to withdraw DPDP consent too.

Smaller frictions are covered in Trayambic's sector studies: minors who may run bank accounts from age ten (banks), SEBI nominees who are not automatically DPDP nominees, and SEBI's suspended localisation standard (capital markets).

One control library

Write each control once, in neutral terms, and attach every requirement it satisfies. A control record carries an objective, parameters (clock, period, location, approval level), the source of each parameter, the entities and data in scope, an owner, a test and the evidence it produces.

Set each parameter to the strictest rule within that rule's scope. Group log retention becomes one year in India: the DPDP Rules supply the year, CERT-In the location. Escalation runs on six hours for anything that may be a cyber incident and "without delay" for every personal data breach. Scope stops the strictest rule spreading: India-only storage for payment data does not reach HR records. A new circular then becomes a parameter edit, not a new project.

One incident desk

Every regime has its own trigger, clock, recipient and format; Trayambic's breach-notification framework compares them. A group needs one desk that runs them all:

• one intake for cyber events, misdirected mail, lost devices and vendor alerts, because DPDP breaches are not only cyber incidents;
• one fact record that timestamps "noticed", "detected" and "aware";
• a clock register listing each affected entity's recipients and deadlines;
• pre-approved notices in each entity's name.

The desk can be shared; the duty cannot. CERT-In's FAQs say an entity that notices an incident must report it and cannot transfer that duty, and each fiduciary owes its own Rule 7 notices.

One body of evidence

Collect evidence once and index it to every requirement it serves: tests by a CERT-In empanelled auditor (which the CSCRF requires for all its audits), log-retention reports, access reviews, deletion logs and incident drills. A vendor questionnaire built on the master map can serve the RBI's outsourcing directions, the CSCRF, IRDAI's guidelines and s.8(2) at once.

Reuse evidence, not conclusions. A cyber audit says little about grounds, notices or rights, so it cannot replace a DPDP assessment; Trayambic's paper on Significant Data Fiduciaries covers those.

Worked example: an NBFC group with two broking companies

A Middle Layer NBFC lends to 9 lakh borrowers. Its group includes an IRDAI-registered insurance-broking company selling motor and health cover, much of it to the NBFC's borrowers, and a SEBI-registered stockbroking subsidiary with 1.5 lakh clients. A group services company runs the CRM, data lake, security operations centre and SMS gateway for all three. All figures are illustrative.

1. 1.Three fiduciaries, one processor. Each regulated company is a separate fiduciary; group membership is not a ground. The services company is a processor for each, under a contract with entity-wise schedules that also carries the RBI outsourcing, CSCRF third-party and IRDAI terms.
2. 2.Scoped parameters. Logs stay one year in an Indian cloud region for all three. The RBI's India-server rule for digital lending covers the NBFC's loan data, not the broker's research subscriptions.
3. 3.Retention by record, not by person. A borrower who also trades and holds a policy has one data-lake profile but three record sets. Five years after her loan relationship ends, the NBFC's KYC copy goes, though the stockbroker keeps its records for eight years and the insurance broker for at least ten.
4. 4.Cross-selling needs consent at source. To text borrowers about health cover, the insurance broker needs the NBFC to have the borrower's DPDP consent and her express permission under its KYC directions, and needs explicit TRAI consent itself, having no dealings of its own with her. One screen in the NBFC's app, naming the broker, records the DPDP consent and starts the broker's TRAI consent registration.
5. 5.One incident, separate filings. A misconfigured CRM export exposes contact and product details of 40,000 customers across the group. The desk opens one fact record. The NBFC reports on DAKSH within six hours of the services company's detection; the stockbroker emails SEBI within six hours and uses the portal within 24; the services company and each regulated company report to CERT-In within six hours of noticing or being told. Each company informs the Board and its own customers and files its own 72-hour report. In our view one notice can serve a customer of two companies if it names both and carries each one's Rule 7 content.
6. 6.One test, three audits. One CERT-In empanelled assessment of the shared platform, with entity-wise scope sections, feeds the stockbroker's CSCRF audit, the NBFC's IS audit and the insurance broker's IRDAI assurance audit, and doubles as Rule 6 evidence.

Compliance framework

Checklist

Roadmap to 13 May 2027

Now to December 2026. Build the obligations register and control library. Assign an owner company to each shared platform and sign processor contracts with any group services company.

January to March 2027. Complete the retention and disclosure registers. Rebuild marketing and loan journeys around the two consent ledgers and bureau consent. Run a joint incident drill, including a non-cyber breach.

April to 13 May 2027. Re-paper vendors, align grievance desks, send s.5(2) notices to existing customers and run the first deletion cycle.

After May 2027. Treat each new circular as a parameter change, review the map quarterly, and watch for SDF designations and the end of SEBI's localisation abeyance.

Recommendations

1. 1.Trace every retention period, disclosure and control to a parent statute.
2. 2.Apply the strictest rule within its own scope, never across the whole estate.
3. 3.Treat sector permissions as questions. Permission to disclose is not a DPDP ground.
4. 4.Keep taking bureau-reporting consent and rely on s.6(6).
5. 5.Run two consent ledgers for marketing: one for the channel, one for the data.
6. 6.Share the incident desk, not the duty. File in each entity's name, on each regime's clock.
7. 7.Collect evidence once and map it many times.

Key takeaways

• Section 38 makes the DPDP Act additional to sector law and lets it prevail only on conflict; ss.6(6), 7(d), 8(7), 12(3) and 17(1) remove most conflicts, and s.16(2) keeps stricter transfer rules alive.
• A sector rule that permits a disclosure is not a DPDP ground; in our view the Act's narrower rule governs because both can be met by not disclosing.
• Retention floors protect the record the rule names, for its period only; each group company's floor protects its own copy.
• The RBI calls bureau-reporting consent redundant, but lenders should keep taking it and rely on s.6(6); TRAI's inferred consent to send messages is never DPDP consent.
• Build one control library with scoped parameters, one incident desk that files in each entity's name, and one evidence index mapped to every regulator.