Financial technology companies operate in a data intensive environment. A single fintech platform may collect identity information, financial records, transaction details, credit information, device information, location data and behavioural information. This makes fintech privacy compliance a central legal and operational issue rather than a narrow cybersecurity concern. In India, fintech businesses must navigate the Digital Personal Data Protection Act, 2023 alongside sector specific requirements issued by the Reserve Bank of India, SEBI, IRDAI and other regulators, depending on their activities. Payment platforms, digital lenders, Account Aggregators, wealthtech businesses and fintech service providers can face different obligations. A strong privacy programme therefore needs to connect data protection law with financial regulation, technology governance, contractual controls and customer protection. What Does FinTech Privacy Compliance Mean? Fintech privacy compliance refers to the processes a financial technology business uses to lawfully collect, use, store, share, secure and delete personal data. The concept goes beyond having a privacy policy on a website. A fintech needs to understand why it collects each category of information, whether the processing has a valid legal basis, who receives the information, how long it is retained and what happens if the information is compromised. For example, a digital lending application may collect information during customer onboarding, KYC verification, credit assessment, loan servicing and recovery. Each stage can involve different purposes, systems, employees and vendors. The compliance framework must therefore follow the complete data lifecycle. India Has a Layered Privacy Framework for FinTechs The DPDP Act provides a broad framework for processing digital personal data. It applies across sectors rather than creating a separate privacy statute specifically for fintech businesses. However, fintechs do not operate under the DPDP Act alone. A regulated entity may also need to comply with RBI directions relating to digital lending, payment systems, outsourcing, information technology, cybersecurity, customer protection and data storage. A securities focused fintech may have SEBI requirements, while an insurance technology business may need to consider IRDAI requirements. This creates an important principle: DPDP compliance does not replace financial sector compliance. A fintech should identify every regulatory framework connected with its business model before designing its privacy controls. DPDP Act and FinTech Businesses Under the DPDP Act, an organisation deciding the purpose and means of processing personal data will generally operate as a Data Fiduciary. A technology provider processing information on behalf of another organisation may instead operate as a Data Processor. The same fintech group can sometimes occupy both roles. For example, a lending technology company may process borrower information for its own services while separately processing information on behalf of a bank or NBFC. The contractual and legal analysis should reflect the actual processing relationship rather than simply relying on the label used in an agreement. The Data Fiduciary remains responsible for complying with its obligations even when processing is outsourced. This makes role mapping an important first step in any privacy assessment. The Current DPDP Implementation Timeline Matters The DPDP Act was enacted in 2023, while the DPDP Rules were notified on 13 November 2025. The Rules use a phased commencement model. Rules 1, 2 and 17 to 21 came into force on publication. Rule 4, dealing with Consent Managers, is scheduled to commence one year after publication. Rules 3, 5 to 16, 22 and 23 are scheduled to commence eighteen months after publication. For fintech businesses, this means the major operational requirements are scheduled for 13 May 2027, while the Consent Manager registration framework is scheduled to commence on 13 November 2026. This distinction is important. A fintech should not describe every DPDP obligation as fully enforceable today. At the same time, waiting until May 2027 to begin implementation would create unnecessary operational pressure. Notice and Consent in FinTech Products Consent is particularly important in fintech because customer journeys are often fast and highly automated. The DPDP Act requires consent, where consent is the applicable basis, to be free, specific, informed, unconditional and unambiguous. It must involve clear affirmative action. A fintech should therefore avoid treating a long terms and conditions document as an adequate privacy consent mechanism. The customer should understand what information is being collected and why. There should also be a distinction between information needed to provide a requested financial service and information used for optional purposes such as marketing, profiling or additional product offers. A customer applying for a loan, for example, should not automatically be required to provide unnecessary permissions for unrelated marketing activities. Data Minimisation in Digital Lending Digital lending is one of the most important areas for fintech privacy governance. Loan applications can involve identity documents, bank information, financial statements, credit information and other personal details. Mobile applications may also have access to device related information. The principle should be simple: collect information needed for a defined purpose and avoid unnecessary data harvesting. RBI's digital lending framework has placed emphasis on need based data collection, prior and explicit consent for specified data collection, clear audit trails and privacy policies. It also places restrictions around the storage of borrowers' personal information by Lending Service Providers and Digital Lending Apps. Fintechs should therefore conduct a data inventory before collecting information through mobile permissions, APIs or third party services. KYC and Privacy Obligations KYC creates one of the most difficult compliance questions for fintech businesses. Financial regulations may require an organisation to collect and retain particular information. Privacy law may simultaneously impose requirements around purpose, transparency, security, rights and lawful processing. These obligations should not be treated as contradictory. A fintech should identify the precise legal requirement for each category of KYC information. It should then establish the appropriate retention period and ensure information is not reused for unrelated purposes without a valid legal basis. This becomes especially important when a company wants to reuse KYC information for marketing, analytics, cross selling or automated profiling. Payment Data and Localisation Payment fintechs must consider RBI requirements concerning payment system data. RBI's April 2018 directive requires payment system operators to store the entire payment system data in systems located in India, subject to the treatment permitted for the foreign leg of an international transaction. This is separate from the DPDP Act. The DPDP Act itself does not create a universal requirement for every category of personal data to be stored only in India. Section 16 establishes a framework under which the Central Government may restrict transfers to specified countries or territories. A fintech should therefore distinguish between DPDP transfer rules and sector specific localisation requirements. Account Aggregators and Consent Architecture Account Aggregator businesses demonstrate why fintech privacy cannot be reduced to a generic consent banner. The RBI Account Aggregator framework contains detailed requirements around explicit customer consent, standardised consent artefacts, purpose, recipients, validity, revocation and auditability. An Account Aggregator cannot use customer financial information for purposes outside the permitted framework. The ecosystem also requires secure information transfer and appropriate consent management. This creates a useful compliance model for other fintech businesses. Consent should be treated as a lifecycle rather than a single button. The fintech should be able to determine what the customer agreed to, for which purpose, for how long, with whom information could be shared and whether consent was later withdrawn. Customer Rights Under the DPDP Framework The DPDP Act provides rights for Data Principals, including access to information about personal data, correction and completion, updating, erasure in applicable circumstances, grievance redressal and nomination. Fintechs need operational processes to respond to these rights. A privacy right is not meaningful if the organisation cannot identify where customer information is stored. For this reason, data mapping is essential. Customer information may exist in the main application, CRM, KYC platform, cloud storage, analytics system, customer support platform and vendor databases. A rights request should therefore trigger an organised workflow rather than a manual search of one database. Retention and Deletion of Financial Data Fintechs often retain information for legitimate regulatory reasons. KYC requirements, tax laws, accounting requirements, fraud prevention obligations, contractual disputes and financial sector regulations can require information to be retained for defined periods. The answer is not to delete all information immediately after the customer closes an account. Instead, fintechs should create a retention schedule based on purpose and applicable law. Once the mandatory retention period ends, information should be securely deleted or anonymised where appropriate. Retention policies should also apply to backups, archives and third party systems. Vendor and Processor Management Fintech businesses depend heavily on technology providers. Cloud platforms, KYC providers, credit information services, customer support platforms, payment processors, communication providers and analytics tools may process personal data. This creates a significant contractual risk. Contracts should address the purpose of processing, confidentiality, security measures, access controls, incident reporting, subcontractors, deletion, audit rights and assistance with customer rights. For regulated financial entities, RBI's Outsourcing of Information Technology Services Directions also require strong oversight of outsourced technology activities. Outsourcing cannot transfer regulatory responsibility away from the regulated entity. Data Security and Cybersecurity Privacy compliance and cybersecurity are closely connected, but they are not identical. Cybersecurity protects systems and information from unauthorised access, alteration, loss and disruption. Privacy governance also asks whether information should have been collected, why it is being processed and whether the processing is transparent and lawful. A fintech should implement appropriate technical and organisational measures such as access controls, encryption, authentication, monitoring, vulnerability management, secure development practices, logging, backups and incident response. Access should be limited according to role and business necessity. Sensitive financial information should not be available to employees simply because their account permissions technically allow access. Data Breach Response for FinTechs A fintech data breach can trigger several regulatory obligations at the same time. A security incident may involve customer information, payment data, KYC records or financial information. The organisation should therefore assess the incident against each applicable framework. CERT In directions require specified cyber incidents, including data breaches and data leaks, to be reported within six hours. Financial regulators may also impose separate reporting obligations depending on the regulated entity and incident. The DPDP Rules provide a separate framework for personal data breach notifications once the relevant provisions commence. Fintechs should therefore maintain a regulatory incident matrix rather than relying on a single breach notification procedure. Privacy and Artificial Intelligence in FinTech Artificial intelligence is increasingly used for fraud detection, credit assessment, customer service, personalisation and risk analysis. AI creates new privacy questions. A fintech should know what data is used to train or operate an AI system. It should assess whether information collected for one purpose is being reused for another. It should also understand which external AI provider receives customer information. Special care is needed when using real customer information for testing or model development. Where possible, organisations should consider anonymised or synthetic data for development and testing environments. AI governance should also address access, retention, vendor controls and human oversight where automated systems materially affect customers. Cross Border Data Transfers International cloud infrastructure and global technology vendors are common in fintech. A business should map every international data flow before assuming a transfer is permissible. The assessment should identify the information involved, destination, recipient, purpose, applicable Indian financial regulations and any foreign privacy laws. Payment data localisation requirements can be stricter than the general DPDP position. A fintech should therefore avoid adopting a generic global data transfer policy without checking the rules applicable to its specific financial activity. Privacy Compliance and Corporate Governance Privacy should sit within the organisation's broader governance framework. Boards and senior management should understand material privacy risks, regulatory exposure, significant vendor dependencies and major incidents. A clear internal ownership model should identify responsibility across legal, compliance, information security, technology, product, risk and customer service teams. For growing fintech businesses, data protection and privacy compliance should also be considered during product development rather than added after launch. Privacy reviews should become part of the product lifecycle. New data fields, integrations, analytics tools and vendors should pass an appropriate privacy and regulatory assessment before deployment. Practical Privacy Compliance Roadmap for FinTechs The first step is data discovery. The fintech should identify what personal data it collects and where it moves. The second step is purpose mapping. Each important data field should have a clear business and legal purpose. The third step is legal basis analysis. The organisation should determine whether processing relies on consent, a legitimate use under the DPDP Act or another applicable legal requirement. The fourth step is notice and consent redesign. Customer journeys should communicate privacy information clearly and record relevant consent events. The fifth step is vendor assessment. Contracts and technical controls should be reviewed together. The sixth step is security validation. Access controls, encryption, monitoring, testing and incident response should be assessed against applicable requirements. The final stage is continuous monitoring. Privacy compliance is not a one time project because fintech products, vendors and regulations change continuously. Common Privacy Compliance Mistakes in FinTech One common mistake is assuming a privacy policy means the business is compliant. The policy must reflect actual data practices. Another mistake is collecting excessive information because technology makes collection easy. Some fintechs also confuse RBI compliance with DPDP compliance. Meeting one regulatory requirement does not automatically satisfy the other. A further mistake is treating all customer data as having the same retention period. Another risk is weak vendor governance. A fintech may have strong internal security while allowing an external provider excessive access to customer information. Finally, organisations sometimes build consent mechanisms without creating a process for withdrawal, correction, erasure or grievance handling. Conclusion Fintech privacy compliance in India requires a coordinated approach. The DPDP Act provides the broad privacy framework, but fintech businesses must also consider the regulatory requirements applicable to their specific activities. A payment company, digital lender, Account Aggregator, wealthtech platform and insurance technology business can have materially different data obligations.  The most effective approach is to understand the data before attempting to control it. Fintechs should know what they collect, why they collect it, where it goes, who receives it, how long it is retained and what happens when a customer exercises a privacy right. The transition towards fuller DPDP implementation gives fintech businesses an opportunity to strengthen these systems now. Privacy should be incorporated into product design, contracts, vendor management, cybersecurity, customer communication and corporate governance. For organisations operating in regulated financial markets, corporate law and compliance should be considered alongside privacy governance because data obligations often intersect with outsourcing, regulatory reporting, contractual responsibility, board oversight and customer protection. A mature privacy programme therefore does more than satisfy a statutory requirement. It creates a structured framework for responsible data use across the fintech business. Frequently Asked Questions (FAQs) Q1. What is fintech privacy compliance? Fintech privacy compliance involves ensuring a financial technology business processes personal data lawfully, transparently and securely while meeting the DPDP Act and applicable financial sector regulations. Q2. Does the DPDP Act apply to fintech companies? Yes. Fintech companies processing digital personal data can fall within the DPDP framework. Their exact obligations depend on their role, processing activities, applicable provisions and any relevant exemptions. Q3. Is consent mandatory for every fintech activity? No. The DPDP Act recognises consent as one lawful basis and also provides for certain legitimate uses. Fintechs should assess the legal basis for each processing purpose rather than treating consent as universally mandatory. Q4. Does RBI regulation still apply after the DPDP Act? Yes. The DPDP Act does not replace RBI requirements. Regulated fintech businesses may need to comply with both frameworks simultaneously. Q5. Is all fintech data required to be stored in India? No single rule requires every category of fintech personal data to be stored in India. However, specific RBI frameworks impose localisation requirements for certain payment data and other financial activities. The applicable sectoral rules must therefore be checked. Q6. What privacy issues arise in digital lending? Digital lending raises issues around KYC information, device permissions, data minimisation, borrower consent, privacy notices, Lending Service Providers, recovery agents, data retention and third party sharing. Q7. Are fintech vendors considered Data Processors? A vendor may be a Data Processor when it processes personal data on behalf of a Data Fiduciary. The classification depends on the actual relationship and decision making responsibilities. Q8. What should a fintech do after a data breach? It should contain the incident, preserve evidence, investigate affected systems and determine every applicable notification and reporting obligation. CERT In and financial regulators may have separate reporting requirements. Q9. Does the DPDP Act regulate Account Aggregators? Account Aggregators are subject to the RBI framework governing their activities and also need to consider the DPDP framework where they process digital personal data. The RBI framework already contains detailed consent, security and information sharing requirements. Q10. How should fintechs prepare for DPDP compliance before May 2027? They should begin with data mapping, purpose analysis, legal basis assessment, privacy notice review, consent redesign, vendor due diligence, retention analysis, security testing and breach response planning. Q11. Can fintech companies use customer data for AI? Potentially, but the organisation should assess the purpose, legal basis, transparency, data minimisation, security and vendor arrangements involved. Data collected for one purpose should not automatically be repurposed for AI development without appropriate legal analysis. Q12. What are the consequences of DPDP non compliance? The DPDP Act provides a statutory penalty framework, with the highest penalty in the Schedule reaching ₹250 crore for certain failures. Actual exposure depends on the nature of the contravention and applicable provisions.

