DPDP for the Marketing head (CMO) in Manufacturing

Loyalty schemes collect names, phone numbers, photos, ID and bank details to pay rewards. Joining is a choice, so this rests on consent with a clear notice. Collect only what rewards and tax rules need, keep bank details in one secure place, and make leaving the scheme easy. The loyalty vendor acts for you. Dealer KYC for appointment is a separate purpose from loyalty.

Section 5 needs a notice. Section 6 sets what valid consent is, including easy withdrawal. Section 8(1) covers the loyalty vendor. Section 5 · Rule 3 · Section 6 · Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(7) · Rule 8

1. List the fields the app and forms collect, and drop what rewards do not need.
2. Show a short notice at sign-up in the local language.
3. Keep bank details in the payout system only.
4. Add a data schedule to the loyalty vendor contract.
5. Close and delete inactive members' data on a set period.

• Field list with reasons
• Sign-up notice and consent records
• Vendor schedule
• Inactive member deletion log

• Bank details in spreadsheets sent by email
• Field staff enrolling masons without telling them
• Loyalty data reused for unrelated offers

Subsidised fertiliser is sold through PoS devices at retailers, with Aadhaar-based farmer authentication on iFMS, a government platform built by NIC for the Department of Fertilizers. The scheme decides why farmer identity is collected in that flow. Your company sees sales data from it and supplies the retailers. Treat any farmer-level data you see as personal data, use it only for supply and subsidy work, and never for marketing. For your own farmer meetings, soil testing and agronomy apps, you are the Data Fiduciary with full duties. Get a written legal view on your role.

Section 4 needs a lawful basis for each use. Section 6 needs consent for your own programmes. Section 8(1) and 8(5) apply to any data your staff, dealers or vendors handle for you. Section 4 · Section 6 · Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 5 · Rule 3

1. Write down which farmer data you see from the scheme, and which you collect yourself.
2. Limit company dashboards and exports to what supply and subsidy work needs.
3. Remind dealers and retailers not to keep Aadhaar copies or note numbers in registers.
4. Give a notice and ask consent in your own farmer apps and meetings.
5. Keep scheme data and marketing data apart in your systems.

• Written role view
• Dashboard access list
• Dealer circular
• Farmer app notice and consent records

• Using scheme purchase data to target offers
• Retailers keeping Aadhaar photocopies
• Farmer meeting registers kept for ever

Marketing needs consent that is separate and specific, unless the person clearly expects it from the relationship. Bought or scraped lead lists are risky because you cannot show consent. Every message should carry an easy way to stop.

Never use fertiliser scheme purchase data or dealer KYC for offers.

Section 6 sets the consent standard. Section 5 needs a notice. Section 9 bars targeted advertising at children. Section 6 · Section 5 · Rule 3 · Section 9 · Rules 10, 12

1. Separate service messages from marketing messages.
2. Ask marketing consent separately, with a clear action.
3. Stop using bought lists unless the seller can show consent for you.
4. Add an easy stop option to every message.
5. Respect the telecom preference rules for calls and SMS.

• Marketing consent records
• Lead source records
• Stop requests and their handling

• Treating account sign-up as marketing consent
• Agency lists with no consent proof
• A stop option that does not work

For every use of personal data you need one basis: consent, or one of the legitimate uses in Section 7, such as a legal duty, employment, a medical emergency, or data a person gave voluntarily for a specific purpose. Anything beyond what the person expects, such as marketing, profiling or sharing with partners, usually needs consent.

Attendance, wages and OSH Code medical examinations rest on employment and legal duty. Loyalty schemes, contests and connected-vehicle sharing need consent.

Section 4 allows processing only with consent or for a legitimate use. Section 6 sets what valid consent looks like. Section 7 lists the uses that need no consent. Section 4 · Section 6 · Section 7

1. List each purpose for which you use personal data.
2. Against each purpose, write the basis: consent or the exact clause of Section 7.
3. Where the basis is consent, check that it was asked separately, with a clear action and no pre-ticked box.
4. Stop or re-paper any purpose with no basis.
5. Review the list whenever a new product, campaign or system starts.

• Purpose and basis register
• Consent records with date, version and channel
• Legal sign-off on each legitimate use relied on

• Treating account terms as consent for marketing
• Bundling several purposes in one tick-box
• Relying on 'legitimate interest', which the Indian Act does not have

Withdrawal must be as easy as giving consent. Once someone withdraws, you and every vendor working for you must stop that use within a reasonable time. What was done before withdrawal stays lawful, and data that a law requires you to keep is kept.

A mason leaves the loyalty scheme in the app. Offers stop, and the vendor closes his account within the set period.

Section 6(4) to 6(6) give the right to withdraw at any time, with the same ease, and require processors to stop as well. Section 8(7) then asks for erasure unless a law requires retention. Section 6 · Section 8(7) · Rule 8 · Section 8(1)–(2)

1. Give one simple way to withdraw on every channel where consent is taken.
2. Record the withdrawal against the person and the purpose.
3. Push the change to every system and vendor that uses that purpose.
4. Confirm to the person, in writing, what has stopped and what is kept by law.
5. Check a sample every month to see that the change actually reached every list.

