DPDP for social media, community and content platforms

Social and content platforms hold the most personal data of any sector: what people say, whom they know, what they watch and for how long, where they are, whom they message, and in the case of dating apps, whom they want to meet. Much of it is not typed in by the user but inferred: interests, affinities, likely age, likely politics. Recommendation and ads systems turn those signals into decisions about what each person sees.

The risk sits in four places. Children, who under DPDP means everyone under 18, are on every platform and need verifiable parental consent and protection from tracking and targeted ads. Inference creates sensitive data nobody gave you. Public data is often treated as fair game when the Act’s exclusion is narrower than it looks. And scale: large platforms are likely to be notified as Significant Data Fiduciaries, with yearly audits and due diligence on their algorithms. This guide applies the Data Fiduciary playbook to social and content platforms.

Are you a Data Fiduciary, a processor, or both?

• Platform operator: you are the Data Fiduciary for your users: accounts, profiles, content, messages, social graph, activity, inferences and ads data. You decide why and how all of it is processed. Your cloud host, content-moderation BPO, trust and safety tools, identity-verification vendor, CDN, analytics and messaging vendors are your Data Processors.
• Data about people in users’ posts: a user posting photos of friends is usually processing for personal purposes, which section 3(c)(i) takes outside the Act. Your own processing of that content, such as hosting, ranking, face grouping or ads targeting, is different. You decide how it is done, so treat yourself as a fiduciary for it. Confirm the position with counsel.
• Advertisers and brand partners: an advertiser who uploads its customer list for targeting is a fiduciary for that list and is disclosing it to you. Where you use the list only to serve that advertiser’s campaign, you may be its processor. Where you also use it to improve your own models, you are a fiduciary for that use. Write it down in the ads terms.
• Creators and community admins: a creator who collects fans’ emails, runs paid communities or sells merchandise is a Data Fiduciary for that data. Give creators aggregated audience insights rather than lists of identifiable followers, or you turn every creator into a fiduciary for your users’ data.
• Dating and matrimony apps: you are a fiduciary for profiles, photos, preferences, location, chats and verification selfies. Background-check and verification vendors are processors. Family members who create matrimony profiles on someone’s behalf raise a separate question: you need the person’s own consent, not only the relative’s.
• Third-party developers and API partners: anyone who receives user data through your API for their own app is a separate fiduciary. Your API terms should limit what they may do, and you should be able to tell users who received their data (section 11(1)(b)).

The data you hold

Data category	Where it usually lives	Typical purpose	Sensitivity	Typical retention
Account: name, handle, mobile, email, password, date of birth	Identity service	Account, login, age checks	Medium	While active, then the inactivity rule
Profile: photos, bio, location, school, work, relationship status	Profile service, media store	Display, discovery	Medium to high	While the user keeps them
Posts, comments, stories, videos, live streams	Content store, CDN	Publishing, sharing	Medium to high (can reveal religion, health, sexuality, politics)	Until the user deletes; legal holds for reported content
Private messages and group chats	Messaging service	Communication	High	Short where possible; follow your published policy
Social graph: followers, friends, groups, contact uploads	Graph service	Connections, suggestions	Medium to high (non-users’ numbers)	Delete uploaded contacts of non-users
Activity: views, watch time, likes, searches, dwell time	Event pipeline, warehouse	Ranking, analytics	Medium to high in aggregate	Aggregate quickly; raw events briefly
Inferred interests and segments	Recommendation and ads systems	Feed ranking, ads	High where sensitive	Recompute often; erase on withdrawal
Precise location and check-ins	Location service	Nearby features, dating, safety	High	Short; never keep history unless the user asks
Dating preferences, orientation, verification selfies	Dating profile service, verification vendor	Matching, safety	High	Delete verification images after the check
Ads data: impressions, clicks, advertiser audiences	Ads platform	Delivery, billing, measurement	Medium to high	Set short limits
Reports, moderation decisions, appeals	Trust and safety tools, BPO	Moderation, legal compliance	High	As long as appeals and legal holds need
Creator payouts: PAN, bank, GST details	Payments, finance	Monetisation	High	As tax law requires
Device IDs, IP, cookies, SDK data	Apps, web, analytics	Security, analytics, ads	Medium to high	Logs for at least one year
Children’s accounts and parental consent records	Identity service, age-assurance vendor	Section 9 compliance	High	As long as the account, plus evidence

Risk hotspots