Healthcare organisations handle some of the most private information about individuals. Patient names, diagnoses, medical histories, prescriptions, laboratory reports, scans, insurance details, genetic information, contact details and payment records can all form part of a modern healthcare data environment. For hospitals and healthcare companies, data protection for healthcare is therefore not limited to publishing a privacy policy. It involves lawful data collection, appropriate access, secure storage, controlled sharing, retention, patient rights and effective incident response. India's privacy framework is also evolving. The Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 create an important statutory framework, while healthcare organisations must also consider medical confidentiality requirements, the Information Technology Act framework during the transition period, ABDM requirements and sector specific rules. Why Healthcare Data Requires Strong Protection? Healthcare data can reveal highly personal facts about an individual. A medical record may disclose a diagnosis, disability, pregnancy, mental health condition, reproductive health information or long term treatment history. Unauthorised disclosure can create financial, professional, social and personal consequences.The risk is not limited to hacking. Healthcare data may be exposed through an incorrectly configured hospital information system, excessive employee access, insecure email communication, lost devices, third party vendors, unauthorised downloads, weak passwords or inappropriate sharing between departments. Healthcare organisations also operate complex data ecosystems. A hospital may share information with laboratories, pharmacies, insurers, billing providers, cloud service providers, telemedicine platforms and technology vendors. Each additional connection creates another point requiring governance. India's Healthcare Data Protection Framework India does not have one single law dealing with every aspect of healthcare data. Instead, healthcare organisations operate within a combination of privacy, information technology, medical ethics and sector specific requirements. The Digital Personal Data Protection Act, 2023 is the central modern framework for digital personal data. It applies to processing of digital personal data within India and, in specified circumstances, processing outside India connected with offering goods or services to individuals in India. The Act uses the concepts of Data Principal, Data Fiduciary and Data Processor. A hospital or healthcare company will often be a Data Fiduciary because it determines why and how patient information is processed. A cloud provider, software company or outsourced service provider may act as a Data Processor where it processes personal data on behalf of the healthcare organisation. The official Digital Personal Data Protection Act, 2023 on India Code should be treated as a primary legal reference when reviewing the statutory framework. An Important Point About Health Data Under the DPDP Act A common misconception is that the DPDP Act creates a separate statutory category called sensitive personal data for health information. It does not. The DPDP Act adopts a broader concept of personal data rather than reproducing the older SPDI category. This does not mean healthcare information should be treated casually. Health information can create substantial risks for individuals, so hospitals should apply security, access and governance controls proportionate to the nature and potential impact of the processing. During the transition period, the position is more nuanced because Section 43A of the Information Technology Act and the associated SPDI Rules have not yet been displaced. Healthcare organisations should therefore avoid assuming the older framework has simply disappeared. A proper compliance review should consider which requirements currently apply and which future DPDP obligations are being prepared for. Consent Is Important, But It Is Not the Only Legal Basis Healthcare organisations often assume every activity involving patient information requires a fresh consent form. The DPDP framework is more nuanced. The Act provides for consent as one basis for processing. It also recognises certain legitimate uses. These include specific circumstances connected with medical emergencies and provision of healthcare services in situations contemplated by the legislation. This distinction is particularly important in clinical settings. A hospital should not design its entire patient care process around repeated consent requests where another lawful basis applies. At the same time, consent becomes important for activities such as optional data sharing or certain secondary uses where consent is the applicable basis. Consent should be specific, informed and capable of being withdrawn where the law permits withdrawal. Healthcare organisations should also distinguish treatment related processing from marketing. Using information collected during treatment to create promotional campaigns or targeted communications requires a separate legal and governance analysis. Privacy Notices for Hospitals and Healthcare Companies A privacy notice should explain how patient information is handled in language a patient can understand. A healthcare privacy notice should normally address the types of information collected, purposes of processing, relevant third parties, retention practices, rights, complaint mechanisms and contact details. The notice should reflect actual operations. A hospital should not state it only collects information required for treatment if its systems also process information for billing, insurance claims, appointment management, analytics, patient communications or research. The DPDP Rules, 2025 introduce more detailed requirements around notices. These requirements form part of the later implementation phase, giving organisations time to redesign their notices and consent architecture. The Ministry of Electronics and Information Technology's DPDP Rules 2025 resources provide the official reference point for the notified Rules and implementation material. Patient Rights and Medical Records Data protection becomes particularly challenging when patient rights intersect with medical record retention requirements. The DPDP Act provides rights relating to correction, completion, updating and erasure in specified circumstances. Erasure is not an absolute requirement to destroy every record immediately. Retention may still be necessary where required by law or for a specified lawful purpose. Healthcare organisations therefore need a documented retention schedule. It should distinguish clinical records from administrative information, billing records, insurance documents, research information, system logs and marketing records. The NMC's medical ethics framework also addresses maintenance and access to medical records. Hospitals should therefore reconcile privacy rights with professional and legal obligations relating to clinical documentation. This is an area where a simple “delete everything when requested” policy can create serious operational problems. Security Controls for Patient Information Healthcare organisations should adopt security controls based on the sensitivity and risk associated with their information systems. Access should follow a need to know principle. Doctors, nurses, technicians, billing teams, administrators and external vendors should not automatically receive access to the same information. Hospitals should consider encryption, access controls, authentication, privileged access management, audit logs, monitoring, backups, endpoint security and secure disposal. Systems should also record meaningful access events so organisations can investigate inappropriate viewing or disclosure of patient records.  The DPDP Rules, 2025 specify security safeguards including encryption or similar protections, access controls, monitoring and logs, backups, contractual safeguards for processors and appropriate technical and organisational measures. These detailed requirements are part of the later commencement phase. Security should not be treated as an IT responsibility alone. Clinical leadership, compliance, legal, information security, procurement and senior management all have a role. Healthcare Vendors and Data Processors Modern hospitals rarely operate their entire technology environment internally. Electronic medical record platforms, laboratory systems, radiology platforms, cloud infrastructure, appointment software, payment providers, telemedicine tools and analytics platforms may all process patient information. This makes vendor governance essential. Contracts should clearly establish the permitted processing activities, security expectations, confidentiality obligations, incident notification, subcontracting, access controls, retention, deletion and assistance with patient rights. A healthcare company should also maintain visibility over where vendors store information and which subcontractors may receive access. This is where data protection compliance for healthcare becomes an operational discipline rather than a document exercise. Procurement teams should involve privacy and legal teams before onboarding vendors capable of accessing patient information. ABDM and Digital Health Data Governance The Ayushman Bharat Digital Mission has introduced an important additional layer to India's digital health ecosystem. The ABDM Health Data Management Policy focuses on principles such as security and privacy by design, consent, interoperability and protection of personal health information. It covers participants in the digital health ecosystem, including health facilities, healthcare professionals, health information providers and health information users. The official ABDM Health Data Management Policy is therefore particularly relevant to organisations participating in the ABDM ecosystem. Healthcare organisations should identify whether they participate in ABDM enabled systems and then assess the specific technical, contractual and governance requirements applicable to their role. Telemedicine and Digital Healthcare Services Telemedicine creates additional privacy considerations because healthcare information may move through websites, mobile applications, video platforms, messaging systems and cloud infrastructure. Patient identity verification, secure communication, recording practices, access control and storage should be addressed before a telemedicine service is launched. Healthcare companies should also consider whether consultation recordings are necessary. If recordings are made, the organisation should identify the purpose, retention period, access permissions and applicable legal basis. The same principle applies to patient communication through messaging applications. Convenience should not replace appropriate confidentiality and security controls. Clinical Research and Secondary Use of Patient Data Research creates another major compliance challenge. A hospital may wish to use clinical records for medical research, analytics, artificial intelligence development or population health studies. The legal analysis can change when information collected for patient care is later used for another purpose. Healthcare organisations should identify the purpose of secondary processing, determine the applicable legal basis, evaluate whether identifiable information is necessary and consider anonymisation or other privacy preserving measures where appropriate.  Research governance should also consider ethics committee requirements, clinical trial rules and contractual restrictions. A useful distinction is between genuinely anonymised information and information which has merely had obvious identifiers removed. If an individual can still reasonably be identified using available information, the organisation should not automatically assume the information is outside the personal data framework. Children and Healthcare Data Children's information requires particular care. Hospitals, paediatric clinics, mental health providers and digital health platforms may process information belonging to minors. The DPDP Act contains additional obligations concerning children's personal data. Healthcare organisations should establish procedures for identifying the appropriate person responsible for consent and verification where required. At the same time, emergency treatment and other lawful healthcare situations must be considered within the broader statutory framework. The organisation's policy should therefore distinguish routine administrative processing from urgent clinical situations. Data Breach Response in Healthcare A healthcare data breach can involve more than stolen passwords. It may include unauthorised access to electronic medical records, disclosure of test reports, ransomware, compromised cloud accounts, lost devices or accidental disclosure through email.Healthcare organisations should maintain a documented incident response plan before a breach occurs. The plan should identify who investigates the incident, who decides whether regulatory reporting is required, who communicates with affected individuals, how evidence is preserved and how clinical operations continue during system disruption. The DPDP Rules provide for notification to affected Data Principals without delay and detailed notification to the Data Protection Board within 72 hours in the circumstances specified by Rule 7. However, these detailed DPDP Rules belong to the later commencement phase. Healthcare organisations must also consider the separate CERT In cyber incident reporting framework. Specified cyber incidents can trigger a six hour reporting requirement, meaning a healthcare organisation cannot build its incident response plan around a single future DPDP deadline. Cross Border Transfers of Healthcare Information Healthcare companies increasingly use international cloud providers, global technology platforms, overseas research partners and multinational insurance or pharmaceutical systems. Cross border transfers therefore require careful assessment. Section 16 of the DPDP Act provides a framework under which the Central Government may restrict transfers to specified countries or territories. Other Indian laws and sector specific requirements can also affect international transfers. Before transferring patient information overseas, organisations should map the data flow, identify the recipient, establish the purpose, review contractual protections and assess applicable Indian and foreign laws. Significant Data Fiduciary Considerations The DPDP Act allows the Central Government to designate certain organisations or classes of organisations as Significant Data Fiduciaries based on factors including the volume and sensitivity of personal data processed and risks to Data Principals. Large healthcare organisations may therefore need to monitor developments around Significant Data Fiduciary classification rather than assuming their size alone determines their status. Where an organisation is designated, additional requirements include a Data Protection Officer based in India, an independent data auditor, periodic Data Protection Impact Assessments and periodic audits. Healthcare groups should therefore consider these requirements when designing their governance framework. How Hospitals Can Prepare for DPDP Compliance? Preparation should begin with a complete data inventory. The organisation should identify what patient information it collects, why it collects it, where it is stored, who can access it, which vendors receive it and when it is deleted. The next stage is to review privacy notices and consent journeys. Paper admission forms, websites, mobile applications and telemedicine platforms should not provide contradictory information. Hospitals should then review contracts with technology providers and other processors. Security requirements should be measurable rather than limited to generic confidentiality clauses. Access permissions should also be reviewed regularly. Former employees, temporary staff, contractors and external consultants should not retain unnecessary access to patient systems. Finally, organisations should conduct incident response exercises. A breach involving a hospital's patient database can affect clinical operations as well as privacy compliance. The response plan should therefore involve both technology and healthcare leadership. Why Legal and Compliance Governance Matters? Healthcare privacy is ultimately a governance issue. Technology teams can implement encryption and access controls. Clinical teams understand patient confidentiality and treatment requirements. Compliance teams can monitor regulatory obligations. Procurement teams can manage vendors. Legal teams can assess contracts, statutory duties and emerging regulatory requirements. These functions need to operate together. Healthcare organisations can also benefit from structured corporate legal support when reviewing contracts, privacy notices, regulatory responsibilities, data sharing arrangements and incident response procedures. Legal review is particularly useful where several overlapping healthcare and technology requirements apply. Common Data Protection Mistakes in Healthcare One common mistake is treating a privacy policy as the complete compliance solution. A policy cannot compensate for excessive employee access, weak vendor contracts or poor security controls. Another mistake is assuming every healthcare processing activity requires consent. The legal basis should be assessed according to the specific purpose and applicable law. Some organisations also assume health data is automatically subject to one universal localisation rule. The position is more nuanced and can depend on the applicable healthcare ecosystem, contract, sectoral requirements and transfer framework. A further mistake is waiting until the DPDP provisions become fully operational before preparing. Hospitals need time to map legacy systems, redesign forms, update contracts and test their incident response processes. Conclusion Data protection in healthcare requires much more than cybersecurity. Hospitals and healthcare companies must manage patient information across the entire data lifecycle, from collection and clinical use to sharing, retention, research and eventual deletion. The DPDP Act provides the central modern framework, but healthcare organisations must also consider the continuing transition from the earlier IT Act and SPDI framework, medical confidentiality requirements, ABDM governance, healthcare specific rules and cyber incident obligations. The strongest approach is practical and risk based. Healthcare organisations should know what information they hold, why they hold it, who can access it, where it travels and how quickly they can respond when something goes wrong. With the DPDP framework moving towards fuller implementation, hospitals and healthcare companies have an important opportunity to strengthen privacy governance before regulatory deadlines become operational requirements. Frequently Asked Questions (FAQs) Q1. Is health data protected under Indian data protection law? Yes. Health information relating to an identifiable individual is personal data within the DPDP framework. The Act does not create a separate general category called sensitive personal data, although healthcare information can present significant privacy and security risks. Other laws and healthcare frameworks may also impose additional requirements. Q2. Does a hospital need patient consent for every use of health data? No. Consent is an important basis for processing, but the DPDP Act also recognises certain legitimate uses. Medical emergencies and specified healthcare situations require careful assessment under the applicable provisions. Q3. Are hospitals required to follow the DPDP Act? Hospitals processing digital personal data in India can fall within the DPDP framework. Their exact obligations depend on their activities, role as Data Fiduciary or Data Processor, applicable exemptions and the implementation status of individual provisions. Q4. Is health data considered sensitive personal data under the DPDP Act? The DPDP Act does not create a separate sensitive personal data category. However, health information requires strong safeguards because misuse or unauthorised disclosure can create significant harm. Q5. What should a hospital privacy policy contain? It should explain the categories of personal data collected, purposes of processing, relevant disclosures, rights, complaint mechanisms, retention practices and appropriate contact details. The final content should reflect the hospital's actual processing activities and applicable legal requirements. Q6. Can patients request deletion of their medical records? The DPDP Act provides a right to erasure in specified circumstances, but it does not mean every medical record must always be destroyed on request. Retention may be required by another law or may remain necessary for a lawful purpose. Q7. What happens if a hospital suffers a data breach? The organisation should immediately activate its incident response process, contain the incident, preserve evidence, assess the affected information and determine all applicable reporting obligations. DPDP requirements and CERT In requirements should be assessed separately because they operate under different frameworks. Q8. Do healthcare companies need a Data Protection Officer? Not every healthcare organisation automatically needs a statutory Data Protection Officer merely because it operates in healthcare. Additional DPO requirements arise where an organisation is designated as a Significant Data Fiduciary under the DPDP framework. Organisations may still choose to appoint privacy leadership as part of good governance. Q9. Does ABDM create additional privacy obligations? Organisations participating in the Ayushman Bharat Digital Mission ecosystem should review the applicable ABDM policies, technical requirements and consent framework alongside the general data protection laws. Q10. Does GDPR apply to Indian hospitals? GDPR may apply in specific circumstances, particularly where an organisation falls within its territorial scope. An Indian hospital should not assume GDPR applies merely because it uses European technology or has an international patient. The actual processing activities and territorial connection must be assessed. Q11. How should hospitals prepare for the DPDP Rules? Hospitals should begin with data mapping, privacy notice review, consent management, vendor due diligence, retention analysis, access controls, security testing and breach response planning. Preparing early allows legacy systems and contracts to be addressed before the later implementation deadlines.  

