Your SaaS Company Is in India. That Doesn't Mean GDPR Doesn't Apply.

Your SaaS Company Is in India. That Doesn't Mean GDPR Doesn't Apply.

Your company is registered in India. Your developers work in Bengaluru, Chennai or Hyderabad. Your customer data may sit in an Indian cloud region. None of those facts, by itself, answers whether the EU General Data Protection Regulation applies to your SaaS business.

GDPR can reach processing carried out outside Europe. The relevant questions concern your activities, the people you serve or monitor, and the roles you play. For a SaaS founder preparing to sell abroad, treating the company’s address as the entire answer can leave important questions unresolved.

This guide explains the scope tests and the practical work to do before making privacy commitments to customers. It focuses on EU GDPR as it applies across the European Economic Area, or EEA: the EU plus Iceland, Liechtenstein and Norway. UK GDPR requires a separate assessment.

Does GDPR apply to an Indian SaaS company

It can. An EEA establishment connected to the processing, an offer of goods or services to people in the EEA, or monitoring their behaviour there can bring relevant processing within scope. Being headquartered in India is not an automatic exemption.

The answer should be assessed for the relevant processing activity. Avoid replacing one blanket assumption with another: “we are in India, so GDPR cannot apply” and “we have a European contact, so everything is subject to GDPR” both skip the necessary analysis.

EDPB guidance on personal data and GDPR applicability

Three scope questions to ask before expanding into Europe

Is processing connected to an EEA establishment

Look beyond the location of the server or the registered parent company. An EEA presence can matter where personal data processing takes place in the context of its activities. Review the relationship between your European operations and the specific processing, rather than assuming only a separately incorporated subsidiary counts.

Are you offering services to people in the EEA

Consider evidence of intentional market targeting. A Europe-focused launch, localised signup journey or campaigns aimed at people there can be relevant. A website that someone in Europe can simply open does not, by itself, demonstrate that targeting.

Are you monitoring behaviour in the EEA

Review profiling and tracking used to analyse or predict behaviour there. Do not assume that every log or every analytics feature automatically satisfies this test; examine its purpose and operation.

For the targeting test, location matters rather than nationality alone. A person need not hold an EU passport to be relevant to the assessment.

Assess territorial scope for each relevant processing activity.

EDPB Guidelines 3/2018 on territorial scope

Serving an EEA customer raises a separate processor question

A SaaS product can process personal data on behalf of an EEA business even where the provider’s own direct territorial scope requires further analysis. Customer contracts and transfer arrangements therefore deserve their own review.

The EDPB distinguishes these routes. Using a processor outside the EEA does not remove a controller’s obligations. Nor does that customer relationship, by itself, automatically bring the overseas processor within GDPR’s direct territorial scope. The customer may impose relevant obligations through its processing contract, and international transfer requirements may also apply.

For example, consider an Indian HR platform hosting employee records for a French customer. Before onboarding, document the parties’ roles, the customer’s instructions, the locations from which staff can access records, and the terms governing subprocessors. This is an illustrative scenario, not a reported customer case.

Your company may be a controller and a processor

A controller determines the purposes and means of processing. A processor handles personal data on behalf of a controller. Roles follow the activity, so a single company can have different roles for different uses.

You may be a processor for customer-uploaded employee records and a controller for your own prospect database or billing contacts. That distinction affects who decides the purpose, answers rights requests and instructs other suppliers. A contract label should reflect what actually happens.

One company may have different privacy roles for different processing purposes.

EDPB guidance on controllers and processors

Hosting in Europe does not settle transfers to India

An EEA cloud region does not answer every question about data access. Map customer uploads, Indian support-team access, backups, logging tools, and downstream vendors. Where data is made available to a separate organisation outside the EEA, review whether Chapter V applies.

India is not currently on the European Commission’s adequacy list. Where an applicable transfer needs safeguards, identify a suitable mechanism; standard contractual clauses are one commonly used option. Assess the specific transfer, the applicable terms and any supplementary measures required. Signing a document alone is not the whole exercise.

