CELEBRATING MORE THAN YEARS
AWARDS & RECOGNITION
UPDATES
PRACTICE AREAS
PEOPLE
News and Articles
e-commerce privacy compliance,
Privacy Compliance Challenges for E-commerce Businesses
Online shopping has transformed how businesses collect and use customer information. An e commerce platform may process names, mobile numbers, email addresses, delivery details, account information, purchase histories, device information and behavioural data within a single customer journey. This makes e-commerce privacy compliance a significant legal and operational responsibility for online businesses in India. The challenge is not limited to having a privacy policy. E commerce businesses need to understand why information is collected, how consent works, which vendors receive the information, how customer preferences are managed, how long information is retained and what happens when a security incident occurs. India's Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 provide the central privacy framework. However, e commerce businesses also operate within consumer protection, cybersecurity, payment and sector specific requirements. Why Privacy Compliance Is More Complex for E Commerce Businesses? An ordinary website may collect limited information. An e commerce platform often operates a much broader data ecosystem. A customer may browse products, create an account, add items to a cart, make a payment, provide a delivery address, contact customer support, leave a review and later receive personalised offers. Each interaction can create additional personal data. The information may then move between the website, mobile application, CRM platform, payment gateway, logistics provider, marketing platform, analytics service and cloud infrastructure. Personalisation adds another layer. Businesses may analyse purchase history, browsing activity and customer preferences to recommend products or target advertising. These practices can create privacy concerns if customers do not understand how their information is being used. Recent Indian analysis of the e commerce sector identifies personalisation, targeted advertising, dynamic pricing, recommendation systems and behavioural analytics as important areas of privacy risk. Understanding the DPDP Framework for E Commerce The Digital Personal Data Protection Act, 2023 regulates processing of digital personal data in India within its statutory scope. An e commerce platform will generally act as a Data Fiduciary because it determines the purpose and means of processing customer information. The Act recognises consent as one ground for processing and also permits certain legitimate uses. This distinction is important for e commerce businesses. Not every activity should be treated as requiring the same form of consent. Processing necessary to fulfil an order can have a different legal basis from optional marketing or other secondary uses. The Act also establishes obligations relating to notice, consent, security, personal data breaches, retention, Data Principal rights and grievance redressal. The official India Code version of the Act provides the complete statutory framework. Businesses should use the legislation itself rather than relying solely on generic online compliance checklists. The First Challenge Is Knowing What Data the Business Collects Many privacy problems begin with incomplete data mapping. An e commerce business may know what information its checkout page collects but have limited visibility over information generated elsewhere. For example, analytics tools may collect device identifiers. Marketing platforms may create customer profiles. Loyalty programmes may record purchasing patterns. Customer support systems may retain conversations. Delivery providers may receive addresses and contact numbers. A business should therefore map the complete customer data journey. The exercise should identify what information is collected, the purpose of collection, the system involved, the people or organisations receiving it, the processing location and the applicable retention period. Data mapping also helps identify unnecessary collection. If a checkout form asks for information which is not required for the transaction or another defined purpose, the business should question why it is being collected. Consent and Checkout Design Consent is one of the most important challenges for e commerce businesses. The DPDP Act provides specific requirements for consent. Consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. It should also be limited to personal data necessary for the specified purpose. This creates practical questions for online stores.  Should marketing consent be bundled with account creation? Can a customer be required to accept promotional communications to complete an order? Is a preselected marketing option appropriate? Can consent be withdrawn easily? Businesses should separate necessary transaction processing from optional marketing preferences wherever the legal basis differs. The Act itself provides an e commerce illustration involving an online shopping service, demonstrating the distinction between processing necessary to fulfil an order and the consequences of withdrawing consent. Good privacy design should therefore begin at checkout rather than being added after the purchase journey has already been built. Privacy Notices Must Match Actual Data Practices An e commerce privacy notice should reflect the platform's real processing activities. A generic statement saying “we collect information to improve our services” may provide little practical understanding. Customers should be able to understand what categories of personal data are collected and why. The notified DPDP Rules, 2025 prescribe more detailed requirements for notices, including clear and plain language, an itemised description of personal data and the purpose for processing. Rule 3 is part of the eighteen month commencement phase under the Rules. Businesses should therefore review privacy notices across websites, mobile applications, checkout pages, loyalty programmes and other customer touchpoints. The notice should also remain consistent with actual technology configurations. A privacy notice is not effective if the website uses tracking tools or shares information with vendors not reflected in the organisation's documented processing practices. Cookies, Tracking and Advertising Technologies E commerce businesses often use cookies, pixels, software development kits and advertising technologies to understand customer behaviour. These tools may support analytics, advertising, fraud prevention and personalisation. The privacy question depends on what information is collected, how it is linked to an individual and why it is used. Businesses should understand which tracking technologies operate on their websites and applications. They should also know which third parties receive the resulting information. Marketing consent should not be treated as an afterthought. A customer agreeing to receive promotional messages does not automatically mean every advertising technology may collect and analyse information for every purpose. The consent experience should correspond with the actual processing. Personalisation and Customer Profiling Personalisation can improve an online shopping experience. It can also create privacy concerns when businesses build detailed profiles from customer behaviour. A platform may analyse products viewed, searches conducted, previous purchases, location information or interaction with marketing communications. Businesses should define the purpose of such profiling and assess whether the information collected is necessary for it. The customer should also receive appropriate transparency where the applicable legal framework requires it. Recent Indian legal analysis specifically identifies targeted advertising, behavioural analytics, personalisation and dynamic pricing as areas requiring careful privacy and consumer law consideration. This is particularly important when automated systems influence product recommendations or other customer experiences. Dark Patterns and Privacy Choices Privacy compliance is also connected with interface design. A dark pattern can influence a user's decision through confusing, misleading or manipulative design. Examples may include making acceptance easier to find than rejection or presenting privacy choices in a way which discourages meaningful choice. The Central Consumer Protection Authority has issued Guidelines for Prevention and Regulation of Dark Patterns, 2023. The Department of Consumer Affairs lists these guidelines alongside the Consumer Protection framework. E commerce businesses should therefore assess privacy interfaces alongside consumer protection requirements. The legal question is not simply whether a button exists. The overall design of the customer journey matters. Customer Rights and Request Management The DPDP Act provides Data Principals with rights including access to information about personal data, correction and erasure, grievance redressal and nomination. For e commerce businesses, responding to these requests can be complicated. Customer information may exist in an account database, CRM system, payment platform, customer support tool and marketing system. A request for correction or erasure may therefore require action across several systems. The business needs a process for authenticating requests, locating relevant information, assessing the request and coordinating with Data Processors. Technology can assist, but governance remains important. Automated deletion without understanding legal retention requirements can also create problems. Retention and Deletion of E Commerce Data Online platforms often retain information because storage is inexpensive. This does not mean indefinite retention is appropriate. The DPDP Act provides for erasure when retention is no longer necessary for the specified purpose, subject to applicable legal requirements. The 2025 Rules introduce a specific retention framework for certain large e commerce entities. Rule 8 and the Third Schedule address an e commerce entity with not less than two crore registered users in India. For specified purposes, the framework provides a three year period calculated from the relevant last interaction or commencement of the Rules, whichever is later, subject to the exceptions in the Rules. Businesses should therefore avoid applying the large platform retention rule to every e commerce business. Its scope depends on the statutory conditions. For smaller businesses, retention should still be assessed according to the applicable purpose, legal requirements and broader data governance framework. Payment Data and Third Party Providers Payments create another major compliance challenge. E commerce platforms may integrate payment gateways, banks, wallet providers and other payment service providers. A business should understand what payment information it actually receives and what information remains with the payment provider. The organisation should avoid collecting payment information unnecessarily when the transaction can be completed through a specialised provider. Vendor contracts should establish appropriate responsibilities concerning security, incident management, access and deletion. Payment processing can also bring sector specific regulatory requirements into the analysis. An e commerce company should therefore avoid assuming the DPDP Act is the only relevant framework. Logistics and Delivery Partners Privacy obligations do not stop when an order leaves the website. Delivery partners may receive names, addresses, telephone numbers, order references and other information needed to complete delivery. The e commerce business should identify which information is shared and why. Vendor agreements should define permitted processing, security expectations, incident reporting, retention and deletion. The business should also assess whether delivery providers use information for additional purposes beyond fulfilment. This becomes particularly important when several logistics providers operate across different regions. Customer Support and Call Centre Data Customer support systems can contain extensive personal information. Support agents may see order history, addresses, contact details, complaints and payment related information. Call recordings may create additional data protection considerations. Businesses should establish access controls and define retention periods. Employees should only access information required for their role. Training is also essential. A customer support agent forwarding an account screenshot through an unsecured channel can create a privacy incident even when the company's main systems are well protected. Data Breach Response E commerce platforms are attractive targets because they can hold substantial volumes of customer information. A breach may involve account credentials, contact information, transaction records or other personal data. Businesses should maintain a documented incident response process covering detection, containment, investigation, evidence preservation, legal assessment and communication. CERT In also requires specified cyber incidents to be reported within six hours of noticing the incident or being informed about it. Businesses should therefore assess CERT In obligations separately from the DPDP breach notification framework. The DPDP Rules provide their own process for personal data breach notification once the relevant provisions commence. Rule 7 provides for notification to affected Data Principals without delay and detailed information to the Data Protection Board within 72 hours, subject to the Rule. E commerce businesses should therefore prepare for potentially overlapping regulatory obligations. Vendor and Marketplace Data Sharing An e commerce platform rarely operates alone. Its technology ecosystem may include payment providers, delivery partners, cloud services, analytics platforms, advertising networks, customer support providers and fraud prevention services. Each relationship should be assessed. The business should know whether the vendor acts as a Data Processor or has an independent purpose for processing information. Contracts should reflect the relationship and include appropriate privacy and security controls. Recent industry guidance specifically identifies third party transfers and processor contracts as important compliance considerations for e commerce businesses. This is an area where data privacy compliance services can assist businesses with data mapping, vendor assessments, privacy notices, consent processes and compliance reviews. Children Using E Commerce Platforms E commerce businesses should consider whether their services are likely to be used by children. Section 9 of the DPDP Act contains specific obligations concerning children's personal data. The framework requires verifiable parental consent in applicable cases and restricts certain forms of processing involving children. Businesses selling toys, educational products, games, entertainment services or other child focused products should examine their customer journey carefully. Age related controls should not be treated as a purely technical issue. Legal, product and engineering teams should work together. Cross Border Data Processing International e commerce creates additional complexity. A platform may be hosted by an overseas cloud provider. Customer support may operate from another country. Analytics and advertising tools may process information outside India. Section 16 of the DPDP Act provides a framework for processing personal data outside India and permits the Central Government to restrict transfers to specified countries or territories through notification. Other laws can impose additional requirements. Businesses should therefore map international data flows rather than simply stating in a privacy policy that information “may be transferred internationally”. The Current DPDP Implementation Timeline Businesses should be careful when describing the DPDP Act as fully operational. The Rules were notified on 13 November 2025. Rules 1, 2 and 17 to 21 came into force on publication. Rule 4 has a one year commencement period. Rules 3, 5 to 16, 22 and 23 have an eighteen month commencement period. The Act itself also has phased commencement. This means businesses should distinguish between provisions currently in force and provisions requiring implementation preparation. For e commerce businesses, this distinction is particularly important because changing checkout interfaces, vendor contracts, retention systems and customer rights workflows can take months. Preparation should therefore begin before the relevant statutory dates. How E Commerce Businesses Can Build Privacy Into Operations Privacy compliance works best when it is integrated into product design. When a new feature is developed, the business should ask what personal data it requires, why the information is needed, who receives it and how long it will remain available. Marketing teams should coordinate with privacy and legal teams before launching new tracking or personalisation initiatives. Procurement teams should identify vendors processing personal data before contracts are signed. Engineering teams should build appropriate access controls and deletion mechanisms into systems. Customer service teams should know how to handle privacy requests. This approach makes privacy a business process rather than a document stored on a website. E Commerce Privacy Compliance Checklist A practical review should examine the complete customer lifecycle. The organisation should assess its data inventory, privacy notices, consent mechanisms, marketing practices, tracking technologies, profiling, customer rights processes, retention schedules, vendor contracts, security safeguards, breach response procedures and international data flows. It should also review its consumer protection obligations, particularly where privacy choices intersect with interface design, advertising or other digital practices. For larger businesses, regular privacy audits can provide management with evidence of whether documented policies match actual processing. Conclusion Privacy compliance for e commerce businesses is no longer limited to publishing a privacy policy. Online retailers and marketplaces operate complex data ecosystems involving checkout systems, customer accounts, analytics, advertising, payment providers, logistics companies, cloud platforms and customer support tools. Each stage can create a separate privacy consideration. The DPDP Act and the notified 2025 Rules provide an important new framework for managing these activities in India. The phased commencement gives businesses time to review their practices, but it should not become a reason to postpone preparation. A strong privacy programme begins with data mapping. It then connects appropriate processing grounds with transparent notices, meaningful consent where required, security controls, vendor governance, retention practices and effective customer rights processes. Businesses should also consider consumer protection requirements. Privacy choices should not be separated from the design of the customer journey. Dark patterns, misleading interfaces and unclear marketing choices can create risks beyond data protection law. For growing e commerce businesses, privacy should become part of product development, marketing, procurement, technology and customer service. This approach creates a more sustainable compliance framework and gives businesses a clearer understanding of how customer information moves through their operations. Where e commerce platforms operate across multiple jurisdictions, use extensive profiling or manage large volumes of personal data, specialist legal review can help align corporate legal compliance with the organisation's actual technology, commercial and customer data practices. Legal note: This article provides general information on Indian data protection and e commerce law. It is not legal advice for a specific business or processing activity. The application of the DPDP Act and Rules depends on the organisation, processing activity, applicable commencement provisions and other relevant laws and regulations.   Frequently Asked Questions (FAQs) Q1. What is e commerce privacy compliance? E commerce privacy compliance means managing customer and other personal data in accordance with applicable privacy, cybersecurity, consumer protection and sector specific requirements. It covers collection, use, sharing, storage, security, retention and deletion. Q2. Does the DPDP Act apply to online shopping websites? Yes, where the processing falls within the Act's scope. An e commerce platform generally processes digital personal data and may act as a Data Fiduciary. Q3. Does an e commerce website need customer consent for every activity? No. The DPDP Act recognises consent as one ground for processing and also provides for certain legitimate uses. Businesses should identify the appropriate basis for each processing activity. Q4. Is marketing consent different from order processing? Yes. Order fulfilment and promotional communications can have different purposes and legal bases. Businesses should avoid assuming consent for one purpose automatically covers another. Q5. Do e commerce companies need a privacy policy? Businesses processing personal data should provide appropriate transparency under the applicable legal framework. The DPDP Rules, 2025 prescribe detailed notice requirements for the relevant commencement phase. Q6. Can an e commerce business use customer purchase history for personalised advertising? It depends on the purpose, applicable legal basis, notice, consent requirements and other applicable laws. Businesses should distinguish between using purchase history to fulfil an order and using it for separate marketing or profiling purposes. Q7. How long can an e commerce company keep customer data? There is no single retention period applicable to every e commerce business. Retention depends on purpose, applicable law and the relevant DPDP provisions. The 2025 Rules introduce a specific three year framework for certain large e commerce entities meeting the stated user threshold. Q8. What happens if an e commerce company suffers a data breach? The business should activate its incident response process, contain the incident, preserve evidence and assess applicable notification requirements. CERT In obligations and DPDP breach notification requirements should be considered separately where applicable. Q9. Are payment gateways responsible for customer data protection? Payment providers have their own regulatory and contractual responsibilities. The e commerce business should also understand what personal data it shares with the provider and establish suitable contractual and security controls. Q10. Do delivery partners need data protection contracts? Where a delivery provider processes personal data on behalf of an e commerce business, the relationship should be appropriately documented and governed. The exact contractual structure depends on the parties' roles and processing activities. Q11. Are cookies covered by Indian data protection law? Cookies themselves are technologies rather than a separate statutory category under the DPDP Act. The relevant question is whether their use involves processing of personal data and which legal requirements apply to the resulting processing. Businesses should also consider applicable consumer, advertising and technology requirements. Q12. What are dark patterns in e commerce? Dark patterns are interface or design practices which can mislead, manipulate or unfairly influence users. India's Central Consumer Protection Authority has issued Guidelines for Prevention and Regulation of Dark Patterns, 2023, making interface design relevant to wider e commerce compliance. Q13. Do small online stores need to prepare for DPDP compliance? Yes. The organisation's size does not by itself determine whether the DPDP Act applies. Small businesses should assess their actual processing activities and prepare proportionate privacy controls.
data processing agreements,
Data Processing Agreements: Why They Matter for Businesses
Businesses increasingly rely on external service providers to store, analyse and manage personal information. Cloud platforms, payroll providers, SaaS applications, marketing agencies, customer support providers and IT vendors may all process personal data on behalf of a business. This makes data processing agreements an important part of modern privacy governance. A well drafted DPA defines how a service provider may handle personal data and establishes responsibilities around security, confidentiality, incidents, sub processors and deletion. In India, the Digital Personal Data Protection Act, 2023 introduces a specific framework for relationships between Data Fiduciaries and Data Processors. Section 8(2) provides for engagement of a Data Processor under a valid contract. However, businesses should also understand the phased commencement of the Act before describing every processor obligation as currently enforceable. (India Code) What Is a Data Processing Agreement? A Data Processing Agreement, commonly called a DPA, is a contractual arrangement governing the processing of personal data by one party on behalf of another. Under India's DPDP framework, the organisation determining the purpose and means of processing is generally the Data Fiduciary. A Data Processor is a person processing personal data on behalf of the Data Fiduciary. The relationship is therefore based on the actual processing activity rather than simply the title of the commercial contract. For example, an organisation may appoint a payroll company to process employee information, a cloud provider to host customer records or a customer service provider to manage support requests. Where the third party processes personal data on the organisation's behalf, the processing relationship should be clearly documented. A DPA may operate as a standalone agreement, a schedule to a master services agreement or an addendum to an existing commercial contract. The important point is not the document's title. It is whether the agreement clearly governs the personal data processing relationship. Why Data Processing Agreements Matter for Businesses Personal data can move through several organisations before a service reaches an individual. A customer may submit information through a company's website. The information may then enter a CRM platform, pass to a cloud hosting provider, be accessed by a customer support vendor and be analysed through another technology service. Without appropriate contractual controls, the business may have limited visibility over how those providers use the information. A DPA creates a contractual framework for controlling this processing. It can establish permitted purposes, security requirements, access restrictions, incident notification procedures, sub processor controls and deletion requirements. It also creates clearer accountability between the parties. This is particularly important because India's DPDP framework places significant responsibility on the Data Fiduciary for processing carried out on its behalf. A contract can allocate responsibilities and financial risk between the parties, but it should not be assumed to eliminate the Data Fiduciary's statutory responsibilities. Data Fiduciary and Data Processor: Understanding the Difference Correctly identifying the parties is the starting point for preparing a DPA. A Data Fiduciary determines the purpose and means of processing personal data. A Data Processor processes personal data on behalf of the Data Fiduciary. Consider a company using a cloud platform to store customer records. If the cloud provider processes the information only to provide the contracted hosting service, it may operate as a Data Processor. However, the same vendor could act as a Data Fiduciary for separate processing activities where it determines its own purposes. The contractual label should therefore reflect the actual relationship. Simply calling a vendor a “processor” does not resolve the legal analysis. Indian guidance increasingly emphasises this distinction because a single organisation can potentially have different roles for different processing activities. What Does the DPDP Act Say About Processor Contracts? Section 8 of the Digital Personal Data Protection Act contains the principal provisions concerning Data Fiduciaries and Data Processors. Section 8(2) provides that a Data Fiduciary may engage, appoint, use or otherwise involve a Data Processor to process personal data on its behalf for activities related to offering goods or services to Data Principals only under a valid contract. Section 8(1) also establishes the continuing responsibility of the Data Fiduciary for compliance with the Act in relation to processing undertaken on its behalf. These provisions are important because they make the vendor relationship part of the organisation's privacy governance framework. However, businesses should note the commencement position. The Government's commencement notification places Section 8 within the eighteen month commencement group following the November 2025 notification. The corresponding operational Rules are also subject to phased commencement. This distinction matters for accurate legal content and internal compliance planning. What Should a Data Processing Agreement Include? A DPA should be tailored to the actual service and data involved. A generic document may provide a useful starting point, but it should not replace a proper assessment of the processing relationship. Scope and purpose of processing The agreement should explain why the Processor receives personal data and what services it is authorised to perform. The Processor should not receive unrestricted permission to use personal information for its own purposes unless the parties have separately established the appropriate legal relationship and basis for such processing. A clear purpose clause reduces uncertainty. It also makes later compliance reviews easier because the business can compare actual processing against the contractual scope. Categories of personal data The DPA should identify the types of personal data involved. This may include names, contact information, account details, employment records, financial information, location information or other categories relevant to the service. The more sensitive or consequential the processing, the greater the need for precise contractual controls.  Categories of Data Principals  The agreement should also identify whose information is being processed. The Data Principals could be customers, employees, job applicants, suppliers, students, patients or website users. This information helps both parties understand the nature of the processing and the potential risks involved. Duration of processing The agreement should specify how long the Processor may process the information. The processing period should normally correspond with the service relationship and any legitimate retention period. A DPA should also explain what happens after the commercial contract ends. Security Obligations Are Central to a DPA A DPA should establish appropriate security obligations rather than relying on a general confidentiality clause. The DPDP Rules, 2025 identify security measures including encryption, masking or obfuscation, access controls, logging and monitoring, backups, retention of relevant logs and contractual provisions concerning security safeguards between Data Fiduciaries and Data Processors. The contractual standard should reflect the nature of the service. A vendor processing payroll information may require stronger access restrictions than a supplier receiving only limited business contact information. The agreement can also require the Processor to maintain appropriate technical and organisational measures, restrict privileged access, train authorised personnel and notify the Data Fiduciary of material security incidents. The objective is not to copy a technical checklist into every contract. It is to establish controls appropriate to the actual risk. Confidentiality and Personnel Access A Processor may have employees, contractors or other authorised personnel accessing personal data. The DPA should therefore establish confidentiality obligations for people authorised to process the information. Access should be limited to individuals who require it for their role. Access should also be removed when personnel change responsibilities or leave the organisation. Businesses should periodically assess whether vendor access remains necessary. A contractual confidentiality promise becomes much stronger when supported by practical access controls. Data Breach and Incident Notification A DPA should establish a clear incident notification process. The Processor should notify the Data Fiduciary promptly after becoming aware of a relevant personal data breach. The contract can also specify the information the Processor must provide, such as the nature of the incident, affected systems, categories of information, likely impact and containment measures. The purpose is to give the Data Fiduciary sufficient time to assess its own regulatory responsibilities. This becomes particularly important under the notified DPDP Rules. Rule 7 provides for notification of affected Data Principals without delay and establishes a process for notifying the Data Protection Board, including detailed information within 72 hours, subject to the Rule's requirements. The Processor's contractual notification period should therefore be short enough to support the Data Fiduciary's response. Sub Processors Need Contractual Control Many technology vendors rely on other service providers. A SaaS provider may use a cloud infrastructure company. A payroll platform may rely on another hosting provider. A customer support provider may use external communication systems. These entities can become sub processors within the wider processing chain. The DPA should therefore establish how sub processors may be appointed. Depending on the risk and commercial arrangement, the Data Fiduciary may require prior approval, advance notice or another appropriate control mechanism. The Processor should also remain responsible for ensuring relevant obligations flow through the processing chain where appropriate. Without sub processor visibility, a business may not know where its personal data ultimately resides. Assistance With Data Principal Requests Individuals may have rights under applicable data protection law. A Processor may hold information needed to respond to those requests even though the Data Fiduciary is responsible for managing the relationship with the individual. The DPA should therefore require reasonable assistance. For example, if an individual requests correction or erasure, the Processor may need to locate relevant information and implement the instruction. The agreement should establish practical procedures for such requests, including communication channels and reasonable response times. This helps prevent a situation where a business receives a request but cannot act because its vendor has no internal process for responding. Retention, Return and Deletion A DPA should address what happens when processing ends. The Processor may be required to return or delete personal data, subject to applicable legal retention requirements. Deletion should be considered across active systems, backups and other storage environments where relevant. The contract should also clarify whether the Processor must provide evidence of deletion. This becomes particularly important when a business changes vendors. The outgoing supplier should not retain personal information indefinitely simply because the commercial agreement has ended. Audit and Compliance Evidence Businesses need some method of verifying whether their Processors comply with contractual requirements. The DPA may establish audit rights, security assessments, independent certifications, compliance reports or other evidence mechanisms. The appropriate approach depends on the risk. A company processing large volumes of financial or health information may require stronger assurance than a low risk supplier. Unrestricted audit rights can also create practical problems for both parties. A well structured DPA can establish reasonable notice, scope, confidentiality and frequency rules while preserving meaningful oversight. Modern enterprise DPAs commonly address cooperation, assessments and audit evidence as part of the contractual framework. Cross Border Data Processing A vendor agreement should make international processing visible. A company may be based in India while its cloud provider stores information in another country. Support personnel may also access systems from overseas locations. Section 16 of the DPDP Act addresses processing outside India and permits the Central Government to restrict transfers to specified countries or territories through notification. Other sector specific requirements may apply independently. Businesses should therefore understand where vendors host, access and transfer personal data. The DPA should contain suitable provisions for international processing where required by the applicable legal framework. Businesses subject to the GDPR or other overseas privacy regimes may also need additional transfer mechanisms. A DPA designed for Indian law should not automatically be assumed to satisfy every foreign privacy requirement. Liability, Indemnity and Insurance A DPA is also a commercial risk allocation document. Businesses should examine how liability for privacy breaches, security incidents and contractual failures interacts with the main services agreement. A vendor may accept extensive privacy obligations but still have a low overall liability cap under its commercial contract. The parties should therefore consider the relationship between privacy obligations, indemnities, exclusions, insurance and liability limits. There is no universal clause suitable for every transaction. The appropriate allocation depends on the volume and sensitivity of information, the vendor's role, the business impact of a breach and the parties' negotiating position. Data Processing Agreements and GDPR Many Indian businesses work with international customers or vendors. As a result, their DPAs may need to address more than Indian law. Under Article 28 of the GDPR, controller and processor relationships must be governed by a contract containing specified requirements concerning processing instructions, confidentiality, security, sub processors, assistance and audits. The GDPR and DPDP Act use different terminology and structures. Indian contracts should therefore avoid simply copying a GDPR DPA without checking whether its provisions accurately reflect Indian law. Where both frameworks apply, businesses should map the requirements rather than assume one document automatically satisfies both. Why Generic DPA Templates Can Create Problems? Templates can save time, but a DPA should reflect the actual processing relationship. A template designed for a cloud provider may not be appropriate for a payroll company. A template created for GDPR compliance may contain provisions irrelevant to an Indian only processing arrangement. The agreement should match the real data flow. If the vendor does not access certain categories of data, those categories should not be included merely because they appear in a standard form. If a vendor uses sub processors, the agreement should address them. If international processing occurs, the relevant provisions should be included. Accuracy is more valuable than unnecessary contractual length. When Should Businesses Sign a DPA? Ideally, the processing relationship should be assessed before the vendor receives personal data. Procurement teams should identify whether the supplier will process personal information during vendor selection. Legal and privacy teams can then determine whether a DPA or equivalent contractual provisions are required. The agreement should be finalised before operational access begins wherever the applicable legal framework requires contractual controls. Existing vendor arrangements should also be reviewed, particularly where they involve significant volumes of personal data or sensitive processing. How Businesses Can Manage DPAs at Scale? Large organisations may have hundreds of vendors. Managing each DPA manually can create gaps. A practical governance programme should maintain a central vendor register showing which suppliers process personal data, what information they receive, where processing occurs and when the agreement expires. Risk based classification can help prioritise reviews. High risk vendors can receive deeper security assessments and more detailed contractual review. Lower risk vendors can follow a proportionate process. Renewal workflows should also trigger privacy review. A contract should not automatically renew for several years while the underlying processing arrangement changes. This is where specialist data protection services for businesses can support contract reviews, vendor assessments and wider privacy governance where internal resources are limited. What Businesses Should Review in Existing DPAs? Existing agreements should be compared against current processing activities. The organisation should ask whether the vendor's role is still correctly classified, whether the permitted processing remains accurate, whether sub processors have changed, whether data is stored in new locations and whether security commitments match the vendor's current practices. Businesses should also review breach notification periods. A DPA negotiated several years ago may contain a notification period unsuitable for current regulatory expectations. The same applies to deletion clauses. The contract should reflect how the vendor actually handles backups, archives and account termination. The Indian DPDP Transition and DPA Preparation The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025. Rule 1 provides for phased commencement. Rule 4 takes effect one year after publication, while Rules 3, 5 to 16, 22 and 23 take effect 18 months after publication. The Act's substantive provisions concerning Data Fiduciary obligations are similarly subject to the commencement notification. This means businesses should distinguish between preparation and current enforceability. The absence of full commencement should not be treated as a reason to ignore vendor contracts. Reviewing hundreds of commercial agreements, renegotiating supplier terms and changing vendor onboarding processes can take considerable time. Businesses can use the transition period to establish a consistent DPA framework and align contracts with actual data flows. Conclusion Data Processing Agreements have become an important part of responsible vendor governance. They provide a contractual structure for controlling how third parties handle personal data and help businesses translate privacy requirements into practical obligations. A strong DPA should do more than repeat general statements about compliance. It should reflect the actual processing relationship. It should identify the data involved, define permitted purposes, establish security requirements, control sub processors, provide a workable incident response process and address retention and deletion. For Indian businesses, the DPDP Act and the notified Rules make this area particularly important as the country moves towards full implementation of its new privacy framework. The phased commencement also gives businesses time to review existing vendor arrangements and build stronger contractual controls. A carefully prepared DPA cannot eliminate every privacy risk. It can, however, make responsibilities clearer, improve vendor accountability and provide an important contractual foundation for wider privacy governance. Businesses should also seek advice from experienced commercial lawyers where a DPA involves complex liability provisions, international processing, regulated data, substantial vendor dependencies or overlapping Indian and foreign privacy requirements. Frequently Asked Questions (FAQs) Q1. What is a Data Processing Agreement? A Data Processing Agreement is a contract governing the processing of personal data by a Data Processor on behalf of a Data Fiduciary. It defines permitted processing and establishes contractual responsibilities concerning security, incidents, confidentiality and other privacy matters. Q2. Is a Data Processing Agreement mandatory in India? Section 8(2) of the DPDP Act provides that a Data Fiduciary may engage a Data Processor for covered activities only under a valid contract. However, Section 8 is subject to the phased commencement notification. Businesses should prepare processor contracts before the relevant provision becomes operational. Q3. Who signs a Data Processing Agreement? The agreement is generally entered into between the organisation acting as Data Fiduciary and the organisation acting as Data Processor. The exact contractual structure depends on the commercial relationship. Q4. What should a DPA contain? A DPA should normally address the purpose and duration of processing, types of personal data, categories of Data Principals, processing instructions, confidentiality, security, breach notification, sub processors, rights assistance, retention, deletion, audits and relevant international processing. Q5. Is a DPA the same as a privacy policy? No. A privacy policy or privacy notice explains how an organisation processes personal data and communicates information to individuals. A DPA governs a contractual relationship between a Data Fiduciary and Data Processor. Q6.Does every vendor need a DPA? Not necessarily. The relevant question is whether the vendor processes personal data on behalf of the organisation. A supplier with no access to personal data may not require a processor agreement. Some vendors may also act as independent Data Fiduciaries for certain activities. Q7. Can a DPA transfer all legal responsibility to the vendor? No. A contract can allocate responsibilities, costs and remedies between the parties, but it does not automatically remove statutory responsibility from the Data Fiduciary. The DPDP framework places important obligations on the Data Fiduciary for processing undertaken on its behalf. Q8. Should a DPA include breach notification timelines? Yes. A clear contractual notification mechanism is important because the Data Fiduciary may have its own regulatory notification duties. The Processor should notify the Data Fiduciary quickly enough to allow appropriate assessment and response. Q9. What are sub processors? Sub processors are third parties engaged by a Data Processor to perform part of the processing service. A DPA should establish appropriate controls over their appointment and processing activities. Q10. Do DPAs need to address data deletion? Yes. The agreement should establish what happens to personal data when the service ends, including return, deletion and any legally required retention. Q11. Are DPAs required under GDPR? Where Article 28 of the GDPR applies to a controller and processor relationship, the processing must be governed by a contract containing specified requirements. Q12. Can one company be both a Data Fiduciary and a Data Processor? Yes. An organisation may act as a Data Fiduciary for processing carried out for its own purposes and as a Data Processor when it processes another organisation's data on that organisation's behalf. The role should be assessed for each processing activity.
vendor data processing obligations,
Vendor Agreements and Data Processing Obligations Explained
Personal data rarely remains within one organisation. Businesses routinely share customer, employee, applicant and user information with cloud providers, SaaS platforms, payroll companies, marketing agencies, logistics providers, analytics platforms and technology vendors. This makes vendor data processing obligations an important part of privacy governance in India. A vendor contract is no longer merely a commercial document. Where a third party processes personal data on behalf of a business, the agreement can become an important mechanism for controlling privacy, security and operational risk. India's privacy framework is moving towards a more structured approach through the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. However, the framework has phased commencement. As of September 2026, several core operational provisions, including Section 8 and the detailed security requirements in Rule 6, are scheduled for the later commencement phase. Businesses should therefore prepare contracts now rather than wait until the statutory obligations become operational. Why vendor agreements matter for data protection A business can outsource a processing activity, but outsourcing does not automatically remove its responsibility for the underlying data. Under the DPDP framework, a Data Processor is a person who processes personal data on behalf of a Data Fiduciary. The distinction depends on the actual processing relationship, rather than the commercial label given to the vendor. For example, a company may appoint a cloud provider to host its customer database. It may use a payroll platform to manage employee records or a customer support provider to handle complaints. In each situation, the third party may be processing personal data on behalf of the organisation. The contractual relationship therefore needs to reflect the actual data flow. A simple confidentiality clause may protect confidential business information, but it does not necessarily address the operational requirements associated with personal data processing. The DPDP Act specifically provides for contractual engagement of Data Processors. Section 8(2), which is scheduled for the eighteen month commencement phase, states that a Data Fiduciary may engage a Data Processor for relevant activities only under a valid contract. Data Fiduciary and Data Processor: who is responsible? The first step in reviewing a vendor agreement is identifying the role of each party. A Data Fiduciary determines the purpose and means of processing personal data. A Data Processor processes personal data on behalf of the Data Fiduciary. A vendor may therefore be a Data Processor for one activity but operate as an independent Data Fiduciary for another. This distinction is particularly important for modern SaaS arrangements. A software provider might process customer information strictly according to a company's instructions for one service. The same provider might use certain information independently for its own purposes in another context. The contract should not simply assume one role covers every processing activity. Businesses should document the purpose of processing, categories of personal data, categories of Data Principals, systems involved, locations of processing and permitted uses before finalising the agreement. What should a data processing clause cover? A well drafted vendor agreement should establish clear boundaries around how personal data may be processed. The vendor should receive clear instructions about the permitted purpose. Personal data provided for customer support should not automatically become available for unrelated product development, advertising or other commercial purposes. The agreement should also identify the categories of information involved. Customer contact information creates different risks from identity documents, financial information, health information or children's information. A risk based approach helps determine the level of contractual protection required. The agreement should also address access. Vendor personnel should only access personal data where necessary for their assigned responsibilities. Access should be controlled, reviewed and removed when no longer required. These contractual controls support the wider accountability model contemplated by India's data protection framework. Security safeguards should be contractual obligations Security is one of the most important areas in a vendor relationship. The notified DPDP Rules, 2025 provide for reasonable security safeguards covering personal data processed by a Data Fiduciary itself or on its behalf through a Data Processor. Rule 6 includes measures such as encryption, masking or obfuscation, access controls, logging and monitoring, backups, retention of relevant logs and contractual safeguards with Data Processors. Businesses should therefore avoid vague wording such as “the vendor will maintain adequate security”. The contract should explain the expected standard in terms suitable for the service and risk involved. For a cloud provider, this may involve encryption, identity management, access logging and resilience controls. For a customer support provider, it may also require restrictions on downloading records, controlled employee access and secure disposal. A vendor agreement should ideally connect contractual commitments with evidence. Depending on risk, this may include security certifications, audit reports, penetration testing summaries, policies or other appropriate assurance material. Breach notification must work in practice A privacy contract is tested most severely during a security incident. If a vendor discovers unauthorised access to personal data, the business needs information quickly. A clause requiring notification “promptly” may be too vague for an effective incident response programme. The contract should establish an internal escalation process. It should specify how the vendor will notify the business, what initial information must be provided, how updates will be communicated and who will coordinate investigation and remediation.The agreement should also require reasonable cooperation with forensic investigations and regulatory responses where appropriate. This matters because the organisation engaging the processor may have its own statutory notification responsibilities once the relevant DPDP provisions commence. The vendor therefore needs to notify the organisation quickly enough for the organisation to assess and discharge its own legal duties. Businesses should also align vendor incident clauses with their internal incident response plan. Contractual rights are of limited value if nobody knows who must activate them. Sub processors require careful control Many vendors do not operate alone. A SaaS provider may use cloud infrastructure, analytics platforms, customer support systems or other technology providers. This creates a chain of processing. A business should know whether its vendor uses sub processors, who those entities are, what data they receive and where processing takes place. The agreement should establish an appropriate mechanism for approving or objecting to material changes in the sub processor chain. Equivalent privacy and security obligations should also flow down where appropriate. This is especially important for technology vendors whose underlying infrastructure can change during the contract term. A company may sign an agreement believing its data will be handled by one provider, only to discover later that another entity is performing a material part of the processing. Data retention, deletion and return Vendor agreements should also address the end of the data lifecycle. When a service ends, the business should know what happens to the personal data. The vendor should not retain information indefinitely merely because the service agreement has expired. The contract should establish whether information must be returned, deleted or securely disposed of. It should also address backups, legal retention requirements and the evidence available to demonstrate deletion where appropriate. This requirement becomes particularly important during vendor transitions. A company moving from one CRM, payroll platform or cloud provider should not have personal data scattered across its previous supplier's active systems and backups without a defined retention position. Cross border processing should be visible A vendor may process Indian personal data outside India even when the business itself operates from India. Cloud architecture, support teams, infrastructure providers and sub processors can create international data flows without the procurement team fully appreciating them. The DPDP Act does not create a blanket prohibition on every cross border transfer. Section 16 provides a framework under which the Central Government may restrict transfers of personal data outside India to specified countries or territories. Other sector specific requirements may also apply depending on the organisation and information involved. Vendor agreements should therefore require sufficient transparency about processing locations and material changes to those arrangements. A business operating in a regulated sector should also assess applicable requirements from sectoral regulators before approving an international processing arrangement. Vendor due diligence should begin before signing A contract cannot compensate for inadequate vendor selection. Before onboarding a supplier, the organisation should understand what personal data the supplier will access and why. It should assess the nature of the service, the volume of information, security controls, subcontracting model, processing locations and incident history where relevant. High risk vendors should receive deeper scrutiny than vendors with no access to personal data. Procurement, information security, privacy and legal teams should work together. A vendor questionnaire can identify technical and organisational controls, while legal review can convert material risks into enforceable contractual terms. This is where data processing compliance becomes part of procurement governance rather than an issue addressed only after a contract has already been negotiated. Vendor monitoring does not end after contract signing One common mistake is treating the signed agreement as the end of compliance work. Vendor risk can change. Services evolve, new sub processors are appointed, processing locations change and new features may introduce artificial intelligence or additional analytics. Businesses should therefore periodically reassess material vendors. Contract reviews should be triggered by significant changes such as a new processing purpose, acquisition of the vendor, major system migration, new sub processor, material security incident or expansion into new jurisdictions. Evidence of reviews should also be retained. A documented vendor governance process helps demonstrate that privacy commitments are actively managed rather than merely written into contracts. What happens when a vendor refuses strong privacy clauses? Large technology suppliers often operate on standard terms. Businesses may have limited negotiating leverage. This does not mean every clause should simply be accepted. The organisation should first identify which provisions are legally essential, which are risk controls and which are preferred commercial protections. A risk based approach can then determine whether alternative safeguards are acceptable. For high risk processing, inability to obtain adequate contractual protections may itself be a reason to reconsider the vendor. For lower risk services, other controls may reduce exposure. The decision should be documented rather than left to informal procurement discussions. The role of indemnities and liability provisions Privacy obligations should also be considered alongside liability provisions. A vendor may agree to comply with data protection requirements while its general liability clause places a relatively low cap on claims. This can create a mismatch between the seriousness of the processing risk and the available contractual remedy. Businesses should examine liability caps, indemnities, exclusions, insurance requirements and treatment of regulatory costs. o single liability structure works for every transaction. A payroll vendor, health technology provider and ordinary office supplies vendor present very different levels of privacy risk. The commercial allocation should therefore reflect the nature of the processing. Indian businesses should prepare before full commencement The Government notified the DPDP Rules, 2025 in November 2025. MeitY's official materials confirm a phased eighteen month implementation approach. The commencement notification places the core operational provisions of the Act, including Sections 3 to 17 and Section 8, in the later phase. This gives businesses an important preparation window. Organisations should identify vendors handling personal data, classify their roles, map data flows and review existing contracts. Procurement templates should be updated before new vendors are onboarded. Existing high risk arrangements should be prioritised for remediation. Businesses should also remember that India's privacy landscape currently includes other applicable legal requirements. The Information Technology Act, 2000 and the Information Technology SPDI Rules, 2011 remain relevant during the transition, particularly for organisations handling sensitive personal data or information within their scope. Building a stronger vendor governance model The most effective approach is to treat vendor privacy as a lifecycle process. At the procurement stage, identify whether personal data will be processed. During due diligence, assess the vendor's security and privacy controls. During contract negotiation, document processing instructions, security obligations, incident response, sub processor controls, retention, deletion and relevant transfer provisions. During the relationship, monitor material changes and reassess risk. During termination, confirm return or deletion of personal data and revoke access. This approach creates a defensible record showing how the organisation manages third party data risk. For businesses dealing with extensive personal data, specialist corporate contract compliance review can also help align commercial agreements with the organisation's wider privacy framework. Conclusion Vendor management is now an important part of privacy governance for Indian businesses. Personal data may pass through several technology and service providers before a business delivers its product or service. Each additional processing relationship can create operational, contractual and regulatory risk. A strong vendor agreement should therefore do more than protect confidential information. It should establish clear processing boundaries, security expectations, incident procedures, sub processor controls, retention rules and appropriate accountability. With India's DPDP framework moving through its phased implementation, businesses have an opportunity to review vendor arrangements before the core obligations become operational. A structured approach to vendor due diligence, contracting and ongoing monitoring can reduce avoidable risk and create stronger evidence of responsible data governance. Frequently Asked Questions Q1. Is a data processing agreement mandatory in India? Under Section 8(2) of the DPDP Act, a Data Fiduciary may engage a Data Processor for covered activities only under a valid contract. However, Section 8 is part of the eighteen month commencement phase following the November 2025 notification. Businesses should therefore prepare processor agreements in advance rather than assuming the provision is already fully operational. Q2. What is the difference between a vendor and a Data Processor? A vendor is a commercial concept. A Data Processor is a legal role based on how the party processes personal data. A vendor becomes a Data Processor where it processes personal data on behalf of a Data Fiduciary. The actual activities should be examined rather than relying solely on the contract title. Q3. What should a vendor data processing agreement contain? It should address the processing purpose, instructions, permitted data, confidentiality, security safeguards, access controls, breach notification, sub processors, retention, deletion, return of information, relevant audit or assurance rights and applicable transfer requirements. Q4. Can a standard vendor agreement cover data protection requirements? Sometimes, but a generic vendor agreement may not provide sufficient detail. Businesses should review the agreement against the actual data processing activities and applicable law. A confidentiality clause alone is rarely an adequate privacy governance mechanism. Q5. Who is responsible if a vendor causes a data breach? Responsibility depends on the facts and applicable legal framework. A contractual arrangement does not automatically eliminate the Data Fiduciary's statutory responsibilities. The organisation should therefore maintain oversight of its processors and ensure vendors have effective security and incident reporting obligations. Q6. Should companies review old vendor agreements? Yes. Existing contracts should be prioritised based on risk. Agreements involving customer databases, employee information, financial information, health information, children's data or large volumes of personal data deserve particular attention. Q7. Do vendor contracts need to address sub processors? Where a vendor uses other parties to process personal data, the organisation should understand and appropriately govern the sub processor arrangement. Contractual flow down of relevant privacy and security requirements is an important control. Q8. Does Indian data protection law prohibit vendors from processing data outside India? Not as a blanket rule. The DPDP Act provides for restrictions on transfers to certain countries or territories through Government notification. Sector specific requirements may also apply. Businesses should therefore understand the vendor's processing locations before approving the arrangement. Q9. Why are vendor agreements important for DPDP compliance? They provide a practical mechanism for translating an organisation's privacy and security requirements into enforceable obligations for third parties. They also help establish accountability across the data processing chain. Q10. When should a business review its vendor privacy contracts? A review should occur during onboarding and periodically afterwards. It should also be triggered by major changes in processing, new sub processors, international expansion, significant security incidents, new technology features or changes in applicable law.  
data protection compliance audit,
How to Prepare for a Data Protection Compliance Audit
Businesses increasingly rely on customer information, employee records, analytics, cloud platforms and third party technology. As data use grows, organisations need more than a privacy policy. They need evidence showing how personal data is collected, used, stored, shared and protected. A data protection compliance audit helps identify legal, operational and security gaps before they develop into regulatory problems, customer complaints or costly incidents. In India, audit preparation now needs to be viewed alongside the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025. The Act was enacted on 11 August 2023, while the Rules were notified in November 2025. The framework is being introduced through a phased commencement structure. Top Four Search Results for “Data Protection Compliance Audit” Search rankings can vary by location, device, search history and date. The current search landscape for the query includes the following highly relevant pages: ICAI Data Protection Compliance and Audit Certification ICAI Data Protection Compliance and Audit Certification Programme DPDP Audit India Compliance Tool DPDP Act Data Protection Audit Requirements A review of the available results shows an important content gap. Many pages focus on audit services, certification or checklists. Businesses also need a practical explanation of how to prepare, what evidence auditors should examine, how Indian requirements fit together and what changes under the notified DPDP Rules. This article addresses those practical questions. What Is a Data Protection Compliance Audit? A data protection audit is a structured examination of an organisation’s personal data practices against applicable legal, contractual, regulatory and internal requirements. It is not simply a review of a privacy policy. An effective audit examines whether the organisation’s actual behaviour matches its documented commitments. For example, a company may state in its privacy notice that customer information is collected only for specified purposes. An audit should test whether its applications, databases, marketing systems and employees follow this principle in practice. The audit should therefore connect three areas: legal requirements, operational processes and technical controls. A useful audit may examine data collection, notices, consent, legitimate processing, access rights, correction and erasure procedures, retention, vendor management, security safeguards, breach response, international transfers and governance. The notified DPDP framework is particularly relevant because the Act places responsibility on the Data Fiduciary for compliance. Section 8 contains general obligations concerning personal data processing, while Section 10 establishes additional obligations for Significant Data Fiduciaries. Why Should Indian Businesses Prepare for an Audit? Audit preparation gives management an opportunity to identify weaknesses before they become incidents. A business may have multiple systems collecting personal information without a central record. Marketing may use information collected for one purpose for another purpose. Former employees may retain access to systems. Vendors may process customer information without suitable contractual safeguards. Data may remain stored long after the original purpose has ended. These issues are difficult to identify through policy review alone. An audit creates a documented picture of how personal data moves through the organisation. It can also help management prioritise remediation based on legal exposure, business impact and the sensitivity of the processing. The need for structured preparation is becoming more significant as India moves towards implementation of the DPDP framework. MeitY has described the notified Rules as providing the operational framework needed to implement the Act. Understand Which Legal Requirements Apply to Your Business The first stage of preparation is determining the legal scope. The DPDP Act applies to processing of digital personal data within India in specified circumstances. It can also apply to processing outside India when connected with offering goods or services to Data Principals in India. The Act uses the terms Data Fiduciary and Data Processor to distinguish organisations determining the purpose and means of processing from entities processing data on their behalf. A business should not assume the DPDP Act is its only relevant requirement. Depending on its activities, the organisation may also need to consider sector specific regulations, contractual obligations, cybersecurity requirements, employment laws and CERT In requirements. This matters during an audit because compliance cannot be assessed in isolation. A financial services business, healthcare organisation, technology company and educational institution may process similar categories of personal information but face different regulatory expectations. Build a Complete Personal Data Inventory One of the most important audit preparation exercises is creating a reliable data inventory. The organisation should identify what personal data it collects, where it comes from, why it is collected, where it is stored, who can access it, which vendors receive it and when it is deleted. The exercise should cover more than the main customer database. It should include websites, mobile applications, CRM platforms, email systems, HR platforms, payment systems, analytics tools, customer support platforms, cloud storage, backups and physical records where relevant. Data mapping is particularly useful because it reveals discrepancies between written policies and actual processing. A business may discover, for example, that a marketing platform receives information not mentioned in its privacy notice or that a software vendor retains information beyond the period expected by the business. A practical audit should therefore trace information from collection to deletion. Review Privacy Notices and Consent Mechanisms The next stage is reviewing how individuals are informed about processing. The DPDP Act contains specific provisions concerning notice and consent. The 2025 Rules add operational requirements concerning how notices should be presented and how consent withdrawal should function. Businesses should examine whether their notices clearly explain the relevant processing and whether individuals can understand what they are agreeing to. Consent mechanisms should also be tested from a user perspective. A company should ask whether consent is recorded, whether the record can be retrieved and whether withdrawal is genuinely possible. Consent withdrawal should not become an administrative exercise requiring an individual to contact multiple departments. The audit should also check whether the organisation continues processing information after consent has been withdrawn where no other lawful basis or permitted use applies. Test Data Principal Rights Procedures A compliance audit should examine whether individuals can effectively exercise their statutory rights. The DPDP Act provides rights relating to access to information about personal data, correction and erasure, grievance redressal and nomination. It is not enough for a policy to say these rights exist. The organisation should have an operational process for receiving, authenticating, assessing, responding to and recording requests. Auditors should test sample requests and examine response records. They should also assess whether internal teams know how to escalate a request involving multiple systems or third party processors. This is an area where operational testing often reveals weaknesses missed during document review. Review Vendor and Data Processor Controls Third party relationships deserve particular attention. Businesses frequently share personal information with cloud providers, payroll companies, marketing platforms, customer support providers, analytics companies and technology vendors. The organisation should know which vendors process personal data and what each vendor is permitted to do with it. Contracts should address appropriate data protection responsibilities, security expectations, confidentiality, incident management, deletion or return of data and relevant audit or cooperation obligations. The notified Rules also contemplate contractual security requirements between Data Fiduciaries and Data Processors. An audit should therefore compare contracts against actual vendor practices. A strong contract is of limited value if the operational relationship follows different rules. Examine Security Safeguards Legal compliance and information security are closely connected. The DPDP framework requires Data Fiduciaries to adopt reasonable security safeguards. The notified Rules identify measures such as encryption, masking, access controls, monitoring and backups as part of the security framework. Audit preparation should therefore include technical evidence. This may involve reviewing access permissions, authentication controls, encryption practices, system logs, vulnerability management, backup arrangements and incident detection processes. Access should follow a genuine business need. Former employees should not retain active access. Privileged accounts should receive additional scrutiny. The organisation should also verify whether its security controls cover data processed by external vendors. Prepare for Data Breach Scenarios Every organisation should test its breach response before an incident occurs. The notified DPDP Rules establish a framework for notifying affected Data Principals and the Data Protection Board following a personal data breach. Rule 7 provides for notification to affected Data Principals without delay and requires detailed information to be furnished to the Board within seventy two hours, subject to the mechanism specified in the Rule. However, businesses should also remember other applicable cyber incident reporting obligations. CERT In directions currently require specified cyber incidents to be reported within six hours of noticing the incident or being informed of it. An audit should therefore test whether the legal, technical, communications and management teams can respond quickly enough. The organisation should have clear escalation routes, incident classification procedures, evidence preservation processes and decision making responsibilities. Check Data Retention and Deletion Practices Data protection compliance does not end with collection. Organisations should know how long different categories of personal data are retained and why. Retention periods should be connected with the purpose of processing and other legal obligations. The notified Rules also introduce specific retention and erasure requirements for certain categories of businesses and circumstances. During an audit, sample databases should be checked to determine whether old records are actually deleted. A common weakness is having a retention policy without technical deletion mechanisms. Backups also require attention. A business should understand whether deleted information remains accessible through backup systems and whether its retention practices are documented. Review Cross Border Data Flows International data transfers should also form part of the audit. Businesses using international cloud platforms or overseas service providers need a clear understanding of where personal data travels. Section 16 of the DPDP Act addresses processing of personal data outside India. The framework permits overseas transfers subject to restrictions notified by the Central Government. Significant Data Fiduciaries may also face additional restrictions concerning specified personal data and related traffic data. The audit should therefore identify overseas recipients, hosting locations, transfer arrangements and contractual protections. Understand the Special Audit Position for Significant Data Fiduciaries Not every business faces the same audit obligations. Section 10 creates additional obligations for Significant Data Fiduciaries. These include appointment of a Data Protection Officer, an independent data auditor and periodic Data Protection Impact Assessments and audits. Rule 13 of the notified Rules provides for a DPIA and audit once every twelve months from the relevant notification or inclusion as a Significant Data Fiduciary. It also requires significant observations from the assessment and audit to be furnished to the Data Protection Board. Businesses should therefore determine whether they have been notified as Significant Data Fiduciaries and monitor future government notifications. Prepare an Evidence File Before the Audit An audit is much easier when evidence is organised before the review begins. The organisation should maintain an accessible record of its privacy notices, consent records, data maps, vendor contracts, retention schedules, security policies, access reviews, training records, grievance procedures, breach response plans and previous audit findings. Evidence should be current. A policy last updated several years ago does not demonstrate effective compliance if systems and business processes have changed since then. A useful data protection audit should therefore test both documentation and implementation. How to Turn Audit Findings into Remediation An audit report should not become a document stored in a compliance folder. Every significant finding should have an owner, priority, corrective action and target completion date. High risk issues should be addressed first. Examples include uncontrolled access, unlawful data sharing, missing breach procedures, excessive retention and processing without appropriate notice or consent. Management should also distinguish between immediate remediation and longer term programme improvements. For organisations seeking external assistance, specialist data protection compliance services can help with gap assessments, policy reviews, data mapping, vendor assessments and audit preparation. The appropriate level of external support will depend on the organisation’s size, processing activities and risk profile. Common Mistakes Businesses Make Before an Audit One common mistake is treating the privacy policy as evidence of compliance. A policy describes the organisation’s approach. It does not prove employees, systems and vendors follow it. Another mistake is conducting the audit only from a legal perspective. Technical controls, business processes and vendor arrangements must also be tested. Some organisations also overlook smaller systems. Marketing databases, spreadsheets and customer support tools can contain substantial amounts of personal information. A further weakness is failing to document remediation. An organisation may identify a problem but later struggle to demonstrate whether it was fixed. Finally, businesses should avoid assuming compliance based solely on industry practice. Another company’s privacy programme may not reflect its own processing activities or legal obligations. When Should a Business Conduct a Data Protection Audit? There is no universal audit schedule suitable for every organisation. A business should consider an audit when launching a new product, entering a new market, adopting major technology, outsourcing significant processing, expanding internationally or undergoing a substantial change in its data practices. An audit is also valuable after a significant data breach, regulatory development or material change in the organisation. For a Significant Data Fiduciary, the notified framework provides a specific periodic audit requirement. Other organisations can use a risk based approach, with more frequent reviews where processing involves large volumes, sensitive contexts, children, extensive profiling or significant third party dependencies. Final Thoughts Preparing for a data protection compliance audit should not be treated as a last minute documentation exercise. The strongest approach combines legal analysis, data mapping, operational testing, vendor oversight and technical safeguards. For Indian businesses, the DPDP Act and notified Rules provide an increasingly important framework for responsible digital personal data processing. Businesses should therefore begin with a simple question: Can we demonstrate how personal data moves through our organisation, why we process it, who can access it, how we protect it and when we delete it? If the answer is unclear, the organisation is not yet audit ready.A structured compliance programme, supported where necessary by corporate compliance requirements reviews and specialist legal or technical expertise, can help convert privacy obligations into practical controls and reliable evidence. Frequently Asked Questions (FAQs) Q1. Is a data protection compliance audit mandatory for every Indian company? No. The statutory periodic audit requirement under Section 10 and Rule 13 applies specifically to Significant Data Fiduciaries. Other businesses may still conduct internal or external audits as part of responsible compliance and risk management. Q2. What does a data protection audit normally examine? It can examine data collection, notices, consent, lawful processing, data subject rights, security safeguards, retention, deletion, vendors, international transfers, breach response and governance. Q3. Does having a privacy policy mean a company is compliant? No. Compliance requires operational implementation. An audit should compare the organisation’s documented policies with actual processing activities. Q4. How often should an organisation conduct a privacy audit? The appropriate frequency depends on risk and regulatory obligations. Significant Data Fiduciaries are subject to the periodic requirements prescribed under the DPDP framework. Other organisations can adopt a risk based audit cycle. Q5. What evidence should a company keep for a privacy audit? Relevant evidence may include data inventories, privacy notices, consent records, vendor contracts, access reviews, security assessments, retention schedules, training records, grievance records and incident documentation. Q6. What happens if an audit identifies compliance gaps? The organisation should assess the risk, assign responsibility, establish corrective actions and monitor remediation. Serious issues should receive priority. Q7. Are data processors responsible for compliance? The Data Fiduciary retains important statutory responsibilities even when processing is outsourced. Contracts, due diligence and ongoing oversight of processors are therefore important parts of compliance. Q8. Does a data protection audit also cover cybersecurity? It should examine security safeguards relevant to personal data. A full cybersecurity assessment may be broader and may involve additional technical standards and regulatory requirements. Q9. Are cross border transfers covered in an Indian privacy audit? Yes. Data flows outside India should be mapped and assessed against Section 16 of the DPDP Act, applicable government restrictions and other relevant laws or contractual requirements. Q10. What is the biggest benefit of preparing for an audit? The principal benefit is visibility. A well conducted audit shows management where personal data is processed, where controls are weak and which issues should be addressed first.
MHCO Updates
Litigation
LITIGATION UPDATE | SUPREME COURT UPHOLDS OCCUPANTS' RIGHTS IN REDEVELOPMENT PROJECTS, REINSTATES MHADA ORDERS FOR PERMANENT ALTERNATE ACCOMMODATION
Overview: The Supreme Court of India, vide its judgment dated July 23, 2026, in Mahabanoo Contractor and Another v. Kalikund Developers and Others (Civil Appeal No. 9342 of 2026), set aside a Bombay High Court decision and ruled in favour of the occupants of a redeveloped cessed building. The Supreme Court upheld the Maharashtra Housing and Area Development Authority’s (MHADA) orders directing the developer to execute the Permanent Alternate Accommodation Agreement (PAAA) and hand over possession. The ruling firmly establishes that a PAAA executed under the Maharashtra Housing and Area Development Act, 1976 (MHAD Act) and the Development Control (DC) Regulations is not merely a private arrangement but is governed by a statutory scheme protecting occupants' rights. Brief Background and Facts: The dispute arose regarding a cessed building unfit for human habitation, which the developer (Respondent No. 1) undertook to demolish and redevelop under the MHAD Act, obtaining a No Objection Certificate (NOC) from MHADA. Occupants vacated the premises on the assurance of alternate accommodation in the reconstructed building. The first Appellant and the late Ms. Gool Peshotan Unwalla were joint occupants of Room No. 5 on the third floor of the old building. Following the redevelopment, the developer refused to honour the PAAA executed on 17 October 2019, which granted the Appellants three flats (inclusive of fungible area) totalling 309.98 sq. mtrs. Instead, the developer offered a smaller area, contending that the fungible Floor Space Index (FSI) was not fully utilized due to a reduction in the building's height from 34 to 30 floors. Upon the Appellants' complaint, MHADA issued orders on 28 May 2025, and 27 June 2025, directing the developer to register the PAAA and hand over possession, which were followed by a Show Cause Notice on 10 July 2025 when the developer failed to comply with the orders. The developer challenged the orders and the Show Cause Notice in the Bombay High Court, which stayed MHADA's actions by classifying the PAAA as a "private arrangement" amenable only to civil court jurisdiction. The Hon’ble High Court recorded the developer's undertaking to keep two flats encumbrance-free until a civil suit was decided. Subsequently, the developer filed a civil suit challenging the validity of the PAAA in its entirety. Contentions of the Parties: The Appellants (Occupants): The Appellants emphasized the statutory definition of 'occupant' under the MHAD Act and Rule 33(7) of the DC Regulations. They argued that the PAAA was a statutory requirement enforced by MHADA, not a private arrangement. They further relied on contemporaneous public notices, the certified list of tenants by MHADA, and the developer's NOC, all of which documented the first Appellant as a rightful joint occupant. The Respondents (Developer): The Respondents contended that the PAAA was a concocted document executed by a former expelled partner without proper authorization. They argued that upon the original tenant's death, the tenancy was extinguished, leaving the Appellants without rights to the premises. Furthermore, they asserted the carpet area allotted in the PAAA was excessive compared to the original tenement's area, especially considering that the FSI was not fully utilised. Court’s Findings: The Division Bench of the Supreme Court consisting of the Hon’ble Justice Shri J.B. Pardiwala and the Hon’ble Justice K. Vinod Chandran made several key observations: Statutory Nature of the PAAA: The Hon’ble Supreme Court held that the High Court had misconstrued the PAAA as a mere private arrangement. It was held that the PAAA was executed under the MHAD Act, which is a statutory scheme, and was meant to facilitate redevelopment while ensuring that the original occupants were not displaced. Its enforcement therefore fell squarely within MHADA's regulatory purview. Definition of 'Occupant': The Hon’ble Court held that the MHAD Act defines "occupier" under Section 2(25) as encompassing more than just the statutory tenants. It was held that the first Appellant’s status as an occupant was firmly established by multiple contemporaneous documents, including the developer's own 2010 public notice and MHADA's certified list. Developer's Conduct and Internal Disputes: The Hon’ble Court rejected the developer's attempt to use internal partnership disputes to invalidate agreements made with the occupants, stating that the occupants were not even made a party to the consent terms executed between the partners. It was held that the settlement of inter-se disputes between partners cannot absolve the developer from obligations under a validly executed PAAA, on the basis of which vacant possession was originally obtained. Additionally, it was held that the developer's failure to utilize the full fungible area does not justify resiling from the agreed allotments. Mala Fide Civil Suit: The Hon’ble Court found the civil suit filed by the developer to be misconceived and mala fide in nature because it sought to challenge the Appellants' very claim as occupants contrary to the undertaking given by the developer to the High Court. Judgment: The Supreme Court allowed the appeal, setting aside the Bombay High Court's judgment and reviving MHADA’s original orders. The Hon’ble Court directed the developers to execute the PAAA and hand over possession of the three apartments within two months and stated that if they failed to do so, the Appellants were entitled to recover damages calculated at the monthly rental value of the flats. The Hon’ble Court further restrained the High Court from proceeding with the developer's civil suit and imposed heavy costs on the developer. MHCO Comment: This pivotal judgment strictly curtails the dilatory tactics often employed by developers in redevelopment schemes to avoid handing over agreed-upon permanent alternate accommodations. By reiterating that the PAAA is a statutory instrument governed by the MHAD Act, rather than a standard private contract, the Supreme Court has fortified the regulatory authority of bodies like MHADA to intervene and enforce these agreements. For real estate practitioners and developers, this ruling serves as a stern reminder that internal management disputes or changes in project specifications cannot be utilized to prejudice the vested statutory rights of certified occupants. By: Mr. Akash Jain, Associate Partner Mr. Divyang Salvi, Associate Ms. Diva Lathi, Associate
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
LIFE AT MHCO
Need Help? Chat with us