Article 44 — General principle for transfers

At a glance

Principle	General principle for transfers to third countries or international organisations
Requirement	A Chapter V mechanism plus compliance with all other GDPR obligations
Protection	The level of protection guaranteed by the GDPR must not be undermined
Applies to	Onward transfers as well as the initial transfer

Article 44 is deceptively short. It does not itself provide the detailed mechanisms through which an international transfer becomes lawful. Instead, it performs a much more fundamental function: it establishes the governing principle for the entire GDPR regime on international transfers.

The basic idea is simple:

Moving personal data outside the EU/EEA does not mean that GDPR protection disappears.

If personal data leaves the EU/EEA and is made available to an entity in a third country or to an international organisation, the organisation cannot simply say that the GDPR no longer applies to that data. Chapter V exists precisely to prevent that result.

This is why Article 44 should not be treated merely as an introductory provision before Articles 45, 49. It is the provision that gives the entire international-transfer chapter its underlying purpose and affects how Articles 45, 46, 47, 48 and 49 are interpreted.

The provision therefore has two dimensions.

First, there is a procedural/legal dimension: the transfer must satisfy the appropriate mechanism under Chapter V.

Second, there is a substantive protection dimension: the mechanism chosen cannot be used in a way that undermines the level of protection guaranteed by the GDPR.

That second dimension is particularly important after the CJEU's decisions in Schrems I and Schrems II. The Court made clear that international-transfer mechanisms cannot be interpreted mechanically. The ultimate question is whether the protection guaranteed to individuals is maintained when their data leaves the EU. In Schrems II, the Court specifically emphasised that the protection required by Chapter V must be maintained irrespective of which transfer mechanism is being relied upon. (InfoCuria)

Why does Article 44 exist?

The GDPR generally regulates processing of personal data within its territorial scope. But modern data processing is not confined to geographical borders.

Consider a German company that collects customer information in Germany.

The company may use:

• a US-based cloud provider;

• an Indian customer-support provider;

• a Japanese analytics service;

• a Canadian HR platform;

• a Singapore-based disaster-recovery provider.

The actual physical location of the server may also be different from the location of the service provider.

Without a special international-transfer regime, an organisation could potentially avoid EU data-protection safeguards simply by moving personal data to another jurisdiction.

For example:

German company → US cloud provider → US government access

If the GDPR protections stopped the moment the data reached the United States, the protection offered by EU law would be substantially weakened.

Article 44 prevents this conceptual gap.

The GDPR therefore adopts a continuity principle:

EU protection → transfer → third country → protection must continue

This is why Recital 101 is particularly important. It recognises that international data flows are necessary for international trade and cooperation, but simultaneously insists that those flows should not undermine the protection guaranteed within the EU.

So Article 44 is not an anti-transfer provision.

It does not say:

"Personal data should remain inside the EU."

Instead, it says, in substance:

"Personal data can leave the EU, but the transfer must occur through a mechanism that preserves the required level of protection."

This distinction is fundamental.

Article 44 is a general principle, not the complete transfer mechanism

One of the easiest mistakes is to read Article 44 as though it independently tells an organisation exactly how to transfer data.

It does not.

Articles 45, 49 provide the principal mechanisms.

Broadly:

Article 45 → adequacy

The European Commission has recognised that a country or relevant territory/sector provides an adequate level of protection.

Article 46 → appropriate safeguards

There is no adequacy decision, but the exporter uses an appropriate safeguard, such as Standard Contractual Clauses, Binding Corporate Rules or another recognised mechanism.

Article 47 → Binding Corporate Rules

This deals specifically with BCRs for groups of undertakings or groups of enterprises engaged in international transfers.

Article 48 → foreign authority requests

A foreign court judgment or administrative authority decision does not automatically become a lawful basis for transferring data merely because it demands disclosure.

Article 49 → derogations

Certain narrowly defined situations permit transfers even without adequacy or an Article 46 safeguard.

Article 44 sits above all of these mechanisms.

The relationship can therefore be understood like this:

Article 44 = overarching principle

==Articles 45, 49 = specific legal routes==

But there is an additional layer.

The transfer must also comply with the rest of the GDPR.

That is because Article 44 expressly operates "subject to the other provisions" of the Regulation.

This is extremely important in practice.

A lawful transfer is not necessarily lawful processing

Suppose a French company wants to send employee information to an Indian service provider.

The company signs valid Standard Contractual Clauses.

Can it now process whatever information it wants?

No.

The SCCs solve the international-transfer issue. They do not automatically solve every other GDPR issue.

The company must still consider:

• whether it has a lawful basis under Article 6;

• whether special-category data requires Article 9 compliance;

• whether the purpose is compatible with Article 5;

• whether the data collected is excessive;

• whether transparency obligations have been satisfied;

• whether retention is lawful;

• whether data-subject rights can be exercised;

• whether appropriate security measures exist under Article 32;

• whether processor requirements under Article 28 are satisfied;

• whether the transfer itself satisfies Chapter V.

This produces an important conceptual distinction:

Chapter V compliance is an additional requirement, not a substitute for ordinary GDPR compliance.

Imagine a company has no lawful basis for collecting customer location data in the first place.

