InfraVeritas360InfraVeritas360हिन्दीमराठीதமிழ்DPDPiq

DPDP Insights › IT, ITeS, BPO and GCC › Data and analytics department

DPDP for the Data and analytics department in IT and ITeS

Reviewed by InfraVeritas360 ResearchFirst published Last reviewed

Sources: DPDP Act, 2023 and DPDP Rules, 2025 (MeitY) · CERT-In · MeitY · MeitY · TRAI

The data team holds analytics copies of staff, sales and sometimes client data.

Written for: Data and analytics department, IT, ITeS, BPO and GCC. Open this seat in the interactive tool

What is different here

Client data may be used only as the client instructs, so analytics copies need a contract check first. Staff data in HR dashboards is yours but still bound by the purpose people were told. Offshore data under a foreign contract still needs the same security.

The first four things to sort out

  1. Tag each data set as yours or the client's.
  2. Check the contract before using client data.
  3. Mask staff data in dashboards.
  4. Set a deletion date for every analysis copy.

A worked example

Data and analytics department

Client data in an internal dashboard

  1. Week 1A delivery dashboard shows client customer names.
  2. Week 1The contract allows only service reporting.
  3. Week 2Names are replaced with counts.
  4. AfterDashboards are reviewed at project start.

Evidence kept

  • Contract check
  • Dashboard change

Client data in your own tools needs the client's permission.

What others in the sector usually do. Many data teams delete analysis copies when the project or report closes.

Where it usually goes wrong, by organisation type

Organisation typeHotspots
IT services and consultingProduction data copied to laptops or test environments; Shared client credentials in team chats; Sub-contractors working under your client access
BPO and contact centreCard numbers spoken on recorded calls; Phones and paper on the floor; Outbound calls without consent checks for Indian customers
Global capability centreIndian customer data mixed into global data sets; Global HR systems hosted abroad; Intra-group agreements that predate DPDP
SaaS and software productsSupport staff browsing customer tenants; Analytics on customer data beyond the contract; Deletion that does not reach backups
Managed services, data centres and cloudPrivileged admin access across many clients; Subscriber records kept with no access limits; Backups of client systems held for years

7 questions the Data and analytics department asks, answered in full

How should our people access client systems?

Short answer: Named, logged and removed at roll-off

Through named accounts, from managed devices or controlled jump servers, with multi-factor sign-in and logging. Access should be removed the day someone rolls off. Client data should stay in client systems and not be copied to laptops, internal tickets or chat.

What the law says

Section 8(5) and Rule 6 apply to your safeguards even where you are the processor. Section 8(5) · Rule 6 · Section 8(1)–(2)

Steps
  1. No shared client credentials.
  2. MFA on all client access.
  3. Jump servers or VDI for sensitive clients.
  4. Roll-off removal the same day.
  5. Quarterly access review per client.
Evidence to keep
  • Access lists per client
  • Review records
  • Roll-off removal reports
Common mistakes
  • Shared logins in team chat
  • Copying production data to laptops
  • Access left after roll-off

Can we use customer data for analytics and models?

Short answer: Yes, within the purpose or with 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.

From your seat: Data and analytics department. Check the purpose before each analysis.
What the law says

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)

Steps
  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.
Evidence to keep
  • Purpose checks
  • Data specifications
  • Retention entries
Common mistakes
  • Using all data because it is there
  • Analysis copies with no end date
  • Profiling children

How do we build privacy into a new product or system?

Short answer: Four questions at design, then build the basics in

Ask four questions at the design stage: what personal data, why, for how long, and who sees it. Then build in what the Act assumes: a notice, consent where needed, role-based access, logs of record views, a way to delete, and a way to answer requests. Adding these after launch costs far more.

From your seat: Data and analytics department. Mask and aggregate by default.
What the law says

Sections 5 to 12 assume systems that can show notices, record consent, limit access, log, delete and answer requests. Section 5 · Rule 3 · Section 6 · Section 8(5) · Rule 6 · Section 8(7) · Rule 8 · Sections 11–14 · Rule 14

Steps
  1. Add the four questions to design templates.
  2. Drop data you do not need.
  3. Build access roles and record-view logs.
  4. Build deletion and request export.
  5. Register the system in the inventory at launch.
Evidence to keep
  • Design review records
  • Inventory entries
  • Deletion tests
Common mistakes
  • Privacy review only at launch
  • Collecting 'in case we need it'
  • No delete function

Do we need a Data Protection Impact Assessment?

Short answer: Required only for SDFs; good practice for high-risk changes

By law, only Significant Data Fiduciaries must do a yearly impact assessment. For everyone else it is good practice for high-risk changes: new tracking, profiling, large data sharing, children's data or moving data abroad. A short assessment before the change is cheaper than fixing it later.

From your seat: Data and analytics department. Assess profiling.
What the law says

Section 10 and Rule 13 require a yearly impact assessment for Significant Data Fiduciaries. Section 10 · Rule 13 · Section 9 · Rules 10, 12 · Section 16 · Rule 15

Steps
  1. Define what counts as a high-risk change for you.
  2. Use a two-page template.
  3. Record the data, purpose, risks and safeguards.
  4. Get the DPO's view before approval.
  5. Keep it with the project record.
Evidence to keep
  • Assessment template
  • Completed assessments
  • DPO views
Common mistakes
  • Treating it as paperwork after launch
  • A 40-page template nobody completes
  • No trigger list

How long can we keep personal data?

Short answer: For the legal or business period, then erase

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.

From your seat: Data and analytics department. Analytics copies need a period.
Example in IT and ITeS

Candidates, employees, alumni, and client data at project end.

What the law says

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

Steps
  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.
Evidence to keep
  • Retention schedule approved by Legal
  • Deletion log
  • Shredding or disposal certificates
Common mistakes
  • 'Keep everything forever' because storage is cheap
  • Deleting before the legal minimum
  • Forgetting email, shared drives and backups

Do we process children's data, and what changes if we do?

Short answer: Check every channel; children often appear where you least expect

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.

From your seat: Data and analytics department. No behavioural monitoring of children.
Example in IT and ITeS

Usually only if a client's service involves children, or in staff dependants' records.

What the law says

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

Steps
  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.
Evidence to keep
  • Channel-by-channel note on children's data
  • Parent-consent records
  • Ad and tracking settings
Common mistakes
  • 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

The sections you will use most

Other rules that sit alongside DPDP

RuleWhat it saysWhat it means alongside DPDPSource
CERT-In Directions, 28 April 2022Report 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, 2011Reasonable 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.MeitY
TRAI Telecom Commercial Communications Customer Preference Regulations, 2018Commercial 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.