India privacy policy checklist

Inventory collection at every doorway

Walk through the website, application, sales process, support desk, events, recruitment, vendor onboarding, payments, security logs, and offline forms. Record each personal-data field, where it comes from, whether it is required, the person it concerns, and the purpose. Include data collected automatically through logs, analytics, cookies, device identifiers, integrations, and fraud controls. Note information inferred or created by the business. Separate customer-user data processed for a business customer from data used for the provider's own account and security. The policy needs a clear scope, so identify which sites, products, companies, countries, and people it covers. If a field has no owner or current purpose, remove or pause it rather than finding vague words to justify it. The data map should match live forms and settings. Screenshots and a versioned inventory make later review much easier.

• Forms, product, logs, and offline collection
• Required and optional fields
• Direct, automatic, and inferred data
• Customer-instructed versus own processing
• Product and entity scope

State purpose and choice where it occurs

People should receive useful information near the collection point, not be sent to a long policy for every decision. Map each purpose to the notice, consent, contractual need, legal duty, security reason, or other current basis relied on. The DPDP framework uses defined concepts and has rules on notice and consent that require current legal review. Avoid bundling marketing with service access where a separate choice is needed. Explain how consent may be withdrawn and what changes when it is. Children's data and data of persons with lawful guardians can require special handling, so do not infer age safeguards from a general statement. Product settings, unsubscribe routes, account closure, cookie controls, and sales practice should match the published text. Keep records of wording and choices by version. A policy cannot make an unclear interface fair merely by describing it after the fact.

• Purpose mapped to each data field
• Layered notice at collection
• Consent and withdrawal operation
• Marketing and service choices separated
• Current child-data review

Name sharing, location, and retention honestly

List the real recipients and recipient categories: hosting, analytics, payments, communications, support, security, professional advisers, group companies, customers, authorities, and transaction counterparties where applicable. Identify the countries and remote-access locations involved rather than using a global phrase without an internal record. Vendor contracts and data processing agreements should support what the policy says. Explain sale, merger, financing, or reorganisation disclosures carefully without implying unrestricted use. For retention, connect each data set to an event, period, legal need, dispute need, security purpose, or customer instruction. Do not promise immediate deletion where backups or required records remain. State the treatment accurately and narrow access. The final DPDP Rules and any sector directions may affect notice, retention, transfer, and processor work. Recheck the current position with qualified professionals before publication.

Keep evidence for each statement.

• Actual recipient categories
• Countries and remote access
• Vendor terms supporting disclosures
• Event-based retention schedule
• Accurate backup and deletion language

Make rights and contact routes work

The policy should provide a monitored contact and explain the current routes for access to information about processing, correction, completion, erasure, consent withdrawal, grievances, and nomination or other rights where applicable. The response team needs identity checks, intake records, search owners, decision rules, deadlines, escalation, and a way to preserve data needed for a dispute or legal duty. Do a test request before publishing the promise. Security language should describe the approach without giving attackers a blueprint or claiming perfect protection. Add a breach communication process outside the policy. State how material policy changes are communicated and keep prior versions with effective dates. Do not refresh a reviewed date without checking the systems, vendors, forms, and current rules. A privacy policy remains credible when customer support, product settings, and back-office records can carry out the rights it describes.

• Monitored privacy and grievance contact
• Identity and request workflow
• Test of search and response capability
• Measured security description
• Version and change-notice record