It cannot cure that defect by signing SCCs before sending the location data to a US processor.

The transfer mechanism addresses the transfer.

It does not retrospectively legalise the underlying processing.

What exactly is a "transfer"?

This is one of the most important technical issues under Article 44.

The GDPR itself does not provide a comprehensive statutory definition of "transfer" for Chapter V purposes.

This creates an important interpretative question:

When exactly does an organisation's disclosure of personal data become an international transfer?

The EDPB has approached this through three cumulative criteria.

The three elements essentially ask:

1. Is the exporter subject to the GDPR for the relevant processing?

2. Does that exporter disclose or otherwise make personal data available to another entity?

3. Is that recipient located in a third country or is it an international organisation?

If all three conditions are satisfied, Chapter V is engaged. (European Data Protection Board)

This is much more nuanced than simply asking:

"Where is the server?"

The legal analysis is about who is disclosing data to whom and where the recipient is located.

First criterion, the exporter must be subject to the GDPR

The first question is whether the organisation exporting the data is subject to the GDPR for that particular processing operation.

For example:

A company established in France collects customer information and sends it to a US processor.

The French company is clearly subject to the GDPR.

It is therefore the exporter.

But the concept becomes more complicated where Article 3(2) is involved.

Suppose a US company has no EU establishment but offers services to individuals in Germany and therefore falls within the territorial scope of the GDPR for that processing.

That US company could potentially be subject to the GDPR.

If it subsequently discloses relevant personal data to another entity in India, the Chapter V analysis can arise.

Therefore, you should not reduce the concept to:

"EU company = exporter."

The more accurate question is:

Is the entity subject to the GDPR in relation to the relevant processing operation?

This distinction is important for multinational organisations.

Second criterion, disclosure or making data available

The second element requires something more than the mere existence of data outside Europe.

The exporter must disclose the personal data to another controller, joint controller or processor, either through transmission or by otherwise making the data available.

This is where many practical scenarios become difficult.

Example: ordinary transfer

A Dutch company sends its customer database to an Indian outsourcing company. There is an obvious disclosure. Dutch company = exporter. Indian company = importer.

Chapter V applies.

Example: cloud provider

A Spanish company uploads customer information to a cloud service operated by a US company. If the US provider receives or can access the personal data as a separate entity, the Chapter V analysis arises.

Example: group company

A French subsidiary sends employee information to its US parent company. The fact that both entities belong to the same corporate group doesnot, by itself, eliminate the possibility of a transfer. Separate companies within the same group can be separate controllers or processors. Therefore:

same corporate family ≠ same legal entity

This is an important operational point for multinational groups.

The EDPB expressly recognises that intra-group disclosures can constitute transfers where separate entities are involved. (European Data Protection Board)

Merely storing data outside the EU is not the complete legal test

A common misconception is:

"If my data is physically stored in India, there must automatically be an Article 44 transfer."

That is too simplistic.

Suppose an EU company itself processes its own data while temporarily operating its own infrastructure outside the EU, without disclosing the information to a separate entity.

Under the EDPB's transfer concept, that may not constitute a Chapter V transfer because the second criterion, disclosure to another entity, may be absent.

But that does not mean the processing becomes legally irrelevant.

This distinction is crucial.

There may be no Chapter V transfer, but the organisation still has to comply with the GDPR generally.

The organisation must consider:

• security;

• lawful processing;

• accountability;

• data-subject rights;

• government-access risks;

• confidentiality;

• organisational controls.

So:

No Chapter V transfer ≠ no GDPR obligation.

This is one of the most important conceptual distinctions under Article 44. (European Data Protection Board)

Direct collection by a foreign entity, a difficult boundary

Another technically difficult scenario concerns direct collection.

Imagine:

An Indian company has a website accessible to individuals in Germany.

A German customer enters their information directly into the Indian company's website.

The Indian company receives the information directly.

There is not necessarily an EU entity acting as exporter and disclosing the information to the Indian company.

Therefore, under the EDPB's approach, the direct collection itself does not necessarily constitute a Chapter V transfer.

But this does not mean the Indian company escapes the GDPR.

If Article 3(2) applies, the Indian company may itself be subject to the GDPR.

This produces a very important distinction:

Article 3 determines whether the GDPR applies to the processing.

Chapter V determines whether a particular transfer from an exporter to an importer requires transfer safeguards.

These are related but different questions.

Example

Indian SaaS provider Imagine an Indian SaaS provider sells HR software to European companies. A French company uses the SaaS platform. There are two very different possibilities.

Scenario A

The French company sends employee information to the Indian SaaS provider. Here: French company = exporter Indian SaaS company = importer

This is a classic Chapter V transfer.

Scenario B

An employee in France directly enters information into the Indian company's own platform, and the Indian company collects it directly. The Chapter V analysis is different because there may not be an EU exporter disclosing the information. However, Article 3(2) may still bring the Indian company's processing within the GDPR. This distinction is extremely useful in practical privacy assessments.

Who is the "importer"?

The importer is not necessarily simply "the country where the server is located."

The relevant question is generally who receives or is made able to receive the personal data.

Consider:

German company → US cloud company → server in Ireland

The fact that the server is physically in Ireland does not necessarily resolve the Chapter V analysis.

The legal relationship between the exporter and recipient matters.

Similarly:

German company → Indian processor → Indian processor uses a Singapore subprocessor

Now there can be multiple international-transfer layers.

This is where onward-transfer controls become critical.

The importance of onward transfers

Article 44 expressly extends its principle to onward transfers.

This is one of the most important practical aspects of the provision.

Consider:

France → India → Singapore → United States

The original transfer from France to India is one international transfer.

But the Indian recipient cannot simply assume:

"We received the data lawfully, therefore we can send it wherever we want."

The subsequent disclosure creates another transfer issue.

This is the concept of an onward transfer.

The protection must therefore follow the data through subsequent transfers.

This is particularly important with:

• cloud providers;

• outsourcing companies;

• multinational processors;

• subprocessors;

• support centres;

• analytics providers;

• infrastructure providers.

Why onward transfers are so important

Imagine a French company contracts with an Indian customer-support company.

The French company performs due diligence on the Indian company and enters into an appropriate transfer mechanism.

But the Indian company uses a US-based AI service to analyse customer complaints.

Now the data has moved:

France → India → USA

The original French company cannot necessarily stop its compliance analysis at the first transfer.

It needs to understand what happens afterward.

The second movement may create an onward transfer that requires appropriate legal and contractual protection.

This is one reason modern transfer assessments often require organisations to understand the entire processing chain, rather than merely identifying the immediate vendor.

Onward transfer does not mean only a physical movement of data

Another common misunderstanding is that an onward transfer requires a file to be physically downloaded and uploaded somewhere else.

Not necessarily.

If personal data is made available to another entity, that may be enough.

For example:

An Indian processor gives a US subprocessor remote access to an EU customer's personal-data environment.

There may be no physical "file transfer" in the traditional sense.

But making the personal data available to another entity can still constitute the relevant disclosure.

The technical architecture therefore does not determine the legal analysis by itself.

"Third country", what does it mean?

A third country essentially refers to a country outside the EU/EEA framework for purposes of the Chapter V transfer regime.

For practical purposes, the important point is:

The destination being outside the relevant European legal area triggers the question whether Chapter V applies.

It does not mean that every non-EU country is automatically unsafe.

That would be inconsistent with the adequacy mechanism.

For example, where the European Commission has adopted an adequacy decision covering the destination, Article 45 provides the relevant transfer route.

So:

Third country ≠ prohibited country

Instead:

==Third country = destination requiring an appropriate Chapter V analysis.==

Adequacy changes the analysis

Suppose a company transfers personal data to a country covered by a valid adequacy decision.

The organisation does not generally need to use SCCs merely because the country is outside the EU.

The adequacy decision itself provides the Chapter V mechanism.

This demonstrates why Article 44 should not be interpreted as:

"Every transfer outside Europe requires SCCs."

That is incorrect.

The legal mechanism depends on the circumstances.

Broadly:

Adequacy available → Article 45

No adequacy → consider Article 46 safeguards

Exceptional situation → potentially Article 49

But Article 44 continues to govern the overall interpretation.

"Subject to the other provisions of this Regulation" is extremely important

This phrase prevents organisations from treating Chapter V as a standalone privacy regime.

Suppose:

A company has a valid SCC with a US processor.

But the company has collected the data unlawfully.

The SCC does not cure the unlawful collection.

Or suppose:

The transfer is based on legitimate interests, but the organisation has failed to satisfy the relevant balancing and transparency requirements.

Again, the transfer mechanism does not automatically cure the defect.

Or suppose:

The organisation transfers unnecessary categories of employee information to an outsourcing provider.

The existence of SCCs does not override data minimisation.

This is why an international-transfer assessment should be understood as:

ordinary GDPR compliance + Chapter V compliance

not:

Chapter V instead of ordinary GDPR compliance.

Article 5 remains relevant

Article 44 must be read alongside the GDPR's core principles.

For example, data minimisation remains relevant.

Suppose a European employer wants to outsource payroll to India.

It needs to send:

• employee name;

• bank account details;

• salary information;

• tax information.

But it also sends:

• employee medical history;

• personal photographs;

• disciplinary records;

• unrelated performance notes.

The transfer mechanism may be perfectly valid, but the transfer could still raise serious questions under data minimisation and purpose limitation.

The international-transfer mechanism does not create a licence to send excessive information.

Lawfulness of processing and transfer are separate questions

This distinction is worth emphasising because it frequently causes confusion.

Imagine:

Article 6 problem: The organisation has no lawful basis for processing the data.

Article 44 problem: The organisation also wants to send the data to a third country.

There are two problems.

A valid transfer mechanism cannot cure the first problem.

Conversely, having a lawful basis under Article 6 does not automatically authorise the international transfer.

So an organisation must ask two separate questions:

Can I lawfully process this personal data?

and

Can I lawfully transfer it internationally?

The answers are not necessarily the same.

Article 44 and transparency

International transfers also interact with transparency obligations.

Individuals may need to know that their personal data is being transferred outside the EU and, where applicable, information concerning the relevant safeguards.

