Business contacts are personal data, so prospect lists need a lawful source and an easy way to stop messages. Sales teams also promise clients incident notice times and deletion terms; these must be ones delivery can meet. Calls and SMS to Indian numbers need TRAI compliance.
The first four things to sort out
Use only prospect lists with a known source.
Honour stop requests across email and calls within a day.
Check data terms with legal before promising them in a proposal.
Keep client contact data in the CRM, not personal sheets.
A worked example
Sales department
A prospect asks to stop all contact
Day 1A prospect replies asking to be removed.
Day 1Sales marks the contact in the CRM.
Day 1The email and call lists are updated.
AfterOld sheets outside the CRM are deleted.
Evidence kept
CRM record
Stop log
Stop should reach every list in a day.
What others in the sector usually do. Many sales teams now attach a standard data-handling note to proposals, prepared with legal and the CISO.
Where it usually goes wrong, by organisation type
Organisation type
Hotspots
IT services and consulting
Production data copied to laptops or test environments; Shared client credentials in team chats; Sub-contractors working under your client access
BPO and contact centre
Card numbers spoken on recorded calls; Phones and paper on the floor; Outbound calls without consent checks for Indian customers
Global capability centre
Indian customer data mixed into global data sets; Global HR systems hosted abroad; Intra-group agreements that predate DPDP
SaaS and software products
Support staff browsing customer tenants; Analytics on customer data beyond the contract; Deletion that does not reach backups
Managed services, data centres and cloud
Privileged admin access across many clients; Subscriber records kept with no access limits; Backups of client systems held for years
6 questions the Sales department asks, answered in full
Short answer: Only with separate consent and an easy way to stop
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.
From your seat: Sales department. Use only leads with a consent source.
Example in IT and ITeS
B2B prospect lists still need a lawful source and an easy unsubscribe.
Short answer: It depends on the use; most organisations need both
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.
From your seat: Sales department. Do not treat a business card as consent for campaigns.
Example in IT and ITeS
Payroll and background checks are employment purposes. Newsletters to prospects need consent.
What the law says
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
Steps
List each purpose for which you use personal data.
Against each purpose, write the basis: consent or the exact clause of Section 7.
Where the basis is consent, check that it was asked separately, with a clear action and no pre-ticked box.
Stop or re-paper any purpose with no basis.
Review the list whenever a new product, campaign or system starts.
Evidence to keep
Purpose and basis register
Consent records with date, version and channel
Legal sign-off on each legitimate use relied on
Common mistakes
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
Short answer: Stop that use quickly, across every system and vendor
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.
From your seat: Sales department. Stop requests take effect the same day.
What the law says
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)
Steps
Give one simple way to withdraw on every channel where consent is taken.
Record the withdrawal against the person and the purpose.
Push the change to every system and vendor that uses that purpose.
Confirm to the person, in writing, what has stopped and what is kept by law.
Check a sample every month to see that the change actually reached every list.
Evidence to keep
Withdrawal log with time stamps
Proof that downstream systems and vendors updated
Confirmation sent to the person
Common mistakes
Withdrawal by email only, while consent was one tap in an app
Stopping in the main system but not in vendor lists
Short answer: Yes, this is a common breach; give staff a safer option
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.
From your seat: Sales department. No customer lists on personal chat.
Example in IT and ITeS
Client credentials and customer screenshots in team chats are a common issue.
Short answer: Yes, with notice, a retention period and masking
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.
From your seat: Sales department. Follow TRAI rules for calls and SMS.
Example in IT and ITeS
BPO call recordings must pause for card details and follow client retention rules.
Short answer: Yes, a clear summary, inside the published timeline
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.
From your seat: Sales department. Pass data requests to the DPO's register.
Example in IT and ITeS
Requests about client data go to the client. Requests from staff and candidates come to you.
What the law says
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
Steps
Log the request in one register the day it arrives.
Verify identity using details you already hold.
Search every system, including vendors' copies.
Write a plain summary: what data, why it is used, who received it.
Send it, and file the request, search notes and reply.
Evidence to keep
Request register
Search notes for each request
Copy of each reply with date
Common mistakes
Sending raw database dumps
Forgetting data held by vendors
No identity check before sending
The sections you will use most
Section 5 · Rule 3: Notice. Candidate portals, employee onboarding and your own website forms need notices. For client data, the client normally gives the notice.
Section 6: Consent. Marketing to prospects and optional employee programmes need proper consent.
Report specified cyber incidents within six hours. Keep ICT logs for 180 days within India. Sync clocks to NIC or NPL time servers. Data centres, VPS, cloud and VPN providers keep specified subscriber information for five years.
Breach handling must meet the six-hour CERT-In clock and the DPDP report to the Board. Subscriber records need DPDP-level protection.
CERT-In
DPDP Act, Section 17(1)(d)
Processing of data of people outside India, under a contract with a party outside India, is exempt from most of the Act.
Tag each data set by where the people live. The exemption does not cover Indian staff or Indian customers.
MeitY
IT Act, Section 43A and SPDI Rules, 2011
Reasonable security practices for sensitive personal data, until Section 43A is omitted on 13 May 2027.
Your current ISO 27001 practices meet these today; DPDP Rule 6 takes over from May 2027.
Commercial calls and SMS to Indian numbers must follow registration and preference rules.
Outbound campaigns for Indian clients need both DPDP consent and TRAI compliance.
TRAI
Labour Codes (in force from 21 November 2025)
The four labour codes replaced older labour laws, including registers and records employers must keep.
Set retention for staff records against the new codes and state rules.
Ministry of Labour
Client contracts and foreign laws (for example GDPR for EU clients)
Clients often bind you to their own country's law through contracts and standard clauses.
These are contract duties, not Indian law, but you must meet them alongside DPDP.
Contract
Explore our research-built assessment platformsDPDP Insights helps you understand the law. DPDPiq is where an organisation's evidence is assessed. Each platform comes out of the same Foundation Layer research. No AI, API or outside service is used when you use this site. Everything runs from InfraVeritas360's own server.