1. Under-18s with adult settings. Many platforms allow sign-up from 13, following foreign laws. Under DPDP a child is anyone under 18. Failure: processing children’s data without verifiable parental consent (section 9(1)); tracking, behavioural monitoring or targeted ads directed at them (section 9(3)); features likely to harm their well-being (section 9(2)). Penalties for section 9 breaches can reach ₹200 crore. Control: an age gate, parental consent under rule 10, and teen accounts with non-behavioural feeds, no targeted ads, private-by-default profiles and no messages from strangers.
2. Recommendation feeds built on behaviour. Ranking by watch time and engagement is behavioural monitoring by another name. Failure: feeds for children based on tracking; sensitive inferences used for adults without a clear basis; feeds that amplify self-harm or eating-disorder content to vulnerable users. Control: a signal register, a non-personalised option, no sensitive inferences without consent, and safety rules in the ranking for teens. For SDFs, this is the core of rule 13(3) due diligence.
3. “It is public, so we can use it.” Section 3(c)(ii) takes out of the Act personal data made publicly available by the person it relates to, or by someone under a legal duty to publish it. Failure: treating everything visible on the platform as public, including what others posted about a person, private-group content, content later deleted or made private, and inferences drawn from public posts. Control: a written rule for what counts as public, a check that the person made it public themselves, and fresh consent or another basis for anything else.
4. Scraping and AI training. Third parties scrape profiles; platforms train models on user content. Failure: scraped data used for fraud or harassment; training on private content or children’s content without a basis. Control: rate limits and anti-scraping as part of your security safeguards (section 8(5)), and a documented basis per training dataset, with withdrawals honoured in future training runs.
5. Contact uploads and shadow profiles. Syncing contacts gives you the numbers of people who never joined. Failure: building profiles of non-users with no notice and no way for them to object. Control: match contacts without storing non-users’ numbers, hash and expire uploaded data, and never use it for ads.
6. Content moderation at scale. Moderators, often in a BPO, see private messages, intimate images and children’s data. Failure: moderators copying content, wide access to reported material, moderation records kept forever. Control: least-privilege queues, blurred previews, no downloads, access logs reviewed, BPO contracts that meet section 8(2), and defined retention for moderation records.
7. Intimate images, deepfakes and doxxing. Non-consensual intimate images and doxxing are among the worst harms on social platforms. Control: fast takedown routes, hash-matching to prevent re-upload, and an escalation path to the authorities under the IT Rules and criminal law.
8. Dating apps and location. Precise location, orientation and photos can put users at physical risk. Control: approximate distances only, no location history, verification selfies deleted after the check, and screenshot and sharing protections where the platform supports them.
9. Ads targeting with sensitive segments. Advertisers can reach people by inferred religion, health or orientation unless you stop them. Control: remove sensitive segments from ads tools, require consent for personalised ads, block all targeted ads to under-18s, and refresh advertiser audiences so withdrawals take effect.
10. Account deletion that leaves data behind. Messages in other people’s inboxes, reshared posts, backups and ML features survive deletion. Control: define what deletion removes, explain what remains (for example, a message already delivered), and run erasure across feature stores and training datasets.

Legal basis, purpose by purpose

Purpose	Basis	Notes
Creating an account and providing the service	7(a): the user voluntarily signed up for the service, or consent at sign-up	Keep sign-up fields minimal; for a child, verifiable parental consent comes first.
Age assurance (confirming the user is not a child)	Fourth Schedule Part B, item 6 lifts sections 9(1) and 9(3) for this	Process only what the check needs.
Hosting and showing the user’s posts to the audience they chose	7(a)	Respect privacy settings strictly.
Private messaging	7(a)	Limit access by staff to what safety and law require.
Ranking feeds on on-platform activity	7(a) where the notice describes it as part of the service, otherwise consent	Offer a non-personalised option. Not for children if it tracks behaviour.
Sensitive inferences (religion, health, sexuality, politics)	Consent, or do not infer	Treat as the highest-risk processing.
Personalised ads using activity and inferences	Consent	Never for children (section 9(3)).
Advertiser customer-list matching	The advertiser’s consent from its customers; your role set in the ads terms	Do not reuse uploaded lists for your own purposes.
Contact sync and friend suggestions	Consent	Do not keep non-users’ numbers.
Content moderation and enforcing community rules	7(a) under your published terms; section 17(1)(c) for content that may be an offence	Filtering harmful content for children is covered by Fourth Schedule Part B, item 5.
Responding to lawful orders and law-enforcement requests	7(d) or 7(e), and section 17(1)(c)	Section 11(2) and rule 23(2) can limit what you tell the user.
Using publicly available data	Outside the Act under section 3(c)(ii), only where the person made it public	Document why each source qualifies.
Training AI models on user content	Consent, or 7(a) where it is strictly needed for the service the user asked for	Exclude children’s content and private content.
Creator payouts and tax	7(a) for the payout; retention required by law for tax records	Use masked Aadhaar or DigiLocker where identity proof is needed.