Consider a privacy notice saying:

"We process your personal data to provide customer support."

But in reality:

Customer → EU company → Indian support centre → US analytics provider

A generic statement may fail to provide the level of transparency required by the GDPR.

This is why international transfers are not merely a procurement or contract issue.

They can affect:

• privacy notices;

• records of processing activities;

• vendor disclosures;

• data-subject communications;

• contractual documentation.

Article 44 and security

Security is equally important.

Suppose a European company transfers sensitive customer information to a third-country processor using an Article 46 mechanism.

Even if the transfer mechanism is legally valid, the company must still consider Article 32 security requirements.

For example:

• encryption;

• access controls;

• authentication;

• logging;

• segregation;

• incident management;

• key management;

• pseudonymisation where appropriate.

The reason is straightforward.

A lawful transfer mechanism does not make insecure processing lawful.

The major conceptual shift after Schrems II

Article 44 became particularly important after Schrems II.

The CJEU's reasoning established that transfer mechanisms cannot be treated as mere paperwork.

The key concern is the level of protection actually available in the destination country.

The Court held that the level of protection guaranteed in the EU must not be undermined when data is transferred to a third country. (InfoCuria)

This is a profound shift in how international transfers should be approached.

Before this reasoning became central to transfer compliance, organisations could sometimes approach SCCs as a contractual exercise:

"We have signed the SCCs, therefore the transfer is compliant."

Schrems II makes that approach inadequate.

The question becomes:

Do the SCCs, together with the circumstances and any supplementary measures, actually provide the required level of protection?

This is the foundation of the modern transfer impact assessment approach.

Why the destination country's law matters

Suppose an EU company transfers data to a country where government authorities have extensive legal powers to obtain private-sector data.

The exporter cannot necessarily ignore that fact merely because it has signed SCCs.

The question becomes whether the legal environment of the destination undermines the protections promised by the transfer mechanism.

This is particularly relevant where:

• intelligence authorities have broad powers;

• government-access laws are extensive;

• judicial remedies are weak;

• surveillance powers lack sufficient safeguards;

• individuals lack effective legal remedies.

This does not mean:

"Any government-access law makes a transfer illegal."

That would be far too broad.

The assessment is contextual and concerns whether the legal framework and practices undermine the protection required under EU law.

The EDPB's recommendations on supplementary measures were developed precisely in this context. (European Data Protection Board)

"Essentially equivalent" does not mean identical

This is an important nuance.

The destination country does not have to reproduce the GDPR word-for-word.

The standard is generally understood as essential equivalence, not absolute identity.

In other words:

The US does not need to become the EU.

India does not need to enact an identical GDPR.

Japan does not need to reproduce every provision of European data-protection law.

The question is whether the overall level of protection afforded to the transferred data is sufficiently equivalent in substance.

This concept originates in the CJEU's transfer jurisprudence and has become central to international-transfer analysis.

Why Article 44 is a "catch-all" provision

The final part of Article 44 is arguably its most powerful component.

It requires the Chapter V provisions to be applied so that the GDPR's level of protection is not undermined.

This means Article 44 acts as a control principle over Articles 45, 49.

Suppose someone interprets Article 46 in an extremely formalistic manner and says:

"The SCC document is signed, so everything is automatically lawful."

Article 44 prevents that simplistic interpretation.

Similarly, an organisation cannot say:

"Article 49 gives us a derogation, therefore the GDPR's level of protection no longer matters."

The purpose of Article 44 is to ensure that Chapter V mechanisms remain connected to the underlying rights-protection objective.

Article 44 and SCCs, practical example

Imagine:

German company → US cloud provider

There is no applicable adequacy route for the particular transfer.

The parties use the European Commission's SCCs.

At first glance, the transfer appears compliant.

But now consider that the US provider's processing could potentially be subject to government-access laws.

The organisation therefore needs to examine the circumstances of the transfer and whether additional measures are required.

Possible supplementary measures could include technical protections such as:

• strong encryption;

• appropriate key control;

• pseudonymisation;

• strict access controls.

The effectiveness of the measure depends on the actual threat.

For example, encryption is much more meaningful if the importer cannot access the decryption key.

Simply saying:

"The data is encrypted"

is therefore not necessarily enough.

The legal and technical architecture must be examined together.

Why encryption is not automatically a magic solution

Consider:

EU company encrypts data.

US processor receives encrypted data.

But:

• US processor has the decryption key; or

• the processor can access the application in decrypted form; or

• the processor operates the system where data is routinely available in plaintext.

The mere presence of encryption does not necessarily eliminate the risk.

By contrast, properly implemented encryption where the importer genuinely cannot access intelligible data may provide significantly stronger protection.

This illustrates an important Article 44 principle:

The effectiveness of a safeguard depends on how it operates in reality, not merely on its label.

What happens when the recipient is itself subject to the GDPR?

This is one of the trickier issues.

Suppose an American company is subject to the GDPR under Article 3(2).

Does that automatically mean Chapter V disappears when an EU organisation transfers data to it?

No.

The EDPB's transfer concept focuses on the location of the importer and the disclosure of data, not merely whether the importer is independently subject to GDPR obligations for the processing. (European Data Protection Board)

