Personal data rarely remains within one organisation. Businesses routinely share customer, employee, applicant and user information with cloud providers, SaaS platforms, payroll companies, marketing agencies, logistics providers, analytics platforms and technology vendors. This makes vendor data processing obligations an important part of privacy governance in India. A vendor contract is no longer merely a commercial document. Where a third party processes personal data on behalf of a business, the agreement can become an important mechanism for controlling privacy, security and operational risk. India's privacy framework is moving towards a more structured approach through the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. However, the framework has phased commencement. As of September 2026, several core operational provisions, including Section 8 and the detailed security requirements in Rule 6, are scheduled for the later commencement phase. Businesses should therefore prepare contracts now rather than wait until the statutory obligations become operational. Why vendor agreements matter for data protection A business can outsource a processing activity, but outsourcing does not automatically remove its responsibility for the underlying data. Under the DPDP framework, a Data Processor is a person who processes personal data on behalf of a Data Fiduciary. The distinction depends on the actual processing relationship, rather than the commercial label given to the vendor. For example, a company may appoint a cloud provider to host its customer database. It may use a payroll platform to manage employee records or a customer support provider to handle complaints. In each situation, the third party may be processing personal data on behalf of the organisation. The contractual relationship therefore needs to reflect the actual data flow. A simple confidentiality clause may protect confidential business information, but it does not necessarily address the operational requirements associated with personal data processing. The DPDP Act specifically provides for contractual engagement of Data Processors. Section 8(2), which is scheduled for the eighteen month commencement phase, states that a Data Fiduciary may engage a Data Processor for relevant activities only under a valid contract. Data Fiduciary and Data Processor: who is responsible? The first step in reviewing a vendor agreement is identifying the role of each party. A Data Fiduciary determines the purpose and means of processing personal data. A Data Processor processes personal data on behalf of the Data Fiduciary. A vendor may therefore be a Data Processor for one activity but operate as an independent Data Fiduciary for another. This distinction is particularly important for modern SaaS arrangements. A software provider might process customer information strictly according to a company's instructions for one service. The same provider might use certain information independently for its own purposes in another context. The contract should not simply assume one role covers every processing activity. Businesses should document the purpose of processing, categories of personal data, categories of Data Principals, systems involved, locations of processing and permitted uses before finalising the agreement. What should a data processing clause cover? A well drafted vendor agreement should establish clear boundaries around how personal data may be processed. The vendor should receive clear instructions about the permitted purpose. Personal data provided for customer support should not automatically become available for unrelated product development, advertising or other commercial purposes. The agreement should also identify the categories of information involved. Customer contact information creates different risks from identity documents, financial information, health information or children's information. A risk based approach helps determine the level of contractual protection required. The agreement should also address access. Vendor personnel should only access personal data where necessary for their assigned responsibilities. Access should be controlled, reviewed and removed when no longer required. These contractual controls support the wider accountability model contemplated by India's data protection framework. Security safeguards should be contractual obligations Security is one of the most important areas in a vendor relationship. The notified DPDP Rules, 2025 provide for reasonable security safeguards covering personal data processed by a Data Fiduciary itself or on its behalf through a Data Processor. Rule 6 includes measures such as encryption, masking or obfuscation, access controls, logging and monitoring, backups, retention of relevant logs and contractual safeguards with Data Processors. Businesses should therefore avoid vague wording such as “the vendor will maintain adequate security”. The contract should explain the expected standard in terms suitable for the service and risk involved. For a cloud provider, this may involve encryption, identity management, access logging and resilience controls. For a customer support provider, it may also require restrictions on downloading records, controlled employee access and secure disposal. A vendor agreement should ideally connect contractual commitments with evidence. Depending on risk, this may include security certifications, audit reports, penetration testing summaries, policies or other appropriate assurance material. Breach notification must work in practice A privacy contract is tested most severely during a security incident. If a vendor discovers unauthorised access to personal data, the business needs information quickly. A clause requiring notification “promptly” may be too vague for an effective incident response programme. The contract should establish an internal escalation process. It should specify how the vendor will notify the business, what initial information must be provided, how updates will be communicated and who will coordinate investigation and remediation.The agreement should also require reasonable cooperation with forensic investigations and regulatory responses where appropriate. This matters because the organisation engaging the processor may have its own statutory notification responsibilities once the relevant DPDP provisions commence. The vendor therefore needs to notify the organisation quickly enough for the organisation to assess and discharge its own legal duties. Businesses should also align vendor incident clauses with their internal incident response plan. Contractual rights are of limited value if nobody knows who must activate them. Sub processors require careful control Many vendors do not operate alone. A SaaS provider may use cloud infrastructure, analytics platforms, customer support systems or other technology providers. This creates a chain of processing. A business should know whether its vendor uses sub processors, who those entities are, what data they receive and where processing takes place. The agreement should establish an appropriate mechanism for approving or objecting to material changes in the sub processor chain. Equivalent privacy and security obligations should also flow down where appropriate. This is especially important for technology vendors whose underlying infrastructure can change during the contract term. A company may sign an agreement believing its data will be handled by one provider, only to discover later that another entity is performing a material part of the processing. Data retention, deletion and return Vendor agreements should also address the end of the data lifecycle. When a service ends, the business should know what happens to the personal data. The vendor should not retain information indefinitely merely because the service agreement has expired. The contract should establish whether information must be returned, deleted or securely disposed of. It should also address backups, legal retention requirements and the evidence available to demonstrate deletion where appropriate. This requirement becomes particularly important during vendor transitions. A company moving from one CRM, payroll platform or cloud provider should not have personal data scattered across its previous supplier's active systems and backups without a defined retention position. Cross border processing should be visible A vendor may process Indian personal data outside India even when the business itself operates from India. Cloud architecture, support teams, infrastructure providers and sub processors can create international data flows without the procurement team fully appreciating them. The DPDP Act does not create a blanket prohibition on every cross border transfer. Section 16 provides a framework under which the Central Government may restrict transfers of personal data outside India to specified countries or territories. Other sector specific requirements may also apply depending on the organisation and information involved. Vendor agreements should therefore require sufficient transparency about processing locations and material changes to those arrangements. A business operating in a regulated sector should also assess applicable requirements from sectoral regulators before approving an international processing arrangement. Vendor due diligence should begin before signing A contract cannot compensate for inadequate vendor selection. Before onboarding a supplier, the organisation should understand what personal data the supplier will access and why. It should assess the nature of the service, the volume of information, security controls, subcontracting model, processing locations and incident history where relevant. High risk vendors should receive deeper scrutiny than vendors with no access to personal data. Procurement, information security, privacy and legal teams should work together. A vendor questionnaire can identify technical and organisational controls, while legal review can convert material risks into enforceable contractual terms. This is where data processing compliance becomes part of procurement governance rather than an issue addressed only after a contract has already been negotiated. Vendor monitoring does not end after contract signing One common mistake is treating the signed agreement as the end of compliance work. Vendor risk can change. Services evolve, new sub processors are appointed, processing locations change and new features may introduce artificial intelligence or additional analytics. Businesses should therefore periodically reassess material vendors. Contract reviews should be triggered by significant changes such as a new processing purpose, acquisition of the vendor, major system migration, new sub processor, material security incident or expansion into new jurisdictions. Evidence of reviews should also be retained. A documented vendor governance process helps demonstrate that privacy commitments are actively managed rather than merely written into contracts. What happens when a vendor refuses strong privacy clauses? Large technology suppliers often operate on standard terms. Businesses may have limited negotiating leverage. This does not mean every clause should simply be accepted. The organisation should first identify which provisions are legally essential, which are risk controls and which are preferred commercial protections. A risk based approach can then determine whether alternative safeguards are acceptable. For high risk processing, inability to obtain adequate contractual protections may itself be a reason to reconsider the vendor. For lower risk services, other controls may reduce exposure. The decision should be documented rather than left to informal procurement discussions. The role of indemnities and liability provisions Privacy obligations should also be considered alongside liability provisions. A vendor may agree to comply with data protection requirements while its general liability clause places a relatively low cap on claims. This can create a mismatch between the seriousness of the processing risk and the available contractual remedy. Businesses should examine liability caps, indemnities, exclusions, insurance requirements and treatment of regulatory costs. o single liability structure works for every transaction. A payroll vendor, health technology provider and ordinary office supplies vendor present very different levels of privacy risk. The commercial allocation should therefore reflect the nature of the processing. Indian businesses should prepare before full commencement The Government notified the DPDP Rules, 2025 in November 2025. MeitY's official materials confirm a phased eighteen month implementation approach. The commencement notification places the core operational provisions of the Act, including Sections 3 to 17 and Section 8, in the later phase. This gives businesses an important preparation window. Organisations should identify vendors handling personal data, classify their roles, map data flows and review existing contracts. Procurement templates should be updated before new vendors are onboarded. Existing high risk arrangements should be prioritised for remediation. Businesses should also remember that India's privacy landscape currently includes other applicable legal requirements. The Information Technology Act, 2000 and the Information Technology SPDI Rules, 2011 remain relevant during the transition, particularly for organisations handling sensitive personal data or information within their scope. Building a stronger vendor governance model The most effective approach is to treat vendor privacy as a lifecycle process. At the procurement stage, identify whether personal data will be processed. During due diligence, assess the vendor's security and privacy controls. During contract negotiation, document processing instructions, security obligations, incident response, sub processor controls, retention, deletion and relevant transfer provisions. During the relationship, monitor material changes and reassess risk. During termination, confirm return or deletion of personal data and revoke access. This approach creates a defensible record showing how the organisation manages third party data risk. For businesses dealing with extensive personal data, specialist corporate contract compliance review can also help align commercial agreements with the organisation's wider privacy framework. Conclusion Vendor management is now an important part of privacy governance for Indian businesses. Personal data may pass through several technology and service providers before a business delivers its product or service. Each additional processing relationship can create operational, contractual and regulatory risk. A strong vendor agreement should therefore do more than protect confidential information. It should establish clear processing boundaries, security expectations, incident procedures, sub processor controls, retention rules and appropriate accountability. With India's DPDP framework moving through its phased implementation, businesses have an opportunity to review vendor arrangements before the core obligations become operational. A structured approach to vendor due diligence, contracting and ongoing monitoring can reduce avoidable risk and create stronger evidence of responsible data governance. Frequently Asked Questions Q1. Is a data processing agreement mandatory in India? Under Section 8(2) of the DPDP Act, a Data Fiduciary may engage a Data Processor for covered activities only under a valid contract. However, Section 8 is part of the eighteen month commencement phase following the November 2025 notification. Businesses should therefore prepare processor agreements in advance rather than assuming the provision is already fully operational. Q2. What is the difference between a vendor and a Data Processor? A vendor is a commercial concept. A Data Processor is a legal role based on how the party processes personal data. A vendor becomes a Data Processor where it processes personal data on behalf of a Data Fiduciary. The actual activities should be examined rather than relying solely on the contract title. Q3. What should a vendor data processing agreement contain? It should address the processing purpose, instructions, permitted data, confidentiality, security safeguards, access controls, breach notification, sub processors, retention, deletion, return of information, relevant audit or assurance rights and applicable transfer requirements. Q4. Can a standard vendor agreement cover data protection requirements? Sometimes, but a generic vendor agreement may not provide sufficient detail. Businesses should review the agreement against the actual data processing activities and applicable law. A confidentiality clause alone is rarely an adequate privacy governance mechanism. Q5. Who is responsible if a vendor causes a data breach? Responsibility depends on the facts and applicable legal framework. A contractual arrangement does not automatically eliminate the Data Fiduciary's statutory responsibilities. The organisation should therefore maintain oversight of its processors and ensure vendors have effective security and incident reporting obligations. Q6. Should companies review old vendor agreements? Yes. Existing contracts should be prioritised based on risk. Agreements involving customer databases, employee information, financial information, health information, children's data or large volumes of personal data deserve particular attention. Q7. Do vendor contracts need to address sub processors? Where a vendor uses other parties to process personal data, the organisation should understand and appropriately govern the sub processor arrangement. Contractual flow down of relevant privacy and security requirements is an important control. Q8. Does Indian data protection law prohibit vendors from processing data outside India? Not as a blanket rule. The DPDP Act provides for restrictions on transfers to certain countries or territories through Government notification. Sector specific requirements may also apply. Businesses should therefore understand the vendor's processing locations before approving the arrangement. Q9. Why are vendor agreements important for DPDP compliance? They provide a practical mechanism for translating an organisation's privacy and security requirements into enforceable obligations for third parties. They also help establish accountability across the data processing chain. Q10. When should a business review its vendor privacy contracts? A review should occur during onboarding and periodically afterwards. It should also be triggered by major changes in processing, new sub processors, international expansion, significant security incidents, new technology features or changes in applicable law.  