Notices and consent: getting the screens right

Channel	Do	Don’t
App sign-up	Show a short notice itemising account, content, activity and inference data, and who receives it. Ask date of birth neutrally. Put ads personalisation, contact sync and sensitive-interest features as separate unticked toggles.	Hide personalised ads and contact sync inside the Terms.
Age gate and parental consent	Route under-18s to verifiable parental consent (rule 10), using reliable age details you hold or DigiLocker. Explain the teen account settings to the parent.	Let a child tick “My parent agrees”.
Web	Load non-essential trackers and pixels only after consent; keep a tracker register.	Fire ad pixels before the user has chosen.
In-app permission prompts	Ask for contacts, location, camera and microphone only when the feature is used, explaining why.	Ask for contacts and location at launch.
Feed settings	Show why a post is recommended and offer a non-personalised feed.	Make the personalised feed impossible to turn off.
Dating profile set-up	Explain who sees each field, especially orientation, location and photos. Keep sensitive fields optional.	Make orientation or religion mandatory.
Creator and advertiser portals	Tell creators and advertisers what audience data they get and their own duties as fiduciaries.	Give creators exportable lists of followers’ contact details.
Support and grievance forms	Name the DPDP contact and the IT Rules grievance officer; say which handles what.	Route privacy requests into a general complaints queue with no deadline.
Existing users	Send a section 5(2) notice in the app with links to manage choices, and a parental-consent flow for existing under-18 accounts.	Assume old blanket consent covers new purposes.

Each notice must stand on its own, itemise the data and the purposes, describe the service, and link to withdrawal, rights and complaints to the Board (rule 3). Withdrawal must be as easy as giving consent, which on a platform means a setting one or two taps deep, not a support ticket. Offer the notice in English and the Eighth Schedule languages (section 5(3)). Large platforms should offer all 22 from the start; users in India post in all of them.

Other laws you must line up with

• IT Act, 2000 and the IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021, as amended: due diligence, published rules, a grievance officer, takedown on orders, and for significant social media intermediaries (50 lakh or more registered users) a Chief Compliance Officer, a nodal contact person and a resident grievance officer in India, monthly compliance reports and, for messaging services, identification of the first originator on order. The IT Rules grievance timelines are shorter than DPDP’s ceiling. Run both processes side by side. Confirm the current requirement with counsel.
• Grievance Appellate Committees under the IT Rules: users can appeal content decisions there; DPDP complaints go to the Data Protection Board. Keep the two routes distinct in your notices.
• Rules and advisories on synthetic and AI-generated content: labelling and takedown duties for deepfakes and synthetic media have been changing. Confirm the current requirement with counsel.
• CERT-In Directions (2022): reporting cyber incidents on a much shorter clock than the DPDP 72 hours, and log retention. Confirm the current requirement with counsel.
• Bharatiya Nyaya Sanhita, 2023 and Bharatiya Nagarik Suraksha Sanhita, 2023: offences such as defamation, obscenity and stalking, and the procedure for law-enforcement requests and data production.
• POCSO Act, 2012: mandatory reporting of child sexual abuse material and offences against children that you become aware of.
• Indecent Representation of Women (Prohibition) Act and IT Act section 66E and 67 offences: relevant to intimate images and takedowns.
• Consumer Protection Act, 2019 and the dark-patterns guidelines: nagging, confirm-shaming and hard-to-cancel subscriptions breach consumer law and section 6.
• Election law and Election Commission advisories: political advertising and content around elections. Risk to electoral democracy is one of the factors for SDF notification (section 10(1)(d)).
• Income-tax and GST law: creator payouts, tax deductions and invoices.
• Telecommunications Act, 2023: may affect messaging and calling features. Confirm the current requirement with counsel.

Retention and erasure