This creates an important distinction:

GDPR applicability to the importer

and

Chapter V transfer requirements

are separate analytical questions.

An importer can be subject to the GDPR and the transfer can still potentially fall within Chapter V.

Corporate groups do not create an automatic exception

Suppose:

French subsidiary → US parent

The company might say:

"It is an internal group transfer, so there is no international transfer."

That is not a safe assumption.

If the French subsidiary and US parent are separate legal entities, the disclosure can constitute a transfer.

The EDPB specifically recognises that intra-group disclosures may constitute international transfers. (European Data Protection Board)

This is one reason multinational groups often use BCRs.

Processing by an EU company outside the EU

Another difficult scenario is:

A French company sends its own employee to Singapore.

The employee accesses the company's European database from Singapore.

Is that automatically a Chapter V transfer?

Not necessarily.

If there is no disclosure to another entity, the EDPB's three-criteria transfer concept may not be satisfied.

But the processing may still raise:

• security concerns;

• access-control concerns;

• confidentiality concerns;

• government-access concerns;

• accountability issues.

This is a good example of why:

international processing ≠ automatically Chapter V transfer.

The distinction must be made carefully.

Remote access can create a transfer issue

Now change the example.

The French company gives a Singapore-based outsourcing company's employees access to the database.

The Singapore company is a separate processor.

Now personal data is being made available to another entity in a third country.

The Chapter V analysis becomes much clearer.

The critical factor is not whether the data was physically copied to Singapore.

It is that a third-country recipient has been given access to the personal data.

This is particularly important in cloud and remote-support arrangements.

Data centre location versus recipient location

Privacy professionals often focus heavily on data residency.

But residency is only one part of the analysis.

Consider:

EU company → US provider

with data stored in Germany.

If the US provider, as a separate entity, can access or process the data, the fact that the server is physically located in Germany does not automatically eliminate the Chapter V issue.

Conversely:

EU company → its own infrastructure in India

may raise a different question if no separate importer is involved.

Therefore:

Where the server is located is not always the decisive legal question.

The organisation must understand:

• who operates the system;

• who receives the data;

• who can access it;

• in what capacity;

• where that entity is located;

• what further disclosures occur.

The international organisation limb

Article 44 does not deal only with countries.

It also covers transfers to international organisations.

This is relevant where an organisation governed by public international law receives personal data.

For example, a European public authority might transmit personal data to an international organisation for a legitimate international-cooperation purpose.

The organisation cannot simply treat that as an ordinary domestic transfer.

The Chapter V framework may become relevant depending on the circumstances and applicable instrument.

International agreements do not automatically override GDPR requirements

Recital 102 is important here.

The EU may conclude international agreements involving personal-data transfers.

Member States may also enter into agreements in appropriate circumstances.

But those agreements cannot simply operate as a blanket exemption from GDPR requirements.

The underlying requirement remains:

The protection of the individual's fundamental rights must be appropriately maintained.

Therefore, an organisation cannot simply say:

"There is an international treaty, so GDPR transfer rules do not matter."

The legal relationship between the agreement, EU law and the GDPR must be examined.

The practical meaning of "not undermined"

The phrase "not undermined" is broader than asking whether a contract exists.

Consider two companies.

Company A

Uses SCCs.

The importer has strong technical controls.

The data is pseudonymised.

The importer has limited access.

The destination country's relevant authorities have limited practical ability to obtain the particular data.

Company B

Uses the same SCCs.

But the importer has unrestricted access to highly sensitive information.

The data is stored in plaintext.

The importer is subject to broad legal obligations potentially requiring disclosure.

The organisation has performed no meaningful assessment.

The contractual documents may look identical.

The actual protection may be very different.

Article 44 focuses on the latter.

Article 44 therefore creates a substantive obligation

It is tempting to think of Chapter V as a documentation exercise.

But Article 44 demonstrates that international-transfer compliance is ultimately about substantive protection.

This is why transfer compliance increasingly involves:

• legal analysis;

• technical analysis;

• vendor assessment;

• government-access analysis;

• contractual safeguards;

• organisational controls.

The privacy lawyer cannot always complete the assessment by looking only at the contract.

The lawyer may need to understand the actual data flow and technical architecture.

Transfer impact assessments

Although Article 44 does not itself create a standalone statutory document called a "Transfer Impact Assessment", modern transfer practice often involves conducting a structured assessment of the transfer circumstances.

The organisation may need to examine:

• the categories of personal data;

• the purposes;

• the recipients;

• the destination country;

• relevant laws;

• government-access possibilities;

• the nature of the processing;

• technical safeguards;

• contractual protections;

• practical enforcement and remedies.

The EDPB's supplementary-measures recommendations are particularly relevant to this risk-based analysis. (European Data Protection Board)

The important point is not the name of the document.

The important point is the substantive assessment.

Example

, HR outsourcing to India Consider a European company outsourcing payroll processing to India. The data includes:

• names;
• addresses;
• bank information;
• salaries;
• tax information. The company first asks: Is this processing lawful? Then: Is the Indian entity a controller or processor? Then: Is there a Chapter V transfer? Yes, if the EU exporter makes the information available to the Indian entity. Then: Is there an adequacy decision covering the transfer? If not, an Article 46 mechanism may be required. Then: Do the circumstances require additional assessment or supplementary measures? Then: Does the Indian processor use subprocessors elsewhere? If yes, onward-transfer issues arise. Then: Can employees exercise their GDPR rights effectively? Then: Are the technical safeguards adequate? This shows how Article 44 operates in the real world. It is not an isolated legal clause. It sits at the centre of the entire international-processing architecture.

Example

, EU SaaS provider using Indian support Consider an EU SaaS company. Customer data is stored in Europe. But technical support is provided by an Indian team. The company may initially say: "The data is stored in Europe." That does not end the inquiry. If Indian support personnel are able to access customer data, personal data may be made available to an entity in a third country. Therefore, the organisation needs to examine whether that access constitutes a Chapter V transfer. This is why privacy teams should mapaccess, not merely storage.

Example

, US parent company A French subsidiary maintains employee records. The US parent wants monthly HR reports. The reports contain:

• employee names;
• compensation;
• performance ratings;
• disciplinary information. The French subsidiary sends the reports to the US parent. This is potentially an international transfer even though the purpose is internal corporate management. The company therefore needs to analyse the Chapter V mechanism. If the group uses BCRs, those may provide the appropriate framework where applicable. The fact that the transfer is "internal" does not itself eliminate Chapter V.

Example

, cloud infrastructure with multiple subprocessors Imagine:

1. EU company
2. US cloud provider
3. Indian support provider
4. Singapore infrastructure provider There may be several legal relationships. The organisation cannot responsibly assess the transfer merely by looking at the first contract. It needs to understand the chain. This is especially important because modern cloud architecture often involves:

• hosting;
• backup;
• support;
• monitoring;
• security;
• analytics;
• customer service. The actual data flow can therefore be considerably more complex than the contractual relationship suggests.

What Article 44 does not say

Article 44 does not say:

All international transfers are prohibited.

It does not say:

Every transfer requires SCCs.

It does not say:

Data must physically remain inside the EU.

It does not say:

A third-country recipient is automatically unlawful.

It does not say:

A contract alone always solves the transfer issue.

It does not say:

If Chapter V does not apply, GDPR does not apply.

The correct position is much more nuanced.

The relationship between Article 44 and Article 45

Article 45 is the adequacy route.

The basic idea is:

If the Commission determines that the relevant third country ensures an adequate level of protection, transfers can occur under that decision.

Article 44 still matters because adequacy is not conceptually detached from the overall protection objective.

The Commission's adequacy assessment is itself intended to address whether the destination provides an appropriate level of protection.

The EU-US Data Privacy Framework is an example of a current adequacy framework for participating US organisations, following the Commission's 10 July 2023 adequacy decision. The EDPB has issued information concerning transfers under that framework. (European Data Protection Board)

The important operational lesson is:

Always determine whether an adequacy decision actually covers the proposed transfer and recipient.

Do not simply write:

"Country X has adequacy."

Adequacy can be subject to scope and conditions.

The relationship between Article 44 and Article 46

Article 46 becomes particularly important where adequacy is unavailable.

The best-known mechanism is the European Commission's Standard Contractual Clauses.

But the existence of SCCs is not the end of the analysis.

The EDPB describes SCCs as pre-approved contractual instruments for international transfers. (European Data Protection Board)

After Schrems II, organisations must also consider whether the legal and practical environment of the destination undermines the protections contemplated by the SCCs.

This is why the modern analysis is:

SCCs + transfer circumstances + destination-country assessment + supplementary measures where necessary

rather than simply:

==SCCs = compliance.==

The relationship between Article 44 and Article 49

Article 49 contains derogations for specific situations.

Examples include certain situations involving

• explicit consent;
• contractual necessity;
• important reasons of public interest;
• establishment, exercise or defence of legal claims;

• protection of vital interests;

• certain publicly available data.

But these derogations are not intended to become a routine alternative to Article 46 safeguards.

This is a particularly important operational point.

Suppose a company routinely transfers European customer data to a US service provider.

It should not attempt to justify every routine transfer by obtaining individual consent merely because SCCs are inconvenient.

Article 49 is designed for specific situations and must be interpreted according to its conditions.

So Article 44 provides the overarching principle, while Articles 45, 49 provide the different routes and conditions.

A particularly important grey area: internet publication

One difficult question is whether publishing personal data publicly on the internet constitutes an Article 44 transfer merely because individuals outside Europe can access it.

There is no simple rule that:

"Public website = international transfer."

The transfer analysis focuses on the exporter, disclosure/making available to another entity, and third-country importer.

Therefore, simply making information publicly accessible does not automatically answer the Chapter V question.

But that does not mean public publication is unregulated.

Other GDPR provisions remain relevant, including:

• lawful basis;

• purpose limitation;

• data minimisation;

• transparency;

• special-category data restrictions;

• rights of data subjects.

This is an excellent example of why the absence of a Chapter V transfer does not mean absence of GDPR obligations.

The "same company" problem

Suppose an EU company operates its own subsidiary branch in India.

