GDPR Essentials for Indian Companies

The General Data Protection Regulation (EU) 2016/679 — universally known as the GDPR — entered into force on 25 May 2018 and immediately became the most consequential data protection law in the world. For Indian businesses, the GDPR is not a distant European concern. It is an operational reality that carries direct, enforceable obligations and severe penalties.

India's information technology and business process outsourcing sectors together employ over five million people and service thousands of European clients. Every time an Indian IT services company processes the personal data of EU-based individuals — whether employees, customers, or end-users — the GDPR applies. The same is true for Indian SaaS companies selling subscriptions to European users, e-commerce platforms shipping to EU addresses, and Indian subsidiaries of European multinationals that handle employee data centrally.

The stakes are significant. The GDPR empowers EU supervisory authorities to impose fines of up to EUR 20 million or 4% of global annual turnover, whichever is higher. These are not theoretical numbers: by 2025, cumulative GDPR fines across the EU exceeded EUR 4.5 billion, with penalties levied against companies headquartered far outside Europe.

India's own Digital Personal Data Protection Act, 2023 (DPDPA) draws on many GDPR concepts, but the two regimes are not identical. Indian companies that assume DPDPA compliance will automatically satisfy GDPR requirements expose themselves to material risk. This guide provides a structured, article-by-article walkthrough of the GDPR provisions most relevant to Indian businesses, highlights the key divergences from the DPDPA, and offers practical compliance steps tailored to the Indian IT and BPO landscape.

Article 3 of the GDPR defines its territorial scope, and it is deliberately expansive. Two limbs of Article 3 are particularly relevant to Indian companies.

Article 3(1): Establishment in the EU

If your Indian company has any form of "establishment" in the EU — a subsidiary, branch office, liaison office, or even a single employee based in an EU member state — the GDPR applies to all processing carried out "in the context of the activities" of that establishment. The concept of establishment is broad: the CJEU has held that even a single representative can constitute an establishment if they participate in revenue-generating activities directed at the EU market.

Article 3(2): Targeting or Monitoring EU Data Subjects

Even without any physical presence in the EU, the GDPR applies to an Indian company if it:

• Offers goods or services to individuals in the EU (Article 3(2)(a)). Indicators include: a website available in EU languages, pricing in euros, EU-specific marketing campaigns, or references to EU delivery or customer support.
• Monitors the behaviour of individuals in the EU (Article 3(2)(b)). This covers tracking EU users via cookies, device fingerprinting, behavioural profiling, location tracking, or analytics tools that process personal data of EU residents.

Practical Implications for Indian Companies

Business Model	GDPR Trigger	Typical Data
IT services / outsourcing	Processing on behalf of EU controller (processor role)	Customer records, HR data, financial data
SaaS / cloud platform	Offering services to EU users (controller or joint controller)	Account data, usage analytics, payment details
BPO / call centre	Processing EU customer data on behalf of EU client	Voice recordings, CRM records, complaint data
E-commerce	Selling and shipping to EU addresses	Order history, delivery addresses, payment data
Indian subsidiary of EU parent	Establishment in context of parent's activities	Employee data, intra-group transfers
Analytics / AdTech	Monitoring behaviour of EU individuals	Cookie data, IP addresses, browsing behaviour

Where Article 3(2) applies and the Indian company has no EU establishment, the company must designate an EU representative under Article 27. This representative serves as a point of contact for supervisory authorities and data subjects. Failure to appoint a representative is itself a compliance violation.

Article 5 of the GDPR establishes seven foundational principles that govern all personal data processing. These principles are not aspirational — they are enforceable obligations, and several of the largest GDPR fines have been levied for principle-level violations rather than specific procedural failures.