• Withdrawal log with time stamps
• Proof that downstream systems and vendors updated
• Confirmation sent to the person

• Withdrawal by email only, while consent was one tap in an app
• Stopping in the main system but not in vendor lists
• Deleting records a law requires you to keep

Anyone under 18 is a child under the Act. For a child's data you need verifiable consent from a parent or lawful guardian, and you must not track, behaviourally monitor or show targeted ads to children. Some classes and purposes are exempt under Rule 12 and the Fourth Schedule, for example healthcare to the extent needed to protect the child's health, and educational institutions for their educational work.

Product contests and school promotions may reach children. Parent consent and no targeted ads apply.

Section 9 sets the duties. Rule 10 explains how to verify the parent. Rule 12 and the Fourth Schedule list the exemptions. Section 9 · Rules 10, 12 · Section 6

1. Find where children's data enters: customers, dependants, interns, visitors, scholarships, app sign-ups.
2. Decide whether an exemption in the Fourth Schedule applies to that purpose.
3. Where none applies, add an age question and a parent-consent step.
4. Switch off tracking and targeted ads for under-18 users.
5. Record the decision for each channel.

• Channel-by-channel note on children's data
• Parent-consent records
• Ad and tracking settings

• Assuming 'we are B2B, so no children'
• Using the age 13 or 16 from foreign laws
• Treating a tick-box from the child as parental consent

Yes, where the use fits the purpose people were told, or you have consent for it. Improving the service people signed up for usually fits. Selling insights, profiling for third parties or targeting children does not. Mask or aggregate wherever the question allows, and give analysis copies their own deletion date.

Section 4 needs a lawful basis for each purpose. Section 6 needs specific consent. Section 9 bars behavioural monitoring of children. Section 8(3) asks for accuracy when data drives decisions. Section 4 · Section 6 · Section 9 · Rules 10, 12 · Section 8(3)

1. Write the question and the data needed.
2. Check the purpose people were told.
3. Mask or aggregate by default.
4. Get consent for uses outside the purpose.
5. Set a deletion date for the copy.

• Purpose checks
• Data specifications
• Retention entries

• Using all data because it is there
• Analysis copies with no end date
• Profiling children

A notice must tell people, in plain words, what data you collect, why, how they can withdraw consent, how they can use their rights and how they can complain to the Data Protection Board. It has to stand on its own, separate from long terms and conditions, and be shown at the point where data is collected.

Gate pass forms, contract worker enrolment, the medical centre, dealer and mason app sign-ups and warranty cards each need a short notice, in the language people use.

Section 5 and Rule 3 ask for a notice that can be understood on its own, with an itemised list of the data and the purpose for each item. Data you already hold from before the Act also needs a notice, as soon as reasonably practicable. Section 5 · Rule 3 · Section 6 · Sections 11–14 · Rule 14

1. List every point where personal data comes in: forms, apps, counters, calls, emails, partner feeds.
2. Write one short notice per collection point, with the data items and purpose side by side.
3. Add how to withdraw consent, how to make a request and the DPO or contact person's details.
4. Offer the notice in English and in the languages your workers and customers actually use.
5. Keep each version with the date it went live.

• Screenshots or copies of the notice at each collection point, with dates
• Notice version history
• Translations, where used

• Hiding the notice inside terms and conditions
• One notice for everything, with no link between data items and purposes
• Forgetting old data collected before the Act

You stay responsible for what your vendors do with personal data. The contract should say what data they get, for what purpose, the security they must keep, how fast they must tell you about an incident, that sub-contractors need your approval, and how data is returned or deleted at the end.

Manpower agencies, contractors, canteen and medical centre operators, transporters, loyalty and telematics vendors.

Section 8(1) keeps responsibility with you. Section 8(2) allows a processor only under a valid contract. Rule 6 asks for security terms in that contract. Section 8(1)–(2) · Section 8(5) · Rule 6 · Section 8(6) · Rule 7 · Section 8(7) · Rule 8

1. List vendors who receive or can see personal data.
2. Rank them by how much and how sensitive.
3. Add a data-protection schedule to each contract, starting with the top ten.
4. Ask for evidence: certificates, test results, deletion confirmations.
5. Review the top vendors every year.

• Vendor register
• Signed data-protection schedules
• Annual review notes

• Relying on the vendor's standard terms
• No incident-notice time
• No exit and deletion clause

Call recordings, chat transcripts and agent screens hold a lot of personal data. Tell callers that calls are recorded and why, keep recordings for a set period, limit who can listen, and mask card numbers and passwords on screen and in recordings.

Warranty and service lines record calls; tell callers at the start.

Section 5 needs notice, Section 8(5) needs safeguards, and Section 8(7) needs erasure after the purpose. Section 5 · Rule 3 · Section 8(5) · Rule 6 · Section 8(7) · Rule 8

1. Play a short recording notice at the start of calls.
2. Set a retention period by call type.
3. Pause recording when card or other sensitive details are given.
4. Limit replay rights to quality and complaint teams.
5. Lock agent screens and stop phones on the floor if data is sensitive.

• Recording notice script
• Retention settings
• Replay access list

• Recordings kept indefinitely
• Card numbers in recordings
• Open replay access for all supervisors