Is transferring data from the EU headquarters to the Indian branch automatically a Chapter V transfer?

The answer depends heavily on the legal structure.

If the Indian operation is merely part of the same legal entity, there may not be a disclosure to a separate controller or processor.

If it is a separate legal entity, the analysis can be different.

Therefore:

Corporate structure matters.

This is why data-flow mapping should identify not merely "Group X" but the actual legal entities involved.

Processor-to-processor transfers

Article 44 is not limited to controller-to-controller transfers.

Processors can also be involved.

Imagine:

EU controller → EU processor → Indian subprocessor

The EU processor may be making personal data available to the Indian subprocessor.

Chapter V therefore becomes relevant to the onward international transfer.

This is particularly important under Article 28 because controllers need visibility into subprocessing arrangements and appropriate contractual controls.

Why procurement teams need Article 44

Article 44 is not only a privacy-law issue.

It directly affects procurement.

Suppose procurement wants to buy:

"A US-based AI analytics platform."

The privacy team needs to know:

• What data enters the system?

• Where does the provider process it?

• Who receives it?

• Which subprocessors are involved?

• Where are those subprocessors?

• Is there an adequacy route?

• Which transfer mechanism is used?

• Can foreign authorities obtain the data?

• What technical safeguards exist?

Therefore, international-transfer compliance should often begin before the vendor is selected, not after the contract is signed.

Why AI systems make Article 44 more complicated

This is particularly important for modern technology.

Imagine:

EU company → AI SaaS provider → US infrastructure → Indian human review team

The company may believe it is merely "using an AI tool."

Legally, however, the processing chain may involve several recipients and several jurisdictions.

For example, prompts may contain:

• customer names;

• employee information;

• confidential documents;

• emails;

• identifiers;

• legal information.

The organisation must understand where those inputs are processed and who can access them.

Article 44 therefore has significant implications for:

• generative AI;

• cloud AI;

• analytics platforms;

• customer-support AI;

• automated transcription;

• translation services.

The international-transfer assessment should follow the actual data flow, not the marketing description of the product.

Why "EU-hosted" does not always end the issue

A vendor may advertise:

"Your data is hosted in the EU."

That is useful information but not necessarily the end of the transfer analysis.

Questions remain:

• Who owns the vendor?

• Who provides technical support?

• Can non-EU personnel access the environment?

• Are non-EU subprocessors involved?

• Is telemetry sent elsewhere?

• Are backups stored elsewhere?

• Does the vendor remotely administer the infrastructure?

Therefore:

EU data residency ≠ automatically no international transfer.

The relevant legal question remains who receives or can be given access to the data.

Article 44 and government access

Government access is one of the central concerns underlying modern international-transfer law.

Suppose a European company transfers data to a foreign processor.

The processor's local law permits a government agency to request access.

The organisation must consider whether that possibility undermines the protection required by the GDPR.

This is not simply about whether the government has ever requested data.

The assessment can involve:

• the applicable law;

• powers of public authorities;

• safeguards;

• necessity;

• proportionality;

• independent oversight;

• available judicial remedies;

• practical enforcement.

This is why a proper transfer assessment is a legal and factual exercise.

The importance of effective remedies

The CJEU's transfer jurisprudence places considerable emphasis on whether individuals have meaningful protection and remedies.

It is not enough to say:

"The third country has privacy legislation."

The deeper question is whether individuals can actually exercise rights and obtain effective legal protection.

This is part of the "essential equivalence" analysis.

A legal system that contains impressive privacy principles on paper but provides no meaningful remedy against disproportionate government interference may present a different risk profile.

The CJEU's jurisprudence has made this distinction central to international-transfer analysis. (InfoCuria)

Article 44 and accountability

Article 44 also reinforces the broader GDPR principle of accountability.

The organisation transferring the data must be able to demonstrate that it has addressed the transfer appropriately.

This is why documentation matters.

But documentation is not the objective.

The objective is lawful and adequately protected processing.

A 100-page transfer assessment that incorrectly describes the actual data flow is less useful than a short but accurate assessment.

The real question is:

Can the organisation demonstrate that it understood the transfer and implemented appropriate protection?

What makes Article 44 difficult in practice?

The difficulty is that international transfers are not merely geographical events.

They involve multiple layers:

Legal layer

Is the GDPR applicable?

Entity layer

Who is the exporter?

Who is the importer?

Processing layer

What processing occurs?

Contractual layer

What contractual safeguards exist?

Technical layer

Who can access the data?

Jurisdictional layer

Which laws apply to the recipient?

Remedial layer

What rights and remedies are available?

Article 44 connects all these layers through its central requirement that the GDPR's protection must not be undermined.

A complete example

Consider this hypothetical arrangement.

A French company operates an online marketplace.

Customer information is collected in France.

The company uses:

• a US cloud provider;

• an Indian customer-support provider;

• a Singapore analytics provider.

The architecture is:

Customer → French company → US cloud

and:

French company → Indian support company

and:

French company → Singapore analytics provider

Now analyse it.

First

The French company is subject to the GDPR.

Second

It discloses personal data to separate entities.

Third

Those entities are located outside the EU/EEA.