1. Lawfulness, fairness, and transparency. Personal data must be processed lawfully (under one of the six bases in Article 6), fairly (not in ways the data subject would not reasonably expect), and transparently (with clear, accessible privacy notices).
2. Purpose limitation. Data must be collected for specified, explicit, and legitimate purposes. It cannot subsequently be processed in a manner incompatible with those purposes. For Indian BPOs, this means data received from an EU client for customer support cannot be repurposed for marketing or internal analytics without a separate lawful basis.
3. Data minimisation. Only personal data that is adequate, relevant, and limited to what is necessary for the stated purpose may be processed. Over-collection — such as requiring a date of birth when only an email address is needed — violates this principle.
4. Accuracy. Personal data must be accurate and kept up to date. Reasonable steps must be taken to erase or rectify inaccurate data without delay.
5. Storage limitation. Data must be kept in a form that permits identification of data subjects for no longer than is necessary. Indian companies often retain data indefinitely "just in case." Under the GDPR, you must define and enforce retention periods for every category of personal data.
6. Integrity and confidentiality. Appropriate technical and organisational measures must be in place to protect personal data against unauthorised processing, accidental loss, destruction, or damage. This is the principle that underpins the GDPR's security requirements.
7. Accountability. The controller must be able to demonstrate compliance with all of the above principles. This is not a passive obligation — it requires documented policies, records of processing activities, audit trails, and evidence of ongoing compliance efforts.

The accountability principle is especially significant for Indian companies. It is not enough to be compliant; you must be able to prove it. Supervisory authorities routinely request documentation during investigations, and the absence of records is treated as evidence of non-compliance.

Every act of personal data processing under the GDPR must rest on one of six lawful bases specified in Article 6(1). There is no default or catch-all basis. If you cannot identify which basis applies to a given processing activity, that processing is unlawful.

(a) Consent

The data subject has given clear, affirmative consent to the processing of their personal data for one or more specific purposes. GDPR consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes, bundled consent, and "consent or no service" models are generally invalid. Consent can be withdrawn at any time, and withdrawal must be as easy as giving consent.

(b) Performance of a Contract

Processing is necessary for the performance of a contract to which the data subject is a party, or to take pre-contractual steps at their request. For Indian SaaS companies, this typically covers processing account data needed to deliver the subscribed service. It does not extend to all data you might find useful — only data genuinely necessary for contract performance.

(c) Legal Obligation

Processing is necessary to comply with a legal obligation to which the controller is subject. This covers statutory record-keeping, tax reporting, anti-money laundering checks, and similar regulatory requirements. The obligation must arise under EU or member state law — an obligation under Indian law alone does not satisfy this basis for GDPR purposes.

(d) Vital Interests

Processing is necessary to protect the vital interests of the data subject or another natural person. This is a narrow basis, typically limited to life-or-death situations (e.g., medical emergencies). It is rarely applicable to commercial processing.

(e) Public Task

Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority. This basis is primarily relevant to government bodies and is seldom applicable to Indian private-sector companies.

(f) Legitimate Interests

Processing is necessary for the legitimate interests of the controller or a third party, except where overridden by the interests or fundamental rights of the data subject. This is the most flexible basis but requires a documented Legitimate Interest Assessment (LIA) balancing the controller's interest against the data subject's rights. Common examples for Indian IT companies include fraud prevention, network security, and direct marketing to existing customers (subject to opt-out).

Practical Examples for Indian IT/BPO

Processing Activity	Likely Lawful Basis	Notes
Processing EU client's customer data under outsourcing agreement	Contract (as processor)	Data Processing Agreement required under Art. 28
Sending marketing emails to EU prospects	Consent	Must be opt-in; soft opt-in may work for existing customers under ePrivacy
Employee background checks for EU subsidiary	Legal obligation / Legitimate interest	Depends on member state employment law
Website analytics on EU visitors	Consent (for non-essential cookies)	Cookie consent banner required under ePrivacy Directive
Fraud detection in payment processing	Legitimate interest	Requires documented LIA
Retaining invoices with personal data	Legal obligation	Retention period governed by applicable tax/commercial law

Both the GDPR and India's DPDPA treat consent as a primary basis for processing personal data, but the two regimes differ in significant ways. Indian companies operating under both laws must understand these differences to avoid building a consent framework that satisfies one regime but falls short of the other.