Businesses increasingly rely on customer information, employee records, analytics, cloud platforms and third party technology. As data use grows, organisations need more than a privacy policy. They need evidence showing how personal data is collected, used, stored, shared and protected. A data protection compliance audit helps identify legal, operational and security gaps before they develop into regulatory problems, customer complaints or costly incidents. In India, audit preparation now needs to be viewed alongside the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. The Act was enacted on 11 August 2023, while the Rules were notified in November 2025. The framework is being introduced through a phased commencement structure. Top Four Search Results for “Data Protection Compliance Audit” Search rankings can vary by location, device, search history and date. The current search landscape for the query includes the following highly relevant pages: ICAI Data Protection Compliance and Audit Certification ICAI Data Protection Compliance and Audit Certification Programme DPDP Audit India Compliance Tool DPDP Act Data Protection Audit Requirements A review of the available results shows an important content gap. Many pages focus on audit services, certification or checklists. Businesses also need a practical explanation of how to prepare, what evidence auditors should examine, how Indian requirements fit together and what changes under the notified DPDP Rules. This article addresses those practical questions. What Is a Data Protection Compliance Audit? A data protection audit is a structured examination of an organisation’s personal data practices against applicable legal, contractual, regulatory and internal requirements. It is not simply a review of a privacy policy. An effective audit examines whether the organisation’s actual behaviour matches its documented commitments. For example, a company may state in its privacy notice that customer information is collected only for specified purposes. An audit should test whether its applications, databases, marketing systems and employees follow this principle in practice. The audit should therefore connect three areas: legal requirements, operational processes and technical controls. A useful audit may examine data collection, notices, consent, legitimate processing, access rights, correction and erasure procedures, retention, vendor management, security safeguards, breach response, international transfers and governance. The notified DPDP framework is particularly relevant because the Act places responsibility on the Data Fiduciary for compliance. Section 8 contains general obligations concerning personal data processing, while Section 10 establishes additional obligations for Significant Data Fiduciaries. Why Should Indian Businesses Prepare for an Audit? Audit preparation gives management an opportunity to identify weaknesses before they become incidents. A business may have multiple systems collecting personal information without a central record. Marketing may use information collected for one purpose for another purpose. Former employees may retain access to systems. Vendors may process customer information without suitable contractual safeguards. Data may remain stored long after the original purpose has ended. These issues are difficult to identify through policy review alone. An audit creates a documented picture of how personal data moves through the organisation. It can also help management prioritise remediation based on legal exposure, business impact and the sensitivity of the processing. The need for structured preparation is becoming more significant as India moves towards implementation of the DPDP framework. MeitY has described the notified Rules as providing the operational framework needed to implement the Act. Understand Which Legal Requirements Apply to Your Business The first stage of preparation is determining the legal scope. The DPDP Act applies to processing of digital personal data within India in specified circumstances. It can also apply to processing outside India when connected with offering goods or services to Data Principals in India. The Act uses the terms Data Fiduciary and Data Processor to distinguish organisations determining the purpose and means of processing from entities processing data on their behalf. A business should not assume the DPDP Act is its only relevant requirement. Depending on its activities, the organisation may also need to consider sector specific regulations, contractual obligations, cybersecurity requirements, employment laws and CERT In requirements. This matters during an audit because compliance cannot be assessed in isolation. A financial services business, healthcare organisation, technology company and educational institution may process similar categories of personal information but face different regulatory expectations. Build a Complete Personal Data Inventory One of the most important audit preparation exercises is creating a reliable data inventory. The organisation should identify what personal data it collects, where it comes from, why it is collected, where it is stored, who can access it, which vendors receive it and when it is deleted. The exercise should cover more than the main customer database. It should include websites, mobile applications, CRM platforms, email systems, HR platforms, payment systems, analytics tools, customer support platforms, cloud storage, backups and physical records where relevant. Data mapping is particularly useful because it reveals discrepancies between written policies and actual processing. A business may discover, for example, that a marketing platform receives information not mentioned in its privacy notice or that a software vendor retains information beyond the period expected by the business. A practical audit should therefore trace information from collection to deletion. Review Privacy Notices and Consent Mechanisms The next stage is reviewing how individuals are informed about processing. The DPDP Act contains specific provisions concerning notice and consent. The 2025 Rules add operational requirements concerning how notices should be presented and how consent withdrawal should function. Businesses should examine whether their notices clearly explain the relevant processing and whether individuals can understand what they are agreeing to. Consent mechanisms should also be tested from a user perspective. A company should ask whether consent is recorded, whether the record can be retrieved and whether withdrawal is genuinely possible. Consent withdrawal should not become an administrative exercise requiring an individual to contact multiple departments. The audit should also check whether the organisation continues processing information after consent has been withdrawn where no other lawful basis or permitted use applies. Test Data Principal Rights Procedures A compliance audit should examine whether individuals can effectively exercise their statutory rights. The DPDP Act provides rights relating to access to information about personal data, correction and erasure, grievance redressal and nomination. It is not enough for a policy to say these rights exist. The organisation should have an operational process for receiving, authenticating, assessing, responding to and recording requests. Auditors should test sample requests and examine response records. They should also assess whether internal teams know how to escalate a request involving multiple systems or third party processors. This is an area where operational testing often reveals weaknesses missed during document review. Review Vendor and Data Processor Controls Third party relationships deserve particular attention. Businesses frequently share personal information with cloud providers, payroll companies, marketing platforms, customer support providers, analytics companies and technology vendors. The organisation should know which vendors process personal data and what each vendor is permitted to do with it. Contracts should address appropriate data protection responsibilities, security expectations, confidentiality, incident management, deletion or return of data and relevant audit or cooperation obligations. The notified Rules also contemplate contractual security requirements between Data Fiduciaries and Data Processors. An audit should therefore compare contracts against actual vendor practices. A strong contract is of limited value if the operational relationship follows different rules. Examine Security Safeguards Legal compliance and information security are closely connected. The DPDP framework requires Data Fiduciaries to adopt reasonable security safeguards. The notified Rules identify measures such as encryption, masking, access controls, monitoring and backups as part of the security framework. Audit preparation should therefore include technical evidence. This may involve reviewing access permissions, authentication controls, encryption practices, system logs, vulnerability management, backup arrangements and incident detection processes. Access should follow a genuine business need. Former employees should not retain active access. Privileged accounts should receive additional scrutiny. The organisation should also verify whether its security controls cover data processed by external vendors. Prepare for Data Breach Scenarios Every organisation should test its breach response before an incident occurs. The notified DPDP Rules establish a framework for notifying affected Data Principals and the Data Protection Board following a personal data breach. Rule 7 provides for notification to affected Data Principals without delay and requires detailed information to be furnished to the Board within seventy two hours, subject to the mechanism specified in the Rule. However, businesses should also remember other applicable cyber incident reporting obligations. CERT In directions currently require specified cyber incidents to be reported within six hours of noticing the incident or being informed of it. An audit should therefore test whether the legal, technical, communications and management teams can respond quickly enough. The organisation should have clear escalation routes, incident classification procedures, evidence preservation processes and decision making responsibilities. Check Data Retention and Deletion Practices Data protection compliance does not end with collection. Organisations should know how long different categories of personal data are retained and why. Retention periods should be connected with the purpose of processing and other legal obligations. The notified Rules also introduce specific retention and erasure requirements for certain categories of businesses and circumstances. During an audit, sample databases should be checked to determine whether old records are actually deleted. A common weakness is having a retention policy without technical deletion mechanisms. Backups also require attention. A business should understand whether deleted information remains accessible through backup systems and whether its retention practices are documented. Review Cross Border Data Flows International data transfers should also form part of the audit. Businesses using international cloud platforms or overseas service providers need a clear understanding of where personal data travels. Section 16 of the DPDP Act addresses processing of personal data outside India. The framework permits overseas transfers subject to restrictions notified by the Central Government. Significant Data Fiduciaries may also face additional restrictions concerning specified personal data and related traffic data. The audit should therefore identify overseas recipients, hosting locations, transfer arrangements and contractual protections. Understand the Special Audit Position for Significant Data Fiduciaries Not every business faces the same audit obligations. Section 10 creates additional obligations for Significant Data Fiduciaries. These include appointment of a Data Protection Officer, an independent data auditor and periodic Data Protection Impact Assessments and audits. Rule 13 of the notified Rules provides for a DPIA and audit once every twelve months from the relevant notification or inclusion as a Significant Data Fiduciary. It also requires significant observations from the assessment and audit to be furnished to the Data Protection Board. Businesses should therefore determine whether they have been notified as Significant Data Fiduciaries and monitor future government notifications. Prepare an Evidence File Before the Audit An audit is much easier when evidence is organised before the review begins. The organisation should maintain an accessible record of its privacy notices, consent records, data maps, vendor contracts, retention schedules, security policies, access reviews, training records, grievance procedures, breach response plans and previous audit findings. Evidence should be current. A policy last updated several years ago does not demonstrate effective compliance if systems and business processes have changed since then. A useful data protection audit should therefore test both documentation and implementation. How to Turn Audit Findings into Remediation An audit report should not become a document stored in a compliance folder. Every significant finding should have an owner, priority, corrective action and target completion date. High risk issues should be addressed first. Examples include uncontrolled access, unlawful data sharing, missing breach procedures, excessive retention and processing without appropriate notice or consent. Management should also distinguish between immediate remediation and longer term programme improvements. For organisations seeking external assistance, specialist data protection compliance services can help with gap assessments, policy reviews, data mapping, vendor assessments and audit preparation. The appropriate level of external support will depend on the organisation’s size, processing activities and risk profile. Common Mistakes Businesses Make Before an Audit One common mistake is treating the privacy policy as evidence of compliance. A policy describes the organisation’s approach. It does not prove employees, systems and vendors follow it. Another mistake is conducting the audit only from a legal perspective. Technical controls, business processes and vendor arrangements must also be tested. Some organisations also overlook smaller systems. Marketing databases, spreadsheets and customer support tools can contain substantial amounts of personal information. A further weakness is failing to document remediation. An organisation may identify a problem but later struggle to demonstrate whether it was fixed. Finally, businesses should avoid assuming compliance based solely on industry practice. Another company’s privacy programme may not reflect its own processing activities or legal obligations. When Should a Business Conduct a Data Protection Audit? There is no universal audit schedule suitable for every organisation. A business should consider an audit when launching a new product, entering a new market, adopting major technology, outsourcing significant processing, expanding internationally or undergoing a substantial change in its data practices. An audit is also valuable after a significant data breach, regulatory development or material change in the organisation. For a Significant Data Fiduciary, the notified framework provides a specific periodic audit requirement. Other organisations can use a risk based approach, with more frequent reviews where processing involves large volumes, sensitive contexts, children, extensive profiling or significant third party dependencies. Final Thoughts Preparing for a data protection compliance audit should not be treated as a last minute documentation exercise. The strongest approach combines legal analysis, data mapping, operational testing, vendor oversight and technical safeguards. For Indian businesses, the DPDP Act and notified Rules provide an increasingly important framework for responsible digital personal data processing. Businesses should therefore begin with a simple question: Can we demonstrate how personal data moves through our organisation, why we process it, who can access it, how we protect it and when we delete it? If the answer is unclear, the organisation is not yet audit ready.A structured compliance programme, supported where necessary by corporate compliance requirements reviews and specialist legal or technical expertise, can help convert privacy obligations into practical controls and reliable evidence. Frequently Asked Questions (FAQs) Q1. Is a data protection compliance audit mandatory for every Indian company? No. The statutory periodic audit requirement under Section 10 and Rule 13 applies specifically to Significant Data Fiduciaries. Other businesses may still conduct internal or external audits as part of responsible compliance and risk management. Q2. What does a data protection audit normally examine? It can examine data collection, notices, consent, lawful processing, data subject rights, security safeguards, retention, deletion, vendors, international transfers, breach response and governance. Q3. Does having a privacy policy mean a company is compliant? No. Compliance requires operational implementation. An audit should compare the organisation’s documented policies with actual processing activities. Q4. How often should an organisation conduct a privacy audit? The appropriate frequency depends on risk and regulatory obligations. Significant Data Fiduciaries are subject to the periodic requirements prescribed under the DPDP framework. Other organisations can adopt a risk based audit cycle. Q5. What evidence should a company keep for a privacy audit? Relevant evidence may include data inventories, privacy notices, consent records, vendor contracts, access reviews, security assessments, retention schedules, training records, grievance records and incident documentation. Q6. What happens if an audit identifies compliance gaps? The organisation should assess the risk, assign responsibility, establish corrective actions and monitor remediation. Serious issues should receive priority. Q7. Are data processors responsible for compliance? The Data Fiduciary retains important statutory responsibilities even when processing is outsourced. Contracts, due diligence and ongoing oversight of processors are therefore important parts of compliance. Q8. Does a data protection audit also cover cybersecurity? It should examine security safeguards relevant to personal data. A full cybersecurity assessment may be broader and may involve additional technical standards and regulatory requirements. Q9. Are cross border transfers covered in an Indian privacy audit? Yes. Data flows outside India should be mapped and assessed against Section 16 of the DPDP Act, applicable government restrictions and other relevant laws or contractual requirements. Q10. What is the biggest benefit of preparing for an audit? The principal benefit is visibility. A well conducted audit shows management where personal data is processed, where controls are weak and which issues should be addressed first.

