DPDP for the Sales department 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

Sending personal data to the wrong chat or a personal account is one of the most common breaches. Banning messaging rarely works. Give staff an approved tool that is easy to use, set simple rules, and make it safe to report a wrong send at once.

Supervisors and contractors share worker lists on chat groups. Give them a better route.

Section 8(5) asks for reasonable safeguards. A wrong send is a breach under Section 2(u), and Section 8(6) applies. Section 8(5) · Rule 6 · Section 8(6) · Rule 7

1. Ask teams how they actually share files and photos today.
2. Provide an approved tool for that job.
3. Set three simple rules: approved tool, no personal accounts, report wrong sends.
4. Teach the rules with real examples from your own work.
5. Treat a quick report as good behaviour, not a disciplinary case.

• Approved-tool policy
• Training record
• Incident reports of wrong sends

• A ban with no alternative
• Punishing people who report
• Ignoring group chats with vendors

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

Send a summary of the personal data you hold about them and what you do with it, and the names of the other organisations you shared it with and what was shared. Check the person's identity first, log the request and keep a copy of your reply.

A contract worker's summary should include what the agency and the medical centre hold for you.

Section 11 gives the right to a summary and the list of organisations it was shared with. Rule 14 asks you to publish how requests are made and to answer within the period you publish. Sections 11–14 · Rule 14 · Section 8(9)–(10) · Rules 9, 14

1. Log the request in one register the day it arrives.
2. Verify identity using details you already hold.
3. Search every system, including vendors' copies.
4. Write a plain summary: what data, why it is used, who received it.
5. Send it, and file the request, search notes and reply.

• Request register
• Search notes for each request
• Copy of each reply with date

• Sending raw database dumps
• Forgetting data held by vendors
• No identity check before sending