Aspect	GDPR (EU)	DPDPA 2023 (India)
Standard	Freely given, specific, informed, unambiguous indication by statement or clear affirmative action (Art. 4(11), Art. 7)	Free, specific, informed, unconditional, unambiguous, clear affirmative action (Sec. 6)
Granularity	Separate consent required for each distinct purpose; bundling prohibited	Consent must be specific to each purpose; bundling not explicitly addressed but implied by "specific" requirement
Children	Parental consent required for children under 16 (member states may lower to 13) (Art. 8)	Verifiable parental consent required for children under 18 (Sec. 9)
Withdrawal	Must be as easy as giving consent; controller must inform data subject of right to withdraw before consent is given (Art. 7(3))	Right to withdraw at any time; must be as easy as giving consent (Sec. 6(4))
Record-keeping	Controller must be able to demonstrate consent was given (Art. 7(1))	Not explicitly mandated but implied by accountability obligations
Sensitive / Special Category	Explicit consent required for special categories (Art. 9(2)(a))	No separate category of sensitive data in DPDPA; all personal data treated uniformly
Legitimate Interest alternative	Available as alternative to consent (Art. 6(1)(f))	Not available; DPDPA has a narrower set of non-consent bases ("Certain Legitimate Uses" in Sec. 7)

The most consequential difference for Indian companies is the GDPR's concept of special category data (Article 9). Health data, biometric data, data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, and data concerning sex life or sexual orientation all require explicit consent (or one of the other narrow exceptions in Article 9(2)). The DPDPA does not distinguish between ordinary and sensitive personal data — a significant divergence that Indian companies must account for when processing EU data.

Another practical difference: the GDPR's legitimate interest basis (Article 6(1)(f)) is widely used by companies to process data without consent where the processing is reasonable and expected. The DPDPA's equivalent — "Certain Legitimate Uses" under Section 7 — is considerably narrower and does not include a general legitimate interest test. Indian companies accustomed to relying on legitimate uses under the DPDPA may need to obtain explicit consent for the same activities under the GDPR, or conduct a proper Legitimate Interest Assessment.

The GDPR grants individuals a comprehensive set of rights over their personal data. These rights are directly enforceable, and failure to respond to a valid request within the statutory timeframe (generally one month, extendable by two months for complex requests) is itself a compliance violation.

Right of Access (Article 15)

Data subjects can request confirmation of whether their data is being processed and, if so, obtain a copy of the data along with detailed information about the processing (purposes, categories, recipients, retention periods, source of data, existence of automated decision-making). Indian IT companies acting as processors must have mechanisms to assist their EU controller clients in responding to access requests.

Right to Rectification (Article 16)

Data subjects can require the controller to correct inaccurate personal data and complete incomplete data. This must be done without undue delay.

Right to Erasure / "Right to Be Forgotten" (Article 17)

Data subjects can request deletion of their personal data where: the data is no longer necessary for the original purpose; consent has been withdrawn; the data subject objects and there are no overriding legitimate grounds; the data was unlawfully processed; or erasure is required by law. Controllers must also inform other controllers to whom the data has been disclosed.

Right to Restriction of Processing (Article 18)

In certain circumstances — such as when accuracy is contested or processing is unlawful but the data subject opposes erasure — the data subject can require that processing be restricted (i.e., the data is stored but not actively processed).

Right to Data Portability (Article 20)

Where processing is based on consent or contract and carried out by automated means, the data subject can receive their data in a structured, commonly used, machine-readable format and transmit it to another controller. This right is particularly relevant for SaaS and platform businesses.

Right to Object (Article 21)

Data subjects can object to processing based on legitimate interests or public task grounds. For direct marketing, the right to object is absolute — no balancing test applies. The controller must cease processing immediately upon receiving a valid objection to direct marketing.

Rights Related to Automated Decision-Making (Article 22)

Data subjects have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significant effects. This is directly relevant to Indian companies deploying AI-driven credit scoring, automated hiring tools, or algorithmic content moderation for EU clients.

For Indian processors handling EU data, the practical requirement is to build internal workflows that enable your EU controller clients to fulfil these rights within the required timeframes. Your data processing agreements should clearly allocate responsibilities for rights management.

The GDPR requires certain organisations to designate a Data Protection Officer (DPO). Unlike the DPDPA — which does not mandate a DPO role — the GDPR imposes specific requirements on when a DPO must be appointed, what qualifications they must hold, and how they must be positioned within the organisation.

When a DPO Is Mandatory (Article 37)

A DPO must be appointed where:

• The processing is carried out by a public authority or body (except courts acting in a judicial capacity).
• The core activities of the controller or processor consist of processing operations which, by their nature, scope, or purposes, require regular and systematic monitoring of data subjects on a large scale.
• The core activities consist of processing on a large scale of special categories of data (Article 9) or data relating to criminal convictions (Article 10).

For Indian IT/BPO companies, the second criterion is the most commonly triggered. If your core business involves processing large volumes of EU personal data — as is the case for most outsourcing, cloud services, and analytics companies — you likely need a DPO.

Qualifications and Independence (Articles 37-38)

The DPO must be appointed on the basis of professional qualities, in particular expert knowledge of data protection law and practices. The DPO:

• Must report directly to the highest level of management.
• Must not receive instructions regarding the exercise of their tasks.
• Must not be dismissed or penalised for performing their duties.
• Can hold other tasks and duties, provided there is no conflict of interest (e.g., the DPO should not also be the Head of IT or Marketing).
• Can be an employee or an external service provider engaged under a contract.

Tasks of the DPO (Article 39)

The DPO is responsible for: informing and advising the organisation on GDPR obligations; monitoring compliance, including staff training and audits; advising on Data Protection Impact Assessments (DPIAs); cooperating with the supervisory authority; and acting as the contact point for the supervisory authority on processing-related issues.

Indian companies may appoint a single DPO for their entire group, provided the DPO is easily accessible from each establishment. Many Indian IT companies designate a DPO based in India who also serves the EU-facing operations. This is permissible, but the DPO must have sufficient knowledge of EU data protection law and be reachable by EU supervisory authorities in their language and time zone.

A Data Protection Impact Assessment (DPIA) is a structured process for evaluating the necessity and proportionality of a processing operation and for managing the risks it poses to data subjects. Under Article 35, a DPIA is mandatory before any processing that is "likely to result in a high risk to the rights and freedoms of natural persons."

When a DPIA Is Required

Article 35(3) provides a non-exhaustive list of situations requiring a DPIA:

• Systematic and extensive profiling with significant effects (e.g., automated credit decisions, behavioural advertising targeting EU users).
• Large-scale processing of special category data or criminal offence data (e.g., processing health records for EU patients).
• Systematic monitoring of a publicly accessible area on a large scale (e.g., CCTV with facial recognition at a facility used by EU employees).

Additionally, each EU supervisory authority publishes its own list of processing activities that require a DPIA. Indian companies should consult the list published by the supervisory authority of the member state most relevant to their operations.

DPIA Methodology

While the GDPR does not prescribe a single methodology, Article 35(7) specifies the minimum content of a DPIA:

1. A systematic description of the processing operations and their purposes, including the legitimate interest pursued (if applicable).
2. An assessment of the necessity and proportionality of the processing in relation to its purposes.
3. An assessment of the risks to the rights and freedoms of data subjects.
4. The measures envisaged to address those risks, including safeguards, security measures, and mechanisms to ensure the protection of personal data and demonstrate GDPR compliance.

Widely used frameworks include the CNIL DPIA methodology, the ICO's DPIA guidance, and ISO 29134. Indian companies should adopt a consistent framework and document every DPIA for audit purposes.

Prior Consultation (Article 36)

If the DPIA indicates that the processing would result in a high risk that the controller cannot mitigate, the controller must consult the relevant supervisory authority before proceeding. The authority has up to eight weeks (extendable by six weeks for complex cases) to provide written advice.

Chapter V of the GDPR (Articles 44-49) restricts transfers of personal data to countries outside the European Economic Area unless an adequate level of protection is ensured. This is one of the most operationally significant provisions for Indian companies, because India has not received an adequacy decision from the European Commission.

Adequacy Decisions (Article 45)

The European Commission can determine that a third country ensures an adequate level of data protection, enabling free data flows without additional safeguards. As of February 2026, adequacy decisions have been granted to countries including Japan, South Korea, the United Kingdom, Canada (commercial organisations), and — under the EU-US Data Privacy Framework — the United States. India does not have an adequacy decision, and the DPDPA's provisions on cross-border transfers are unlikely to satisfy the Commission's requirements in the near term, given the broad government access provisions in the DPDPA.

Standard Contractual Clauses (Article 46(2)(c))