Online shopping has transformed how businesses collect and use customer information. An e commerce platform may process names, mobile numbers, email addresses, delivery details, account information, purchase histories, device information and behavioural data within a single customer journey. This makes e-commerce privacy compliance a significant legal and operational responsibility for online businesses in India. The challenge is not limited to having a privacy policy. E commerce businesses need to understand why information is collected, how consent works, which vendors receive the information, how customer preferences are managed, how long information is retained and what happens when a security incident occurs. India's Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 provide the central privacy framework. However, e commerce businesses also operate within consumer protection, cybersecurity, payment and sector specific requirements. Why Privacy Compliance Is More Complex for E Commerce Businesses? An ordinary website may collect limited information. An e commerce platform often operates a much broader data ecosystem. A customer may browse products, create an account, add items to a cart, make a payment, provide a delivery address, contact customer support, leave a review and later receive personalised offers. Each interaction can create additional personal data. The information may then move between the website, mobile application, CRM platform, payment gateway, logistics provider, marketing platform, analytics service and cloud infrastructure. Personalisation adds another layer. Businesses may analyse purchase history, browsing activity and customer preferences to recommend products or target advertising. These practices can create privacy concerns if customers do not understand how their information is being used. Recent Indian analysis of the e commerce sector identifies personalisation, targeted advertising, dynamic pricing, recommendation systems and behavioural analytics as important areas of privacy risk. Understanding the DPDP Framework for E Commerce The Digital Personal Data Protection Act, 2023 regulates processing of digital personal data in India within its statutory scope. An e commerce platform will generally act as a Data Fiduciary because it determines the purpose and means of processing customer information. The Act recognises consent as one ground for processing and also permits certain legitimate uses. This distinction is important for e commerce businesses. Not every activity should be treated as requiring the same form of consent. Processing necessary to fulfil an order can have a different legal basis from optional marketing or other secondary uses. The Act also establishes obligations relating to notice, consent, security, personal data breaches, retention, Data Principal rights and grievance redressal. The official India Code version of the Act provides the complete statutory framework. Businesses should use the legislation itself rather than relying solely on generic online compliance checklists. The First Challenge Is Knowing What Data the Business Collects Many privacy problems begin with incomplete data mapping. An e commerce business may know what information its checkout page collects but have limited visibility over information generated elsewhere. For example, analytics tools may collect device identifiers. Marketing platforms may create customer profiles. Loyalty programmes may record purchasing patterns. Customer support systems may retain conversations. Delivery providers may receive addresses and contact numbers. A business should therefore map the complete customer data journey. The exercise should identify what information is collected, the purpose of collection, the system involved, the people or organisations receiving it, the processing location and the applicable retention period. Data mapping also helps identify unnecessary collection. If a checkout form asks for information which is not required for the transaction or another defined purpose, the business should question why it is being collected. Consent and Checkout Design Consent is one of the most important challenges for e commerce businesses. The DPDP Act provides specific requirements for consent. Consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. It should also be limited to personal data necessary for the specified purpose. This creates practical questions for online stores.  Should marketing consent be bundled with account creation? Can a customer be required to accept promotional communications to complete an order? Is a preselected marketing option appropriate? Can consent be withdrawn easily? Businesses should separate necessary transaction processing from optional marketing preferences wherever the legal basis differs. The Act itself provides an e commerce illustration involving an online shopping service, demonstrating the distinction between processing necessary to fulfil an order and the consequences of withdrawing consent. Good privacy design should therefore begin at checkout rather than being added after the purchase journey has already been built. Privacy Notices Must Match Actual Data Practices An e commerce privacy notice should reflect the platform's real processing activities. A generic statement saying “we collect information to improve our services” may provide little practical understanding. Customers should be able to understand what categories of personal data are collected and why. The notified DPDP Rules, 2025 prescribe more detailed requirements for notices, including clear and plain language, an itemised description of personal data and the purpose for processing. Rule 3 is part of the eighteen month commencement phase under the Rules. Businesses should therefore review privacy notices across websites, mobile applications, checkout pages, loyalty programmes and other customer touchpoints. The notice should also remain consistent with actual technology configurations. A privacy notice is not effective if the website uses tracking tools or shares information with vendors not reflected in the organisation's documented processing practices. Cookies, Tracking and Advertising Technologies E commerce businesses often use cookies, pixels, software development kits and advertising technologies to understand customer behaviour. These tools may support analytics, advertising, fraud prevention and personalisation. The privacy question depends on what information is collected, how it is linked to an individual and why it is used. Businesses should understand which tracking technologies operate on their websites and applications. They should also know which third parties receive the resulting information. Marketing consent should not be treated as an afterthought. A customer agreeing to receive promotional messages does not automatically mean every advertising technology may collect and analyse information for every purpose. The consent experience should correspond with the actual processing. Personalisation and Customer Profiling Personalisation can improve an online shopping experience. It can also create privacy concerns when businesses build detailed profiles from customer behaviour. A platform may analyse products viewed, searches conducted, previous purchases, location information or interaction with marketing communications. Businesses should define the purpose of such profiling and assess whether the information collected is necessary for it. The customer should also receive appropriate transparency where the applicable legal framework requires it. Recent Indian legal analysis specifically identifies targeted advertising, behavioural analytics, personalisation and dynamic pricing as areas requiring careful privacy and consumer law consideration. This is particularly important when automated systems influence product recommendations or other customer experiences. Dark Patterns and Privacy Choices Privacy compliance is also connected with interface design. A dark pattern can influence a user's decision through confusing, misleading or manipulative design. Examples may include making acceptance easier to find than rejection or presenting privacy choices in a way which discourages meaningful choice. The Central Consumer Protection Authority has issued Guidelines for Prevention and Regulation of Dark Patterns, 2023. The Department of Consumer Affairs lists these guidelines alongside the Consumer Protection framework. E commerce businesses should therefore assess privacy interfaces alongside consumer protection requirements. The legal question is not simply whether a button exists. The overall design of the customer journey matters. Customer Rights and Request Management The DPDP Act provides Data Principals with rights including access to information about personal data, correction and erasure, grievance redressal and nomination. For e commerce businesses, responding to these requests can be complicated. Customer information may exist in an account database, CRM system, payment platform, customer support tool and marketing system. A request for correction or erasure may therefore require action across several systems. The business needs a process for authenticating requests, locating relevant information, assessing the request and coordinating with Data Processors. Technology can assist, but governance remains important. Automated deletion without understanding legal retention requirements can also create problems. Retention and Deletion of E Commerce Data Online platforms often retain information because storage is inexpensive. This does not mean indefinite retention is appropriate. The DPDP Act provides for erasure when retention is no longer necessary for the specified purpose, subject to applicable legal requirements. The 2025 Rules introduce a specific retention framework for certain large e commerce entities. Rule 8 and the Third Schedule address an e commerce entity with not less than two crore registered users in India. For specified purposes, the framework provides a three year period calculated from the relevant last interaction or commencement of the Rules, whichever is later, subject to the exceptions in the Rules. Businesses should therefore avoid applying the large platform retention rule to every e commerce business. Its scope depends on the statutory conditions. For smaller businesses, retention should still be assessed according to the applicable purpose, legal requirements and broader data governance framework. Payment Data and Third Party Providers Payments create another major compliance challenge. E commerce platforms may integrate payment gateways, banks, wallet providers and other payment service providers. A business should understand what payment information it actually receives and what information remains with the payment provider. The organisation should avoid collecting payment information unnecessarily when the transaction can be completed through a specialised provider. Vendor contracts should establish appropriate responsibilities concerning security, incident management, access and deletion. Payment processing can also bring sector specific regulatory requirements into the analysis. An e commerce company should therefore avoid assuming the DPDP Act is the only relevant framework. Logistics and Delivery Partners Privacy obligations do not stop when an order leaves the website. Delivery partners may receive names, addresses, telephone numbers, order references and other information needed to complete delivery. The e commerce business should identify which information is shared and why. Vendor agreements should define permitted processing, security expectations, incident reporting, retention and deletion. The business should also assess whether delivery providers use information for additional purposes beyond fulfilment. This becomes particularly important when several logistics providers operate across different regions. Customer Support and Call Centre Data Customer support systems can contain extensive personal information. Support agents may see order history, addresses, contact details, complaints and payment related information. Call recordings may create additional data protection considerations. Businesses should establish access controls and define retention periods. Employees should only access information required for their role. Training is also essential. A customer support agent forwarding an account screenshot through an unsecured channel can create a privacy incident even when the company's main systems are well protected. Data Breach Response E commerce platforms are attractive targets because they can hold substantial volumes of customer information. A breach may involve account credentials, contact information, transaction records or other personal data. Businesses should maintain a documented incident response process covering detection, containment, investigation, evidence preservation, legal assessment and communication. CERT In also requires specified cyber incidents to be reported within six hours of noticing the incident or being informed about it. Businesses should therefore assess CERT In obligations separately from the DPDP breach notification framework. The DPDP Rules provide their own process for personal data breach notification once the relevant provisions commence. Rule 7 provides for notification to affected Data Principals without delay and detailed information to the Data Protection Board within 72 hours, subject to the Rule. E commerce businesses should therefore prepare for potentially overlapping regulatory obligations. Vendor and Marketplace Data Sharing An e commerce platform rarely operates alone. Its technology ecosystem may include payment providers, delivery partners, cloud services, analytics platforms, advertising networks, customer support providers and fraud prevention services. Each relationship should be assessed. The business should know whether the vendor acts as a Data Processor or has an independent purpose for processing information. Contracts should reflect the relationship and include appropriate privacy and security controls. Recent industry guidance specifically identifies third party transfers and processor contracts as important compliance considerations for e commerce businesses. This is an area where data privacy compliance services can assist businesses with data mapping, vendor assessments, privacy notices, consent processes and compliance reviews. Children Using E Commerce Platforms E commerce businesses should consider whether their services are likely to be used by children. Section 9 of the DPDP Act contains specific obligations concerning children's personal data. The framework requires verifiable parental consent in applicable cases and restricts certain forms of processing involving children. Businesses selling toys, educational products, games, entertainment services or other child focused products should examine their customer journey carefully. Age related controls should not be treated as a purely technical issue. Legal, product and engineering teams should work together. Cross Border Data Processing International e commerce creates additional complexity. A platform may be hosted by an overseas cloud provider. Customer support may operate from another country. Analytics and advertising tools may process information outside India. Section 16 of the DPDP Act provides a framework for processing personal data outside India and permits the Central Government to restrict transfers to specified countries or territories through notification. Other laws can impose additional requirements. Businesses should therefore map international data flows rather than simply stating in a privacy policy that information “may be transferred internationally”. The Current DPDP Implementation Timeline Businesses should be careful when describing the DPDP Act as fully operational. The Rules were notified on 13 November 2025. Rules 1, 2 and 17 to 21 came into force on publication. Rule 4 has a one year commencement period. Rules 3, 5 to 16, 22 and 23 have an eighteen month commencement period. The Act itself also has phased commencement. This means businesses should distinguish between provisions currently in force and provisions requiring implementation preparation. For e commerce businesses, this distinction is particularly important because changing checkout interfaces, vendor contracts, retention systems and customer rights workflows can take months. Preparation should therefore begin before the relevant statutory dates. How E Commerce Businesses Can Build Privacy Into Operations Privacy compliance works best when it is integrated into product design. When a new feature is developed, the business should ask what personal data it requires, why the information is needed, who receives it and how long it will remain available. Marketing teams should coordinate with privacy and legal teams before launching new tracking or personalisation initiatives. Procurement teams should identify vendors processing personal data before contracts are signed. Engineering teams should build appropriate access controls and deletion mechanisms into systems. Customer service teams should know how to handle privacy requests. This approach makes privacy a business process rather than a document stored on a website. E Commerce Privacy Compliance Checklist A practical review should examine the complete customer lifecycle. The organisation should assess its data inventory, privacy notices, consent mechanisms, marketing practices, tracking technologies, profiling, customer rights processes, retention schedules, vendor contracts, security safeguards, breach response procedures and international data flows. It should also review its consumer protection obligations, particularly where privacy choices intersect with interface design, advertising or other digital practices. For larger businesses, regular privacy audits can provide management with evidence of whether documented policies match actual processing. Conclusion Privacy compliance for e commerce businesses is no longer limited to publishing a privacy policy. Online retailers and marketplaces operate complex data ecosystems involving checkout systems, customer accounts, analytics, advertising, payment providers, logistics companies, cloud platforms and customer support tools. Each stage can create a separate privacy consideration. The DPDP Act and the notified 2025 Rules provide an important new framework for managing these activities in India. The phased commencement gives businesses time to review their practices, but it should not become a reason to postpone preparation. A strong privacy programme begins with data mapping. It then connects appropriate processing grounds with transparent notices, meaningful consent where required, security controls, vendor governance, retention practices and effective customer rights processes. Businesses should also consider consumer protection requirements. Privacy choices should not be separated from the design of the customer journey. Dark patterns, misleading interfaces and unclear marketing choices can create risks beyond data protection law. For growing e commerce businesses, privacy should become part of product development, marketing, procurement, technology and customer service. This approach creates a more sustainable compliance framework and gives businesses a clearer understanding of how customer information moves through their operations. Where e commerce platforms operate across multiple jurisdictions, use extensive profiling or manage large volumes of personal data, specialist legal review can help align corporate legal compliance with the organisation's actual technology, commercial and customer data practices. Legal note: This article provides general information on Indian data protection and e commerce law. It is not legal advice for a specific business or processing activity. The application of the DPDP Act and Rules depends on the organisation, processing activity, applicable commencement provisions and other relevant laws and regulations.   Frequently Asked Questions (FAQs) Q1. What is e commerce privacy compliance? E commerce privacy compliance means managing customer and other personal data in accordance with applicable privacy, cybersecurity, consumer protection and sector specific requirements. It covers collection, use, sharing, storage, security, retention and deletion. Q2. Does the DPDP Act apply to online shopping websites? Yes, where the processing falls within the Act's scope. An e commerce platform generally processes digital personal data and may act as a Data Fiduciary. Q3. Does an e commerce website need customer consent for every activity? No. The DPDP Act recognises consent as one ground for processing and also provides for certain legitimate uses. Businesses should identify the appropriate basis for each processing activity. Q4. Is marketing consent different from order processing? Yes. Order fulfilment and promotional communications can have different purposes and legal bases. Businesses should avoid assuming consent for one purpose automatically covers another. Q5. Do e commerce companies need a privacy policy? Businesses processing personal data should provide appropriate transparency under the applicable legal framework. The DPDP Rules, 2025 prescribe detailed notice requirements for the relevant commencement phase. Q6. Can an e commerce business use customer purchase history for personalised advertising? It depends on the purpose, applicable legal basis, notice, consent requirements and other applicable laws. Businesses should distinguish between using purchase history to fulfil an order and using it for separate marketing or profiling purposes. Q7. How long can an e commerce company keep customer data? There is no single retention period applicable to every e commerce business. Retention depends on purpose, applicable law and the relevant DPDP provisions. The 2025 Rules introduce a specific three year framework for certain large e commerce entities meeting the stated user threshold. Q8. What happens if an e commerce company suffers a data breach? The business should activate its incident response process, contain the incident, preserve evidence and assess applicable notification requirements. CERT In obligations and DPDP breach notification requirements should be considered separately where applicable. Q9. Are payment gateways responsible for customer data protection? Payment providers have their own regulatory and contractual responsibilities. The e commerce business should also understand what personal data it shares with the provider and establish suitable contractual and security controls. Q10. Do delivery partners need data protection contracts? Where a delivery provider processes personal data on behalf of an e commerce business, the relationship should be appropriately documented and governed. The exact contractual structure depends on the parties' roles and processing activities. Q11. Are cookies covered by Indian data protection law? Cookies themselves are technologies rather than a separate statutory category under the DPDP Act. The relevant question is whether their use involves processing of personal data and which legal requirements apply to the resulting processing. Businesses should also consider applicable consumer, advertising and technology requirements. Q12. What are dark patterns in e commerce? Dark patterns are interface or design practices which can mislead, manipulate or unfairly influence users. India's Central Consumer Protection Authority has issued Guidelines for Prevention and Regulation of Dark Patterns, 2023, making interface design relevant to wider e commerce compliance. Q13. Do small online stores need to prepare for DPDP compliance? Yes. The organisation's size does not by itself determine whether the DPDP Act applies. Small businesses should assess their actual processing activities and prepare proportionate privacy controls.