1. When the purpose ends (section 8(7)): the user deletes a post, closes the account or withdraws consent for a feature. Stop using the data and erase it, unless a law requires you to keep it. Explain in the notice what deletion cannot reach, such as a message already delivered to someone else.
2. The one-year minimum (rule 8(3)): keep the personal data, traffic data and logs of each processing activity for at least one year from the date of processing, for the purposes in the Seventh Schedule. This sits alongside the IT Rules’ own retention duties for removed content and user registration data. After that, erase unless another law requires longer.
3. Legal holds: content removed on an order, data preserved for an investigation, child-safety reports and creator tax records each have their own retention. Record each hold with the law or order behind it, the data it covers and the end date. Keep held data out of ranking and ads systems.
4. The Third Schedule three-year rule: if you are a social media intermediary (as defined in rule 2(1)(w) of the IT Rules, 2021) with 2 crore or more registered users in India, you must erase a user’s personal data three years after the user last approached you for the purpose or exercised a right, or from the Rules’ commencement if that is later (rule 8(1)). “User” here covers anyone who uses your platform to host, publish, share, view, display, download or upload information, so passive viewers count. At least 48 hours before erasure, tell the user it will happen unless they log in or get in touch (rule 8(2)). Data needed to access the account, and virtual tokens issued by you that can be used to get money, goods or services (such as tipping credits or coins), are excluded.
5. Inferences and models: erase inferred segments and feature-store records with the account. Document how withdrawals and erasure are reflected in future model training.
6. Processors: make your moderation BPO, verification vendor, analytics and messaging tools erase too, and get confirmation.
7. Backups: document how long backups keep data and make sure a restore replays erasures.

Rights requests and grievances

• Channels: an in-app privacy centre, a web form, and an email address. Publish them with the identifier you need, such as the handle, registered mobile or email (rule 14(1)).
• Identity: use an OTP to the registered contact or an in-app confirmation from a logged-in session. Do not ask for ID documents you do not already hold. For a child’s account, the request comes from the verified parent.
• Access (section 11): give a summary of the account, content, messages, activity, inferred interests and ad segments, and devices. List the other fiduciaries and processors you shared data with, including API partners and advertisers who matched the user. Disclosures to law enforcement on a written request for preventing or investigating offences need not be listed (section 11(2)), and the Government can bar you from telling the user about some information requests (rule 23(2)).
• Correction (section 12(2)): correct profile data and dates of birth. A date-of-birth change across 18 should trigger the age process again.
• Erasure (section 12(3)): erase the account, content, messages held only for this user, graph, inferences and ad segments. Refuse only what you must keep: content and data under a legal order or hold, child-safety reports, tax records for creators, and the one-year logs. Tell the person what you kept and why.
• Grievances: acknowledge quickly. Publish a response period well inside the 90-day ceiling in rule 14(3); 15–30 days is good practice, and the IT Rules timelines will often be shorter. Name the DPO or contact person in every reply (rule 9).
• Nomination (section 14): let users nominate someone to act after death or incapacity. Link this to your memorialisation or legacy-contact feature.

Breach readiness

Likely scenarios:

• an API bug that exposes private profile fields or messages
• scraping at scale that exploits a weak rate limit or a search feature
• a moderation BPO agent leaking reported intimate images
• account takeover of high-profile users or creators
• a misconfigured analytics or ads bucket with activity data
• a third-party app that misuses data obtained through your API

Run-book:

1. Contain within hours: close the API endpoint, revoke tokens, block the scraper, suspend the vendor’s access.
2. Assess: which data, how many users, how many children, and the consequences (harassment, extortion, outing, physical risk from location data).
3. Notify affected users without delay in the app or through their registered contact, covering every point in rule 7(1): what happened and when, the likely consequences for them, what you are doing, what they can do (review privacy settings, change passwords, watch for impersonation), and a contact. For a child, notify the parent.
4. Notify the Board without delay, then send the detailed report within 72 hours (rule 7(2)): updated facts, the circumstances and reasons, mitigation, findings about who caused it, steps to prevent a repeat, and a report on the notices sent to users.
5. Report to CERT-In where its directions apply, and to other authorities where content involves offences against children.
6. Learn: fix the root cause, tighten API terms or vendor access, and record what changed.

The checklist

Phase 1: discover (days 0–30)