In the absence of adequacy, Standard Contractual Clauses (SCCs) adopted by the European Commission are the most widely used transfer mechanism for India. The current SCCs, adopted in June 2021, are modular:

• Module 1: Controller to controller
• Module 2: Controller to processor (most common for Indian IT/BPO)
• Module 3: Processor to processor (sub-processing chains)
• Module 4: Processor to controller

Critically, following the Schrems II judgment (Case C-311/18), SCCs alone are not sufficient. The data exporter must conduct a Transfer Impact Assessment (TIA) evaluating whether the laws and practices of the destination country (India) provide an essentially equivalent level of protection. If the assessment reveals deficiencies — and India's surveillance and government access framework may raise concerns — supplementary measures (encryption, pseudonymisation, access controls) must be implemented.

Binding Corporate Rules (Article 47)

For multinational groups, Binding Corporate Rules (BCRs) provide an organisation-wide framework for intra-group transfers. BCRs require approval from the competent supervisory authority and are a substantial undertaking — typically 12-18 months and significant legal cost. They are best suited for large Indian IT conglomerates with extensive EU operations.

Derogations (Article 49)

In the absence of adequacy, SCCs, or BCRs, Article 49 permits transfers in limited circumstances: explicit consent (after being informed of the risks), necessity for contract performance, important reasons of public interest, legal claims, and vital interests. These derogations are to be interpreted strictly and cannot be used for systematic, large-scale transfers.

Transfer Mechanism	Suitability for Indian Companies	Key Consideration
Adequacy decision	Not available for India	Monitor Commission assessments
Standard Contractual Clauses	Primary mechanism; widely used	Must pair with Transfer Impact Assessment + supplementary measures
Binding Corporate Rules	Suitable for large multinationals	18-month approval process; significant investment
Explicit consent (derogation)	Limited; not for systematic transfers	Narrow interpretation; not scalable
Contractual necessity (derogation)	Occasional; case-by-case	Only for transfers directly necessary for the specific contract

The GDPR imposes strict obligations to report personal data breaches. These obligations apply to both controllers and processors, and the timelines are among the tightest in global data protection law.

Notification to the Supervisory Authority (Article 33)

A controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it. If notification is made after 72 hours, the controller must provide reasons for the delay. The notification must include:

• The nature of the breach, including the categories and approximate number of data subjects and personal data records affected.
• The name and contact details of the DPO or other contact point.
• A description of the likely consequences of the breach.
• A description of the measures taken or proposed to address the breach, including mitigation measures.

The only exception is where the breach is "unlikely to result in a risk to the rights and freedoms of natural persons." In practice, this exception is narrowly applied, and authorities expect notification in most cases.

Communication to Data Subjects (Article 34)

Where a breach is likely to result in a high risk to the rights and freedoms of individuals, the controller must also communicate the breach directly to affected data subjects "without undue delay." This communication must use clear and plain language and describe the nature of the breach, the likely consequences, and the measures taken.

Direct communication to data subjects is not required if: the controller has implemented appropriate technical protections (such as encryption) that render the data unintelligible; the controller has taken subsequent measures that ensure the high risk is no longer likely to materialise; or individual communication would involve disproportionate effort (in which case, a public communication or similar measure is required).

Processor Obligations

Processors must notify the controller without undue delay after becoming aware of a breach. The GDPR does not specify a timeframe for processor-to-controller notification, but most Data Processing Agreements set this at 24-48 hours. Indian IT/BPO companies acting as processors should ensure their incident response procedures enable rapid detection and escalation.

Practical Requirements for Indian Companies

• Maintain a breach register documenting all breaches, their effects, and the remedial action taken (Article 33(5)), regardless of whether the breach was notified to the authority.
• Conduct regular incident response drills to ensure the 72-hour notification window is achievable. Factor in time zone differences between Indian operations and EU supervisory authorities.
• Pre-draft notification templates to accelerate the reporting process during an actual incident.
• Ensure DPA clauses clearly define breach notification obligations and timelines between your organisation and EU clients.

The GDPR's penalty regime is among the most severe in global data protection law. Article 83 establishes a two-tier structure for administrative fines.

Two-Tier Fine Structure

