Artificial intelligence and machine learning systems depend heavily on data. Businesses use AI to analyse customers, automate decisions, personalise services, detect fraud, support employees and generate content. As these systems become more sophisticated, the relationship between technology and privacy becomes increasingly important. AI and data protection laws therefore need to be considered together whenever an AI system collects, analyses, stores or generates information relating to identifiable individuals. In India, businesses must consider the Digital Personal Data Protection Act, 2023 alongside information technology laws, contractual obligations, cybersecurity requirements, intellectual property rules and sector specific regulations. The legal question is no longer simply whether a company can use AI. It is whether the company can use the relevant data for the specific AI purpose in a lawful, transparent and responsible manner. What Are AI and Data Protection Laws? AI and data protection laws are not necessarily a single category of legislation. They describe the overlapping legal requirements which apply when artificial intelligence systems process personal data. An AI model may use information during training, testing, fine tuning, deployment and monitoring. Personal data may also appear in prompts, uploaded documents, model outputs, application logs or analytics systems. Each processing activity can raise different legal questions. The Digital Personal Data Protection Act provides India's principal modern framework for digital personal data. It does not contain a separate chapter dedicated exclusively to artificial intelligence. Instead, its general rules apply where AI related activities involve personal data within the scope of the legislation. This makes the first compliance question straightforward: a business should determine whether its AI system processes personal data and then identify the purpose, legal basis, participants and data flows involved. Does India Have a Specific AI Data Protection Law? India does not currently have one comprehensive statute regulating every aspect of artificial intelligence. AI governance is developing through existing laws, regulatory frameworks, government initiatives and sector specific requirements. The DPDP Act is particularly important because AI systems frequently rely on personal data for training, testing, profiling and deployment. The Information Technology Act and associated IT Rules can also become relevant depending on the AI application. Consumer protection law, intellectual property law, contract law and sector specific rules may create additional obligations. The legal position can therefore differ considerably between an AI recruitment platform, healthcare model, financial scoring system, customer service chatbot and general purpose AI application. Businesses should avoid treating the absence of a standalone AI statute as an absence of regulation. The applicable obligations may already exist across several legal frameworks. How the DPDP Act Applies to AI Systems? The DPDP Act regulates the processing of digital personal data. Processing is broad enough to cover automated operations involving data. As a result, an AI system can fall within the framework when it processes information capable of identifying an individual. For example, a company using employee records to train an internal AI assistant may be processing personal data. A financial institution using customer information for fraud detection may also be processing personal data. A healthcare company analysing patient records through machine learning creates another example. The relevant legal analysis depends on the actual data and purpose. An AI model trained entirely on information which is not personal data raises different questions from a model trained on identifiable customer records. AI Training Data and Legal Basis Training data is one of the most important privacy issues in AI development. Businesses often assume they can use any dataset available to them for model training. This approach creates significant legal risk. The organisation should establish where the training data came from, whether it contains personal data, why the information was originally collected and whether the proposed AI use is compatible with the applicable legal basis. If consent is the applicable basis, the organisation needs to consider whether the notice and consent mechanism adequately covers the intended processing. Where another lawful basis or legitimate use applies under the DPDP framework, the business should document why it applies. The analysis should also consider whether the data was obtained from a third party. A company cannot necessarily assume its vendor had the right to use personal data for AI training simply because the vendor supplied the dataset. Can Businesses Use Publicly Available Data to Train AI? Public availability does not automatically resolve every legal issue surrounding AI training. Information available on a website may still relate to identifiable individuals. Businesses should therefore examine how the information was collected, whether the information falls within an applicable statutory provision, how it will be used and whether other laws impose restrictions. The DPDP Act contains provisions concerning publicly available personal data, but businesses should not interpret these provisions as a universal permission to scrape any publicly accessible information for any AI purpose. The legal analysis should also consider copyright, database rights where applicable, website terms, contractual restrictions, confidentiality and cybersecurity requirements. This is particularly important for businesses building large language models or machine learning datasets through web scraping. Purpose Limitation and AI Model Development Purpose limitation creates a difficult question for AI developers. A company may originally collect information to provide a service. Later, its product team may want to use the same information to train an AI model, improve an algorithm or develop a new product. The company should not assume the new purpose is automatically covered by the original collection. It should assess the relationship between the original purpose and the proposed AI use, identify the applicable legal basis and determine whether additional notice or consent is required. A clear data purpose map can help prevent inappropriate secondary use. Data Minimisation in Artificial Intelligence AI systems often create pressure to collect as much data as possible. More information can appear useful for improving model performance, but privacy law does not necessarily support unlimited collection. Businesses should identify the information genuinely needed for the intended AI purpose. Where a model can perform effectively without direct identifiers, those identifiers should be removed or separated where practical. Where aggregated or anonymised information is sufficient, using identifiable information may create unnecessary privacy risk. Data minimisation should also apply to testing datasets. Developers should not automatically use live customer information when synthetic or appropriately anonymised data can achieve the same technical objective. AI Data Governance Throughout the Model Lifecycle AI privacy governance should cover more than training. Personal data can enter an AI system during data collection, training, validation, fine tuning, deployment, prompting, retrieval augmented generation, monitoring and model improvement. A business should therefore map the complete lifecycle. For a generative AI application, this can include user prompts, uploaded files, retrieval databases, external model providers, conversation history, logs and generated outputs. Each component can create a separate data processing activity. This is one of the most important differences between conventional software privacy reviews and AI privacy reviews. AI systems can create complex and sometimes unpredictable data flows. Automated Decision Making and Profiling AI can influence decisions about individuals even when the system does not make the final decision itself. Examples include recruitment screening, credit assessment, insurance risk analysis, fraud detection, employee monitoring and customer segmentation. Businesses should determine whether an AI system is merely assisting a human or materially influencing an outcome affecting an individual. They should also consider whether the information used by the system is accurate, relevant and appropriate for the decision. The DPDP Act does not create a general GDPR style right to object to every automated decision. However, businesses still need to comply with applicable data processing requirements, and other sector specific laws may impose additional obligations. High impact uses should receive stronger governance because errors can have serious consequences for individuals. Accuracy and Data Quality in Machine Learning Poor quality training data can produce inaccurate or discriminatory outcomes. From a privacy perspective, businesses should consider whether personal information used by an AI system is accurate and appropriately maintained where accuracy matters to the processing purpose. An outdated customer profile, incorrect financial information or inaccurate employment record can affect an automated recommendation. Data governance should therefore include processes for correcting relevant information and assessing the quality of datasets used in material AI applications. Sensitive and High Risk Data in AI The DPDP Act does not reproduce the former SPDI framework by creating a general statutory category called sensitive personal data. However, some types of information can create significantly greater privacy risks when processed through AI. Healthcare records, financial information, biometric information, children's information and employment data can require enhanced governance depending on the context and applicable legal framework. Businesses using such information should apply stronger access controls, security measures, purpose restrictions and monitoring. The risk assessment should consider both the sensitivity of the data and the consequences of an AI failure. AI and Children's Personal Data Children require special protection under the DPDP Act. Businesses processing children's personal data must consider the specific requirements concerning verifiable parental consent and restrictions on certain processing activities. AI systems used in education, gaming, social platforms, healthcare and children's services can therefore require additional safeguards. Age verification, parental consent mechanisms, profiling controls and product design should be reviewed before deploying AI features involving children. Privacy by Design for AI Products Privacy should be incorporated into AI development from the beginning. A privacy by design approach requires product teams to consider data collection, purpose, access, retention, security and deletion before an AI feature is launched. The design should also account for model inputs and outputs. For example, an AI assistant may unintentionally reproduce personal information contained in its training or retrieval sources. A company should therefore consider access controls, filtering, data segregation and output monitoring. Privacy testing should form part of AI testing rather than being treated as a separate legal exercise after deployment. AI Vendors and Third Party Model Providers Many businesses do not build AI models themselves. They use external providers through APIs, cloud platforms or software products. This creates additional privacy considerations. Before sending personal data to an AI vendor, the business should understand where the information is processed, whether the provider retains prompts, whether data is used for model training, how long information is retained and whether subcontractors receive access. Contracts should clearly address permitted processing, confidentiality, security, incident reporting, deletion and use of customer information for model improvement. A vendor's general statement claiming it is privacy compliant should not replace contractual and technical due diligence. AI and Data Processors An AI provider may act as a Data Processor where it processes personal data on behalf of a Data Fiduciary. The role depends on the actual processing arrangement. For example, a company may instruct an AI service to analyse customer support records for the company's internal purposes. In such a situation, the AI provider may be processing information on behalf of the business. The contractual framework should reflect this relationship and define the permitted processing activities. A business should also assess whether an AI vendor uses customer information for its own independent purposes. If it does, the legal analysis may become more complex. Data Retention and AI Systems Retention can be difficult in AI environments. Deleting personal information from a customer database may not remove copies contained in training datasets, vector databases, model evaluation files, prompts, logs or backups. Businesses should therefore establish retention controls before using personal data for AI. They should also understand whether information has been incorporated into model development and whether it can be technically removed or isolated later. Where the technical ability to delete training information is limited, this issue should be assessed before the dataset is used rather than after a rights request arrives. Data Principal Rights and AI The DPDP Act provides Data Principals with rights including access to information, correction and completion, updating, erasure in applicable circumstances, grievance redressal and nomination. AI systems can make these rights operationally difficult. A company may know an individual's information exists in its CRM but not realise it also appears in a training dataset or AI monitoring system. Businesses should therefore connect their data rights processes with AI data inventories. When a correction or erasure request is received, the organisation should know which systems need to be assessed and whether another legal requirement permits or requires retention. AI Security and Data Protection AI introduces security risks alongside privacy risks. Prompt injection, model extraction, unauthorised access, insecure APIs, data leakage and compromised model infrastructure can expose personal information. Security controls should therefore cover both the underlying data and the AI application. Businesses should use appropriate authentication, access controls, encryption, logging, monitoring and vulnerability management. AI specific testing should also consider whether the system can be manipulated into disclosing information it should not reveal. A secure model is not necessarily a privacy compliant model, but privacy compliance becomes difficult to demonstrate without appropriate security. Cross Border AI Processing AI providers frequently operate infrastructure across several countries. An Indian company sending personal data to an overseas AI provider should assess the applicable cross border requirements under Indian law and any contractual or foreign legal requirements. The DPDP Act provides a framework under which the Central Government may restrict transfers to specified countries or territories. Sector specific laws can create additional requirements. Businesses should map where prompts, training datasets, model outputs, logs and backups are stored or accessed. The location of the AI vendor's headquarters is not enough. Actual processing locations and remote access arrangements should also be considered. AI and International Privacy Laws Businesses serving customers outside India may need to consider foreign privacy regimes alongside Indian law. The GDPR is particularly relevant for organisations within its territorial scope. Other jurisdictions may have their own privacy requirements. The European framework also contains specific rules concerning automated decision making and high risk AI when the relevant laws apply. An Indian company developing AI for international markets should therefore conduct jurisdictional analysis before deployment rather than assuming compliance with Indian law will automatically satisfy overseas requirements. AI Governance and the DPDP Framework in India India's AI governance approach is evolving through existing laws, policy initiatives and emerging governance frameworks rather than one comprehensive AI statute. Government discussions have increasingly recognised the need to address responsible AI, data governance, cybersecurity, fairness, transparency and accountability. The DPDP Act is an important part of this framework because it governs personal data processing even when the processing is performed through AI. This means businesses should avoid waiting for a future standalone AI law before establishing governance controls. Significant Data Fiduciaries and AI Risk The DPDP Act creates additional obligations for Significant Data Fiduciaries. Where an organisation is designated as an SDF, the framework includes requirements concerning a Data Protection Officer, independent data auditing and Data Protection Impact Assessments. The DPDP Rules also introduce specific due diligence relating to algorithmic software used for processing personal data by Significant Data Fiduciaries. This is important for businesses operating large scale AI systems involving substantial volumes of personal data. An organisation should therefore assess whether its size, data processing activities and risk profile could bring it within the SDF framework. AI Impact Assessments A formal AI impact assessment can help businesses identify privacy and other risks before deployment. The assessment should examine the purpose of the AI system, categories of personal data, affected individuals, data sources, model behaviour, potential harms, security controls, vendor dependencies and mitigation measures. Where the organisation is subject to statutory DPIA requirements, those obligations should be integrated into the assessment process. Even where a DPIA is not legally mandatory, a structured risk assessment can provide valuable evidence of responsible governance. AI Training Data Provenance Businesses should maintain records showing where important training datasets came from. Data provenance can help answer questions about ownership, permissions, privacy rights, contractual restrictions and data quality. This is particularly important when datasets come from vendors or are assembled from multiple sources. A company should be able to explain the origin and permitted use of material datasets used in an important AI system. Poor provenance can create privacy, contractual, copyright and regulatory risks simultaneously. How Businesses Can Build an AI Data Compliance Framework? Businesses should begin by creating an inventory of AI systems. The inventory should identify which systems are in development, testing and production and whether each system processes personal data. The next step is data mapping. Organisations should identify the source, purpose, location and recipients of information used by each AI system. They should then assess the applicable legal basis and review privacy notices, contracts and vendor arrangements. Technical teams should test access controls, data leakage, retention and deletion. Legal and compliance teams should assess regulatory obligations and contractual exposure. For businesses deploying AI at scale, AI data compliance should become part of the organisation's wider privacy and technology governance framework rather than a one time project. Common AI Privacy Mistakes Businesses Should Avoid One common mistake is assuming publicly available information can always be scraped and used for model training without further legal analysis. Another is using customer data for AI training when the original purpose of collection did not clearly contemplate such use. Businesses also frequently overlook data contained in prompts, logs and monitoring systems. A company may protect its main database while sending personal information to an external AI provider without adequate contractual controls. Another mistake is failing to distinguish AI vendor roles. A provider may act as a processor for one activity and have an independent purpose for another. Finally, businesses may focus on model accuracy while overlooking privacy rights, data provenance, retention and security. Conclusion AI and data protection laws are becoming increasingly interconnected because modern AI systems depend on large volumes of information. Businesses cannot treat privacy as a separate issue to be considered after a model has been developed. Data protection needs to be incorporated into dataset selection, model development, testing, deployment, vendor management and ongoing monitoring. For Indian businesses, the DPDP Act provides an important foundation, but it operates within a wider legal environment involving information technology law, cybersecurity, intellectual property, consumer protection and sector specific regulation. India is also continuing to develop its broader AI governance approach. The most practical approach is to begin with the data. Businesses should know what information an AI system uses, where it came from, why it is being processed, who can access it, where it is transferred and how long it remains available. They should also understand whether they are acting as a Data Fiduciary, Data Processor or both across different activities. AI governance should then connect legal requirements with technical controls. Data mapping, provenance records, privacy notices, consent mechanisms, vendor agreements, access controls, model testing, retention policies and incident response should work together. Businesses developing or deploying high impact AI should also consider structured privacy and AI risk assessments before launch. This approach can identify problems early, when changes to datasets, contracts or architecture are still practical. As AI adoption continues across financial services, healthcare, employment, education, retail and enterprise technology, responsible data governance will become increasingly important. Organisations developing AI products or integrating third party AI systems should ensure privacy considerations are addressed throughout the technology lifecycle. For businesses developing AI products or integrating third party AI systems, technology business lawyers can assist with the legal issues arising from data protection, AI contracts, technology licensing, vendor arrangements, intellectual property, cybersecurity and regulatory compliance. The objective should not be to prevent responsible AI use. It should be to create a framework in which innovation can take place with clear accountability for the data used and the people affected. Frequently Asked Questions (FAQs) Q1. Do AI systems fall under Indian data protection law? AI systems can fall within the DPDP framework when they process digital personal data within its scope. The law applies to the relevant processing rather than simply to the label “AI”. Q2. Does the DPDP Act specifically regulate artificial intelligence? The DPDP Act does not contain a standalone chapter dedicated to AI. Its general provisions can apply to AI related processing of personal data. Additional obligations may arise under other laws and sector specific frameworks. Q3. Can personal data be used to train AI models in India? It may be possible depending on the data, purpose, legal basis, applicable provisions and contractual restrictions. Businesses should not assume all personal data can automatically be used for AI training. Q4. Can publicly available data be used for AI training? Public availability does not automatically resolve every legal issue. Businesses should examine the applicable DPDP provisions as well as copyright, contractual, cybersecurity and other legal considerations. Q5. Does consent have to be obtained for AI training? Not in every situation. The applicable legal basis depends on the processing and circumstances. Where consent is relied upon, businesses must ensure the consent framework meets the requirements of applicable law. Q6. Can a company use customer data to train its AI model? It depends on the relationship with the customer, the purpose for which the information was collected, the applicable legal basis, contractual terms and the nature of the proposed AI use. Customer data should not automatically be treated as unrestricted training material. Q7. Do AI vendors need Data Processing Agreements? Where an AI vendor processes personal data on behalf of a Data Fiduciary, appropriate contractual arrangements should address the processing relationship, security, confidentiality, sub processors, incidents, retention and deletion. Q8. Does GDPR apply to AI systems used by Indian companies? The GDPR can apply where its territorial requirements are met. Indian companies serving overseas markets should assess the relevant jurisdiction rather than assuming Indian law alone applies. Q9. What are the main privacy risks associated with generative AI? Important risks include inappropriate training data, excessive data collection, prompt leakage, use of personal data for model improvement, inaccurate outputs, uncontrolled retention, third party processing and difficulty responding to individual rights requests. Q10. Can an individual request deletion of personal data used in an AI model? The DPDP Act provides an erasure right in applicable circumstances, but the practical application to trained models can be technically complex. Businesses should assess where personal data exists within the AI lifecycle and whether any legal retention requirement applies. Q11. Are AI systems allowed to make automated decisions about individuals? Indian law does not contain a universal prohibition on automated decision making. However, organisations must comply with applicable privacy requirements and any sector specific laws. High impact uses should receive careful governance and risk assessment. Q12. Do AI businesses need a Data Protection Officer? Not every AI company automatically requires a statutory Data Protection Officer. Additional requirements can apply where an organisation is designated as a Significant Data Fiduciary under the DPDP framework. Q13. What should businesses do before deploying an AI system? They should identify the data being processed, establish the purpose and legal basis, assess vendors, review privacy notices and contracts, map data flows, evaluate risks, implement security controls and establish retention and rights management processes.