• [Leadership] Appoint a DPDP owner and a working group (product, ranking and ads, trust and safety, engineering, legal, security, creator and advertiser teams).
• [DPO] Count registered users in India, including passive viewers, against the Third Schedule threshold (2 crore or more) and the IT Rules SSMI threshold.
• [Product] Map every collection point: sign-up, profile, posts, messages, contact sync, location, ads, creator tools, API, support.
• [Eng] Inventory every store: identity, content, messages, graph, event pipeline, warehouse, feature store, model training sets, backups.
• [Eng] List every signal used by ranking and ads, and flag sensitive inferences.
• [Product] Estimate the share of users under 18, using declared ages, age signals and support data.
• [Legal] List the sources you treat as publicly available and test each against section 3(c)(ii).
• [Trust and safety] Map moderation queues, who sees what, and where moderation data is stored and for how long.
• [Legal] List API partners, advertisers’ data uploads and data sharing with any third party.
• [Legal] Collect processor contracts (moderation BPO, verification, cloud, analytics, messaging).
• [Legal] Match your IT Rules grievance officer and compliance roles to the DPDP contact and DPO roles.

Phase 2: design and build (days 31–90)

• [Legal] Assign a legal basis to each purpose (use the table above) and stop purposes without one.
• [Legal] Write itemised notices for sign-up, teens and parents, messaging, ads, contact sync, creator tools and dating features.
• [Product] Publish the notices in English and all 22 Eighth Schedule languages, starting with your top user languages.
• [Product] Build a neutral age gate and route under-18s to verifiable parental consent under rule 10.
• [Product] Build teen accounts: private by default, non-behavioural feed, no targeted ads, no messages from unknown adults.
• [Eng] Add a non-personalised feed option for all users.
• [Eng] Remove sensitive inferences from ads targeting, and stop inferring them without consent.
• [Eng] Pass an age flag to the ads system so no targeted ad is served to a child.
• [Eng] Stop storing non-users’ numbers from contact uploads; hash and expire matching data.
• [Eng] Tighten rate limits, search and API scopes to reduce scraping.
• [Trust and safety] Move moderators to least-privilege queues with blurred previews, no downloads and logged access.
• [Trust and safety] Set retention for moderation records, appeals and child-safety reports.
• [Product] For dating features, show approximate distance only and delete verification selfies after the check.
• [Legal] Update creator and advertiser terms: their duties as fiduciaries, no export of follower contact data, audience refresh for withdrawals.
• [Legal] Update API terms: permitted uses, deletion on revocation, breach notice to you.
• [Legal] Add DPDP clauses to processor contracts: security, breach notice to you, erasure on instruction, one-year logs, sub-processors, audit.
• [Eng] Check consent before every personalised ad, audience match and marketing message; feed withdrawals to ranking, ads and CRM in real time.
• [Eng] Run erasure across content, messages, graph, feature stores and training datasets.
• [Eng] If you are in the Third Schedule, build the three-year inactivity erasure with the 48-hour warning, excluding account access and virtual tokens such as coins and credits.
• [Eng] Keep access and processing logs for at least one year.
• [Security] Add MFA and time-limited, approved access for internal tools that can read user content.
• [Product] Publish the privacy centre: contact person, request channels, identifier needed, grievance timeline, and the IT Rules grievance officer separately.
• [CX] Set up the rights and grievance workflow with in-app verification, owners and deadlines, including parent requests.
• [Product] Send the section 5(2) notice to existing users, and the parental-consent flow to existing under-18 accounts.

Phase 3: operate (ongoing)

• [DPO] Review new features, ranking changes, ads products and partnerships before launch.
• [DPO] If notified as an SDF, run the DPIA and the audit every 12 months and send the Board a report of significant observations (rule 13(1) and 13(2)).
• [Eng] Carry out algorithmic due diligence on ranking, recommendation, ads, moderation and face or image tools, checking they are not likely to pose a risk to users’ rights (rule 13(3)).
• [Legal] Track any notification of data that must stay in India (rule 13(4)) and any country restrictions under section 16(1).
• [Trust and safety] Review teen safety metrics and child-safety reports every month.
• [Security] Review moderator and internal-tool access logs every month.
• [Security] Run a penetration test every year on apps, APIs and internal tools, including scraping tests.
• [Security] Run a breach tabletop drill every year (for example, an API leak of private fields) against the 72-hour clock.
• [CX] Review rights and grievance timelines every month against both DPDP and IT Rules deadlines.
• [Legal] Track changes to the IT Rules and advisories on synthetic content, and update flows.
• [DPO] Keep evidence: consent and parental-consent records, withdrawal handling, erasure confirmations, audit reports, training records.

Where myconsentapp comes in