Tier	Maximum Fine	Applicable Violations
Lower tier (Art. 83(4))	EUR 10 million or 2% of global annual turnover, whichever is higher	Violations related to: controllers and processors (Art. 8, 11, 25-39, 42-43); certification bodies (Art. 42-43); monitoring bodies (Art. 41)
Upper tier (Art. 83(5))	EUR 20 million or 4% of global annual turnover, whichever is higher	Violations of: processing principles (Art. 5-7, 9); data subject rights (Art. 12-22); cross-border transfer rules (Art. 44-49); member state law provisions; non-compliance with supervisory authority orders

Factors Influencing Fine Amounts (Article 83(2))

Supervisory authorities consider the following when determining fines:

• The nature, gravity, and duration of the infringement.
• Whether the infringement was intentional or negligent.
• Actions taken to mitigate the damage.
• Degree of responsibility, considering technical and organisational measures implemented.
• Any previous infringements.
• The degree of cooperation with the supervisory authority.
• The categories of personal data affected.
• How the authority became aware (self-reported vs. complaint vs. investigation).

Notable Enforcement Actions

Several landmark fines illustrate the scale of enforcement:

• Meta (Ireland, 2023): EUR 1.2 billion for unlawful transfers of EU personal data to the United States without adequate safeguards — the largest GDPR fine to date. Directly relevant to any company transferring data to a non-adequate country.
• Amazon (Luxembourg, 2021): EUR 746 million for processing personal data in violation of the GDPR's general data processing principles, related to targeted advertising.
• TikTok (Ireland, 2023): EUR 345 million for violations related to the processing of children's data, including transparency and data minimisation failures.
• Clearview AI (Multiple authorities, 2022): Fines totalling over EUR 60 million from France, Italy, Greece, and the UK for unlawful collection of facial biometric data from publicly available sources — significant for Indian AI/ML companies.

Beyond fines, supervisory authorities can issue orders to cease processing, ban data transfers, or require the deletion of unlawfully processed data. For an Indian company, an order to cease processing EU personal data would be operationally devastating — potentially more damaging than the fine itself.

Enforcement against non-EU companies is increasing. While collection of fines from companies with no EU presence or assets presents practical challenges, the reputational impact and the risk of losing EU clients make non-compliance a material business risk.

Moving from awareness to compliance requires a structured programme. The following steps reflect the approach we recommend for Indian companies based on our experience advising IT services, BPO, and technology firms.

1. Conduct a Gap Analysis

Map your current data protection practices against GDPR requirements. Identify every processing activity involving EU personal data, the lawful basis relied upon, existing security measures, and current contractual arrangements with EU clients and sub-processors. A gap analysis is the foundation — without it, compliance efforts are unfocused and wasteful.

2. Build and Maintain Records of Processing Activities (RoPA)

Article 30 requires both controllers and processors to maintain written records of processing activities. For processors, this must include: categories of processing carried out on behalf of each controller; transfers to third countries (including the transfer mechanism); and a general description of technical and organisational security measures. Your RoPA should be a living document, updated whenever processing activities change.

3. Update Data Processing Agreements (DPAs)

Every arrangement where you process personal data on behalf of an EU controller must be governed by a DPA that meets the requirements of Article 28. Key provisions include: processing only on documented instructions; confidentiality obligations; security measures; sub-processor management (prior specific or general written authorisation); assistance with data subject rights and breach notification; deletion or return of data upon termination; and audit rights.

4. Implement Standard Contractual Clauses

For data transfers from the EU to India, execute the 2021 SCCs (Module 2 for controller-to-processor transfers is most common). Conduct a Transfer Impact Assessment for each transfer, documenting the Indian legal framework and any supplementary measures implemented. Review and update TIAs periodically and whenever Indian law changes.

5. Appoint a DPO (If Required)

Assess whether your organisation meets the DPO appointment thresholds under Article 37. If so, appoint a qualified DPO with genuine independence and ensure they are accessible to EU supervisory authorities. Even if not legally required, consider appointing a DPO voluntarily — it demonstrates commitment to compliance and provides a clear point of accountability.

6. Implement Technical and Organisational Measures

Article 32 requires security measures appropriate to the risk, including (where appropriate): pseudonymisation and encryption; the ability to ensure ongoing confidentiality, integrity, availability, and resilience; the ability to restore data availability after an incident; and regular testing and evaluation of security measures. For Indian IT companies, this typically means: encryption at rest and in transit, access controls based on the principle of least privilege, network segmentation, endpoint protection, and regular penetration testing.

