CELEBRATING MORE THAN YEARS
AWARDS & RECOGNITION
UPDATES
PRACTICE AREAS
PEOPLE
News and Articles
privacy policy requirements
Privacy Policies: Legal Requirements Every Business Should Know
A privacy policy is more than a page placed in the footer of a website. It explains how a business collects, uses, stores and shares personal information. For organisations operating in India, understanding the privacy policy requirements has become increasingly important following the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. The legal framework is moving towards a more structured approach to privacy notices, consent, security, retention and individual rights. At the same time, sector specific regulations and international privacy laws may apply to particular businesses. A well drafted privacy policy should therefore reflect actual business practices rather than rely on a generic template. What Is a Privacy Policy? A privacy policy is a document explaining an organisation's practices concerning personal data. It normally tells users what information is collected, why it is collected, how it is used, who may receive it, how long it may be retained and how individuals can exercise applicable rights. The document serves an important transparency function. It also helps businesses establish a consistent internal approach to handling personal information. For Indian businesses, the privacy notice framework is increasingly connected with the statutory obligations of a Data Fiduciary under the DPDP Act. A Data Fiduciary is an entity deciding the purpose and means of processing personal data. A privacy policy should therefore be consistent with the organisation's actual processing activities. Privacy Policy Requirements Under Indian Law India's privacy framework has developed through several legal instruments. The Information Technology Act, 2000 and the Information Technology Rules, including the Sensitive Personal Data or Information Rules, 2011, established earlier privacy and security requirements. The DPDP Act, 2023 now provides a broader statutory framework for digital personal data. Section 5 of the DPDP Act requires a notice to accompany or precede a request for consent. The notice must inform the Data Principal about the personal data proposed to be processed, the purpose of processing, how specified rights may be exercised and how a complaint may be made to the Board. The DPDP Rules, 2025 provide more detailed requirements for such notices. This means businesses should not view a privacy policy as a static legal document. It should form part of the organisation's wider privacy governance system. What Should a Privacy Policy Contain? A good privacy policy should clearly identify the organisation responsible for processing personal data. The legal name of the business and appropriate contact details should be easy to find. It should explain the categories of personal data collected. Depending on the business, this could include names, contact details, account information, location information, transaction records, device information or information generated through use of a service. The policy should then explain the purposes for which each category is processed. Specific explanations are preferable to broad statements such as “for business purposes”. The notice should also explain relevant rights, consent withdrawal procedures and grievance mechanisms. Rule 3 of the DPDP Rules requires the notice to provide an itemised description of the personal data and the specified purpose for processing. It also requires information concerning rights, the manner of exercising those rights and complaints to the Board. The notice must be presented in clear and plain language. Identity and Contact Details of the Business Users should know who is collecting their information. A privacy policy should identify the relevant legal entity and provide a reliable privacy contact mechanism. Where a Data Protection Officer is legally required, the relevant contact details should be provided. This becomes especially important for corporate groups. A website may display one brand while another legal entity actually processes customer information. The privacy documentation should make the relationship clear. Explain What Personal Data Is Collected Businesses should describe the information they collect in understandable terms. This can include information supplied directly by customers, information generated through transactions and information collected automatically through websites or applications. The description should be sufficiently specific for an individual to understand the nature of the information involved. A business should also review whether every data field it collects is necessary. Collecting information simply because the technology allows it can increase privacy and security risks. Explain Why the Information Is Collected Purpose is one of the most important elements of an effective privacy notice. A business should connect data collection with a defined purpose. For example, an e commerce business may process contact details to deliver an order, payment information to complete a transaction and account information to manage the customer relationship. Separate purposes should not be hidden behind vague language. This is particularly important when businesses later introduce analytics, profiling, personalised marketing or artificial intelligence tools. A new use should be assessed against the original purpose and the applicable legal basis. Consent Must Be Meaningful Where consent is used as the basis for processing, it must satisfy the requirements of the DPDP Act. Section 6 states consent must be free, specific, informed, unconditional and unambiguous, with clear affirmative action. It must relate to the specified purpose and be limited to personal data necessary for that purpose. The request for consent must also use clear and plain language. Businesses should avoid confusing consent interfaces, pre selected choices and bundled permissions for unrelated activities. A user should understand what they are agreeing to. Where consent is withdrawn, the business must follow the statutory requirements concerning cessation of processing, subject to circumstances where continued processing is authorised or required by law. Privacy Policies Must Match Actual Business Practices One of the biggest weaknesses in privacy documentation is inconsistency. A policy may state personal data is retained for a specific period while the company's systems retain it indefinitely. It may say information is shared only with selected providers while several additional analytics services receive data. Such inconsistencies can undermine the value of the policy. Businesses should therefore conduct a data mapping exercise before drafting or updating the document. The legal team should understand how the website, application, CRM, payment systems, cloud platforms and marketing tools actually process information. The policy should describe reality rather than an idealised version of the business. Data Sharing With Third Parties Many organisations share personal information with service providers. These may include payment gateways, cloud hosting providers, customer support platforms, analytics companies, marketing platforms and outsourced service providers. The privacy policy should explain relevant categories of recipients and the purpose for sharing information. The business should also examine its contracts with these providers. Under Section 8 of the DPDP Act, a Data Fiduciary remains responsible for compliance concerning processing carried out by it or on its behalf by a Data Processor. A Data Processor may be engaged for activities related to offering goods or services only under a valid contract. A privacy policy therefore cannot replace appropriate vendor agreements. Data Retention and Deletion A privacy policy should explain how long personal information is retained or the criteria used to determine retention. The retention approach should be linked to business purposes and legal requirements. Section 8 requires a Data Fiduciary, subject to legal retention requirements, to erase personal data when consent is withdrawn or when it is reasonable to assume the specified purpose is no longer being served. The Data Fiduciary must also cause its Data Processor to erase relevant information. Businesses should therefore maintain internal retention schedules alongside their public privacy notices. Security Measures and Data Breaches A privacy policy should provide an appropriate explanation of security practices without revealing information which could itself create security risks. The DPDP Act requires Data Fiduciaries to implement appropriate technical and organisational measures and reasonable security safeguards to prevent personal data breaches. The DPDP Rules 2025 further specify security safeguards. Rule 6 includes measures such as encryption, masking, access controls, logs, monitoring, backups and appropriate contractual provisions concerning Data Processors. Businesses should also establish an internal breach response procedure. A privacy policy can explain how affected individuals will be informed where notification is required, but the operational response must be supported by technical and organisational processes. Cookies and Online Tracking Websites often collect information automatically through cookies, pixels, analytics tools and similar technologies. A business should identify the technologies it uses and explain their purposes where applicable. It should also distinguish essential functionality from analytics, advertising and other tracking activities where the relevant legal framework requires separate choices or disclosures. Cookie practices should match the actual configuration of the website. A privacy policy should not state cookies are used only for basic functionality if advertising platforms or analytics providers are also receiving information. Privacy Policies for Mobile Applications Mobile applications create additional considerations. An application may access device identifiers, location information, camera functions, contacts, photographs or other information depending on its functionality. The privacy documentation should accurately describe such collection and use. Businesses must also consider platform specific requirements. Google Play, for example, requires apps to provide a clear and accessible privacy policy and to disclose relevant data collection, use, sharing, security and retention practices. The policy should therefore be reviewed alongside the application's actual permissions and platform disclosures. Children's Personal Data Businesses serving children require additional care. Under Section 9 of the DPDP Act, a child means an individual who has not completed eighteen years of age. Processing a child's personal data requires verifiable parental or guardian consent, subject to the statutory framework. The Act also addresses processing likely to cause detrimental effects on a child's well being and restricts tracking, behavioural monitoring and targeted advertising directed at children, subject to specified exemptions. Businesses offering gaming, education, social, healthcare or other services likely to be used by children should assess these obligations before collecting information. The privacy policy alone will not satisfy these requirements. Product design, age assurance and consent mechanisms may also need to be considered. International Data Transfers A business may store or process personal data outside India. The DPDP Act generally permits transfer of personal data outside India subject to restrictions which may be imposed by the Central Government. Other laws may impose additional requirements. Businesses should therefore disclose relevant international processing practices where appropriate and understand the countries in which information is stored or accessed. If an organisation serves individuals in other jurisdictions, foreign privacy laws may also apply. For example, the GDPR contains its own transparency and international transfer requirements. A privacy policy should not make broad claims about international transfers without first understanding the organisation's actual technology and vendor arrangements. Sector Specific Privacy Requirements Not every business operates under the same regulatory framework. Financial institutions, payment businesses, insurers, healthcare organisations, telecommunications companies and other regulated entities may face additional requirements. For example, the RBI's framework for payment system data includes specific storage requirements in India. A business operating in this sector therefore needs to consider RBI requirements alongside the general DPDP framework. This is one reason generic privacy templates can create risk. A document suitable for an ordinary online retailer may be inadequate for a regulated financial or healthcare business. Privacy Policy Requirements During the DPDP Transition Businesses should pay close attention to the DPDP implementation timeline. The DPDP Act was enacted on 11 August 2023. The Central Government issued the commencement notification in November 2025, establishing a phased implementation structure. Certain provisions commenced immediately, some after one year and the principal operational provisions after eighteen months. The DPDP Rules 2025 follow a similar phased structure. Rules 1, 2 and 17 to 21 commenced upon publication. Rule 4 is subject to a one year period, while Rules 3, 5 to 16, 22 and 23 are subject to the eighteen month period. The eighteen month period runs from 13 November 2025, making 13 May 2027 the commonly calculated date for the principal requirements. This distinction matters. Businesses should avoid saying the entire DPDP framework is already operational. At the same time, waiting until 2027 to begin preparation would be commercially unwise. When Should a Business Update Its Privacy Policy? A privacy policy should be reviewed whenever there is a material change in data processing. Examples include launching a new product, introducing a new analytics platform, appointing a new processor, changing data retention periods, introducing targeted advertising, expanding internationally or using customer information for artificial intelligence. The policy should also be reviewed when legislation, rules or sector specific regulatory requirements change. Businesses should maintain version control and record significant changes. Where appropriate, affected users should be informed about material changes. Common Privacy Policy Mistakes A common mistake is copying a policy from another business. A document may look professionally drafted but describe services, technologies or data practices the business does not actually use. Another problem is excessive legal language. Users should be able to understand how their information is handled without needing specialist legal knowledge. Businesses also sometimes list every possible type of data without explaining why it is collected. This weakens transparency. Other frequent issues include outdated vendor lists, missing retention information, broken privacy contact channels, inconsistent cookie disclosures and failure to update the policy after launching new features. A privacy policy should be treated as a living compliance document. Why Legal Review Matters? A privacy policy sits at the intersection of technology, contracts, consumer communication and regulatory compliance. Legal review can help determine whether the document accurately reflects the organisation's processing activities and whether additional requirements apply because of the business model or sector. Professional privacy policy legal services can be particularly useful when a business is preparing for DPDP compliance, entering regulated markets, launching an application or handling international customer data. The objective should not be to make the document unnecessarily long. It should be accurate, understandable and aligned with the organisation's actual practices. Privacy Policy as Part of Corporate Governance A privacy policy works best when supported by internal controls. The business should know who owns privacy compliance, how customer requests are handled, how vendors are assessed, how personal data is deleted and how incidents are escalated. For growing organisations, privacy governance should connect with contracts, cybersecurity, human resources, procurement and product development. Broader corporate legal support for businesses can help organisations integrate privacy requirements with wider contractual and regulatory obligations rather than treating the policy as an isolated website document. Penalties and Business Risk Privacy compliance has financial consequences as well as reputational implications. The DPDP Act's Schedule provides penalties of up to ₹250 crore for certain failures concerning security safeguards. Other breaches carry maximum penalties depending on the obligation involved. A defective privacy policy may also expose a business to customer complaints, contractual disputes, regulatory scrutiny and difficulties during investor or enterprise due diligence. The precise consequences depend on the nature of the contravention and the applicable legal framework. How to Build an Effective Privacy Policy? The process should begin with a data audit. The business should identify what information it collects, where it comes from, why it is processed, who receives it, where it is stored and how long it remains in the organisation's systems. The next stage is to identify the applicable legal requirements. This should include the DPDP Act and Rules, relevant sector specific regulations and foreign laws where applicable. The privacy notice can then be drafted around the organisation's real processing activities. Finally, the business should establish a review process. Privacy compliance is not completed when a document is uploaded to a website. It requires continuing governance. Conclusion A privacy policy should be treated as an important part of a business's data governance framework, not as standard website boilerplate. The document should accurately explain what information is collected, why it is used, who receives it, how it is protected, how long it is retained and how individuals can exercise applicable rights. For Indian businesses, the DPDP Act 2023 and DPDP Rules 2025 have made privacy governance increasingly important. The phased implementation timeline provides businesses with an opportunity to review their data practices, update notices, strengthen consent mechanisms and establish appropriate internal controls before the principal obligations become operational. Businesses should also remember that privacy compliance extends beyond the DPDP framework. Sector specific regulations, cybersecurity requirements, contractual commitments and foreign privacy laws can create additional obligations. The most reliable approach is to begin with the business's actual data flows and build the privacy policy around them. A clear policy supported by sound operational controls can improve transparency, reduce legal risk and strengthen customer confidence. Businesses should monitor the official Digital Personal Data Protection Rules resources published by MeitY for future implementation notifications and regulatory developments. The India Code legal database is also a useful government source for checking current legislation. Frequently Asked Questions (FAQs) Q1. Is a privacy policy legally required for every business in India? The answer depends on the nature of the business and the data processing involved. Businesses processing digital personal data should assess the applicable statutory notice and transparency requirements rather than assume a privacy policy is merely optional website content. Q2. What should a privacy policy include in India? It should explain relevant personal data collected, purposes of processing, consent mechanisms where applicable, rights, grievance procedures, data sharing, retention and other information required by the applicable legal framework. Section 5 and Rule 3 of the DPDP framework are particularly important for consent notices. Q3. Does the DPDP Act require consent for all personal data processing? No. The Act provides for processing based on consent as well as specified legitimate uses. The appropriate legal basis should be assessed according to the processing activity. Q4. Can a business use a free privacy policy template? A template can provide a starting point, but it may not accurately reflect the organisation's data practices or sector specific requirements. A policy should be customised and reviewed before publication. Q5. How often should a privacy policy be updated? There is no universal interval suitable for every business. It should be reviewed whenever material changes occur in data collection, processing, sharing, retention, technology or applicable law. Q6. Does a privacy policy need to mention third party vendors? The policy should provide appropriate information about relevant sharing and recipients. Businesses should also maintain appropriate contracts with Data Processors. Section 8 requires processing by a Data Processor on behalf of a Data Fiduciary to be supported by a valid contract. Q7. Should a privacy policy mention cookies? Yes, where the website or application uses cookies or similar technologies. The disclosure should accurately reflect the technologies actually deployed and their purposes. Q8. Does the privacy policy need to mention data retention? Retention practices should be explained where required by the applicable framework, and businesses should maintain internal retention controls. The DPDP Act also contains obligations concerning erasure when the relevant purpose is no longer being served or consent is withdrawn, subject to legal requirements. Q9. Does the DPDP Act apply to employee information? The Act covers digital personal data, subject to its scope and exemptions. Certain processing for employment related purposes is addressed within the Act's legitimate use framework. Businesses should assess employee data separately from customer data because employment laws and internal HR requirements may also apply. Q10. What happens if a privacy policy is inaccurate? An inaccurate policy can create transparency, contractual and regulatory risks. More importantly, it can demonstrate a gap between documented practices and actual processing. The business should investigate the underlying data flows and correct both the operational practice and the privacy documentation. Q11. When do the main DPDP privacy notice requirements become operational? The principal operational provisions of the DPDP Act and Rules are subject to an eighteen month commencement period from November 2025. The commonly calculated date for these provisions is 13 May 2027. Businesses should monitor official Government notifications for implementation developments.
startup data protection obligations
Data Protection Obligations for Startups Collecting Customer Information
For an early stage business, collecting customer information often feels like a routine part of building a product. Names, email addresses, mobile numbers, addresses, payment details and usage information help a startup provide services and understand its customers. Yet once a business begins handling personal information, startup data protection obligations become an important legal and operational consideration. India's Digital Personal Data Protection Act, 2023 creates a comprehensive framework for processing digital personal data. The Digital Personal Data Protection Rules, 2025 provide further operational detail. The framework applies to businesses based on their data processing activities rather than simply their size or funding stage. For founders, privacy compliance should therefore begin alongside product development rather than after the business has scaled. What Are Startup Data Protection Obligations? Startup data protection obligations are the legal, technical and organisational responsibilities a startup must follow when collecting, using, storing or otherwise processing personal data. Under the DPDP Act, an organisation determining the purpose and means of processing personal data is generally a Data Fiduciary. A service provider processing personal data on behalf of another organisation can act as a Data Processor. This distinction is particularly important for technology startups. A SaaS company may be a Data Fiduciary for its own website visitors, employees and marketing contacts while acting as a Data Processor for customer information uploaded by its business clients.The legal role depends on what the startup does with the information, not simply how it describes its business. Does the DPDP Act Apply to Startups? A startup does not escape data protection responsibilities merely because it is small, pre revenue or recently incorporated. The DPDP framework applies to the processing of digital personal data within India and also contains provisions concerning processing outside India in connection with offering goods or services to Data Principals in India. The Act defines personal data broadly as data about an individual who is identifiable by or in relation to such data. This means a startup collecting customer names and email addresses through a website may already be handling personal data. The same applies to mobile applications, online marketplaces, fintech platforms, health technology businesses, edtech companies and SaaS products. The absence of a large compliance department does not remove the need for appropriate privacy controls. Start With a Data Inventory The first practical step is to understand what customer information the startup actually collects. A founder should identify every point where information enters the business. This may include website forms, mobile applications, account registration, customer support, payments, surveys, marketing campaigns and product analytics. The startup should then record why each category of information is collected, where it is stored, who can access it, which vendors receive it and how long it is retained. This process is often called data mapping. It provides the foundation for deciding whether each processing activity has an appropriate legal basis, whether the information is necessary and whether security controls are proportionate to the risk. Without a reliable data inventory, a privacy policy may look comprehensive while failing to reflect what the business actually does. Give Customers a Clear Privacy Notice Transparency is a central part of the DPDP framework. Section 5 requires a notice to accompany or precede a request for consent. The notice must inform the Data Principal about the personal data proposed to be processed, the purpose of processing, the manner in which rights can be exercised and the manner in which a complaint can be made. The 2025 Rules add further detail. Rule 3 provides for a standalone notice in clear and plain language, including itemised information about personal data and its purpose, along with information concerning withdrawal of consent, rights and complaints. For startups, this means a generic statement such as “we may use your information to improve our services” may not be sufficient for every processing activity. The notice should reflect the startup's actual practices. Obtain Valid Consent Where Consent Is Required Section 6 provides specific standards for consent. Consent must be free, specific, informed, unconditional and unambiguous, with clear affirmative action. It must also be limited to personal data necessary for the specified purpose. This has direct implications for startup product design. A registration form should not automatically bundle unrelated marketing, contact access or profiling permissions into a single mandatory acceptance. Where consent is the basis for processing, users must also be able to withdraw it, with the ease of withdrawal comparable to the ease of giving consent. Startups should retain appropriate evidence showing what notice was presented and what consent was obtained. This is especially important because Section 6 places the evidentiary burden on the Data Fiduciary where consent is relied upon and its validity is questioned. Collect Only Information the Business Needs Data minimisation is both a sound business practice and an important privacy principle. A startup should ask whether every requested field is genuinely necessary. A food delivery service may need an address to complete an order. It may not need unrelated personal information merely because the application can technically collect it. Collecting excessive information increases security exposure, storage costs and regulatory risk. It can also make future deletion and rights requests more difficult. A sensible approach is to link every data field to a defined business purpose. Establish Retention and Deletion Rules Customer information should not remain in databases indefinitely without a reason. The DPDP Act requires a Data Fiduciary, subject to legal retention requirements, to erase personal data when the Data Principal withdraws consent or when it is reasonable to assume the specified purpose is no longer being served. The Data Fiduciary must also cause its Data Processor to erase relevant personal data in the circumstances specified by the Act. Startups should therefore establish retention periods for customer accounts, inactive users, support records, marketing contacts, transaction records and backups. The retention period should also consider other applicable legal requirements. Tax, accounting, employment, consumer protection and sector specific regulations may require certain records to be preserved for specified periods. Protect Customer Information With Appropriate Security Customer information must be protected against unauthorised access, misuse, loss and breach. Section 8 requires Data Fiduciaries to implement appropriate technical and organisational measures and take reasonable security safeguards to prevent personal data breaches. The obligation extends to processing undertaken by Data Processors on behalf of the Data Fiduciary. For a startup, appropriate security may include access controls, strong authentication, encryption or other protective measures, secure software development practices, backups, monitoring and incident response procedures. The important point is proportionality. A small business does not necessarily need the same infrastructure as a multinational enterprise, but it should be able to demonstrate sensible controls suited to the data and risks involved. Prepare for Personal Data Breaches A startup should assume a security incident is possible and prepare before one occurs. Customer information can be exposed through compromised credentials, vulnerable applications, accidental disclosures, malicious insiders, misconfigured cloud systems or third party vendors. The DPDP Act requires notification of a personal data breach to the Board and affected Data Principals in the prescribed manner. The 2025 Rules provide detailed requirements concerning breach communications. Startups must also consider the separate cyber incident reporting framework. CERT In's directions identify data breaches and data leaks among incidents subject to reporting within six hours under the prescribed framework. CERT In also clarifies the reporting position where affected data is held on third party systems. A startup should therefore maintain an incident response plan covering detection, containment, investigation, legal assessment, notification and remediation. Manage Vendors and Data Processors Carefully Startups rarely operate entirely on their own infrastructure. Customer information may be shared with cloud providers, payment processors, customer relationship management platforms, analytics providers, communication tools and outsourced support teams. Section 8 expressly recognises processing performed by a Data Processor on behalf of a Data Fiduciary. A startup should therefore understand what each vendor does with customer information and maintain suitable contractual controls. Vendor agreements should address permitted processing, confidentiality, security, incident escalation, deletion, subcontracting and assistance with customer rights. A startup should also know where its vendors store and process information. This becomes particularly important when services involve international infrastructure. Be Careful With Customer Data Used for AI Artificial intelligence creates an additional privacy challenge for startups. A business may initially collect customer conversations, support tickets, product usage data or transaction information to provide a service. Later, the same information may appear useful for training or improving an AI system. The original purpose for collection should therefore be examined before information is repurposed. A consent obtained for providing customer support should not automatically be assumed to cover every future use of those conversations for model development, analytics or profiling. Recent discussion around Indian startups using customer interaction data for AI training highlights the practical uncertainty surrounding secondary use and reasonable user expectations. Startups should document intended purposes at the product design stage and reassess privacy implications before introducing new uses. Give Customers a Practical Rights Process Privacy compliance is not limited to publishing a policy. The DPDP Act gives Data Principals rights concerning access to information about their personal data and its processing, correction and erasure, grievance redressal and nomination. The operational framework is supported by the Rules. A startup should establish a clear internal process for receiving and handling such requests. Customer support teams should know where privacy requests must be routed. Technical teams should know how to locate relevant records. Management should know how requests are escalated and documented. A rights process becomes much easier when the startup has already created a reliable data inventory. Special Care Is Needed for Children's Data Startups offering products to children need additional safeguards. The DPDP Act defines a child as an individual who has not completed eighteen years of age. Section 9 requires verifiable parental or guardian consent before processing a child's personal data and restricts processing likely to cause a detrimental effect on the well being of a child. It also addresses tracking, behavioural monitoring and targeted advertising directed at children, subject to statutory exemptions. This is particularly relevant to edtech, gaming, social platforms, health applications and other consumer products likely to attract younger users. A startup should identify its user base early and determine whether its product requires child specific privacy controls. When Does a Startup Need a Data Protection Officer? Not every startup automatically needs a statutory Data Protection Officer under the DPDP Act. The Act creates additional obligations for a Significant Data Fiduciary. Such entities must appoint a Data Protection Officer based in India, appoint an independent data auditor and undertake measures including periodic Data Protection Impact Assessments and audits. For most early stage startups, the more immediate priority is to establish clear internal responsibility for privacy and grievance handling. As the business grows, its data volume, sensitivity, customer base and regulatory exposure should be reassessed. Do Other Indian Data Protection Requirements Still Matter? Yes. The DPDP framework should not be treated as the only relevant data protection requirement in India. Sector specific rules can impose additional requirements. Financial services and payment businesses, for example, may face RBI requirements concerning storage and handling of payment system data. The earlier Information Technology Act framework also remains relevant during the transition, including provisions concerning compensation for failure to protect sensitive personal data and information. The statutory framework under Section 43A and the 2011 SPDI Rules should therefore be considered where applicable during the transition period. Startups operating in regulated sectors should assess the complete legal framework rather than relying only on the DPDP Act. Understand the Current DPDP Implementation Timeline The DPDP Act was enacted in August 2023. The final DPDP Rules were notified in November 2025, and the Government has published a phased enforcement timeline. Rules 3 and 5 to 16, along with Rules 22 and 23, are subject to the eighteen month commencement period under the notification. The corresponding core statutory provisions are also subject to phased commencement. The commonly calculated date for the principal operational requirements is 13 May 2027. This transition should not be viewed as a reason for startups to postpone preparation. Building consent systems, vendor controls, data inventories and deletion mechanisms can take considerable time. Privacy compliance is much easier when incorporated into product architecture from the beginning. Build Privacy Into the Startup's Product Lifecycle The most effective approach is to treat privacy as part of product development. Before launching a feature, the team should identify what customer information it needs, why it needs it, who will access it and how long it will be retained. Product managers should work with engineering, security, legal and customer support teams when material changes to data processing are introduced. This approach avoids the common problem of trying to retrofit privacy controls after a product has accumulated millions of customer records. Startups seeking structured assistance with privacy assessments, documentation, vendor reviews and compliance implementation may consider data protection services for startups as part of their wider legal and governance planning. Keep Evidence of Compliance A startup should be able to demonstrate how it manages personal data. Relevant evidence may include privacy notices, consent records, vendor agreements, processing inventories, retention schedules, security policies, incident records and logs of customer requests. Documentation becomes especially valuable during investor due diligence, enterprise customer onboarding, regulatory enquiries or a merger or acquisition. Good records also help founders understand their own systems. Privacy documentation should therefore be treated as an operational asset rather than paperwork created solely for an audit. Why Privacy Compliance Matters for Startup Growth Data protection is not only a legal issue. It can influence commercial growth. Enterprise customers increasingly ask technology vendors about security, privacy controls, processor arrangements and data handling before signing contracts. Investors may also examine privacy and cyber risk during due diligence. A startup with clear data governance can respond more confidently to these questions. Strong privacy practices can also reduce the likelihood of avoidable incidents and make future expansion into regulated markets easier. Strategic corporate legal advisory services can help founders align privacy requirements with wider contractual, regulatory and governance decisions as the business develops. Penalties for Non Compliance The DPDP Act provides significant financial exposure for certain breaches. The Schedule permits penalties of up to ₹250 crore for failure to take reasonable security safeguards to prevent personal data breaches. Failure to notify the Board or affected Data Principals of a breach can attract a penalty of up to ₹200 crore. Breaches concerning children's data can also attract penalties of up to ₹200 crore. Other contraventions can attract penalties of up to ₹50 crore. These figures demonstrate why privacy should not be treated as an issue reserved for large companies. For a startup, the reputational and commercial consequences of a serious data incident may be significant even before a regulatory penalty is considered. A Practical Approach for Founders A startup does not need to build an unnecessarily complex privacy programme on its first day. It should begin by understanding its data. The next step is to establish appropriate notices and consent mechanisms. The business should then put sensible security, retention, vendor management and rights handling processes in place. As the startup grows, these controls should mature with its customer base, technology and regulatory exposure. The most important principle is simple: collect responsibly, use information only for understood purposes, protect it appropriately and remove it when there is no continuing reason to retain it. Conclusion Customer information is one of a startup's most valuable business assets, but it also creates legal responsibility. The DPDP Act establishes important obligations around lawful processing, transparency, consent, security, retention, customer rights and accountability. Other Indian laws and sector specific regulations may add further requirements. For founders, compliance should begin with practical steps rather than complex bureaucracy. Map the information you collect, explain its use clearly, obtain appropriate consent where required, protect the data, control vendors, establish deletion practices and prepare for customer rights and security incidents. The official MeitY resources on the DPDP Rules 2025 should be monitored for implementation updates. Startups should also review the Information Technology Act framework on India Code and applicable sector specific regulations relevant to their business. Privacy is easier to build than repair. For a growing startup, responsible customer data management can become part of the foundation for sustainable and trusted growth. Frequently Asked Questions (FAQs) Q1. Does the DPDP Act apply to small startups? Yes. The framework is based primarily on the processing of digital personal data and the role of the organisation. Being a small or early stage company does not by itself remove privacy responsibilities. Q2. Does a startup need a privacy policy? A startup processing personal data should provide appropriate privacy information. Under Section 5, notices must accompany or precede consent requests and must explain relevant personal data, purposes and rights. The 2025 Rules provide more detailed notice requirements. Q3. Is consent always required to process customer data? Not necessarily. Section 4 permits processing for a lawful purpose based on consent or certain legitimate uses identified under the Act. The correct ground should be assessed for each processing activity. Q4. Can a startup collect customer information for future use? A startup should avoid collecting personal data without a defined and lawful purpose. Where consent is used, it must relate to specified processing and be limited to data necessary for the stated purpose. Q5. What should a startup do after a customer withdraws consent? Where consent is the basis of processing, the startup must cease processing within a reasonable time and cause its Data Processors to cease processing unless continued processing is required or authorised under applicable law. Q6. Does a startup need to delete customer data? Personal data should generally be erased when the specified purpose is no longer being served or when consent is withdrawn, subject to applicable legal retention requirements. Q7. Are startups responsible for data handled by cloud vendors? A Data Fiduciary's security obligations extend to processing undertaken by a Data Processor on its behalf. Startups should therefore conduct appropriate vendor due diligence and establish contractual and technical safeguards. Q8. Does every startup need a Data Protection Officer? No. The statutory Data Protection Officer requirement applies to Significant Data Fiduciaries under Section 10. Q9. What happens if a startup suffers a data breach? The startup may have obligations under the DPDP framework to notify affected Data Principals and the Data Protection Board in the prescribed manner. Separate cyber incident reporting obligations may also apply, including CERT In requirements. Q10. When should a startup begin DPDP compliance? The best time is before substantial customer data accumulates. Although the principal operational requirements have a phased commencement timeline, early preparation allows the startup to build privacy into its systems instead of making costly changes later. MeitY has published the official Rules and enforcement timeline.
cross-border data transfers
Cross-Border Data Transfers Under Indian Data Protection Laws
Businesses increasingly depend on global cloud infrastructure, international group companies, overseas vendors and remote service providers. As a result, cross-border data transfers have become an important legal and operational issue for organisations operating in India. Personal data may move from an Indian customer to a cloud server overseas, from an Indian subsidiary to its foreign parent company, or from an Indian business to an international analytics or support provider. India's regulatory framework is evolving through the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. The framework generally permits international transfers, while giving the Central Government power to restrict transfers to specified countries or territories. However, this does not mean businesses can ignore sector specific localisation rules, contractual obligations, security requirements or foreign privacy laws. Understanding these overlapping requirements is essential for organisations managing international data flows. What Are Cross Border Data Transfers? A cross border data transfer occurs when personal data is transferred, accessed, stored or otherwise processed across national boundaries. The concept can cover more than simply sending a database from India to another country. For example, an Indian company may use a cloud provider whose servers are located overseas. An Indian subsidiary may allow its parent company in another country to access employee information. A software provider may send customer information to an overseas support centre. Even remote access by an overseas service team can create an international data flow depending on the circumstances and applicable law. The legal assessment therefore needs to examine the complete data journey rather than only the physical location of the primary database. India's Legal Framework for International Data Transfers The principal framework is the Digital Personal Data Protection Act, 2023, commonly referred to as the DPDP Act. The Act was enacted on 11 August 2023 and establishes India's general framework for processing digital personal data. Section 16 is particularly important for international transfers. It adopts a relatively permissive model. A Data Fiduciary may transfer personal data outside India unless the Central Government restricts transfer to a particular country or territory through notification. This approach differs from the European Union model, where transfers to third countries are governed by a more structured adequacy and safeguards framework. The DPDP Rules, 2025 provide additional detail. Rule 15 permits personal data processed under the Act to be transferred outside India, subject to requirements the Central Government may specify concerning making such data available to a foreign State or an entity under the control of, or an agency of, such State. Businesses should therefore avoid treating international transfer as automatically unrestricted. The general position is permissive, but restrictions and other legal requirements may apply. Is Cross Border Data Transfer Permitted Under the DPDP Act? Yes. The DPDP Act does not impose a blanket prohibition on transferring personal data outside India. Its approach is commonly described as a negative list model. Instead of requiring every destination to be approved before a transfer can occur, the law allows transfers unless the Central Government restricts a destination. This is an important distinction for multinational companies. The DPDP Act does not currently create a general requirement for organisations to use Standard Contractual Clauses merely because personal data leaves India. However, Section 16 also preserves the operation of other Indian laws offering a higher degree of protection or imposing greater restrictions on international transfers. Consequently, compliance cannot stop with checking the DPDP Act. Current Enforcement Position in India A critical point for businesses is the phased commencement of the DPDP framework. The DPDP Act was enacted in 2023, while the final DPDP Rules were notified in November 2025. MeitY has published the Rules together with the official enforcement timeline. The substantive provisions relating to international transfers are part of the eighteen month implementation phase. Section 16 and Rule 15 are expected to become operational in May 2027 based on the commencement notifications issued in November 2025. Current legal commentary identifies 13 May 2027 as the relevant date. This phased approach should not be misunderstood as a reason to delay compliance planning. Businesses with international data flows need time to identify destinations, review vendors, update agreements, assess sector specific requirements and establish internal controls. Does India Require Data Localisation? The DPDP framework should not be confused with a universal data localisation requirement. The general DPDP position allows international transfers unless the Government restricts particular destinations. It does not require every category of personal data to remain physically stored in India. However, localisation requirements can arise from other Indian laws and regulatory frameworks. The Reserve Bank of India provides an important example. Its Storage of Payment System Data direction requires payment system providers to store the entire payment system data in systems located in India. The RBI also provides specific treatment for the foreign component of cross border transactions. Therefore, an organisation should never ask only whether the DPDP Act permits an overseas transfer. It should also ask whether a sector specific regulator imposes a separate storage, access or processing requirement. This distinction is especially relevant to financial services, payments, insurance, telecommunications, healthcare and other regulated industries. How Sector Specific Laws Affect International Transfers Section 16 operates alongside other applicable Indian legislation and regulatory requirements. For example, payment businesses need to consider RBI requirements concerning payment data. The RBI has clarified that while certain payment processing may occur outside India, prescribed payment data must continue to be stored in India. An organisation operating in a regulated sector may therefore face a layered compliance structure. The DPDP Act may permit an international transfer while another regulation restricts where particular information can be stored or processed. This makes a data flow assessment more useful than a simple country based checklist. What Businesses Should Check Before Transferring Data Overseas The first step is to identify the data being transferred. Organisations should determine whether the information constitutes personal data under the applicable framework and identify the individuals concerned. The next step is to establish the purpose of the transfer. A transfer for payroll administration, customer support, cloud hosting, fraud monitoring and international analytics may each involve different recipients and different legal risks. Businesses should then identify the destination country, recipient organisation, processing location and any onward transfer arrangements. Vendor contracts deserve particular attention. Where an overseas service provider processes personal data on behalf of an Indian Data Fiduciary, the agreement should clearly define the processing relationship, permitted purposes, confidentiality obligations, security measures, assistance requirements and incident handling responsibilities. The organisation should also understand whether the overseas provider can appoint sub processors and whether data may be transferred to additional jurisdictions. Why Data Mapping Matters A strong cross border compliance programme begins with accurate data mapping. Many organisations know which software platforms they use but do not know precisely where personal data travels within those systems. A customer relationship management platform may involve servers in several countries. An international payroll provider may allow access from multiple jurisdictions. A cloud backup may replicate information automatically. A data map should therefore record the source of the information, categories of personal data, purpose of processing, recipient, destination country, storage location, access location, retention period and applicable legal restrictions. This information creates an evidence trail for compliance decisions and helps organisations respond quickly when laws or government restrictions change. Contractual Safeguards for Overseas Vendors Indian law should be considered alongside the contractual framework governing an international relationship. A data processing agreement can establish practical controls even where Indian law does not prescribe a specific transfer instrument. The agreement can address confidentiality, security, permitted processing, deletion, breach reporting, audit rights, subcontracting and assistance with individual rights. For multinational organisations subject to the GDPR or another foreign privacy regime, additional transfer mechanisms may be necessary. Standard Contractual Clauses, Binding Corporate Rules or other recognised mechanisms may become relevant under the law governing the outbound transfer. These mechanisms should not be described as mandatory DPDP transfer tools. Their relevance usually comes from another applicable legal regime. GDPR and Indian Cross Border Transfers The DPDP framework differs materially from the GDPR. The GDPR generally regulates international transfers through adequacy decisions and specified safeguards. These include Standard Contractual Clauses and Binding Corporate Rules, alongside other mechanisms under Chapter V. India instead uses a more permissive statutory model under Section 16. Transfers are generally allowed unless the Central Government restricts particular countries or territories. This difference matters for Indian businesses serving European customers. An Indian company may satisfy the Indian transfer framework while still needing to meet GDPR requirements for data originating from the European Economic Area. The correct approach is therefore to identify every applicable jurisdiction rather than assume one country's compliance automatically satisfies another. What About Overseas Cloud Providers? Using an international cloud provider does not automatically mean a business is violating Indian data protection law. The legal assessment depends on the type of data, processing arrangement, storage location, access arrangements, applicable sectoral rules and any government restrictions. Businesses should obtain sufficient information from cloud providers about data residency, replication, remote access, subcontractors, security controls and deletion practices. A cloud contract should also be reviewed from a privacy perspective rather than treated purely as an information technology agreement. International Transfers and Data Security Cross border compliance is closely connected with information security. Moving personal data to another jurisdiction can increase exposure to unauthorised access, government requests, security incidents and uncontrolled onward transfers. Organisations should therefore apply appropriate technical and organisational safeguards throughout the data lifecycle. Encryption, access controls, authentication, logging, monitoring, data minimisation and secure deletion can reduce risk. The appropriate controls depend on the nature and volume of data and the potential consequences of misuse. Security should also be considered when selecting international processors. A transfer to a permitted destination does not make an insecure processing arrangement acceptable. What Happens If a Data Breach Occurs Overseas? An international incident can create obligations in more than one jurisdiction. An organisation should maintain a documented incident response process covering identification, containment, investigation, assessment, notification and remediation. The DPDP framework introduces breach related obligations for Data Fiduciaries, while other laws may impose separate reporting requirements. CERT In directions also require specified cyber incidents, including data breaches and data leaks, to be reported within the prescribed six hour period from noticing the incident. Organisations should therefore assess the applicable cyber security reporting requirements separately from privacy obligations. The existence of an overseas processor does not necessarily remove the Indian organisation's responsibility. Contracts should clearly allocate operational responsibilities and escalation procedures. Practical Compliance Roadmap for Cross Border Data Transfers Organisations preparing for the DPDP framework should begin with a complete inventory of international data flows. The next stage is to classify each transfer according to the type of information, purpose, recipient, destination and applicable law. Businesses should then identify sector specific localisation requirements and assess whether the destination could become subject to a future government restriction. Vendor agreements should be reviewed and updated where necessary. Privacy notices should accurately describe relevant processing activities. Security controls should be tested, and internal teams should understand how international data flows are approved and monitored. A transfer register can provide a central record of these decisions. It should be reviewed periodically rather than treated as a one time exercise. Organisations with complex international structures may also benefit from specialist cross-border data protection services when conducting transfer assessments, vendor reviews and international privacy compliance exercises. What Should Multinational Companies Do Before 2027? The remaining transition period should be used to build operational readiness. Indian subsidiaries should identify all transfers to parent companies, affiliates and global service providers. Indian companies serving overseas customers should determine whether foreign privacy laws apply alongside Indian requirements. Organisations should also review contracts for cloud services, customer relationship management platforms, payroll systems, marketing technology, analytics tools and outsourced support. A robust compliance programme should be capable of answering five basic questions quickly: what personal data leaves India, why it leaves, where it goes, who can access it and which law permits or restricts the transfer. Maintaining this evidence will become increasingly important as international data governance develops. Where cross border arrangements form part of a broader corporate structure, corporate compliance legal support can help align contractual, regulatory and governance requirements across different business functions. Penalties and Compliance Risk The DPDP Act provides significant financial penalties for certain breaches. The Schedule includes penalties of up to ₹250 crore for specified failures relating to security safeguards, while other categories carry lower maximum amounts. The financial exposure is only one part of the risk. Non compliant transfers can also create contractual disputes, regulatory scrutiny, customer concerns, operational disruption and difficulties during mergers, acquisitions or international due diligence. For this reason, cross border data governance should be treated as part of enterprise risk management rather than as a narrow privacy function. Conclusion Cross border data transfers are becoming a central issue for Indian businesses operating in a global digital economy. India's DPDP framework takes a comparatively permissive approach by allowing international transfers unless particular destinations are restricted. Yet this does not create a simple free transfer regime. Businesses must consider sector specific localisation rules, contractual controls, security safeguards, overseas privacy laws and future government notifications. The distinction between permission to transfer and responsibility to govern the transfer is especially important. With the substantive transfer framework moving towards implementation in 2027, organisations should use the transition period to map international data flows, assess overseas vendors, strengthen contracts and establish clear governance processes. A well documented transfer framework can help businesses support international operations while maintaining compliance with India's evolving data protection landscape. Frequently Asked Questions (FAQs) Q1. Is cross border data transfer allowed under Indian law? Yes. The DPDP Act generally permits transfer of personal data outside India, subject to restrictions which may be imposed by the Central Government and any stricter requirements under other applicable Indian laws. Q2. Does the DPDP Act require all personal data to be stored in India? No. The DPDP Act does not establish a universal data localisation requirement. However, sector specific laws and regulations may impose storage or processing restrictions for particular categories of data. Q3. What is Section 16 of the DPDP Act? Section 16 establishes India's principal statutory framework for transfer of personal data outside India. It permits transfers subject to restrictions which the Central Government may notify. Q4. What is Rule 15 of the DPDP Rules 2025? Rule 15 deals with transfer of personal data outside India and allows such transfers subject to requirements which the Central Government may specify concerning making data available to a foreign State or related entities. Q5. Are Standard Contractual Clauses mandatory under Indian DPDP law? The DPDP Act does not establish GDPR style Standard Contractual Clauses as a general mandatory mechanism for every international transfer. SCCs may nevertheless be required where another applicable privacy law, such as the GDPR, governs the transfer. Q6. Can Indian companies use overseas cloud servers? Generally, yes, subject to the DPDP framework, applicable sector specific requirements, contractual obligations, security requirements and any restrictions notified by the Central Government. Q7. Do sector specific localisation rules still apply? Yes. The DPDP framework does not eliminate stricter requirements imposed by other Indian laws. RBI payment data requirements provide an important example. Q8. When will the main cross border transfer provisions become operational? Section 16 of the DPDP Act and Rule 15 of the DPDP Rules are part of the eighteen month implementation phase and are expected to become operational on 13 May 2027 based on the November 2025 commencement notifications. Q9. Does an overseas vendor become responsible for DPDP compliance? The contractual relationship and statutory allocation of responsibilities must be examined carefully. A Data Fiduciary remains responsible for its obligations under the DPDP framework, while processors should be governed through appropriate contractual and security controls. Q10. What should a business do before transferring personal data abroad? The business should identify the data, purpose, recipient and destination, check applicable Indian and foreign laws, review sector specific restrictions, assess the vendor, establish contractual safeguards and maintain records of the transfer decision.
privacy compliance framework,
How to Build a Privacy Compliance Framework for Your Organisation
A strong privacy compliance framework gives an organisation a structured way to manage personal data from collection to deletion. It connects legal requirements with everyday business processes, technology, contracts and employee responsibilities. For Indian organisations, this has become increasingly important following the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. The Rules were notified by the Ministry of Electronics and Information Technology in November 2025 and introduced a phased implementation structure. Privacy compliance is no longer simply a matter of publishing a privacy policy. An organisation needs to understand what personal data it collects, why it collects it, where it is stored, who can access it, which third parties receive it and when it should be deleted. A practical framework brings these activities together so privacy becomes part of business operations rather than a document prepared only when a regulatory issue arises. What Is a Privacy Compliance Framework? A privacy compliance framework is an organised system of policies, procedures, controls, responsibilities and monitoring mechanisms used to manage personal data lawfully and responsibly. It should explain how the organisation identifies privacy obligations and converts them into operational controls. The framework normally covers data collection, notices, consent, legitimate uses, data security, access management, retention, deletion, individual rights, grievance handling, vendor management, incident response and internal accountability. The exact structure will depend on the organisation. A technology company processing large volumes of customer information will have different risks from a manufacturer primarily processing employee and supplier information. A healthcare business, financial institution or education provider may also have sector specific obligations. A good framework therefore starts with the organisation's actual data environment rather than copying a generic policy template. Why Organisations Need a Privacy Compliance Framework? Personal data moves through many parts of a modern organisation. Marketing teams may collect information through websites. Sales teams may store customer details in CRM platforms. Human resources departments maintain employee records. Finance teams process payment and tax information. Technology teams operate cloud infrastructure. External vendors may process information on behalf of the organisation. Without central oversight, these activities can develop independently. One department may retain information for years while another deletes it after a few months. A vendor may receive more information than it needs. A website may collect information not mentioned clearly in its privacy notice. A privacy compliance framework provides consistency. It also creates evidence of responsible governance. This becomes particularly important when an organisation needs to demonstrate how it identified risks, implemented controls and responded to an incident. The International Bar Association has noted the importance of a centralised privacy compliance approach in India because the DPDP framework operates alongside sector specific legal requirements. Different sectors may have different retention and operational requirements, making a coordinated framework valuable for organisations with complex data environments. Understand Which Laws Apply to Your Organisation The first step is determining the legal landscape relevant to the organisation. The DPDP Act is central to India's digital personal data regime, but it should not automatically be treated as the only applicable law. An organisation may also need to consider sector specific regulations, contractual obligations, cybersecurity requirements and foreign privacy laws if it processes information relating to individuals in other jurisdictions. The DPDP Act applies to the processing of digital personal data within India in the circumstances specified by the legislation. It can also apply to processing outside India where the processing is connected with offering goods or services to Data Principals in India. Organisations should therefore document their regulatory scope before designing controls. This prevents a common compliance problem where policies are drafted first and legal requirements are considered later. For the latest statutory material, businesses should refer to the Ministry of Electronics and Information Technology's official Act and policy resources. Map Personal Data Across the Organisation Data mapping is one of the most important foundations of a privacy programme. An organisation cannot properly protect information if it does not know where the information exists. The exercise should identify the categories of personal data collected, the source of the information, the purpose of processing, relevant systems, internal users, external processors, storage locations, retention periods and deletion methods. For example, an ecommerce business may collect names, addresses, contact details, transaction information and customer support records. These datasets may move between the website, payment providers, logistics companies, CRM platforms and cloud services. The organisation should document these flows and identify whether each processing activity is necessary for the stated purpose. PwC's analysis of India's DPDP requirements similarly highlights the importance of creating an inventory of applications and data stores and identifying third party processors involved in personal data processing. Data mapping should not be treated as a one time exercise. New software, vendors, products and marketing tools can change the data environment. The map should therefore be reviewed periodically. Establish Clear Data Governance and Accountability A privacy framework needs clearly assigned ownership. Legal, compliance, information security, IT, human resources, procurement, marketing and product teams may all handle personal data. Senior management should define who is responsible for privacy governance and how privacy issues are escalated. The DPDP Act creates specific additional obligations for Significant Data Fiduciaries. These include appointment of a Data Protection Officer, appointment of an independent data auditor and periodic Data Protection Impact Assessments and audits. Not every organisation will fall into the Significant Data Fiduciary category. Even where a statutory DPO is not required, assigning internal responsibility for privacy can make compliance substantially more effective. Governance should also include reporting mechanisms. Management should know about significant privacy risks, unresolved rights requests, major vendor concerns and material security incidents. Build a Clear Notice and Consent Process Consent should be treated as an operational process rather than a checkbox on a website. Under the DPDP framework, organisations need to communicate clearly about the processing of personal data and provide appropriate mechanisms for consent where consent is the relevant ground for processing. The Act also recognises specified legitimate uses in circumstances prescribed by law. Privacy notices should therefore match actual business practices. If a company says it uses information only for account management but later uses the same information for unrelated marketing, the documentation and operational practice may become inconsistent.  Consent records should also be maintained in a manner which allows the organisation to understand when consent was obtained, for which purpose and how withdrawal is handled. For children, additional requirements apply. Section 9 of the DPDP Act provides for verifiable parental or guardian consent before processing a child's personal data, subject to the statutory framework and prescribed exemptions. It also restricts tracking, behavioural monitoring and targeted advertising directed at children, subject to specified exceptions. Implement Data Minimisation and Retention Controls A privacy programme should ask a simple question about every category of personal data: why does the organisation need it? Collecting information without a clear business purpose increases exposure. More data means more systems, access points, vendors and potential consequences if information is compromised. The organisation should define retention periods based on the purpose of processing and applicable legal or contractual obligations. Information should not remain indefinitely simply because storage is inexpensive. Retention schedules should also distinguish between operational data, records subject to statutory retention duties and information which can be securely deleted once its purpose has ended. Deletion should be practical. It may involve databases, backups, email systems, cloud storage, employee devices and third party platforms. Strengthen Security and Incident Response Privacy compliance and cybersecurity are closely connected but they are not identical. Security controls protect information from unauthorised access, loss, alteration or disclosure. Privacy governance also determines whether information should be collected, used or retained in the first place. The DPDP framework requires Data Fiduciaries to implement reasonable security safeguards. Organisations should translate this requirement into practical controls such as access management, authentication, encryption where appropriate, logging, vulnerability management, secure development practices and incident response procedures. An incident response plan should identify who receives an alert, who assesses the incident, who coordinates containment, who manages legal and regulatory reporting and who communicates with affected stakeholders. The DPDP Rules, 2025 introduce specific breach related requirements, making preparedness especially important as the phased framework moves towards full implementation. The official Rules and enforcement timeline are available through MeitY. Manage Vendors and Data Processors Carefully Third party risk is often overlooked when organisations design privacy programmes. A company may have strong internal controls while a vendor handling its customer or employee information operates with weaker safeguards. Vendor management should therefore form part of the privacy framework from procurement through contract termination. Before appointing a vendor, the organisation should understand what personal data the vendor will process, why the information is required, where it will be stored, who may access it and how incidents will be reported. Contracts should clearly establish responsibilities for data handling, security, confidentiality, assistance with rights requests, incident management, deletion and audit or assurance requirements where appropriate. Vendor reviews should also continue during the relationship. A supplier's services, systems or processing locations may change over time. Build Processes for Data Principal Rights The DPDP Act gives Data Principals specific rights relating to their personal data. These include rights concerning access to information, correction and erasure, grievance redressal and nomination, subject to the statutory conditions. A privacy framework should translate these rights into an internal workflow. The organisation needs a method for receiving requests, verifying the requester, identifying relevant records, coordinating with internal teams and responding within the applicable period. The process should also cover cases where information has been shared with processors. A rights request should not fail simply because relevant information is stored across multiple systems. Clear ownership is essential. Employees should know where requests are sent and who is responsible for coordinating the response. Embed Privacy Into Product Development Privacy should be considered before a new product, feature or service goes live. Product teams should ask what personal information a feature requires, whether the information is necessary, what users will be told, who will receive the information and how long it will be retained. Higher risk processing may require more detailed assessment. For Significant Data Fiduciaries, the DPDP Act specifically provides for periodic Data Protection Impact Assessments and audits. Privacy review can also improve product design. Early identification of privacy risks is usually easier and less expensive than changing systems after launch. Train Employees and Create a Privacy Culture Policies cannot protect information if employees do not understand their responsibilities. Training should reflect the roles employees actually perform. Marketing teams may need guidance on consent and communications. HR teams may need stronger controls for employee information. Developers need secure data handling practices. Procurement teams need to identify privacy requirements when selecting vendors. Training should also cover practical scenarios such as phishing, accidental disclosure, unauthorised access, data sharing and incident escalation. Privacy awareness should be refreshed periodically rather than treated as an induction exercise. Monitor, Test and Improve the Framework A privacy compliance framework should evolve with the organisation. Periodic reviews can assess whether privacy notices still reflect actual practices, whether data maps remain accurate, whether vendors continue to meet requirements and whether deletion processes work as intended. Organisations can also maintain internal compliance metrics. Useful indicators may include unresolved rights requests, completion of privacy training, vendor assessment status, overdue remediation actions and the number of systems covered by the data inventory. Framework reviews should also consider regulatory developments. The DPDP Rules were notified in 2025 with an eighteen month phased implementation structure, making regulatory monitoring particularly important during the transition period. Common Mistakes When Building a Privacy Framework One of the biggest mistakes is treating the privacy policy as the entire compliance programme. A policy explains the organisation's approach, but it cannot replace operational controls. Another common problem is incomplete data mapping. Organisations often document customer information while overlooking employee records, marketing databases, customer support platforms, archived files and vendor systems. Some businesses also focus heavily on consent while neglecting security, retention and rights management. Consent is only one component of a broader privacy governance structure. A further mistake is creating procedures without assigning ownership. A process without a responsible person can fail when an urgent request or security incident occurs. Finally, organisations should avoid building a framework once and leaving it unchanged. Business models, technology, vendors and legal requirements evolve. Privacy governance must evolve with them. How Legal Support Can Strengthen Privacy Governance? Privacy compliance often involves questions extending beyond a standard privacy policy. Businesses may need to assess contractual arrangements, interpret statutory requirements, review vendor terms, address cross border processing, structure consent mechanisms or respond to regulatory developments. Engaging privacy compliance services can help an organisation convert legal requirements into practical policies, contracts, procedures and governance controls. The right approach should remain proportionate to the organisation's size, industry, data practices and risk profile. A strong privacy framework also benefits from broader corporate compliance support services, particularly where data protection intersects with employment, technology contracts, consumer protection, intellectual property, cybersecurity or sector specific regulation. The objective is not to create unnecessary paperwork. It is to establish a system where legal requirements are reflected in how the organisation actually handles information. A Practical Roadmap for Building the Framework An organisation starting from scratch can approach the process in stages. Begin by identifying applicable laws and business activities. Then conduct a data discovery and mapping exercise. Assess existing policies, contracts, systems and procedures against the identified requirements. Next, establish governance ownership and prioritise material risks. Update privacy notices, consent mechanisms, retention practices and vendor agreements. Build processes for Data Principal rights and grievance handling. Security controls should then be reviewed alongside incident response procedures. Employee training should follow implementation so employees understand the processes they are expected to follow. Finally, introduce periodic testing and management review. This creates a cycle of assessment, remediation and improvement rather than a one time compliance project. Conclusion A privacy compliance framework should be viewed as an operating system for responsible data governance. It connects legal obligations with people, processes, technology and contracts. For Indian organisations, the DPDP Act, 2023 and DPDP Rules, 2025 provide an important statutory foundation. Yet effective compliance requires more than reading the legislation. Businesses need visibility over their data, clear accountability, appropriate security measures, reliable rights processes, responsible vendor management and regular review. Organisations that build these controls into everyday operations are better placed to manage privacy risk as their products, workforce, customer base and technology environment grow. A practical framework also creates a stronger foundation for responding to regulatory change and demonstrating responsible data governance. Frequently Asked Questions (FAQs) Q1. What is a privacy compliance framework? A privacy compliance framework is a structured system of policies, procedures, responsibilities and controls used to manage personal data in accordance with applicable legal requirements and organisational standards. Q2. Is a privacy policy enough for compliance in India? No. A privacy policy is only one part of a wider privacy programme. Effective compliance also requires appropriate governance, data mapping, security safeguards, consent or other lawful processing mechanisms, retention controls, rights management and vendor oversight. Q3. Does the DPDP Act apply to all businesses in India? The DPDP Act has a defined scope based on the processing of digital personal data and specified circumstances. Organisations should assess their activities and any applicable exemptions rather than assuming the law applies in exactly the same way to every business. Q4. What is data mapping in privacy compliance? Data mapping identifies what personal data an organisation holds, where it comes from, why it is processed, where it moves, who can access it, which third parties receive it and when it should be deleted. Q5. Is a Data Protection Officer mandatory for every company? No. The DPDP Act specifically requires Significant Data Fiduciaries to appoint a Data Protection Officer. Other organisations may still benefit from assigning internal responsibility for privacy governance. Q6. How should businesses manage third party data processors? Businesses should identify what information each processor handles and establish appropriate contractual and operational controls covering security, confidentiality, permitted processing, incident response and deletion. Q7. How often should a privacy compliance framework be reviewed? The framework should be reviewed periodically and whenever there is a significant change in law, technology, business operations, products, vendors or data processing activities. Q8. What should a company do after discovering a privacy gap? The organisation should document the gap, assess its legal and operational significance, identify the responsible owner, establish a remediation plan and track completion. Higher risk issues may require immediate legal or technical intervention.
MHCO Updates
SEBI Update
REGULATORY UPDATE | SEBI ORDERS VARANIUM CLOUD TO RESTORE & DISGORGE FUNDS OVER IPO & RIGHT ISSUE FRAUD
The Securities and Exchange Board of India (“SEBI”) on 25 August 2025 passed a Final Order against Varanium Cloud Limited (“VCL”) and its key management for alleged fraudulent and misleading activities in connection with its Initial Public Offer (IPO), Rights Issue and subsequent disclosures. BACKGROUND The proceedings stemmed from SEBI’s preliminary examination pursuant to media reports and complaints regarding VCL’s financial statements and corporate announcements, which led to an Interim Order dated 10 May 2024 against VCL and its MD/Chairman, Harshwardhan Hanmant Sabale (Mr Sabale). VCL raised approximately Rs 40.39 crore through its IPO in September 2022 (primarily for Edge Data Centres and Edmission Digital Learning Centres) and proposed a further Rs. 48.45 crore through a Rights Issue in September 2023. SEBI examined the utilisation of issue proceeds, financial statements, Prospectus disclosures, corporate announcements, related-party transactions, and the role of directors, the CFO, the merchant banker and other intermediaries. SEBI’S FINDINGS SEBI found that VCL misrepresented its financial statements and prospectus by showing fictitious sales and purchases, and that its disclosures on utilisation of IPO proceeds (including the Statement of Deviation dated 17 November 2023) were incorrect and misleading. SEBI found that IPO and Rights Issue proceeds of Rs. 62.51 crore were diverted to related parties and other entities, including Rs. 32.73 crore transferred directly to Mr Sabale’s personal account. BM Traders (operated by Mr Raj Jagtani) received Rs. 19.66 crore in aggregate from the issue proceeds, of which Rs. 15.60 crore was transferred onwards; and that no adequate evidence of genuine business purpose was produced. SEBI found several business announcements by VCL to be false and unsubstantiated. SEBI also found that the Company also failed to support the substantial increase in reported revenues (including those of its US subsidiary) with invoices, contracts or employee details. Pending litigation was omitted from the Letter of Offer, and the Prospectus contained material omissions and misstatements. Liability was fastened on the Company, its MD, Executive Directors and CFO. SEBI found that the lead manager, First Overseas Capital Limited (FOCL), failed to exercise independent due diligence and did not disclose pending litigation. SEBI rejected FOCL’s defence that  it  could  rely  on  the  Company’s  representations  and  third-party  reports. Athos Capital Advisors Private Limited (ACAPL) and Mr Jinesh Mehta were held to have aided and abetted the misrepresentations; ACAPL received approximately Rs. 2.50 crore from VCL, and Mr Mehta admitted drafting portions of the Prospectus and assisting with fundraising. SEBI’S DIRECTIONS VCL was directed to bring back Rs. 62.51 crore (with 12% p.a. interest) within three months. Mr Sabale was directed to disgorge unlawful gains of Rs. 128.77 crore (with 12% p.a. simple interest) to the Investor Protection and Education Fund. VCL and Mr Sabale were debarred from the securities market for 7 years. ACAPL and Mr Jinesh Mehta were debarred for 2 years; Mr Raj Jagtani/BM Traders for 4 years; the Executive Directors and CFO (Mr Vinayak Jadhav, Mr Mukundan Raghavan and Mr Fahim Shaikh) for 1 year; and FOCL for 2 years (to run consecutively with an earlier debarment). Monetary penalties were also imposed, including Rs. 20.40 crore on Mr Sabale, Rs. 13 crore on VCL and Rs. 10.10 crore on Mr Raj Jagtani. Proceedings against the Company Secretary (Ms Hetal Somani) and a Non-Executive Director (Mr Kalpesh Acharekar) were disposed of without directions or penalty, the allegations against them being found unsustainable. MHCO COMMENT The order is significant for its treatment of misrepresentation in financial statements and public-issue disclosures, diversion of IPO and Rights Issue proceeds, and the accountability of directors, KMPs and intermediaries. It reiterates that a lead manager must conduct independent due diligence and cannot merely rely on the issuer’s representations or third-party reports. SEBI did not fasten liability on every director or officer; allegations against the Company Secretary and non-executive director were dropped for want of material. Overall, SEBI characterised the matter as a fraudulent scheme of raising public funds on misleading disclosures, followed by diversion of proceeds and creation of a false picture of the Company’s performance. The restoration, disgorgement, debarment and penalty directions reflect the seriousness with which the conduct was viewed. By: Mr. Bhushan Shah, Partner Mr. Abhishek Nair, Associate Ms. Sayali Kshirsagar, Associate
Rea Estate
BOMBAY HIGH COURT ALLOWS REFUND OF STAMP DUTY PAID ON CANCELLED DEVELOPMENT AGREEMENT
The Bombay High Court, vide judgment dated 20 August 2026 in Sai Innovation v. Joint District Registrar and Collector of Stamps, Pune City & Ors. (Writ Petition No. 7566 of 2016), has held that a Development Agreement which fails to achieve its intended purpose and is subsequently cancelled can qualify for refund of stamp duty under Section 47(c)(5) of the Maharashtra Stamp Act, 1958 (“the Stamp Act”), and that such an agreement can avail the extended limitation period under the proviso to Section 48(1) where stamp duty has been calculated with reference to Article 25 of Schedule I. Background: Sai Innovation had entered into a Development Agreement (“said Agreement”) dated 15 April 2013 with the owners of land at Village Mauje Balewadi, Pune, for development of approximately 8,000 sq. metres of land and paid stamp duty under Article 25 read with Article 5 of Schedule I to the Stamp Act. The owners were unable to obtain sanction of the building plans within a reasonable time, and disputes subsequently arose between the parties. The said Agreement was therefore cancelled by a registered Deed of Cancellation (“said Deed”) dated 18 February 2014, registered on 24 February 2014, and the consideration received was returned. Sai Innovation thereafter applied on 7 April 2014 for refund of the stamp duty. The Respondent Nos 1&2 vide their orders dated 11 August 2014 and 6 December 2014 (“Impugned Orders”) respectively, rejected the refund application of the Petitioner, principally on the ground that the said Agreement was not a “conveyance” and therefore did not fall within the proviso to Section 48(1) of the Stamp Act. Issue: The Court dealt with the following issues: Whether the said Agreement had failed to achieve its intended purpose to attract Section 47(c)(5) of the Stamp Act; Whether a Development Agreement could avail the benefit of the proviso to Section 48(1), particularly where stamp duty was calculated as per Article 25 of Schedule I; Whether the reference to “actual, open possession” in Clause 13 of said Agreement be interpreted as transfer of possession to the developer, notwithstanding Clause 11 of the said Agreement which described the developer as a licensee; and Whether the Respondents could subsequently rely upon the alleged transfer of possession as a ground for rejecting the refund claim, when the refund claim had initially been rejected by the Impugned Orders on other grounds, and the issue of possession did not form part of the reasons recorded in those orders. Key Findings The Court, while differentiating between Section 47 and Section 48 of the Stamp Act, held that while Section 47 is the main provision that gives the right to a refund of stamp duty, Section 48 only deals with the time limit. In the present case, the proposed development under the said Agreement was never acted upon, and the parties later cancelled the said Agreement by the said Deed. As a result, the transaction had clearly failed to achieve its intended purpose under Section 47(c)(5) of the Stamp Act. The Court therefore said the refund claim had to be examined first under Section 47 and could not be turned down simply by pointing to the limitation period. On the question of possession, the Court held that Clause 13 of the said Agreement could not be read in isolation from Clause 11. Although Clause 13 referred to “actual, open possession”, Clause 11 expressly described the developer’s rights as those of “a licensee for development”. Reading the Agreement as a whole, the Court concluded that the developer was granted only a limited contractual licence to enter the property and undertake development activities, and that there was no transfer of legal or exclusive possession. The Court also noted that the absence of a separate possession receipt, by itself, did not establish that possession had been transferred. Held In light of the above reasoning, the Court allowed the writ petition and quashed the Impugned Orders passed by the Respondents. The Court held that the refund application was filed within the extended period prescribed under the proviso to Section 48(1) of the Stamp Act and, accordingly, rejected the Respondents’ objection that the claim was barred by the ordinary six-month limitation period. MHCO Comment Parties seeking refund of stamp duty on a cancelled Development Agreement should note that Section 47 governs the substantive entitlement to refund, while the proviso to Section 48(1) determines the applicable limitation period. Further, the legal character of a Development Agreement should be assessed by reading the same meaningfully and not in isolation from other clauses provided therein. By: Mr. Bhushan Shah, Partner Ms. Meeta Kadhi, Associate Partner Mr. Saptadip Nandi Chowdhury, Associate
SEBI Update
REGULATORY UPDATE | SEBI IMPOUNDS ₹ 3.67 CR FROM TWO ENTITIES FOR ALLEGED MANIPULATIVE TRADES DURING CLOSING AUCTION SESSION
BACKGROUND The Securities and Exchange Board of India (“SEBI”) passed an Ex-Parte Interim Order dated 19 August 2026 against Copthall Mauritius Investment Limited (“Copthall”) and Mansi Share and Stock Broking Private Limited (“Mansi”) in relation to alleged manipulative trading during the Closing Auction Session (“CAS”) on the BSE SENSEX expiry day. SEBI's CAS framework, introduced vide Circular dated 16 January 2026 and made effective from 3 August 2026, provides for determination of the closing price through a dedicated auction mechanism based on the interaction of buy and sell orders. The framework replaced the earlier methodology based on the volume-weighted average price (“VWAP”) for securities covered under the CAS framework, which determined the price of securities based on the closing price of the security or focused on the weight of trades executed in the last 30 minutes of the trading session. Now, under the CAS framework, the price of securities is determined based on buy and sell orders in a single pool, executed at a single equilibrium price in a dedicated 20-minute daily auction timeline. SEBI’S FINDING SEBI prima facie found that the trading activity of Copthall and Mansi was linked to their outstanding SENSEX option positions and was undertaken to influence the Indicative Equilibrium Price (“IEP”) and closing price of the SENSEX so as to obtain a favourable payoff from their expiry-day F&O positions. On 13 August 2026, SEBI's surveillance observed three sharp movements in the SENSEX during the CAS. Upon examination of the trade and order logs, SEBI observed that these movements coincided with large and aggressive buy orders placed by Copthall and sell orders placed by Mansi in SENSEX constituent securities, which were subsequently cancelled. SEBI accordingly examined the trading activity of the two entities and its linkage with their outstanding SENSEX option positions. SEBI noted that the material on record did not prima facie indicate that the two Noticees acted in concert. Rather, each appeared to have adopted a separate strategy to move the SENSEX in a direction favourable to its respective F&O positions. SEBI'S DIRECTIONS SEBI directed that the bank accounts of Copthall and Mansi be impounded to the extent of ₹2,96,16,000 and ₹71,64,773 respectively, aggregating a total of ₹3,67,80,773. SEBI also debarred the noticees from accessing the securities markets and prohibited them from participating in the CAS, including placing, modifying or cancelling orders. Restrictions were also imposed on their bank and demat accounts, transfer/redemption of securities and disposal of assets without SEBI's permission. They were further directed to cooperate with SEBI's ongoing examination/investigation. MHCO COMMENT The order is significant in the context of the newly introduced CAS framework and SEBI's surveillance of potential attempts to influence the closing price through order placement and cancellation. The order demonstrates that SEBI is examining the nature, timing and price of orders, their impact on the IEP, subsequent cancellation of orders and the corresponding F&O positions of the concerned entities. The directions are interim in nature and are based on prima facie findings pending further investigation. SEBI has expressly clarified that the detailed investigation is to proceed independently of the prima facie observations contained in the interim order. Notably, SEBI has not alleged that Copthall and Mansi acted in concert. The findings against the two entities are based on their respective trading patterns and F&O positions. Since the order is ex-parte and interim in nature, the findings remain subject to SEBI's further examination, as well as the Noticees' replies and opportunity of hearing. By: Mr. Bhushan Shah, Partner Ms. Sayali Kshirsagar, Associate
IBC Update
IBC UPDATE - REMOVAL OF INTERIM MORATORIUM FOR PERSONAL GUARANTORS APPLIES TO PENDING PROCEEDINGS
Recently, the Bombay High Court in the case of Tata Capital Financial Services Limited v. Neel Motors LLP & Ors., held that the amendment introducing Section 96(4) of the Insolvency and Bankruptcy Code, 2016 (“IBC”) applies to insolvency applications filed before that date which remain pending. The Court consequently held that the interim moratorium under Section 96 ceased to operate against the personal guarantors from 26 May 2026, enabling Tata Capital to pursue limited interim relief under Section 9 of the Arbitration and Conciliation Act, 1996 (“Arbitration Act”). FACTS: The Petitioner, Tata Capital Financial Services Limited (“Tata Capital”) extended financial assistance to Respondent No. 1, Neel Motors LLP, under a Channel Finance Agreement. Respondent Nos. 2 to 4 were individual guarantors and partners of Neel Motors LLP, while Respondent No. 5 was a separate LLP acting as guarantor. The Letters of Guarantee contained arbitration clauses with Mumbai as the seat. In 2021, Tata Capital filed a petition under Section 9 of the Arbitration Act seeking interim protection. Approximately one month prior to filing the Section 9 petition, Tata Capital had initiated Corporate Insolvency Resolution Process (“CIRP”) against Neel Motors under the IBC. The CIRP ultimately failed and Neel Motors was ordered to be liquidated by the NCLT, Mumbai, on 1 April 2022. Thereafter, in June 2022, Tata Capital initiated insolvency proceedings under Section 95 of the IBC against Respondent Nos. 2, 3 and 4, who were the individual guarantors (“Guarantors”). The filing of the Section 95 applications triggered the interim moratorium under Section 96, stalling the Section 9 petition. The legal position changed with the insertion of Section 96(4) into the IBC which came into force on 26 May 2026. The amendment provided that Section 96 would not apply where an application was filed for initiating an insolvency resolution process in respect of a personal guarantor to a corporate debtor. Relying upon the amendment, Tata Capital sought consideration of its pending Section 9 petition. The principal issue before the Court was whether Section 96(4) could apply to Section 95 applications which had been filed before 26 May 2026 but continued to remain pending on the date of the amendment. Tata Capital’s Case Tata Capital contended that, in view of the newly inserted Section 96(4), the moratorium under   Section 96 no longer operated against the individual guarantors and the expression “where an application is filed” was sufficiently broad to include pending applications. It further relied upon the legislative purpose behind the amendment, that it was intended to “remove any perverse incentives” associated with the initiation of individual insolvency proceedings. Considering the considerable delay since filing of the Section 9 petition, Tata Capital only sought disclosure of the guarantors’ assets and an injunction restraining them from selling, transferring, alienating, encumbering or otherwise dealing with such assets pending arbitration. Guarantor’s Case The guarantors opposed the application, contending that such an interpretation would give the amendment retrospective effect. They submitted that the expression “where an application is filed” covers only applications filed after 26 May 2026 and could not extend to applications which had already been filed. Any other interpretation, according to the guarantors, would retrospectively alter the legal consequences attached to the pending proceedings. They further argued that although insolvency proceedings are not strictly recovery proceedings, both the insolvency and arbitration proceedings were directed towards recovery of the same debt and Tata Capital should therefore not be permitted to pursue both simultaneously Court’s Finding The Hon’ble Court held that the expression “where an application is filed” in Section 96(4) encompasses applications which had already been filed and continued to remain pending before the adjudicating authority. Had the legislature intended to restrict the provision only to applications filed after 26 May 2026, it could have expressly used language to that effect. The Court distinguished between retrospective and retroactive operation, relying upon the Supreme Court’s decision in Securities and Exchange Board of India v. Rajkumar Nagpal, the Court observed that a provision is retrospective when it operates backwards and impairs vested rights, whereas a retroactive provision operates prospectively on a character or status originating in the past. The existence of antecedent facts does not, by itself, make its application retrospective. Accordingly, the moratorium under Section 96 operated against Respondent Nos. 2 to 4 until 25 May 2026 but ceased from 26 May 2026 when Section 96(4) came into force. The pending Section 9 petition was therefore no longer barred by the IBC moratorium. The Court further acknowledged the possibility of a conflict of interest where the creditor initiating insolvency proceedings may also be pursuing claims against the individual guarantor. However, it held that such considerations could not override the express statutory language, particularly when Section 96(4) was agnostic as to the identity of the person who initiated the Section 95 proceedings. MHCO Comment Pending proceedings can be affected by a new provision without the provision necessarily being retrospective. The decisive factor is whether the provision changes completed past rights or operates prospectively upon an existing/pending legal status. Section 96(4) therefore lifted the Section 96 moratorium prospectively from 26 May 2026 even in respect of Section 95 applications filed prior to the amendment coming into force. By: Mr. Bhushan Shah, Partner Ms. Neha Lakshman, Associate Partner
LIFE AT MHCO
Need Help? Chat with us