The review of transfers is additional to ordinary GDPR compliance. Hosting choices, contracts and security controls should be considered together.

Review data access and the processing chain as well as the hosting location.

EDPB guidance on international data transfers

European Commission adequacy decisions

What GDPR readiness looks like inside a SaaS product

Map personal data and decide why it is needed

Start with account records, support tickets, billing contacts, uploaded customer content and identifiable activity records. Assign an owner to each processing purpose and record who can access the data. Decide what must be retained and what can be deleted.

Where your company acts as controller, identify an appropriate legal basis and explain the processing clearly. Consent is not the only legal basis, and a copied privacy policy does not establish that your actual operations are lawful.

Make rights requests operational

The controller generally has one month to respond to a rights request. A permitted extension requires informing the person within that first month. Build a workflow to verify identity proportionately, find relevant records and record the response. Processors should support the controller according to their obligations and instructions.

Test a request with a sample account. Can your team find the data in the application, support tools and exports? Can it explain retention exceptions without promising that every record will always be erased?

EDPB guidance on handling individuals’ rights

Prepare for incidents before they happen

Where notification is required, a controller must notify the relevant authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. Notification is not required where the breach is unlikely to result in a risk to individuals’ rights and freedoms. A processor must notify the controller without undue delay; it should not treat 72 hours as a standard waiting period.

Agree an escalation owner and customer contact. Record when the team became aware, what data may be involved, the risk assessment and the actions taken. Communication to affected individuals follows a separate high-risk test.

EDPB guidance on personal data breaches

Check the controls that protect customer data

Review access privileges, tenant isolation, support access, logging, backups and deletion behaviour. Use tests that match the risks in your product. A privacy document cannot show whether one tenant can access another tenant’s records.

Relevant technical assessments include web application penetration testing and a cloud security audit. These can inform remediation; they do not establish GDPR compliance on their own.

Questions to settle before promising GDPR compliance

Which processing activities are directly in scope, and why?

Where are we a controller, processor or subprocessor?

Which personal data can be accessed from India or other non-EEA locations?

Are customer processing agreements and any required transfer safeguards in place?

Can we demonstrate rights handling, retention decisions and incident escalation?

Have we separately assessed whether an EEA representative or a data protection officer is required?

Who owns changes when the product, markets or suppliers change?

Use the answers to create a practical remediation plan. These are preparation questions, not a substitute for a documented assessment of your specific business.

Frequently asked questions

Does any European visitor make our whole company subject to GDPR

No. Website accessibility alone does not settle territorial scope. Assess the relevant activity against the establishment and targeting tests rather than treating a visitor’s location as a complete answer.

Does a business customer mean personal data is irrelevant

No. A B2B product can still contain identifiable employee, administrator and customer contact information. Identify the people behind the business accounts and the purposes for which their information is used.

Does an EEA cloud region remove the need for transfer review

No. Review access by separate overseas organisations and the wider processing chain, not only the primary storage region.

Does SOC 2 or ISO 27001 settle GDPR compliance

No. Those frameworks may provide useful security evidence, but the scope, roles, lawful processing and rights questions in this guide still need answers. Treat supporting assurance and GDPR readiness as related work with distinct objectives.

Do all Indian SaaS companies need an EEA representative

No. This is a separate assessment. Article 27 generally requires a representative for non-EEA controllers or processors subject to the targeting route, subject to specific exceptions. Do not assume that being small, operating online or having a customer contact automatically settles it. A representative and a data protection officer are different roles.

Start with your data flows before making promises

A useful GDPR discussion begins with a description of your product, markets, personal data, suppliers and access locations. That gives your team a basis for deciding what needs to change and what evidence customers can reasonably request.

Discuss your privacy and security requirements with Rex Cyber Solutions. Share your target markets, customer data flows and current procurement questions so the conversation can focus on your actual gaps and next steps.

‍