People and operationsUpdated 26 min read
DPDP for telecom operators, ISPs, cable and DTH
What telecom operators, internet service providers, cable and DTH platforms and their resellers must do under the DPDP Act alongside the Telecommunications Act 2023: subscriber KYC, CDRs and traffic data, lawful interception, DLT and commercial communications, SIM-swap fraud and retail agents.
At a glance
- Who this is for
- Mobile network operators, virtual network operators, broadband and fibre ISPs, enterprise connectivity providers, cable operators and MSOs, DTH platforms, and their franchisees, distributors and retail point-of-sale agents.
- Your usual role
- Data Fiduciary
- Privacy risk level
- High
- Could you be a Significant Data Fiduciary?
- Likely for larger players
- Most duties apply from
- 13 May 2027, 18 months after the Rules were notified
Do these first
- Map subscriber KYC, CDRs, IPDRs, location and viewing data, and record the legal retention period for each, separately from what DPDP allows.
- Bring every retail agent, franchisee and distributor under a contract and a system that stops them keeping customer documents or biometrics.
- Harden SIM replacement and port-out against SIM-swap fraud, and treat an insider-assisted swap as a personal data breach.
- Separate consent for promotional messages, analytics and data sharing from the consent the telecom rules and the DLT system handle.
- Prepare for Significant Data Fiduciary duties now: a DPO in India, an annual DPIA and audit, and algorithmic due diligence.
Telecom is the plumbing of digital India, and it holds the most complete map of people’s lives. A mobile operator knows who a subscriber is (KYC), whom she calls and messages (call detail records), where she is (cell location), and what she does online (IP and usage records). A DTH or cable platform knows what a household watches. Most of this is collected under licence conditions that require it to be kept, handed to authorities on lawful request, and protected.
The DPDP Act adds a layer on top of that. The risk does not sit in the core network, which is already heavily regulated. It sits at the edges: retail agents who copy KYC documents, SIM-swap fraud through store staff, traffic and location data reused for analytics and advertising, and subscriber lists shared with partners. Telecom operators are among the likeliest candidates for Significant Data Fiduciary status. This guide applies the Data Fiduciary playbook to telecom, internet, cable and DTH.
Are you a Data Fiduciary, a processor, or both?
- Mobile operator, ISP, cable or DTH platform: you are the Data Fiduciary for subscribers, users, and enterprise customers’ contact people. Your billing platform, CRM, call centres, cloud host, bill-printing and email vendors, collection agencies and analytics vendors are your Data Processors.
- Franchisees, distributors and retail POS agents: they collect KYC and sell SIMs or connections on your behalf, so for that work they are your processors, and you are responsible for what they do (section 8(1)). An agent who reuses customer documents, or activates extra SIMs on a customer’s identity, is acting outside your instructions; the result is still a breach you must handle.
- Virtual network operators and resellers: usually a Data Fiduciary for your own subscribers, with the host operator as a processor for network services. Some arrangements make the host operator a fiduciary for licence-mandated records. Write it down.
- Enterprise connectivity and managed services: for the traffic of an enterprise customer’s employees, you are often the customer’s processor. For KYC and licence records, you are a fiduciary in your own right.
- Content and value-added service partners: a partner billing through your carrier billing, or a streaming app bundled in your plan, is a separate Data Fiduciary. Share subscriber data with it only with the subscriber’s consent, or where the subscriber asked for that partner service.
The Act’s own example of a processor comes from telecom (section 6(6), illustration). A telecom operator contracts a processor to email telephone bills. A customer who had consented to emailed bills downloads the operator’s app and opts to receive bills only in the app. The operator must stop emailing her bills, and must make the processor stop too. Every channel preference and every withdrawal must reach your vendors.
The data you hold
| Data category | Where it usually lives | Typical purpose | Sensitivity | Typical retention |
|---|---|---|---|---|
| Subscriber KYC (name, address, photo, ID reference, e-KYC response) | KYC platform, customer acquisition forms, retailer apps | Identifying subscribers as the Telecommunications Act and licence require | High | As licence conditions require after disconnection |
| Customer acquisition forms and agent records | Distributor systems, paper archives, POS apps | Proof of verification, agent accountability | High | As licence conditions require |
| Call detail records, SMS records | Mediation, billing, CDR storage | Billing, lawful requests, network operations | High (who talks to whom) | As licence conditions require |
| IP detail records, NAT logs, DNS logs | ISP core, logging systems | Lawful requests, abuse handling, security | High (online activity) | As licence conditions and CERT-In directions require |
| Cell-site location and network events | Network systems, analytics platforms | Network operations, emergency services, lawful requests | High (movements) | Short for operations; legal minimums for records |
| Billing, payments, credit checks, dues | Billing, payment gateway, collection agencies | Billing, recovery | High (financial) | Tax and accounting law minimums |
| Usage and data consumption, app usage profiles | Policy and charging systems, analytics | Plans, fair use, network planning, offers | High | Short raw; aggregated after |
| Viewing history and channel subscriptions (DTH and cable) | Subscriber management system, set-top box logs, CAS | Billing, channel packs, audience measurement | High (can reveal religion, politics, language) | Billing minimums; short for logs |
| Customer support calls, chats, store visit records | Contact centre, CRM, store systems | Support, complaints, quality | Medium to high | Short unless a complaint is open |
| SIM replacement, port-out and number change requests | Store systems, CRM, porting systems | Account changes, fraud control | High (fraud target) | As licence conditions and fraud investigations need |
| DND preferences and commercial-communication consent | DLT platform, preference systems | TCCCPR compliance | Medium | As TRAI regulations require |
| Enterprise customer contact data | Enterprise CRM, provisioning | Contracts, service delivery | Medium | During the contract and after as accounting needs |
| Employee, store staff and agent records | HR systems, distributor management | Employment, agent onboarding | High | As labour and tax law requires |
Risk hotspots
- Retail agents and KYC documents. Agents photograph documents on their phones, keep paper forms, reuse a customer’s verification to activate extra SIMs, or sell customer data. Failure: fraudulent SIMs on real people’s identities, and a breach you are responsible for (section 8(1)). Control: KYC only through your app with no local storage, registration and verification of every POS agent, device binding, activity monitoring for unusual activation patterns, and contracts with termination for misuse.
- SIM-swap fraud. A fraudster gets a replacement SIM through a store or a social-engineered call centre agent, then intercepts banking OTPs. Failure: financial loss for the customer, and an unauthorised disclosure of her number and identity that is a personal data breach (section 2(u)). Control: strong re-verification for SIM replacement, notification to the existing SIM before activation, cooling-off periods, insider monitoring, and a fast path to tell banks where agreed.
- Traffic data reused for analytics and advertising. Location, browsing domains, app usage and viewing history are commercially valuable. Failure: processing licence-mandated data for new purposes without consent, and sharing “anonymised” location data that can be re-identified. Control: a clear wall between records kept for legal reasons and data used for products; consent for profiling and data products; and aggregation with tested re-identification risk before any external use.
- Promotional calls and SMS. Operators run their own campaigns and carry everyone else’s. Failure: marketing without consent under DPDP, as well as a breach of TRAI rules. Control: DPDP consent per purpose and channel for your own marketing, DLT consent templates for others’ commercial communications, and one-tap withdrawal that updates both.
- Lawful requests handled informally. Requests for CDRs, location or subscriber details arrive by email, phone and WhatsApp from people claiming to be officials. Failure: disclosure to an impostor is a breach; disclosure without a legal basis is unlawful. Control: a single law-enforcement liaison cell, verification of every request against the legal authority cited, written requests only, a register of disclosures, and minimal data per request.
- Call centres and collection agencies. Large outsourced teams see full subscriber profiles. Failure: data theft and abusive collection calls. Control: role-based views with masking, no downloads, screen and call monitoring under a notice, processor contracts that meet section 8(2) and rule 6(1)(f), and audits.
- Bills and account messages to the wrong place. Bills emailed to old addresses, recycled numbers receiving the previous owner’s messages, and bank OTPs going to reassigned numbers. Failure: disclosure of personal data to a stranger. Control: honour channel changes everywhere (the section 6(6) illustration), cooling-off before reassigning disconnected numbers, and accuracy duties under section 8(3) when you share number status with banks and others.
- Set-top box and viewing data. Viewing logs feed audience measurement, ad targeting and recommendations. Failure: profiling households, including children, without consent. Control: consent for personalisation and ad targeting, no targeted advertising directed at children (section 9(3)), and aggregation before sharing with measurement bodies.
- Legacy systems and data lakes. Decades of CDRs, CAFs and billing data across merged entities, with weak access logs. Failure: no one can say who accessed what, which makes breach investigation impossible. Control: inventory, encryption, access logs kept for at least a year (rule 6(1)(e)), and erasure when the legal period ends.
- Enterprise and wholesale data. Managed network services carry enterprise traffic and logs. Control: clear processor terms with enterprise customers, and logs separated from your own subscriber analytics.
Legal basis, purpose by purpose
| Purpose | Basis | Notes |
|---|---|---|
| Subscriber verification and KYC | Retention required by law; 7(a) for the connection the subscriber requested | The Telecommunications Act and licence conditions require identification. Use e-KYC or DigiLocker and masked Aadhaar, not photocopies. |
| Providing the service, billing, collections | 7(a) | The subscriber asked for the connection. Recovery of dues may later rely on 17(1)(a). |
| Keeping CDRs, IPDRs and subscriber records | Retention required by law | Licence conditions set what and how long. DPDP does not shorten these periods. |
| Disclosure to authorities under a legal duty, including lawful interception | 7(d) for your disclosure; 7(c) covers the State’s own processing | Act only on requests that meet the procedure in the Telecommunications Act and the licence. |
| Assisting investigation of offences | 17(1)(c) | Section 11(2) means you need not list such sharing in an access reply when the request was in writing. |
| Processing by notified security agencies | 17(2)(a) | The Act does not apply to notified State instrumentalities for those purposes. |
| Fraud and SIM-swap prevention, spam and scam detection | 17(1)(c) for preventing offences; retention required by law where DoT or TRAI mandate it | Do not reuse fraud signals for marketing. |
| Network operations, capacity planning, quality | 7(a), using aggregated data wherever possible | Individual-level analytics beyond running the service needs consent. |
| Your own promotional calls, SMS and offers | Consent, per channel | Also follow TRAI TCCCPR, including preference registration and DLT. |
| Personalised offers based on usage, location or app data | Consent | Treat as profiling. Offer the plan without it. |
| Sharing data with content partners, lenders, insurers or advertisers | Consent, naming the recipient category | Access rights include who you shared with (section 11(1)(b)). |
| Location or usage data products sold or shared externally | Consent, or properly aggregated data | Location data is very hard to anonymise. |
| Viewing history for recommendations and ad targeting (DTH, cable, IPTV) | Consent | No tracking or targeted advertising directed at children (section 9(3)). |
| Emergency services and disaster alerts | 7(f), 7(h), and retention required by law where mandated | Keep it to the emergency. |
| Staff and agent records | 7(i) for employees; 7(a) and contract for agents | See the employers and HR guide. |
Notices and consent: getting the screens right
| Channel | Do | Don’t |
|---|---|---|
| Retail store and POS agent | Show the notice on the agent’s device and give a copy by SMS link; capture KYC in your app only. | Let agents photograph or photocopy documents on personal phones. |
| Self-KYC and app onboarding | Itemise the data collected for verification and for the service; put marketing and analytics as separate unticked options. | Ask for contacts, call logs or SMS access unless a feature needs it. |
| Customer acquisition form (paper, where still used) | Print a short notice on the form and a QR code to the full notice in local languages. | Hide promotional consent in the declarations. |
| Call centre and IVR | Read a short notice before recording; verify identity before any account change. | Change SIMs, plans or contact details on a phone call without strong verification. |
| SMS and WhatsApp | Keep service messages transactional; put a one-tap opt-out in every promotion. | Send promotions on the transactional route. |
| Self-care app and website | Give a privacy centre with all choices: bill channel, marketing, personalisation, partner sharing. | Make withdrawal harder than signing up. |
| Set-top box and TV interface | Show viewing-data choices on screen with remote-friendly toggles. | Switch on viewing-based ads by default. |
| Field installers (fibre, cable, DTH) | Give installers a scripted notice and the app flow. | Collect documents on paper at the doorstep. |
| Existing subscribers | Send a section 5(2) notice by SMS, app and bill message with a link to manage choices. | Assume old CAF declarations cover analytics or partner sharing. |
Each notice must be readable on its own, itemise the data and the purposes, and give the link and other means to withdraw consent, exercise rights and complain to the Board (rule 3). Offer it in English and every Eighth Schedule language (section 5(3)). A national operator serves every language community, so publish all 22 and make the circle’s main languages the default in stores.
Other laws you must line up with
- Telecommunications Act, 2023 and the rules made under it: authorisation, biometric-based identification of users, lawful interception and suspension, user protection measures for specified messages, and telecom cyber security duties. Many of these rules are recent and still being notified. Confirm the current requirement with counsel.
- Licence and authorisation conditions (DoT): retention of CDRs, IPDRs and subscriber records, KYC procedure, POS agent registration, and security conditions. These set your legal retention periods.
- Indian Telegraph Act and older rules, to the extent still in force or saved: interception procedures and existing licences during transition. Confirm the current requirement with counsel.
- TRAI Telecom Commercial Communications Customer Preference Regulations (TCCCPR) and DLT: registration of senders, headers and templates, consent templates and customer preferences for commercial communications. DLT consent covers commercial communications; it is not DPDP consent for your other purposes.
- TRAI regulations on quality of service, consumer protection and broadcasting (tariff, interconnection, subscriber management): complaint handling and subscriber records for DTH and cable.
- Cable Television Networks (Regulation) Act, 1995 and DTH guidelines (MIB): subscriber management and records.
- IT Act, 2000 and CERT-In Directions (2022): incident reporting on a much shorter clock than the DPDP 72 hours, log retention and synchronised clocks. Confirm the current requirement with counsel.
- Aadhaar Act, 2016 and UIDAI regulations: rules for Aadhaar-based e-KYC, storage of Aadhaar numbers and masking.
- Consumer Protection Act, 2019: unfair trade practices and grievance handling for subscribers.
- Sector rules of your partners: banks rely on your number status and SIM-swap signals; RBI rules shape what they ask of you under contract.
- The Appellate Tribunal under DPDP is TDSAT (section 2(a)), so appeals against Board orders go to the tribunal you already know.
Retention and erasure
- When the purpose ends (section 8(7)): a connection is disconnected, a plan or add-on ends, or a subscriber withdraws consent for marketing or analytics. Stop using the data for that purpose and erase it, unless a law requires you to keep it. For telecom, a law often does.
- The one-year minimum (rule 8(3)): keep personal data, associated traffic data and logs of the processing for at least one year from the date of processing, for the Seventh Schedule purposes, then erase them unless another law requires more. Licence conditions and CERT-In directions may require longer for some records.
- Legal holds: CAFs, KYC records, CDRs and IPDRs follow licence periods; billing follows tax law; disputes and investigations follow their own holds. Hold the records the law names, not the whole subscriber profile, and make sure held records are not used for marketing or analytics.
- Number recycling: erase or disconnect the previous subscriber’s data from the number before reassignment, so messages, wallets and bank links do not follow the number.
- Third Schedule: operators are not in the Third Schedule as such. An operator’s app store, marketplace or social feature could be, if it crosses the thresholds for an e-commerce entity or social media intermediary (2 crore or more registered users in India). If so, erase after three years of inactivity with a 48-hour warning (rule 8(2)), excluding data needed to access the account and virtual tokens.
- Processors: bill-printing, email, analytics, collections and call-centre vendors must erase on instruction (section 8(7)(b)) and confirm in writing.
- Backups and archives: document retention of tapes and archives, and replay erasures after restores. Legacy archives from merged companies are a common blind spot.
Rights requests and grievances
- Channels: the self-care app, the website, stores and the call centre. Publish them with the identifier you need: the mobile number, account number, customer ID or CAF number (rule 14(1), (5)).
- Identity: use an OTP to the registered number, or in-store verification against documents you already hold. Be careful: a request that leads to a SIM change or number disclosure is a fraud target, so verify more strongly for those.
- Access (section 11): give a summary of KYC data, plans, billing, usage categories, marketing and sharing choices, and list the fiduciaries and processors you shared data with (content partners, collection agencies, bill vendors, analytics). Sharing with authorities on written requests for investigation is excluded (section 11(2)).
- CDRs and location: a subscriber’s request for her own call records or location history is usually handled under telecom rules and licence conditions. Line up your DPDP access process with them. Confirm the current requirement with counsel.
- Correction (section 12(2)): address and name changes go through the KYC procedure the licence prescribes; section 12(1) says correction and erasure follow any procedure other laws require.
- Erasure (section 12(3)): erase marketing, profiling and partner-sharing data on request. Refuse erasure of KYC, CDRs, IPDRs and billing records the law requires you to keep, and say which and why.
- Grievances: publish a response period within the rule 14(3) ceiling of 90 days; 15–30 days is good practice. Keep DPDP grievances distinct from TRAI complaint handling, but use the same tracking so subscribers are not bounced between them.
- DPO: once notified as a Significant Data Fiduciary you must have a DPO based in India who reports to the board (section 10(2)(a)). As a likely SDF, appoint one now, publish the contact, and mention it in every reply (rule 9).
- Nomination (section 14): let subscribers nominate someone, which matters for postpaid accounts, family plans and number retention after death.
Breach readiness
Likely scenarios:
- a leak of subscriber KYC data from a distributor or POS app
- SIM-swap fraud through compromised store staff
- a CDR or location data export from an analytics environment
- a compromised call-centre vendor
- a misconfigured bucket of bills or CAF scans
- a set-top box or self-care app vulnerability exposing account details
- a fake law-enforcement request answered with real data
Run-book:
- Contain within hours: suspend the agent IDs or vendor access involved, block suspicious SIM changes, rotate credentials, and take exposed storage offline.
- Assess: which data, how many subscribers, and the consequences: OTP interception and bank fraud, identity theft, physical safety where location leaked.
- Notify affected subscribers without delay by SMS, app and registered email, covering every point in rule 7(1): what happened and when; the likely consequences for them; what you are doing; what they should do (for example, check for unknown SIMs on Sanchar Saathi, alert their bank, never share OTPs); and a contact.
- Notify the Board without delay, then send the detailed report within 72 hours (rule 7(2)), with updated facts, causes, mitigation, findings about the person who caused it, remedial steps and a report on the notices to subscribers.
- Report to CERT-In and to DoT and other authorities under the Telecommunications Act rules and licence conditions, which may require faster reporting. Confirm the current requirement with counsel.
- Tell partners: banks and payment partners where SIM-swap or OTP risk exists.
- Learn: fix the root cause, terminate or retrain agents, and record the incident for the annual DPIA and audit.
The checklist
Phase 1: discover (days 0–30)
- [Leadership] Appoint a DPO based in India, reporting to the board, and fund the programme.
- [DPO] Prepare for SDF status: assume you will be notified and plan the annual DPIA and independent audit (rule 13).
- [Eng] Inventory every system holding subscriber, traffic, location or viewing data, including legacy and merged-entity archives.
- [Legal] For each data category, record the licence, Telecommunications Act, TRAI or CERT-In retention period.
- [Ops] List every channel that collects KYC: stores, distributors, POS agents, field installers, self-KYC.
- [Legal] List all processors: billing, CRM, call centres, collections, bill printing and email, cloud, analytics, POS app vendors.
- [Marketing] List every use of usage, location or viewing data for offers, analytics, advertising or data products.
- [Legal] List every partner who receives subscriber data: content partners, lenders, insurers, advertisers, measurement bodies.
- [Security] Review how lawful requests are received, verified, logged and answered.
- [Security] Pull a year of SIM-swap and port-out fraud cases and find the channels they came through.
Phase 2: design and build (days 31–90)
- [Legal] Assign a legal basis to each purpose using the table above, and stop purposes without one.
- [Legal] Write itemised notices for stores, self-KYC, the app, the call centre, installers and set-top boxes.
- [Product] Publish notices in English and all 22 Eighth Schedule languages, with the circle’s languages as defaults.
- [Product] Build a privacy centre in the app and on the web covering bill channel, marketing, personalisation and partner sharing.
- [Eng] Make bill-channel and marketing changes reach every vendor, following the section 6(6) illustration.
- [Ops] Move all KYC capture into your app with no local storage on agent devices; use e-KYC, DigiLocker and masked Aadhaar.
- [Ops] Verify and register every POS agent, bind them to devices, and monitor activation volumes per agent.
- [Legal] Rewrite distributor and agent contracts: purpose limits, no document retention, breach notice, audit, termination for misuse.
- [Security] Strengthen SIM replacement: re-verification, alerts to the current SIM, cooling-off before activation, and insider monitoring.
- [Security] Run a single law-enforcement liaison cell with request verification, a disclosure register and minimal data per request.
- [Eng] Separate legally retained records from analytics environments; block marketing access to CDRs and IPDRs.
- [Marketing] Collect DPDP consent for profiling-based offers and partner sharing, separate from DLT consent.
- [Marketing] Check consent before every campaign and partner share; withdraw in real time.
- [Product] Ask for viewing-data consent on set-top boxes and apps; switch off ad targeting on children’s profiles.
- [Eng] Test aggregated location and usage data products for re-identification before any external use.
- [Legal] Add DPDP clauses to processor contracts: security, breach notice within hours, erasure on instruction, one-year logs, sub-processors, audit.
- [Security] Mask subscriber data in call-centre and collection tools; block exports.
- [Eng] Keep access logs for at least one year across KYC, CRM and CDR systems, with synchronised clocks.
- [Ops] Set a cooling-off and data clean-up process before recycling numbers.
- [CX] Set up the rights and grievance workflow with OTP verification, stronger checks for SIM-related requests, and SLAs.
- [Legal] Publish the privacy page: DPO contact, request channels, identifier needed, grievance period.
- [Product] Send the section 5(2) notice to existing subscribers by SMS, app and bill message.
- [DPO] Run the first DPIA on traffic and location analytics, SIM-swap controls and the agent network.
- [DPO] Start algorithmic due diligence (rule 13(3)) for fraud scoring, credit checks and recommendation systems.
- [Legal] Track which data the government may require to stay in India (rule 13(4)) and plan hosting accordingly.
Phase 3: operate (ongoing)
- [DPO] Run the DPIA and independent audit every 12 months and send significant observations to the Board (rule 13(2)).
- [Security] Review agent activation anomalies every week and suspend outliers.
- [Security] Run a SIM-swap and agent-leak breach drill every year against the 72-hour clock and faster telecom reporting duties.
- [Security] Penetration-test self-care apps, POS apps and partner APIs every year.
- [Legal] Review processor, distributor and partner contracts every quarter.
- [CX] Review rights and grievance timelines every month, separately from TRAI complaint metrics.
- [Ops] Train store staff, agents and call-centre agents every year on KYC handling and SIM-swap red flags.
- [Legal] Track new Telecommunications Act rules and TRAI regulations and update notices and processes.
- [DPO] Keep evidence: notices, consent records, lawful request register, erasure confirmations, audit reports.
- [Security] Audit a sample of lawful-request disclosures every quarter against the legal authority cited.
- [Ops] Inspect a sample of stores and distributors every quarter for retained document copies.
Where myconsentapp comes in
| You need to | With myconsentapp | You still own |
|---|---|---|
| Separate service, marketing, profiling and partner sharing | Define purposes and data items once, each tagged consent or legitimate use with sensitivity and retention days. The hosted consent page, widget or SDKs show each consent purpose as a separate toggle, off by default. | Mapping purposes to your BSS and OSS systems. |
| Capture consent in stores and from agents | A QR code to the hosted page on the agent’s device or the counter, or record consent captured elsewhere, marked as not verified by the person. | KYC itself, which stays in your licensed KYC flow. |
| Offer notices in every language | Versioned notices in English and all 22 Eighth Schedule languages, with machine-translation drafts flagged for review; rights, withdrawal and Board-complaint text and DPO contacts added automatically. | Reviewing translations. |
| Make a channel change or withdrawal reach every vendor | Signed webhooks to your systems and per-processor webhooks from the processor registry; vendors such as bill-email providers confirm the change, and acknowledgements flag anything overdue. | Wiring billing and CRM to the webhooks. |
| Check before every campaign or partner share | The verify API returns not permitted immediately after a withdrawal. | Calling it from campaign and partner pipelines. |
| Prove consent to the Board | A signed, hash-chained consent ledger with receipts, a public verifier, independent timestamp anchoring, and evidence packs. | Linking records to subscriber IDs. |
| Run retention alongside licence periods | Retention days per purpose, a retention job, and retention obligations (legal holds such as licence periods) shown in the notice. | Applying licence retention in your own systems. |
| Handle rights and grievances | A rights inbox with SLA timers; erasure closes with a structured proof; nomination and nominee claims. | Decisions on what licence conditions require you to keep. |
| Manage a breach | A breach register with the 72-hour clock, Rule 7 notices in English and Hindi, and Board intimation and report documents. | Telecom and CERT-In reporting, forensics and containment. |
| Support SDF governance | A hash-chained audit log, analytics and MIS reports, a record of processing export, and a DPIA template; team roles including DPO, with SSO and an IP allow-list; consent records hosted in India. | Running the DPIA and appointing the independent auditor. |
Not included: myconsentapp is not a KYC system, a DLT platform, a lawful-interception system or a fraud engine, and it has no out-of-the-box BSS, OSS or billing integration; integration is through the API and webhooks. It offers a DPIA template, not a DPIA workflow, and no legal advice. It is a proposed Consent Manager.
Common mistakes
- Treating DLT consent templates as DPDP consent for your own marketing and profiling.
- Letting agents keep photos of customer documents “for backup”.
- Using CDRs and cell location in marketing analytics because the data is already there.
- Selling “anonymised” location data that can be re-identified with a few data points.
- Answering a law-enforcement request that arrived by email from an unverified address.
- Changing a SIM on a phone call after weak verification.
- Recycling numbers without clearing the previous subscriber’s links and messages.
- Waiting for SDF notification before appointing a DPO and starting the DPIA.
Frequently asked questions
Does DPDP override our licence retention periods? No. Section 8(7) and section 12(3) both keep data where retention is necessary to comply with another law. Your licence and the Telecommunications Act decide how long you keep KYC, CDRs and IPDRs. DPDP decides what else you may do with them in that time, which is very little.
Is handing CDRs to an investigating agency a breach of DPDP? Not when it follows the legal procedure. Disclosure under a legal duty rests on section 7(d), and processing for the investigation of offences on section 17(1)(c). Verify every request, keep a register, and share only what is asked for.
Do we have to tell a subscriber we gave her records to the police? Not in an access reply, where the police asked in writing for the prevention, detection or investigation of offences (section 11(2)). Other laws may restrict disclosure further.
What does the telephone bill illustration mean for us? It means a preference or withdrawal given in one channel must stop processing everywhere, including at your processors (section 6(6)). If a subscriber switches to in-app bills, your email vendor must stop too.
Is DLT consent enough for our own promotional SMS? DLT and TCCCPR handle commercial-communication rules. For DPDP you still need a notice and consent for marketing and for any profiling behind the offer. Run both and link them, so a withdrawal in one updates the other.
Are we a Significant Data Fiduciary? Not until the government notifies you, but large operators fit almost every factor in section 10(1): volume, sensitivity, risk to rights and security of the State. Prepare for the DPO, the annual DPIA and audit, and algorithmic due diligence now.
Can we use network data to train AI models? Only within a ground. Aggregated network-quality data is usually fine. Individual traffic, location or viewing data used for model training needs consent or proper anonymisation, and an SDF must check that algorithmic software it uses is not likely to pose a risk to people’s rights (rule 13(3)).
This article is general information, not legal advice. Laws and rules change; check the current text or ask counsel before acting on it.