You need to	With myconsentapp	You still own
Ask consent per purpose	Define purposes (account, personalised feed, personalised ads, contact sync, sensitive-interest features, AI training) once, each tagged consent or legitimate use. The SDKs or widget show each optional purpose as a separate toggle, off by default.	Designing the in-app settings around it.
Handle teens and parents	An age gate and guardian verification through DigiLocker; tracking and ad purposes can never be marked child-safe. A family view lets the parent see what they agreed to.	Building teen account settings in your product.
Check consent before ads and matching	Call the verify API before serving a personalised ad, matching an advertiser list or using data for training; it returns not permitted immediately after a withdrawal.	Wiring it into ranking and ads systems at your scale.
Spread withdrawals	Signed webhooks with retries tell your systems the moment a user withdraws; acknowledgement deadlines flag anything not handled.	Updating feature stores and models.
Prove consent	Every choice is signed and hash-chained against the exact notice version, with a receipt and a public verifier. Evidence packs per user support Board inquiries.
Offer notices in every language	Notices in English and the 22 Eighth Schedule languages, with machine-translation drafts marked for review.	Reviewing the translations.
Make vendors stop too	A processor registry links moderation, verification and analytics vendors to purposes; they confirm withdrawals and erasures, and contract expiry dates are flagged.	Signing contracts and policing API partners.
Handle rights requests	A rights inbox with SLA timers; the user sees status in their app; erasure closes with a structured proof.	The answers and your IT Rules grievance handling.
Plan for death and incapacity	Nomination and nominee claims.	Your memorialisation policy.
Manage a breach	A breach register with the 72-hour clock, Rule 7 notices to affected users, and Board intimation and report documents.	Detecting and investigating.
Report to leadership	Analytics and MIS reports on consent, withdrawals and rights requests, and an exportable record of processing.	Your SDF audit and DPIA (only a template is included).

Not included: myconsentapp is a proposed Consent Manager. It does not do content moderation, age estimation, tag or SDK scanning, or data discovery in your stores, and it has no DPIA or algorithmic audit workflow (only a DPIA template). It is not legal advice.

Common mistakes

• Treating 13 as the age of digital consent because a foreign law does; under DPDP it is 18.
• Assuming anything visible on the platform is “public” and outside the Act.
• Running personalised feeds and ads for teen accounts.
• Letting advertisers target by inferred religion, health or orientation.
• Keeping contact uploads of people who never joined.
• Giving moderators unrestricted access to private messages and intimate images.
• Merging the IT Rules grievance officer and the DPDP contact into one inbox with no separate deadlines.
• Deleting the account but leaving segments in the ads system and features in model training data.

Frequently asked questions

If a user makes a post public, is it outside the Act? Only the data that the user made public about themselves, under section 3(c)(ii). Data others posted about them, private-group content and inferences you draw are not covered by that exclusion. Your processing of the account, activity and messages is fully in scope. When a user deletes a post or makes it private, the safest course is to stop treating it as public.

Do we need parental consent for every user under 18? Yes, unless an exemption applies. Section 9(1) requires verifiable parental consent before processing a child’s data, and rule 10 sets how to check that the parent is an identifiable adult. The Government can notify an age above which a platform that processes children’s data in a verifiably safe way is exempt (section 9(5)), but no such notification can be assumed.

Is a personalised feed “behavioural monitoring” of children? A feed that ranks content by tracking a child’s viewing and engagement is very likely to be treated as tracking or behavioural monitoring, which section 9(3) prohibits. Use non-behavioural ranking, such as following, recency and editorial curation, for under-18s, and apply safety filters (Fourth Schedule Part B, item 5).

What does rule 13(3) mean for our algorithms? An SDF must check with due diligence that the technical measures, including algorithmic software, it uses for hosting, display, publishing, sharing and storing personal data are not likely to pose a risk to users’ rights. In practice that means documented testing of ranking, recommendation, ads and moderation systems, with results feeding the yearly DPIA and audit.

Who is responsible for data in an advertiser’s custom audience? The advertiser is the fiduciary for its customer list and needs its customers’ consent to share it. Your ads terms should say whether you act as its processor for matching, and forbid reuse of the list for your own models unless you have your own basis.

How do the IT Rules and DPDP grievance processes fit together? They are separate duties with separate contacts and deadlines. IT Rules complaints cover content and platform conduct; DPDP grievances cover the handling of personal data and rights. A shared intake form is fine if each case is routed to the right owner and clock.

Does the three-year rule count users who only watch? For a social media intermediary, the Third Schedule defines “user” to include anyone who uses your platform to view or display information, not only those who post. Count all registered users in India when checking the 2 crore threshold.