Therefore, Chapter V becomes relevant to each transfer.

Fourth

For each recipient, the company must determine the appropriate mechanism.

The answer may not be identical for every country or provider.

Fifth

The company must examine onward transfers.

Suppose the Indian support company uses a US subprocessor.

Now there is an additional transfer.

Sixth

The company must consider the rest of the GDPR.

For example:

Is customer-support processing lawful?

Is the information necessary?

Are customers informed?

Is the processor properly appointed?

Is the security adequate?

Seventh

The company must consider whether the destination's legal environment affects the protection available.

This is where the Article 44 principle becomes operational.

The deepest point: Article 44 is about continuity of protection

The easiest way to understand Article 44 is this:

Imagine GDPR protection as a protective boundary around personal data.

The data leaves the EU.

Article 44 asks:

What prevents that protective boundary from disappearing when the data crosses the border?

Articles 45, 49 provide the legal mechanisms for maintaining protection.

Article 44 supplies the underlying principle:

The protection must travel with the data.

That is the conceptual heart of Chapter V.

Article 44 is therefore more than a gateway provision

At first glance, Article 44 appears to say:

"Before transferring data abroad, comply with Chapter V."

But its actual legal significance is deeper.

It performs at least four functions.

First, it establishes that international transfers are subject to a special legal regime.

Second, it confirms that Chapter V operates in addition to, rather than instead of, the rest of the GDPR.

Third, it extends the protection principle to onward transfers.

Fourth, it provides the interpretative standard that the GDPR's level of protection must not be undermined.

This last function is why Article 44 became so important in the CJEU's transfer jurisprudence.

The relationship between Article 44 and Schrems II in one example

Imagine:

EU company → US processor.

The company signs SCCs.

If the analysis stopped there, the compliance exercise would be purely contractual.

Schrems II changes that approach.

The company must consider whether the destination-country environment allows the contractual protections to operate effectively.

Suppose foreign law permits authorities to obtain the relevant data in circumstances inconsistent with the protections expected under EU law.

The SCC itself cannot physically prevent that access.

The organisation may therefore need supplementary technical or organisational measures, or in some circumstances may have to reconsider the transfer.

This is the practical meaning of the principle that Chapter V must not undermine the GDPR's guaranteed level of protection. (InfoCuria)

A subtle but important distinction: transfer versus processing abroad

This distinction deserves to be remembered carefully.

Situation 1

EU company processes its own data abroad without disclosing it to another entity.

Potentially not a Chapter V transfer, depending on the circumstances.

But GDPR obligations remain.

Situation 2

EU company discloses data to a foreign processor.

Potentially Chapter V transfer.

Situation 3

EU company discloses data to an EU processor, which sends it to a foreign subprocessor.

Potentially onward international transfer.

Situation 4

Foreign company directly collects data from EU individuals.

Potentially GDPR applies under Article 3(2), but that direct collection is not necessarily itself a Chapter V transfer.

These distinctions are technically important and are often tested in advanced GDPR analysis.

The practical philosophy of Article 44

Article 44 ultimately balances two interests.

On one side:

Free movement of information and international commerce

Modern organisations cannot operate entirely within national borders.

On the other:

Fundamental rights and data protection

Individuals should not lose the protection of EU law simply because their information crosses a border.

The GDPR therefore does not choose:

"No international transfers."

Instead, it chooses:

"International transfers subject to safeguards that preserve the required level of protection."

That is the policy logic running through Chapter V.

Final analytical understanding

If you reduce Article 44 to one sentence, it is:

An organisation cannot use internationalisation of processing as a way to escape the level of data protection guaranteed by the GDPR.

But for professional GDPR analysis, that sentence needs to be unpacked.

When data is sent outside the EU/EEA, you first identify whether there is actually a Chapter V transfer.

You identify:

exporter → disclosure → importer → destination

Then you determine the applicable Chapter V mechanism:

adequacy → safeguards → derogation, as applicable

But you do not stop there.

You separately examine whether:

the underlying processing is lawful

the GDPR principles are respected

data-subject rights remain meaningful

security is appropriate

the recipient's legal environment affects the protection

onward transfers are controlled

the overall level of protection is maintained

That is the real significance of Article 44.

It is therefore best understood not as a procedural "permission to transfer" provision but as a constitutional-style principle for the entire international-transfer framework: Chapter V must facilitate international data flows without allowing the protection afforded by EU data-protection law to be diluted merely because the data has crossed a border.

The EDPB's international-transfer guidance reflects this approach by treating the identification of a transfer and the assessment of the applicable safeguards as substantive legal questions, while the CJEU's jurisprudence reinforces that the protection guaranteed by the GDPR must remain effective after the transfer. (European Data Protection Board)

In practical terms, therefore, whenever you encounter an international-data-flow problem, the wrong first question is:

"Which contract should we sign?"

The better sequence of reasoning begins with:

What data is moving, who is making it available, to whom, where is that recipient located, what happens after the recipient receives it, what Chapter V mechanism applies, and does the arrangement actually preserve the protection that the GDPR requires?

That is the logic of Article 44, and it is the foundation for understanding Articles 45, 49.