A data breach can become a legal, financial and reputational crisis within hours. For Indian businesses, data breach response for businesses now requires more than technical containment. Organisations must assess the incident, preserve evidence, determine applicable reporting duties and coordinate legal, security and business teams. The regulatory landscape is also evolving. India's Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 introduce a dedicated framework for personal data breaches, while CERT In continues to impose separate cyber incident reporting obligations. A strong response therefore starts before an incident occurs. Businesses need a tested response plan, clear responsibilities, reliable logs and a process for making fast legal decisions. What Is a Data Breach? A personal data breach generally involves unauthorised processing or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data in a manner which compromises its confidentiality, integrity or availability. A breach does not always involve a sophisticated cyberattack. A phishing attack, misdirected email, exposed database, stolen laptop, compromised employee account or careless vendor can create a reportable incident. Businesses should also distinguish between a cybersecurity incident and a personal data breach. A system outage may not involve personal data. A stolen database may involve both a cybersecurity incident and a personal data breach. This distinction matters because different legal and regulatory reporting duties can apply at the same time. India’s Legal Framework for Data Breach Response Indian businesses may face several overlapping legal requirements following a security incident. The Digital Personal Data Protection Act, 2023 creates obligations for Data Fiduciaries concerning reasonable security safeguards and personal data breach notification. Section 8 requires a Data Fiduciary to take reasonable security safeguards to prevent personal data breaches. Section 8(6) also provides for intimation of a personal data breach to the Data Protection Board and affected Data Principals. The DPDP Rules, 2025 provide operational detail concerning breach notifications. Rule 7 requires a Data Fiduciary, on becoming aware of a personal data breach, to notify affected Data Principals without delay. The Data Protection Board must also be informed without delay, followed by detailed information within 72 hours unless a longer period is permitted. However, businesses should not assume the DPDP regime has replaced all existing cyber incident requirements. The CERT In Directions issued under Section 70B of the Information Technology Act, 2000 continue to require specified cyber incidents to be reported within six hours of noticing the incident or being informed about it. CERT In expressly identifies data breaches and data leaks among incidents requiring reporting. The result is a potentially overlapping reporting environment. The Two Regulatory Clocks Businesses Must Understand One of the most important practical lessons for businesses is to avoid treating breach reporting as a single deadline. The CERT In framework operates on a six hour reporting requirement for covered cyber incidents. CERT In's official FAQs clarify that an organisation may initially provide the information available within the reporting period and supplement it later. This means uncertainty about the full scope of an incident should not automatically become a reason for delaying a required report. The DPDP Rules create a separate process for personal data breaches. Affected Data Principals must be informed without delay. The Data Protection Board must also receive an initial intimation without delay, followed by detailed information within 72 hours, subject to the applicable rules and any extension permitted by the Board. Businesses should therefore build their incident response process around parallel regulatory assessments, rather than waiting for one investigation to finish before considering another reporting obligation. Step One: Activate the Incident Response Team The first legal step after detecting a potential breach is to activate the organisation's incident response structure. The team should normally include representatives from information security, IT, legal, compliance, senior management and communications. Depending on the incident, HR, finance, insurance, forensic specialists and external counsel may also be required. One person should have clear authority to coordinate the response. Confusion over responsibility can waste valuable time during the first few hours. Businesses should maintain an updated contact list for legal counsel, forensic specialists, cybersecurity providers, insurers, CERT In and relevant sector regulators. CERT In itself recommends maintaining current contacts and having response arrangements in place before an incident occurs. Step Two: Contain the Incident Without Destroying Evidence Containment is essential, but businesses should avoid making rushed technical changes which destroy useful evidence. The security team may need to isolate affected systems, disable compromised accounts, revoke credentials, block malicious access and preserve affected infrastructure. Legal and forensic teams should coordinate evidence preservation. Relevant logs, access records, emails, system images, authentication records and communications should be retained where appropriate. This is particularly important if litigation, regulatory proceedings, insurance claims or law enforcement investigations may follow. CERT In has specifically advised organisations to preserve logs when suspicious activity is identified and to report relevant information as required. Step Three: Establish What Happened The next stage is incident classification. The organisation should determine when the incident began, when it was detected, which systems were affected and whether unauthorised access actually occurred. The investigation should identify the categories of information involved. Customer contact details create different risks from financial information, identity documents, authentication credentials, health information or information relating to children. The organisation should also establish whether the information was merely exposed, actually accessed, copied, altered, destroyed or transferred. A preliminary assessment should be documented even when the investigation remains incomplete. Step Four: Determine Whether Personal Data Is Involved Not every cyber incident creates a personal data breach. For example, a denial of service attack may disrupt business operations without exposing personal information. Conversely, a compromised employee account may provide access to customer records even if no evidence of mass extraction has yet been found. Businesses should therefore map affected systems to the categories of personal data stored within them. The assessment should also consider whether the organisation is a Data Fiduciary, whether another entity is involved as a Data Processor and whether the affected data belongs to customers, employees, applicants, suppliers or other individuals. This distinction can affect contractual responsibilities and notification strategy. Step Five: Assess CERT In Reporting Obligations Businesses covered by the CERT In Directions should assess whether the incident falls within the specified reporting categories. The official CERT In Directions require covered entities to report specified cyber incidents within six hours of noticing them or being brought to notice. The official CERT In FAQs further clarify that data breaches and data leaks fall within the incidents requiring reporting. They also recognise situations where all information may not be available within the initial six hour period. Available information can be provided first, with additional information supplied later. Businesses should therefore avoid waiting for a perfect forensic report before making a legally required preliminary report. CERT In Cyber Security Directions and official guidance Step Six: Assess DPDP Notification Requirements Where the DPDP Act and Rules are applicable, the organisation must assess its obligations towards affected Data Principals and the Data Protection Board. Rule 7 requires affected Data Principals to receive information without delay. The notification should explain the nature, extent and timing of the breach, likely consequences, mitigation measures, safety steps the individual can take and relevant contact information. The Board notification process requires an initial intimation without delay and a detailed report within 72 hours, subject to the possibility of an extension permitted by the Board. This makes advance preparation extremely valuable. Businesses should maintain draft notification templates and an internal approval process before an incident occurs. Step Seven: Consider Sector Specific Reporting Duties A breach may trigger obligations beyond the general cyber and data protection frameworks. Banks and financial institutions may have reporting requirements under RBI regulations. Listed entities may face SEBI requirements. Insurance businesses may have IRDAI obligations. Other regulated sectors can have their own incident reporting frameworks. A business should therefore maintain a regulatory matrix covering the sectors and jurisdictions in which it operates. A single incident can create several reporting obligations with different thresholds, authorities and deadlines. Step Eight: Manage Third Party and Vendor Breaches Many businesses assume a vendor breach is solely the vendor's problem. This approach can create serious legal risk. Cloud providers, payroll companies, SaaS platforms, payment processors, marketing providers, background verification agencies and outsourced IT providers may process personal data on behalf of a business. The organisation should therefore know which vendors hold personal data and how quickly they must report incidents to the business. Vendor contracts should contain appropriate incident notification, cooperation, security, investigation, evidence preservation and remediation provisions. A business should also maintain an escalation process for vendor incidents so legal and security teams are notified immediately. Step Nine: Preserve Legal Privilege Where Appropriate A serious breach can lead to regulatory inquiries, litigation, customer claims and insurance disputes. Businesses should consider involving legal counsel early. Legal counsel can help structure the investigation, identify reporting obligations, manage communications and assess potential exposure. The organisation should also distinguish legal advice from ordinary technical or operational communications. Confidentiality and privilege considerations can become complicated if investigation material is widely circulated internally. A clear legal response structure can help reduce unnecessary disclosure of sensitive investigative information. Step Ten: Control External Communications A breach creates pressure to communicate quickly. Speed matters, but accuracy matters too. Businesses should avoid making speculative statements about the cause, number of affected individuals or identity of attackers before the facts are established. Customer notifications should be clear, factual and useful. Individuals should understand what happened, what information may be affected, what the business has done and what protective steps they should consider. Communications should be coordinated between legal, security, management and public relations teams. Overly technical language can confuse customers. Overly reassuring language can create credibility problems if later facts are different. Step Eleven: Assess Contracts and Insurance A breach can trigger contractual obligations even when no regulator becomes involved. Customers may require immediate notification under commercial agreements. Technology vendors may have contractual incident reporting duties. Insurance policies may contain strict requirements concerning notification, approved forensic providers and cooperation. Businesses should therefore review relevant contracts and cyber insurance policies as part of the response. Failing to follow contractual or insurance procedures can create additional financial exposure. Step Twelve: Document Every Major Decision Incident response is not only about what the organisation does. It is also about demonstrating why it made particular decisions. Businesses should maintain an incident chronology recording key events, assessments, notifications, containment measures and remediation steps. The record should explain important decisions such as why a notification was made, why a particular regulator was contacted, what information was initially available and how the organisation responded as new facts emerged. Good documentation can become valuable evidence of responsible governance. Penalties for Data Breach Failures The financial consequences under the DPDP Act can be substantial once the relevant provisions become operative. The Schedule to the Act provides for penalties of up to ₹250 crore for failure to take reasonable security safeguards to prevent personal data breaches. Failure to notify the Board or affected Data Principal can attract a penalty of up to ₹200 crore. These figures represent statutory maximum penalties rather than an automatic fine for every incident. Businesses should also consider the wider consequences. A breach can cause customer claims, contractual disputes, regulatory scrutiny, operational disruption, investigation costs and reputational damage. The Importance of a Pre Incident Response Plan cyber incidents and personal data breaches. CERT In has recommended structured incident response planning, regular cyber drills and post incident reviews. Tabletop exercises can reveal practical weaknesses. For example, a company may discover during a simulation that nobody knows who can approve a regulatory notification or which vendor holds the affected database. Post Incident Remediation The best time to design a breach response plan is before an incident occurs.A useful plan should identify the incident response team, escalation procedures, forensic contacts, legal contacts, notification templates, regulatory contacts, communication protocols and evidence preservation requirements. The plan should also distinguish between Closing the incident is not the same as completing the response. After containment, the organisation should determine the root cause and identify control failures.  Was the breach caused by a stolen password? Was multi factor authentication missing? Did a vendor have excessive access? Was sensitive data stored without adequate protection? Did employees lack appropriate training?  The organisation should convert these findings into corrective actions with owners and deadlines. Post incident remediation can include access control changes, security testing, employee training, vendor reassessment, policy updates and system redesign. The organisation should also consider whether its data breach compliance framework needs to be updated based on lessons from the incident. How Businesses Can Reduce Future Breach Risk Effective prevention begins with understanding where personal data exists. Businesses should maintain data inventories, restrict unnecessary access, establish retention rules and regularly review third party access. Technical safeguards should be supported by governance. Security controls are less effective when nobody knows who owns the underlying risk. Regular testing is also important. Businesses should assess their applications, cloud infrastructure, authentication systems and APIs for weaknesses. Employee awareness remains equally important. Phishing, credential theft and social engineering continue to create significant risks. Incident response should therefore form part of broader corporate risk management, rather than being treated as an IT only function. Current Position During DPDP Implementation Businesses should be careful when describing the DPDP Act as fully operational. The Government notified the DPDP Rules, 2025 on 13 November 2025 and adopted a phased commencement structure. The core provisions concerning processing obligations, rights and several substantive duties have a later commencement date under the notification. This does not mean businesses should wait. CERT In's existing cyber incident reporting framework continues to matter now. Businesses may also have contractual and sector specific obligations independent of the DPDP Act. The transition period is therefore an opportunity to build a mature incident response system before the full DPDP compliance regime becomes operational. Conclusion A data breach should never be treated as only an IT problem. It can quickly become a legal, regulatory, contractual and reputational event. The most effective data breach response for businesses combines technical containment with legal assessment, evidence preservation, regulatory reporting and controlled communications. Indian businesses should pay particular attention to the different regulatory timelines. CERT In reporting can require action within six hours for covered cyber incidents, while the DPDP Rules provide separate notification requirements for personal data breaches. Preparation is therefore critical. A tested incident response plan, clear ownership, reliable logs, vendor controls and prepared notification procedures can significantly improve an organisation's ability to respond when an incident occurs. Frequently Asked Questions (FAQs) Q1. What should a business do immediately after discovering a data breach? The business should activate its incident response team, contain the incident, preserve relevant evidence, assess whether personal data is involved and identify applicable regulatory reporting requirements. Legal counsel and forensic specialists should be involved where appropriate. Q2. Does every data breach have to be reported to CERT In? Not every operational problem is necessarily a reportable cyber incident. Businesses should assess the incident against the categories covered by the CERT In Directions. CERT In's official guidance expressly includes data breaches and data leaks among incidents requiring reporting. Q3. How quickly must a business report a cyber incident to CERT In? Covered cyber incidents must generally be reported to CERT In within six hours of noticing the incident or being brought to notice. Q4. What is the DPDP breach notification timeline? Under Rule 7 of the DPDP Rules, 2025, affected Data Principals must be notified without delay. The Data Protection Board must also be informed without delay, followed by detailed information within 72 hours, subject to the applicable rules and any extension permitted by the Board. Q5. Can a company wait until the investigation is complete before reporting? Not necessarily. Waiting for a complete forensic investigation can create regulatory risk where a reporting deadline has already started. CERT In specifically permits available information to be submitted initially, with additional information provided later. Q6. Who should lead a data breach response? The response should be coordinated through a designated incident response structure involving security, IT, legal, compliance and senior management. The appropriate participants will depend on the nature and scale of the incident. Q7. What if a third party causes the breach? The business should immediately assess the vendor's contractual duties, contain the incident, obtain relevant evidence and determine whether the business itself has notification or regulatory obligations. Vendor contracts should include clear incident reporting and cooperation requirements. Q8. Should customers always be notified after a data breach? Customer notification depends on the applicable legal and regulatory framework and the nature of the incident. Where the DPDP Rules apply, affected Data Principals must be notified without delay in accordance with Rule 7. Q9. What penalties can apply for failing to report a personal data breach under the DPDP Act? The DPDP Act provides for a penalty of up to ₹200 crore for failure to notify the Board or affected Data Principal of a personal data breach. Failure to take reasonable security safeguards can attract a penalty of up to ₹250 crore. Q10. Is a data breach response plan legally necessary? A written response plan is an important governance measure even where a particular law does not prescribe a document with that exact title. CERT In guidance encourages structured incident response planning, cyber drills and post incident reviews. Q11. How can businesses prepare for the DPDP breach notification requirements? Businesses should map personal data, identify responsible teams, establish escalation procedures, prepare notification templates, review vendor contracts, establish evidence preservation procedures and conduct tabletop exercises. Q12. Does the DPDP Act replace CERT In reporting? No. The two frameworks address different aspects of the regulatory environment. Businesses may have obligations under both, depending on the nature of the incident and their activities. CERT In's six hour reporting requirement can operate alongside DPDP breach notification requirements.