Businesses increasingly rely on external service providers to store, analyse and manage personal information. Cloud platforms, payroll providers, SaaS applications, marketing agencies, customer support providers and IT vendors may all process personal data on behalf of a business. This makes data processing agreements an important part of modern privacy governance. A well drafted DPA defines how a service provider may handle personal data and establishes responsibilities around security, confidentiality, incidents, sub processors and deletion. In India, the Digital Personal Data Protection Act, 2023 introduces a specific framework for relationships between Data Fiduciaries and Data Processors. Section 8(2) provides for engagement of a Data Processor under a valid contract. However, businesses should also understand the phased commencement of the Act before describing every processor obligation as currently enforceable. (India Code) What Is a Data Processing Agreement? A Data Processing Agreement, commonly called a DPA, is a contractual arrangement governing the processing of personal data by one party on behalf of another. Under India's DPDP framework, the organisation determining the purpose and means of processing is generally the Data Fiduciary. A Data Processor is a person processing personal data on behalf of the Data Fiduciary. The relationship is therefore based on the actual processing activity rather than simply the title of the commercial contract. For example, an organisation may appoint a payroll company to process employee information, a cloud provider to host customer records or a customer service provider to manage support requests. Where the third party processes personal data on the organisation's behalf, the processing relationship should be clearly documented. A DPA may operate as a standalone agreement, a schedule to a master services agreement or an addendum to an existing commercial contract. The important point is not the document's title. It is whether the agreement clearly governs the personal data processing relationship. Why Data Processing Agreements Matter for Businesses Personal data can move through several organisations before a service reaches an individual. A customer may submit information through a company's website. The information may then enter a CRM platform, pass to a cloud hosting provider, be accessed by a customer support vendor and be analysed through another technology service. Without appropriate contractual controls, the business may have limited visibility over how those providers use the information. A DPA creates a contractual framework for controlling this processing. It can establish permitted purposes, security requirements, access restrictions, incident notification procedures, sub processor controls and deletion requirements. It also creates clearer accountability between the parties. This is particularly important because India's DPDP framework places significant responsibility on the Data Fiduciary for processing carried out on its behalf. A contract can allocate responsibilities and financial risk between the parties, but it should not be assumed to eliminate the Data Fiduciary's statutory responsibilities. Data Fiduciary and Data Processor: Understanding the Difference Correctly identifying the parties is the starting point for preparing a DPA. A Data Fiduciary determines the purpose and means of processing personal data. A Data Processor processes personal data on behalf of the Data Fiduciary. Consider a company using a cloud platform to store customer records. If the cloud provider processes the information only to provide the contracted hosting service, it may operate as a Data Processor. However, the same vendor could act as a Data Fiduciary for separate processing activities where it determines its own purposes. The contractual label should therefore reflect the actual relationship. Simply calling a vendor a “processor” does not resolve the legal analysis. Indian guidance increasingly emphasises this distinction because a single organisation can potentially have different roles for different processing activities. What Does the DPDP Act Say About Processor Contracts? Section 8 of the Digital Personal Data Protection Act contains the principal provisions concerning Data Fiduciaries and Data Processors. Section 8(2) provides that a Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for activities related to offering goods or services to Data Principals only under a valid contract. Section 8(1) also establishes the continuing responsibility of the Data Fiduciary for compliance with the Act in relation to processing undertaken on its behalf. These provisions are important because they make the vendor relationship part of the organisation's privacy governance framework. However, businesses should note the commencement position. The Government's commencement notification places Section 8 within the eighteen month commencement group following the November 2025 notification. The corresponding operational Rules are also subject to phased commencement. This distinction matters for accurate legal content and internal compliance planning. What Should a Data Processing Agreement Include? A DPA should be tailored to the actual service and data involved. A generic document may provide a useful starting point, but it should not replace a proper assessment of the processing relationship. Scope and purpose of processing The agreement should explain why the Processor receives personal data and what services it is authorised to perform. The Processor should not receive unrestricted permission to use personal information for its own purposes unless the parties have separately established the appropriate legal relationship and basis for such processing. A clear purpose clause reduces uncertainty. It also makes later compliance reviews easier because the business can compare actual processing against the contractual scope. Categories of personal data The DPA should identify the types of personal data involved. This may include names, contact information, account details, employment records, financial information, location information or other categories relevant to the service. The more sensitive or consequential the processing, the greater the need for precise contractual controls.  Categories of Data Principals  The agreement should also identify whose information is being processed. The Data Principals could be customers, employees, job applicants, suppliers, students, patients or website users. This information helps both parties understand the nature of the processing and the potential risks involved. Duration of processing The agreement should specify how long the Processor may process the information. The processing period should normally correspond with the service relationship and any legitimate retention period. A DPA should also explain what happens after the commercial contract ends. Security Obligations Are Central to a DPA A DPA should establish appropriate security obligations rather than relying on a general confidentiality clause. The DPDP Rules, 2025 identify security measures including encryption, masking or obfuscation, access controls, logging and monitoring, backups, retention of relevant logs and contractual provisions concerning security safeguards between Data Fiduciaries and Data Processors. The contractual standard should reflect the nature of the service. A vendor processing payroll information may require stronger access restrictions than a supplier receiving only limited business contact information. The agreement can also require the Processor to maintain appropriate technical and organisational measures, restrict privileged access, train authorised personnel and notify the Data Fiduciary of material security incidents. The objective is not to copy a technical checklist into every contract. It is to establish controls appropriate to the actual risk. Confidentiality and Personnel Access A Processor may have employees, contractors or other authorised personnel accessing personal data. The DPA should therefore establish confidentiality obligations for people authorised to process the information. Access should be limited to individuals who require it for their role. Access should also be removed when personnel change responsibilities or leave the organisation. Businesses should periodically assess whether vendor access remains necessary. A contractual confidentiality promise becomes much stronger when supported by practical access controls. Data Breach and Incident Notification A DPA should establish a clear incident notification process. The Processor should notify the Data Fiduciary promptly after becoming aware of a relevant personal data breach. The contract can also specify the information the Processor must provide, such as the nature of the incident, affected systems, categories of information, likely impact and containment measures. The purpose is to give the Data Fiduciary sufficient time to assess its own regulatory responsibilities. This becomes particularly important under the notified DPDP Rules. Rule 7 provides for notification of affected Data Principals without delay and establishes a process for notifying the Data Protection Board, including detailed information within 72 hours, subject to the Rule's requirements. The Processor's contractual notification period should therefore be short enough to support the Data Fiduciary's response. Sub Processors Need Contractual Control Many technology vendors rely on other service providers. A SaaS provider may use a cloud infrastructure company. A payroll platform may rely on another hosting provider. A customer support provider may use external communication systems. These entities can become sub processors within the wider processing chain. The DPA should therefore establish how sub processors may be appointed. Depending on the risk and commercial arrangement, the Data Fiduciary may require prior approval, advance notice or another appropriate control mechanism. The Processor should also remain responsible for ensuring relevant obligations flow through the processing chain where appropriate. Without sub processor visibility, a business may not know where its personal data ultimately resides. Assistance With Data Principal Requests Individuals may have rights under applicable data protection law. A Processor may hold information needed to respond to those requests even though the Data Fiduciary is responsible for managing the relationship with the individual. The DPA should therefore require reasonable assistance. For example, if an individual requests correction or erasure, the Processor may need to locate relevant information and implement the instruction. The agreement should establish practical procedures for such requests, including communication channels and reasonable response times. This helps prevent a situation where a business receives a request but cannot act because its vendor has no internal process for responding. Retention, Return and Deletion A DPA should address what happens when processing ends. The Processor may be required to return or delete personal data, subject to applicable legal retention requirements. Deletion should be considered across active systems, backups and other storage environments where relevant. The contract should also clarify whether the Processor must provide evidence of deletion. This becomes particularly important when a business changes vendors. The outgoing supplier should not retain personal information indefinitely simply because the commercial agreement has ended. Audit and Compliance Evidence Businesses need some method of verifying whether their Processors comply with contractual requirements. The DPA may establish audit rights, security assessments, independent certifications, compliance reports or other evidence mechanisms. The appropriate approach depends on the risk. A company processing large volumes of financial or health information may require stronger assurance than a low risk supplier. Unrestricted audit rights can also create practical problems for both parties. A well structured DPA can establish reasonable notice, scope, confidentiality and frequency rules while preserving meaningful oversight. Modern enterprise DPAs commonly address cooperation, assessments and audit evidence as part of the contractual framework. Cross Border Data Processing A vendor agreement should make international processing visible. A company may be based in India while its cloud provider stores information in another country. Support personnel may also access systems from overseas locations. Section 16 of the DPDP Act addresses processing outside India and permits the Central Government to restrict transfers to specified countries or territories through notification. Other sector specific requirements may apply independently. Businesses should therefore understand where vendors host, access and transfer personal data. The DPA should contain suitable provisions for international processing where required by the applicable legal framework. Businesses subject to the GDPR or other overseas privacy regimes may also need additional transfer mechanisms. A DPA designed for Indian law should not automatically be assumed to satisfy every foreign privacy requirement. Liability, Indemnity and Insurance A DPA is also a commercial risk allocation document. Businesses should examine how liability for privacy breaches, security incidents and contractual failures interacts with the main services agreement. A vendor may accept extensive privacy obligations but still have a low overall liability cap under its commercial contract. The parties should therefore consider the relationship between privacy obligations, indemnities, exclusions, insurance and liability limits. There is no universal clause suitable for every transaction. The appropriate allocation depends on the volume and sensitivity of information, the vendor's role, the business impact of a breach and the parties' negotiating position. Data Processing Agreements and GDPR Many Indian businesses work with international customers or vendors. As a result, their DPAs may need to address more than Indian law. Under Article 28 of the GDPR, controller and processor relationships must be governed by a contract containing specified requirements concerning processing instructions, confidentiality, security, sub processors, assistance and audits. The GDPR and DPDP Act use different terminology and structures. Indian contracts should therefore avoid simply copying a GDPR DPA without checking whether its provisions accurately reflect Indian law. Where both frameworks apply, businesses should map the requirements rather than assume one document automatically satisfies both. Why Generic DPA Templates Can Create Problems? Templates can save time, but a DPA should reflect the actual processing relationship. A template designed for a cloud provider may not be appropriate for a payroll company. A template created for GDPR compliance may contain provisions irrelevant to an Indian only processing arrangement. The agreement should match the real data flow. If the vendor does not access certain categories of data, those categories should not be included merely because they appear in a standard form. If a vendor uses sub processors, the agreement should address them. If international processing occurs, the relevant provisions should be included. Accuracy is more valuable than unnecessary contractual length. When Should Businesses Sign a DPA? Ideally, the processing relationship should be assessed before the vendor receives personal data. Procurement teams should identify whether the supplier will process personal information during vendor selection. Legal and privacy teams can then determine whether a DPA or equivalent contractual provisions are required. The agreement should be finalised before operational access begins wherever the applicable legal framework requires contractual controls. Existing vendor arrangements should also be reviewed, particularly where they involve significant volumes of personal data or sensitive processing. How Businesses Can Manage DPAs at Scale? Large organisations may have hundreds of vendors. Managing each DPA manually can create gaps. A practical governance programme should maintain a central vendor register showing which suppliers process personal data, what information they receive, where processing occurs and when the agreement expires. Risk based classification can help prioritise reviews. High risk vendors can receive deeper security assessments and more detailed contractual review. Lower risk vendors can follow a proportionate process. Renewal workflows should also trigger privacy review. A contract should not automatically renew for several years while the underlying processing arrangement changes. This is where specialist data protection services for businesses can support contract reviews, vendor assessments and wider privacy governance where internal resources are limited. What Businesses Should Review in Existing DPAs? Existing agreements should be compared against current processing activities. The organisation should ask whether the vendor's role is still correctly classified, whether the permitted processing remains accurate, whether sub processors have changed, whether data is stored in new locations and whether security commitments match the vendor's current practices. Businesses should also review breach notification periods. A DPA negotiated several years ago may contain a notification period unsuitable for current regulatory expectations. The same applies to deletion clauses. The contract should reflect how the vendor actually handles backups, archives and account termination. The Indian DPDP Transition and DPA Preparation The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025. Rule 1 provides for phased commencement. Rule 4 takes effect one year after publication, while Rules 3, 5 to 16, 22 and 23 take effect 18 months after publication. The Act's substantive provisions concerning Data Fiduciary obligations are similarly subject to the commencement notification. This means businesses should distinguish between preparation and current enforceability. The absence of full commencement should not be treated as a reason to ignore vendor contracts. Reviewing hundreds of commercial agreements, renegotiating supplier terms and changing vendor onboarding processes can take considerable time. Businesses can use the transition period to establish a consistent DPA framework and align contracts with actual data flows. Conclusion Data Processing Agreements have become an important part of responsible vendor governance. They provide a contractual structure for controlling how third parties handle personal data and help businesses translate privacy requirements into practical obligations. A strong DPA should do more than repeat general statements about compliance. It should reflect the actual processing relationship. It should identify the data involved, define permitted purposes, establish security requirements, control sub processors, provide a workable incident response process and address retention and deletion. For Indian businesses, the DPDP Act and the notified Rules make this area particularly important as the country moves towards full implementation of its new privacy framework. The phased commencement also gives businesses time to review existing vendor arrangements and build stronger contractual controls. A carefully prepared DPA cannot eliminate every privacy risk. It can, however, make responsibilities clearer, improve vendor accountability and provide an important contractual foundation for wider privacy governance. Businesses should also seek advice from experienced commercial lawyers where a DPA involves complex liability provisions, international processing, regulated data, substantial vendor dependencies or overlapping Indian and foreign privacy requirements. Frequently Asked Questions (FAQs) Q1. What is a Data Processing Agreement? A Data Processing Agreement is a contract governing the processing of personal data by a Data Processor on behalf of a Data Fiduciary. It defines permitted processing and establishes contractual responsibilities concerning security, incidents, confidentiality and other privacy matters. Q2. Is a Data Processing Agreement mandatory in India? Section 8(2) of the DPDP Act provides that a Data Fiduciary may engage a Data Processor for covered activities only under a valid contract. However, Section 8 is subject to the phased commencement notification. Businesses should prepare processor contracts before the relevant provision becomes operational. Q3. Who signs a Data Processing Agreement? The agreement is generally entered into between the organisation acting as Data Fiduciary and the organisation acting as Data Processor. The exact contractual structure depends on the commercial relationship. Q4. What should a DPA contain? A DPA should normally address the purpose and duration of processing, types of personal data, categories of Data Principals, processing instructions, confidentiality, security, breach notification, sub processors, rights assistance, retention, deletion, audits and relevant international processing. Q5. Is a DPA the same as a privacy policy? No. A privacy policy or privacy notice explains how an organisation processes personal data and communicates information to individuals. A DPA governs a contractual relationship between a Data Fiduciary and Data Processor. Q6.Does every vendor need a DPA? Not necessarily. The relevant question is whether the vendor processes personal data on behalf of the organisation. A supplier with no access to personal data may not require a processor agreement. Some vendors may also act as independent Data Fiduciaries for certain activities. Q7. Can a DPA transfer all legal responsibility to the vendor? No. A contract can allocate responsibilities, costs and remedies between the parties, but it does not automatically remove statutory responsibility from the Data Fiduciary. The DPDP framework places important obligations on the Data Fiduciary for processing undertaken on its behalf. Q8. Should a DPA include breach notification timelines? Yes. A clear contractual notification mechanism is important because the Data Fiduciary may have its own regulatory notification duties. The Processor should notify the Data Fiduciary quickly enough to allow appropriate assessment and response. Q9. What are sub processors? Sub processors are third parties engaged by a Data Processor to perform part of the processing service. A DPA should establish appropriate controls over their appointment and processing activities. Q10. Do DPAs need to address data deletion? Yes. The agreement should establish what happens to personal data when the service ends, including return, deletion and any legally required retention. Q11. Are DPAs required under GDPR? Where Article 28 of the GDPR applies to a controller and processor relationship, the processing must be governed by a contract containing specified requirements. Q12. Can one company be both a Data Fiduciary and a Data Processor? Yes. An organisation may act as a Data Fiduciary for processing carried out for its own purposes and as a Data Processor when it processes another organisation's data on that organisation's behalf. The role should be assessed for each processing activity.