7. Establish a Breach Response Protocol

Document an incident response plan that enables 72-hour notification to supervisory authorities. Assign roles and responsibilities, define escalation paths, prepare template notifications, and conduct tabletop exercises at least annually. Ensure the protocol accounts for the time zone difference between India and EU member states.

8. Train Your Workforce

GDPR compliance is not a purely legal or IT function — it depends on the awareness and behaviour of every employee who handles EU personal data. Conduct role-specific training: front-line BPO staff need to understand data subject rights and breach identification; developers need to understand privacy by design; and management needs to understand accountability and governance obligations.

9. Review Vendor and Sub-Processor Arrangements

If you engage sub-processors (including cloud infrastructure providers, analytics tools, or other third-party services), ensure each sub-processor is bound by GDPR-compliant terms. Under Article 28(4), you remain fully liable to the controller for the acts of your sub-processors. Maintain a current list of sub-processors and notify controllers of any changes as required by your DPA.

10. Establish Ongoing Governance

GDPR compliance is not a one-time project. Establish a governance framework that includes: periodic compliance audits (at least annually); DPIA reviews for new processing activities; RoPA updates; policy reviews; training refreshers; and monitoring of regulatory guidance and enforcement trends. Assign clear ownership — whether to a DPO, a privacy team, or a cross-functional privacy committee.

Use this checklist to assess your organisation's GDPR readiness. Each item corresponds to a specific GDPR requirement discussed in this guide.

Governance & Accountability

• Completed a GDPR gap analysis against current practices.
• Designated a Data Protection Officer (or documented the assessment that a DPO is not required).
• Appointed an EU representative under Article 27 (if no EU establishment).
• Established a privacy governance framework with clear roles and reporting lines.
• Implemented a privacy-by-design and privacy-by-default policy (Article 25).

Lawfulness & Transparency

• Identified and documented the lawful basis for every processing activity involving EU personal data.
• Published a GDPR-compliant privacy notice (Articles 13-14) covering all required information.
• Implemented granular consent mechanisms where consent is the lawful basis.
• Conducted and documented Legitimate Interest Assessments where Article 6(1)(f) is relied upon.

Data Subject Rights

• Established a process to receive, verify, and respond to data subject requests within one month.
• Mapped all data stores to enable efficient retrieval, rectification, and deletion.
• Implemented data portability capabilities for data processed by automated means under consent or contract.
• Reviewed automated decision-making systems for Article 22 compliance.

Records & Documentation

• Created and maintain Records of Processing Activities (Article 30) for all EU data processing.
• Documented data retention periods for each category of personal data.
• Maintained a register of all Data Protection Impact Assessments conducted.
• Maintained a breach register documenting all incidents, notified or not.

Cross-Border Transfers

• Executed Standard Contractual Clauses (2021 version) for all EU-to-India data transfers.
• Conducted Transfer Impact Assessments for each transfer, with documented supplementary measures.
• Maintained an up-to-date list of all sub-processors and their locations.
• Established a sub-processor change notification process as required by DPAs.

Security & Breach Response

• Implemented technical measures: encryption, access controls, pseudonymisation, network segmentation.
• Implemented organisational measures: security policies, access management procedures, incident classification.
• Documented a breach response plan enabling 72-hour supervisory authority notification.
• Conducted at least one breach response drill or tabletop exercise in the past 12 months.
• Pre-drafted breach notification templates for supervisory authorities and data subjects.

Contracts & Vendor Management

• Executed Article 28-compliant Data Processing Agreements with all EU controller clients.
• Flowed GDPR-equivalent obligations down to all sub-processors.
• Reviewed cloud infrastructure and SaaS vendor agreements for GDPR compliance.
• Ensured DPAs address all Article 28(3) mandatory provisions.

Training & Awareness

• Conducted GDPR awareness training for all staff handling EU personal data.
• Delivered role-specific training (developers, BPO front-line, HR, management).
• Scheduled annual training refreshers and tracked completion rates.
• Included GDPR obligations in employee onboarding for relevant roles.