Software as a Service businesses operate on data. A SaaS platform may collect information about its own users while also storing and processing personal data belonging to its business customers. This makes data protection for SaaS companies more complex than privacy compliance for a conventional website or software product. A SaaS provider may act as a Data Fiduciary for information it collects directly and as a Data Processor when it handles customer data on instructions from another organisation. Indian SaaS companies must therefore consider the Digital Personal Data Protection Act, 2023, contractual obligations, information security requirements and, where relevant, overseas privacy laws. Effective compliance must be reflected in contracts, product design, cloud architecture, vendor management and day to day operations. Why Data Protection Matters for SaaS Companies? SaaS platforms can process large volumes of personal information across multiple customers and jurisdictions. Customer relationship platforms may hold names, email addresses, phone numbers and employment information. Human resources platforms may process salary, attendance and employee records. Healthcare software can handle medical information, while financial technology platforms may process payment and financial details. The risk becomes more complex because the same SaaS infrastructure may serve hundreds or thousands of customers. A single technical weakness can therefore affect multiple organisations and potentially large numbers of individuals. Privacy compliance must consequently be designed into the architecture rather than added after a product has already been built. Enterprise customers also increasingly examine privacy and security controls during procurement. They may ask for a Data Processing Agreement, information about sub processors, security certifications, data location details, breach procedures and evidence of access controls. For a SaaS company, privacy governance can therefore influence both regulatory exposure and commercial relationships. Understanding the DPDP Framework for SaaS Businesses The Digital Personal Data Protection Act, 2023 creates a framework for processing digital personal data in India. It distinguishes between a Data Fiduciary, which determines the purpose and means of processing, and a Data Processor, which processes personal data on behalf of a Data Fiduciary. This distinction is particularly important for SaaS companies because they commonly perform both roles. When a SaaS provider collects information from its own users for account creation, billing, customer support or marketing, it may determine the purpose and means of processing and therefore act as a Data Fiduciary. When an enterprise customer uploads employee or customer information into the SaaS platform, the SaaS provider will often process the information on the customer's behalf. The classification should always be based on the actual processing arrangement. A contract cannot simply change the legal nature of a relationship if the practical roles are different. The Current DPDP Implementation Position The DPDP Act was enacted in 2023 and the DPDP Rules were notified in November 2025. The Rules provide for phased commencement. Some provisions came into force upon publication, while the main substantive group is scheduled for the later implementation phase. For SaaS companies, this distinction is important because several online articles incorrectly describe the entire DPDP framework as already fully enforceable. The principal substantive provisions covered by the eighteen month commencement notification are scheduled to take effect in May 2027 based on the published commencement framework. This does not mean SaaS companies should wait until 2027. Enterprise customers may already require contractual privacy commitments. Existing information technology and contractual requirements may also apply. More importantly, SaaS architecture can take months to change. Data mapping, deletion functionality, vendor reviews and tenant isolation cannot always be implemented quickly. SaaS Companies Often Have Two Privacy Roles The dual role of a SaaS business is one of the most important issues in privacy compliance. A SaaS provider may be a Data Fiduciary for information collected directly from its own customers and users. It determines why the information is collected and how it is used. The same provider may be a Data Processor for information uploaded by a customer and processed according to that customer's instructions. These roles create different responsibilities. For its own processing, the SaaS company needs to examine notice, consent where applicable, user rights, retention, security and other Data Fiduciary obligations. For customer hosted data, the focus shifts towards processing instructions, contractual controls, security, sub processors, assistance with rights requests and breach support. A single privacy policy cannot adequately explain both relationships. SaaS companies should document their role for each major category of personal data. Data Mapping Should Come Before Compliance Documentation A SaaS privacy programme should begin with a detailed data map. The company should identify what personal information enters the platform, where it is stored, which applications can access it and where it is transferred. The map should cover production databases, cloud storage, backups, application logs, analytics tools, customer support systems and development environments. This is particularly important because personal data does not remain only in the main application database. It can move into error logs, monitoring tools, customer support tickets, email systems, data warehouses and analytics platforms. A privacy programme built only around the primary database can therefore miss significant processing activities. Privacy by Design for SaaS Products Privacy should be considered during product development rather than after launch. When a new feature requires personal information, the product team should identify the purpose for collection and assess whether the information is necessary. The engineering team should then consider access restrictions, retention, encryption and deletion requirements. Privacy by design is especially important for products offering artificial intelligence features. Information may move from a customer interface to an application server, retrieval system, external model provider, monitoring platform and analytics system. Each stage creates a potential processing activity. The architecture should therefore make data flows visible and controllable. Data Processing Agreements for SaaS Providers Data Processing Agreements are central to B2B SaaS relationships. A DPA should establish the nature and purpose of processing, categories of personal data, categories of individuals, duration of processing and permitted instructions. It should also address confidentiality, security, incident notification, sub processors, assistance with rights requests, deletion and return of information. A strong DPA should match the actual service. A SaaS provider should avoid promising controls it cannot technically deliver. If the agreement promises deletion within a particular period, the product architecture and backup systems should be capable of supporting the commitment. The contract should also distinguish between data processed for the customer and information the SaaS provider processes for its own purposes. Managing Sub Processors SaaS businesses rarely operate alone. Cloud hosting providers, payment services, email platforms, analytics providers, customer support tools, identity providers and security vendors can all receive or access information. These organisations may form part of the SaaS provider's sub processor chain. A sub processor register should identify who receives data, what categories of information are involved, where the provider operates and what contractual safeguards are in place. The SaaS company should also establish a process for approving new sub processors and informing customers where contractual arrangements require notification. The risk increases when a company has a long chain of providers but cannot explain which systems have access to customer data. Multi Tenant Architecture and Data Isolation Multi tenant SaaS architecture creates a distinctive privacy risk. Different customers may share the same infrastructure while expecting strict separation of their information. A failure in access controls could allow one customer to access another customer's data. Tenant isolation should therefore be treated as a privacy control as well as a security control. Access rules should be enforced at the application and database layers. APIs should validate tenant permissions before returning information. Administrative tools should also apply appropriate restrictions. Testing should attempt to identify cross tenant access vulnerabilities rather than relying solely on standard penetration testing. Handling Customer Deletion Requests Deletion is one of the most difficult privacy requirements for SaaS providers. A customer may ask the SaaS provider to delete personal information following a user rights request. The provider must then identify where the relevant information exists. This may include the main database, file storage, search indexes, analytics systems, logs, backups and support records. Deletion architecture should therefore be designed before a request arrives. The SaaS provider should also distinguish between active data and information which must be retained for legal, security or contractual reasons. A deletion workflow should record what was deleted, when the action occurred and whether any information was retained under an applicable exception. Data Retention in SaaS Environments SaaS companies should avoid retaining personal information indefinitely simply because cloud storage is inexpensive. Retention should be connected to a defined purpose. When the purpose ends, the organisation should consider whether information can be deleted, anonymised or securely archived where retention remains legally necessary. Retention periods should cover production systems as well as supporting environments. Particular attention should be given to backups. A company may delete information from its live database while retaining multiple copies in backup infrastructure for years. The retention policy should explain how backup copies are managed and when they are overwritten or securely disposed of. Security Requirements for SaaS Companies Security is an essential part of data protection. SaaS providers should implement appropriate technical and organisational safeguards based on the nature and risk of their processing. Common controls include access management, encryption, authentication, network protection, logging, monitoring, vulnerability management, secure software development and backup procedures. The DPDP Rules, 2025 also provide detailed requirements for reasonable security safeguards during their applicable commencement period. These include measures relating to encryption or masking, access controls, logs and monitoring, backups, contractual safeguards with Data Processors and technical and organisational measures. Security should not be reduced to obtaining an ISO certificate. Certifications can provide useful assurance, but they do not automatically establish compliance with every legal or contractual requirement. Data Breach Response for SaaS Companies A SaaS provider may discover a security incident before its customer does. This creates an important contractual and operational responsibility. A breach response plan should identify how the company detects incidents, assesses affected systems, preserves evidence and informs affected customers. Where the SaaS company processes information as a Data Processor, its customer may have the primary statutory notification responsibility. The SaaS provider still needs to notify the customer quickly enough for the customer to meet its own obligations. The CERT In framework also requires specified cyber incidents, including data breaches and data leaks, to be reported within six hours. The applicable requirements should therefore be assessed separately from the DPDP framework. A SaaS company should maintain an incident matrix showing which regulatory and contractual deadlines apply to different categories of incidents. Cross Border Data Transfers and Cloud Hosting SaaS platforms often use international cloud infrastructure. Customer information may be stored in India while support or security teams in another country can access it. Alternatively, an external service provider may process information in another jurisdiction. This makes data flow mapping essential. The DPDP Act provides a framework under which the Central Government may restrict transfers to specified countries or territories. It does not establish a universal rule requiring every personal data set processed by every SaaS company to remain in India. However, contractual commitments and sector specific regulations can impose additional restrictions. A SaaS provider should therefore examine its customer agreements, the location of infrastructure, remote access arrangements, sub processors and any sector specific requirements before designing its international data architecture. SaaS and International Privacy Laws Indian SaaS companies serving overseas customers may also fall within foreign privacy regimes. The GDPR can become relevant where its territorial requirements are met. Other jurisdictions may impose their own privacy requirements. A SaaS company should not assume its Indian privacy policy automatically satisfies every overseas law. Instead, it should identify its target markets and determine whether additional notices, contractual terms, transfer mechanisms, rights processes or security requirements apply. Global SaaS companies often benefit from building a common privacy architecture while allowing jurisdiction specific requirements to be added where necessary. AI and Machine Learning Data Protection AI creates new data protection challenges for SaaS providers. A platform may use customer information to provide an AI feature, train a model, improve service quality or detect abuse. These purposes should not automatically be treated as interchangeable. The company should determine whether it has the appropriate authority to use customer data for each purpose. Customer contracts should clearly address whether customer information may be used for model improvement or training. Technical teams should also examine prompts, retrieved documents, model inputs, outputs, application logs and monitoring systems. Personal data can appear in any of these locations. Where feasible, anonymised, synthetic or minimised information should be considered for development and testing. Employee and Developer Access Employees can create significant privacy risks even when systems have strong external security. Developers may access production databases during troubleshooting. Support staff may view customer tickets. System administrators may have privileged access to infrastructure. Access should therefore follow a least privilege approach. Production access should be limited, monitored and reviewed. Privileged accounts should receive stronger authentication. Where practical, sensitive information should be masked from employees who do not need to see the underlying data. Access should also be removed promptly when an employee changes roles or leaves the organisation. Privacy Notices and SaaS Users A SaaS company acting as a Data Fiduciary should provide appropriate information to individuals whose personal data it collects. The notice should reflect the actual processing activities. It should explain the types of information collected, purposes, relevant rights and how individuals can exercise them. A generic privacy policy copied from another technology company creates legal and operational risk. The policy should match the product. If the platform collects device identifiers, usage information, support communications and payment information, the notice should reflect those activities. Data Protection in Contracts and Enterprise Procurement Enterprise customers increasingly assess SaaS providers before signing agreements. A customer may ask whether the provider has a DPA, where data is hosted, which sub processors are used, how quickly breaches are reported and whether the company can support data deletion. Customers may also request security questionnaires, audit reports, penetration testing summaries and certification evidence. This makes privacy readiness commercially significant. A SaaS company should maintain a central repository of privacy and security information so its sales and procurement teams can respond accurately without making inconsistent commitments. Building a SaaS Privacy Governance Framework A mature privacy framework should connect legal requirements with technical controls. The legal team can identify applicable obligations. Product teams can assess processing purposes. Engineering can implement access and deletion controls. Security teams can manage technical safeguards. Procurement can assess vendors. Customer success teams can manage rights and contractual requests. No single department can manage the entire privacy lifecycle. For growing businesses, obtaining appropriate data protection advice can help align contractual commitments with the actual capabilities of the product and infrastructure. This is particularly useful when a SaaS provider serves regulated customers or operates across multiple jurisdictions. Preparing for DPDP Compliance SaaS companies should begin with a data inventory and role assessment. The next stage should identify processing purposes and applicable legal bases. The company can then review privacy notices, customer agreements, DPAs and sub processor contracts. Technical teams should test tenant isolation, access controls, deletion workflows and retention settings. Security teams should review incident response arrangements. The company should also maintain evidence of its controls. Compliance is easier to demonstrate when an organisation can produce data maps, processing records, contracts, security assessments, deletion records, incident logs and vendor reviews rather than simply stating it has a privacy policy. When Does a SaaS Company Need a Data Protection Officer? Not every SaaS company automatically needs a statutory Data Protection Officer merely because it processes personal data. The DPDP Act provides additional obligations for organisations designated as Significant Data Fiduciaries. These can include requirements relating to a Data Protection Officer, independent data auditing and Data Protection Impact Assessments. Whether a particular SaaS company falls within this category depends on the applicable designation criteria and government notification. Companies should therefore monitor their processing scale, nature of data and regulatory developments rather than assuming every technology business has identical obligations. Common Data Protection Mistakes Made by SaaS Companies One frequent mistake is treating the SaaS provider as only a Data Processor. A company may process customer hosted information on behalf of enterprises while separately determining how its own account, billing, marketing and product analytics information is used. Another mistake is focusing on the main application while ignoring logs, analytics tools, backups and support systems. Weak sub processor governance is another recurring risk. A company may have a detailed DPA with its customer while having little visibility into the vendors receiving access further down the chain. Some companies also promise deletion without testing whether information can actually be removed from backups and secondary systems. Another common issue is using customer data for AI model training or product improvement without clearly assessing the contractual and privacy implications. Conclusion Data protection for SaaS companies is both a legal and technical responsibility. The complexity arises because SaaS providers often process information for their own purposes while simultaneously handling customer data on behalf of other organisations. A strong compliance framework should therefore begin with clear role identification. The company should know which information it controls as a Data Fiduciary and which information it processes as a Data Processor. It should then build appropriate privacy notices, DPAs, vendor controls, security safeguards, retention policies and rights management processes around those roles. The technical architecture must support the legal commitments. Multi tenant isolation, access management, deletion capabilities, audit logs, backup management and secure APIs are not merely engineering considerations. They can become important evidence of responsible data governance. As India's DPDP framework moves towards fuller implementation, SaaS businesses have an opportunity to address these issues before regulatory deadlines create operational pressure. Organisations serving enterprise customers should also expect privacy and security requirements to become increasingly important during procurement and contract negotiations. For complex technology businesses, technology corporate lawyers can play an important role in aligning privacy obligations with SaaS agreements, licensing structures, vendor arrangements, intellectual property considerations, international operations and technology risk. Ultimately, effective SaaS privacy compliance is not achieved by publishing a lengthy privacy policy. It requires a connected system in which contracts, product design, infrastructure, security controls and organisational processes all support responsible handling of personal data. Frequently Asked Questions Q1. What is data protection for SaaS companies? Data protection for SaaS companies involves managing personal data throughout its lifecycle, including collection, processing, storage, sharing, security, retention and deletion. SaaS providers must also determine whether they act as a Data Fiduciary, Data Processor or both for different processing activities. Q2. Does the DPDP Act apply to SaaS companies? Yes. SaaS companies processing digital personal data within the scope of the DPDP Act may be subject to its requirements. The precise obligations depend on the organisation's role, processing activities and applicable provisions. Q3. Is a SaaS company a Data Fiduciary or Data Processor? It can be either or both. A SaaS provider may act as a Data Fiduciary for information it collects directly from its own users and as a Data Processor for personal data processed on behalf of its enterprise customers. Q4. Does a SaaS company need a Data Processing Agreement? Where the SaaS provider processes personal data on behalf of a customer, a suitable processing agreement is an important contractual control. The agreement should reflect the actual processing relationship and address security, confidentiality, sub processors, incidents, retention and deletion. Q5. What should a SaaS Data Processing Agreement contain? A DPA should normally address the subject and duration of processing, purpose, categories of personal data, categories of individuals, instructions, confidentiality, security, sub processors, incident management, assistance with rights, retention and deletion. The precise terms should reflect the applicable law and service. Q6. Are cloud providers sub processors? A cloud provider may operate as a sub processor where it processes personal data on behalf of the SaaS provider and ultimately the relevant Data Fiduciary. The contractual relationship and actual processing activities should be examined before assigning the role. Q7. Does DPDP require SaaS data to remain in India? No universal DPDP localisation requirement applies to every SaaS data set. The Act provides a framework for government restrictions on transfers to specified countries or territories. Separate contractual, sector specific or foreign law requirements may impose additional restrictions. Q8. How should SaaS companies handle deletion requests? They should identify the relevant data across production databases and supporting systems, determine whether deletion is legally required, execute the appropriate deletion or retention process and maintain evidence of the action. Backup and archive systems should also be addressed. Q9. What happens if a SaaS company suffers a data breach? The company should contain the incident, investigate affected systems, preserve evidence and assess contractual and regulatory reporting requirements. If it acts as a processor, it may also need to inform the relevant customer quickly so the customer can meet its own legal obligations. Q10. Does GDPR apply to Indian SaaS companies? It can apply in circumstances covered by the GDPR's territorial scope. An Indian SaaS company serving customers or individuals outside India should assess the relevant foreign privacy laws rather than assuming Indian law is sufficient. Q11. Can SaaS companies use customer data to train AI models? The answer depends on the purpose, contractual terms, applicable law and the relationship between the SaaS provider and customer. Customer data should not automatically be used for model training merely because it is accessible to the SaaS platform. Q12. What security controls should SaaS companies implement? Controls should be appropriate to the nature and risk of processing. They can include encryption, access controls, authentication, tenant isolation, monitoring, logging, vulnerability management, backups, secure development practices and tested incident response procedures. Q13. Do SaaS companies need ISO 27001 or SOC 2 certification? Neither certification automatically applies to every SaaS company as a statutory requirement under the DPDP Act. However, enterprise customers may request such certifications as part of security and procurement assessments. Certification should be viewed as assurance rather than a substitute for legal compliance.

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.