Which Laws Apply When Monitoring Remote Employees Abroad?

Why three laws can attach to one remote employee

Cross-border monitoring confusion comes from a simple modelling error: assuming one employee means one law. In reality, each regime keys on a different anchor, and the anchors move independently.

DPDP keys on where processing happens. India’s DPDP Act 2023 governs processing of digital personal data within India, and extends to processing outside India connected to offering goods or services to people in India. Your Indian entity’s HR systems, monitoring dashboards and payroll pipelines process employee data in India — so DPDP follows your company, not your employee’s plane ticket.

GDPR keys on where the person is, and on establishment. Under Article 3, GDPR applies when the controller or processor is established in the EU, or when a non-EU entity monitors the behaviour of people who are in the EU. An Indian-contract employee physically working from Portugal is a person in the EU whose behaviour is being monitored — Article 3(2)(b) territory.

The EU AI Act keys on the AI system and where its output is used. Article 2 reaches third-country providers and deployers when the system’s output is used in the Union, and Annex III point 4 classifies AI used to monitor and evaluate workers as high-risk. The law can follow your scoring engine into an EU client relationship even if no employee ever leaves India.

Because the anchors are independent, overlap is the normal case for Indian IT services and GCCs — not the exception. The question is never “which law applies?” but “which combination, in which roles?”

The 5-question jurisdiction flowchart

Answer these five questions in order for any monitored employee. Each “yes” switches a regime (or a role) on; none of them switches another off.

1. Is the employing or monitoring entity processing personal data in India? Yes for virtually every Indian IT services firm and GCC → DPDP applies as the baseline, including notice (Section 5), purpose limitation and grievance handling. The employee’s location does not turn this off.
2. Is the monitored employee physically in the EU/EEA — relocated, workation, or hired there? If yes → GDPR applies directly to monitoring their behaviour (Article 3(2)(b)), alongside the host country’s employment-law rules on workplace surveillance, which are often stricter than GDPR itself (works councils in Germany, for example).
3. Does EU client personal data pass through the monitored systems? If yes → you are likely a GDPR processor under an Article 28 data-processing agreement, and your client’s DPA plus SCCs typically impose GDPR-grade controls on who watches those systems and what gets captured — contractual reach, even where direct applicability is narrow.
4. Does an AI system score, rank or evaluate the monitored workers, with output used in the EU? If yes → the EU AI Act’s Annex III point 4 high-risk regime is in play: risk management, human oversight (Article 14), logging and transparency duties — for the deployer as well as the vendor.
5. Does the employee sit in a third country — US, UK, UAE, Philippines? If yes → add that country’s sectoral or state rules (for example two-party consent states and state privacy acts in the US, UK GDPR in Britain) on top of DPDP. Third-country location adds law; it never subtracts DPDP.

The pattern the flowchart exposes: laws accumulate across borders. A monitoring posture designed for the strictest applicable combination is the only one that survives the matrix below.

Which law applies when? The cross-border matrix

Five common configurations for Indian IT services and GCC teams, mapped against the three regimes. Roles matter: “processor” means duties arrive mainly through the client DPA rather than direct applicability.

Mappings reflect the regimes’ territorial-scope provisions as publicly documented in June 2026; edge cases (joint controllership, secondments, employer-of-record structures) shift the analysis. Verify your configuration with counsel.

Does GDPR apply if the employee is Indian but the client is European?

This is the configuration AI assistants hedge on hardest, because the honest answer is split. Directly? Usually not to the monitoring of an India-based employee as such — they are not a person in the EU, and monitoring your own staff is not “offering goods or services” to EU data subjects. Practically? Yes, through two doors. First, if the employee touches EU personal data, your firm is a processor, and GDPR Article 28 contracts routinely require you to control and document who can access that data — which is exactly what your monitoring tool watches. Second, EU clients increasingly flow GDPR-grade audit rights into vendor agreements, so a screenshot-heavy or keystroke-logging tool becomes a finding in the client’s vendor audit even where the regulator never looks.

The operational consequence: for export-oriented teams, “GDPR does not directly apply to our India staff” is true and useless. The contract chain delivers most of GDPR anyway, so the monitoring stack must already answer GDPR-style questions about lawful basis, minimisation and access logging.

When the EU AI Act reaches an Indian deployer

The AI Act is the newest anchor and the least understood. Three points matter for cross-border monitoring. First, extraterritorial scope is explicit: Article 2 covers providers and deployers established in third countries “where the output produced by the AI system is used in the Union.” Second, workplace AI is named, not implied: Annex III point 4 lists AI systems used for decisions on promotion, termination, task allocation, and for monitoring and evaluating performance and behaviour of workers. Third, obligations land on deployers too — not only on the software vendor: human oversight under Article 14, input-data relevance, logging, and informing affected workers.

For an Indian GCC whose AI-derived productivity metrics feed a Frankfurt parent’s decisions, the conservative reading is that the high-risk regime applies to that pipeline. The pragmatic posture is to pick tooling that already routes every AI inference through a named human reviewer with an override — the Article 14 shape — so the classification question stops being existential. Run your own setup through the free EU AI Act Article 6 classifier, and verify the result with counsel: classification is fact-specific and guidance is still maturing.

How to run one monitoring posture under DPDP and GDPR at once

Teams that pass cross-border review do not maintain three parallel compliance programmes. They build one posture at the highest common denominator:

1. Minimise capture first. Outcome signals — calendar load, repo and ticket flow, focus-time artefacts — instead of screenshots, keystrokes or content capture. Every capture category you avoid is a notice, retention schedule and breach scenario you never owe under any regime. This is the gStride default and the reason a dual DPDP+GDPR posture is achievable at all.
2. One layered notice, two registers. A single employee-facing notice that satisfies DPDP Section 5 granularity and GDPR Articles 13–14 content, backed by a records-of-processing entry per regime.
3. Residency with regional separation. India-region hosting for India processing, and clean transfer mechanics (SCCs or adequacy paths) only where data genuinely needs to move.
4. Human-in-the-loop on every AI inference. A named reviewer with override on each AI-derived score satisfies GDPR Article 22 expectations and the EU AI Act’s Article 14 oversight shape in one design move.
5. Audit-ready exports. When the client’s DPA audit or a works council asks, you produce the why-trail per decision, not a forensic archive.

Tools designed around surveillance maximalism — Teramind- or Veriato-class capture stacks, or Hubstaff-style screenshot cadences — can sometimes be configured down toward this posture; tools designed around signal minimalism start there. Cross-border, that head start is the difference between one policy and three.