DPDP for the Finance 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

Keep data for as long as its purpose needs, or as long as a law requires, and then erase it. Every organisation must keep personal data and logs for at least one year under Rule 8(3). Write a retention schedule by record type, with the law or reason against each period.

Set periods from the Labour Codes, the chemical rules and the fertiliser order, record type by record type.

Section 8(7) asks for erasure when the purpose is over, unless a law requires retention. Rule 8(3) sets a one-year minimum for personal data, traffic data and logs. Section 8(7) · Rule 8 · Section 8(5) · Rule 6

1. List the record types you hold.
2. Write the period for each, with the law, regulator rule or business reason.
3. Set a trigger for the period to start: end of relationship, date of transaction, exit date.
4. Automate deletion where you can; for paper, schedule shredding.
5. Keep a deletion log.

• Retention schedule approved by Legal
• Deletion log
• Shredding or disposal certificates

• 'Keep everything forever' because storage is cheap
• Deleting before the legal minimum
• Forgetting email, shared drives and backups

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

Only people who need it for their job, and only the part they need. Use named accounts, give access by role, review it every quarter and remove it on the day someone leaves. Watch privileged accounts closely.

Medical records and biometric data need named access. Supervisors get fitness notes, not results.

Rule 6 names access control as a minimum safeguard, along with logs and monitoring that can detect misuse. Section 8(5) · Rule 6

1. Write a role matrix for each key system.
2. Replace shared logins with named accounts.
3. Use multi-factor sign-in for admin and remote access.
4. Review access every quarter with each manager.
5. Remove access on the last working day.

• Role matrix
• Quarterly review sign-offs
• Leaver removal report

• Generic logins on shared machines
• Access that only grows
• No review of vendor accounts

Usually not for normal employment purposes. Section 7(i) lets you process employee data for employment, such as payroll, attendance, safety and preventing corporate espionage. Anything beyond that, such as wellness apps, photos for marketing or sharing with a bank for offers, needs consent.

OSH Code medical examinations and registers are employment and legal duties; explain them in the worker notice.

Section 7(i) covers employment purposes and safeguarding the employer from loss or liability. Notice, security, retention and rights still apply to employees. Section 7 · Section 5 · Rule 3 · Section 8(7) · Rule 8 · Sections 11–14 · Rule 14

1. List what you collect from staff and why.
2. Mark which items are employment purposes and which are extra.
3. Take consent for the extras, separately.
4. Give staff a short employee privacy notice.
5. Set retention for ex-employee records.

• Employee data list with basis
• Employee privacy notice
• Consent for extras

• A blanket consent clause in the offer letter
• Keeping candidate data forever
• Sharing staff data with vendors without terms

Contain it, then tell people. A reportable cyber incident goes to CERT-In within six hours of being noticed. Under DPDP, each affected person and the Data Protection Board must be told without delay, and the Board needs a detailed report within 72 hours. Sector regulators may have their own clock too.

A stolen gate server or a lost medical register is a breach. CERT-In's six hours and the DPDP steps may both apply.

Section 8(6) and Rule 7 set the DPDP steps. The CERT-In Directions of 28 April 2022 set the six-hour report. A breach includes accidental disclosure and loss of access, not only hacking. Section 8(6) · Rule 7 · Section 8(5) · Rule 6

1. Name one incident lead and a back-up, with phone numbers that work at night.
2. Write the first-hour steps: isolate, preserve logs, tell the DPO and the incident lead.
3. Keep ready-made drafts for CERT-In, the regulator, the Board and affected people.
4. Decide in advance who signs off each message.
5. Rehearse once a year with the people who would actually be called.

• Incident plan with clocks
• Rehearsal record
• Incident log with times of each step

• Waiting to finish the investigation before telling anyone
• Treating a wrong email or a lost laptop as 'not a breach'
• Only IT knowing the plan

Under DPDP, yes, unless the government restricts a country, and none had been restricted when this page was last reviewed. A sector rule can be stricter, for example RBI's rule that payment system data must be stored only in India. Remote support access from abroad also counts as data going outside India.

Buyers' social audits, parent company HR systems and telematics platforms may hold data abroad.

Section 16 allows transfers unless restricted, and keeps stricter sector laws in force. Rule 15 adds conditions on making data available to foreign states. Section 16 · Rule 15 · Section 8(1)–(2)

1. List where each system is hosted and where support teams log in from.
2. Check sector rules for localisation.
3. Put location and access terms in cloud and vendor contracts.
4. Keep the list current; new SaaS tools change it quietly.
5. Tell people in your notice if data goes abroad.

• Hosting and access-location list
• Contract clauses
• Sector rule check

• Forgetting email, CRM and helpdesk SaaS
• Ignoring overseas support logins
• Assuming 'Indian vendor' means 'data in India'