Employee data privacy is no longer only an HR policy issue. Employers collect extensive personal information during recruitment, onboarding, payroll, performance management, benefits administration and exit formalities. As India moves towards full implementation of the Digital Personal Data Protection Act, 2023, businesses must understand how employee information is collected, used, stored, shared and deleted. For employers, employee data privacy for employers now requires coordination between HR, legal, IT, information security and senior management. India's privacy framework is also moving through a transition period. The Digital Personal Data Protection Act, 2023 was enacted on 11 August 2023. The Government notified the Digital Personal Data Protection Rules, 2025 on 13 November 2025. Several provisions are being introduced in phases, with the core processing provisions scheduled to commence 18 months after the November 2025 notification. Why Employee Data Privacy Matters for Employers? HR departments handle some of the most commercially and personally significant information within an organisation. Employee records may include names, addresses, contact details, identification documents, bank account information, salary records, tax information, health and insurance details, attendance records, photographs, performance reviews and background verification information. Modern workplaces also generate digital records through access control systems, CCTV, company email, endpoint security tools, attendance applications, collaboration platforms and employee monitoring software. Remote working and Bring Your Own Device arrangements can increase the volume and complexity of personal data processing. Recent legal commentary on workplace monitoring highlights the need to consider both the purpose and scope of such monitoring. The risk is not limited to external cyberattacks. Unauthorised internal access, excessive data collection, inappropriate sharing with vendors, poor retention practices and unsecured spreadsheets can also expose an organisation to legal and operational risk. The Indian Legal Framework Governing Employee Data The constitutional right to privacy forms an important background principle. The Supreme Court recognised privacy as a constitutionally protected right under Article 21 in Justice K.S. Puttaswamy v Union of India. For private employers, however, practical obligations also arise through legislation, contracts, confidentiality duties and data protection requirements. The Digital Personal Data Protection Act, 2023 is India's principal comprehensive framework for digital personal data. Under the Act, an employer generally acts as a Data Fiduciary because it determines the purpose and means of processing employee information. Employees are Data Principals in relation to their personal data. The DPDP Act creates two principal grounds for processing personal data: consent and certain legitimate uses. Importantly for HR departments, Section 7 recognises processing necessary for employment purposes and certain activities connected with safeguarding the employer from loss or liability as a legitimate use. This means employers should not assume consent is required for every HR activity. At the same time, the employment related provision should not be treated as a blanket exemption. Processing must still be connected with the relevant legitimate purpose. Employers should distinguish between necessary employment processing and additional activities such as optional profiling, intrusive monitoring or unrelated secondary uses.The Information Technology Act, 2000 and the Information Technology Rules concerning reasonable security practices and sensitive personal data or information remain relevant during the transition. The existing SPDI framework covers categories such as financial information, health information, biometric information and certain other sensitive information. The legal position is therefore transitional rather than a simple switch from one regime to another. Businesses should monitor the commencement notifications carefully instead of assuming every provision of the DPDP Act became operational immediately upon enactment. What Employee Data Can Employers Collect? An employer may legitimately need considerable information to establish and manage an employment relationship. Recruitment data may include CV information, qualifications, professional history, references and verification details. Onboarding may require identification documents, tax information, bank details and emergency contact information. During employment, HR may process attendance information, leave records, payroll data, benefits information, insurance details, performance assessments and disciplinary records. Some organisations also process biometric information for attendance or access control. The key question is not simply whether the organisation can collect a particular category of information. The organisation should ask why the information is required, whether the purpose is legitimate, whether less intrusive information would be sufficient, who needs access and how long the information should remain available. Data minimisation should therefore become part of everyday HR decision making. Notice and Transparency Obligations Transparency is a central part of a mature privacy programme. Employees should understand what personal data an organisation processes, why it is required and how it is handled. The notified DPDP Rules, 2025 provide important detail on privacy notices. Rule 3 requires a notice to be presented independently and in clear and plain language. It must include an itemised description of personal data and the specified purpose or purposes of processing. It must also provide relevant means for exercising rights and withdrawing consent where consent is the applicable basis. Employers should therefore review onboarding documents, HR portals, recruitment forms and employee handbooks. A generic privacy statement copied from a consumer website may not adequately explain employment related processing. A practical employee privacy notice should explain the categories of information collected, purposes of processing, relevant disclosures, retention approach, rights, grievance channels and methods for contacting the organisation. When Is Employee Consent Required? Consent remains an important legal basis under the DPDP framework, but it is not the answer to every employment processing activity. Section 7(i) of the DPDP Act permits certain processing necessary for employment and for specified purposes connected with protecting an employer from loss or liability. This can cover activities linked with employment administration, protection of trade secrets, prevention of corporate espionage and provision of benefits or services to employees. Employers should avoid using consent as a substitute for proper legal analysis. For example, collecting bank information to process salary may have a clear employment related purpose. By contrast, using employee information for an unrelated marketing activity may require a different legal basis. The employment relationship also creates a practical power imbalance. A consent mechanism should therefore not be designed as a meaningless tick box. Organisations should document why processing is necessary and identify cases where separate consent is appropriate. Employee Monitoring and Workplace Surveillance Technology has made employee monitoring easier. Employers may use CCTV, access logs, email security tools, device management systems, location information, productivity tools and cybersecurity platforms. The existence of a legitimate business purpose does not automatically make every form of monitoring proportionate. Employers should define the purpose of monitoring, restrict access, establish appropriate safeguards and communicate relevant practices to employees. Monitoring company email for cybersecurity or preventing data leakage is different from accessing an employee's personal communications. Similarly, collecting location information during working hours may require a different assessment from continuous location tracking. A good governance approach asks four questions: what is being monitored, why it is being monitored, who can access the information and when the monitoring stops. Security Responsibilities of Employers Security is one of the most important responsibilities associated with employee data. HR information should not be accessible to every employee simply because it is stored on an internal system. Organisations should implement appropriate technical and organisational safeguards. These can include access controls, authentication, encryption where appropriate, secure backups, audit logs, vulnerability management and employee awareness programmes. Vendor access also requires careful control. Payroll providers, background verification agencies, HR technology platforms, insurers and cloud service providers may process employee information on behalf of an employer. Contracts should clearly address permitted processing, confidentiality, security measures, incident management, access controls and deletion or return of information. The notified DPDP Rules provide further security requirements as part of the emerging compliance framework. Retention and Deletion of Employee Information One common weakness in HR privacy programmes is indefinite retention. An organisation may retain an employee's information for years simply because nobody has decided when it should be deleted. This creates unnecessary exposure. Former employee information can remain in HR folders, email archives, cloud drives, payroll systems and vendor platforms long after the original purpose has ended. Employers should create retention schedules linked to specific categories of records. The schedule should consider employment requirements, tax obligations, labour requirements, litigation holds and other applicable legal duties. Deletion should also cover practical copies. Removing a document from the HR system is not enough if duplicate copies remain in shared drives, email accounts or third party systems. Recruitment and Former Employee Data Privacy compliance should begin before an individual becomes an employee. Recruitment teams often collect CVs, photographs, identification documents, references, assessment results and background verification information. Employers should explain why these details are being collected and avoid retaining unsuccessful candidates' information indefinitely. The same principle applies after employment ends. Exit formalities may require certain records to be retained for legitimate legal or business reasons. Other information may no longer have a continuing purpose. An effective HR privacy framework therefore covers the complete employee lifecycle, from candidate application to post employment retention. Employee Rights and Grievance Handling The DPDP Act provides rights for Data Principals, including mechanisms relating to access to information, correction and erasure, subject to the statutory framework and applicable exceptions. Employers should create an internal process for handling employee privacy requests. HR teams should know who receives a request, how identity is verified, which systems are searched, who approves the response and how the organisation records its decision. A grievance mechanism is equally important. Employees should have a clear route for raising concerns about inappropriate collection, access, disclosure or use of their information. Businesses should begin preparing these processes before the relevant provisions become fully operational rather than waiting until the statutory deadline. How Employers Can Build Stronger Employee Privacy Governance? A practical programme begins with a data inventory. HR should identify every major category of employee information and record where it comes from, where it is stored, who can access it and which vendors receive it. The next step is to map purposes. Each processing activity should have a defined business or legal purpose. Unnecessary information should be removed from forms and systems. Organisations should then review privacy notices, HR policies, vendor contracts, retention schedules and security controls. Employee monitoring practices deserve a separate review because they can create heightened privacy concerns. Training is also essential. A technically strong privacy framework can fail if HR personnel routinely send salary information to the wrong recipient or store identity documents in unsecured folders. For organisations with complex operations, employee data privacy should be integrated into wider governance rather than treated as a standalone HR document. The Role of Legal and Compliance Teams Privacy compliance is not solely an IT responsibility. Legal teams help determine the appropriate legal basis, review contracts, assess regulatory exposure and interpret changing requirements. HR teams understand the operational context. IT and security teams implement safeguards. Senior management provides oversight and resources. Organisations may also require specialist corporate legal responsibilities guidance where employee monitoring, cross border data flows, mergers, acquisitions, outsourcing or large scale HR technology deployments create additional legal questions. The strongest approach is collaborative. Privacy should become part of the organisation's standard decision making process. Preparing for the DPDP Transition The Government notified the DPDP Rules, 2025 on 13 November 2025 and established a phased commencement structure. Under the commencement notification, the core provisions covering processing of personal data, including Sections 3 to 17, are scheduled to take effect 18 months after publication of the notification. This transition period gives employers an important opportunity. They can audit HR databases, review employee notices, assess vendor arrangements, establish retention schedules, test breach response procedures and train HR personnel before the substantive provisions become fully applicable. The official Ministry of Electronics and Information Technology resources provide access to the notified Act, Rules and implementation information. Digital Personal Data Protection Act, 2023 on MeitY Digital Personal Data Protection Rules, 2025 on MeitY Conclusion Employee data is an essential part of modern business operations, but it should not be treated as an unrestricted corporate asset. Employers must understand why information is collected, establish appropriate legal grounds, provide meaningful transparency, protect records, control vendor access and delete information when continued retention is no longer justified. The transition to India's new data protection framework makes this an appropriate time to review existing HR practices. Businesses that build privacy into recruitment, onboarding, employment monitoring, payroll, vendor management and exit processes will be better positioned to meet their legal responsibilities and maintain employee trust. Where an organisation needs specialised support, data protection compliance can be incorporated into broader governance, HR policy and corporate risk management programmes. Frequently Asked Questions (FAQs) Q1. Does the DPDP Act apply to employee data? Yes. Employee personal data can fall within the scope of the DPDP Act when it is digital personal data covered by the legislation. Employers generally act as Data Fiduciaries while employees are Data Principals. Q2. Do employers always need employee consent to process personal data? No. Section 7 of the DPDP Act recognises certain legitimate uses, including specified processing necessary for employment and for safeguarding an employer from certain losses or liabilities. Consent may still be relevant for processing outside those legitimate uses. Q3. Is employee health information protected in India? Yes. Health information can constitute personal information requiring appropriate protection. The existing SPDI framework also treats medical records and physical or mental health information as sensitive personal data or information. Employers should consider the applicable regime during the DPDP transition. Q4. Can an employer monitor employee emails? An employer may have legitimate reasons to monitor company systems for cybersecurity, compliance or protection of business information. However, monitoring should be connected to a legitimate purpose and implemented proportionately. Accessing personal communications raises different privacy considerations. Q5. How long can an employer retain employee data? There is no single retention period for every category of employee information. Retention should depend on the purpose of processing and applicable legal, regulatory, contractual and litigation requirements. Q6. Do former employees have privacy rights? Former employees may continue to have rights and protections concerning personal information held by an organisation, subject to the applicable legal framework and commencement of relevant provisions. Employers should therefore have a clear post employment retention and deletion policy. Q7. What should an employee privacy notice contain? It should explain the categories of personal data collected, purposes of processing, relevant disclosures, rights, grievance mechanisms and other information required under the applicable legal framework. The DPDP Rules, 2025 provide specific requirements concerning clear and plain language notices. Q8. What is the biggest employee data privacy risk for employers? One major risk is uncontrolled data accumulation. Organisations often collect information without clearly defining the purpose, retain it indefinitely and provide access to more people or vendors than necessary. Strong data mapping, access controls, retention rules and staff training can reduce this exposure. Q9. Should employers review their HR technology vendors? Yes. Payroll providers, HR management platforms, recruitment systems, background verification companies, insurers and cloud service providers may process employee information. Employers should assess their contractual and security arrangements before sharing personal data. Q10. Is employee consent required for payroll processing? Not necessarily under the future DPDP framework. Processing necessary for employment can fall within the legitimate use recognised under Section 7. Employers should still provide appropriate transparency and comply with applicable security, governance and other obligations.