Article 46 — Transfers subject to appropriate safeguards

At a glance

Mechanism	Transfers subject to appropriate safeguards
Tools	SCCs, BCRs, codes of conduct, certification, legally binding instruments, ad hoc clauses
Duty	Transfer impact assessment and supplementary measures where third country law defeats the safeguards
Limit	Contracts cannot bind foreign public authorities

Article 46 is one of the most practically important provisions in Chapter V of the GDPR. If Article 45 asks, “Has the European Commission already determined that this country provides adequate protection?”, Article 46 answers the next question:

“If there is no adequacy decision, how can the organisation still lawfully transfer personal data outside the EEA while preserving GDPR-level protection?”

The answer is: through appropriate safeguards, enforceable rights for data subjects, and effective legal remedies.

This is why Article 46 is particularly important for organisations using cloud providers, multinational groups, outsourcing arrangements, HR platforms, SaaS applications, customer-support providers, analytics providers, vendors and other service providers located outside the EEA.

A crucial point, however, is that Article 46 should not be understood as simply saying:

“Sign an SCC and the transfer is legal.”

That understanding is incomplete, particularly after Schrems II. The legal mechanism is more sophisticated. The organisation must consider the transfer instrument, the law and practice of the destination country, possible government access, the ability of the importer to comply with its contractual obligations, supplementary measures where necessary, and the availability of effective rights and remedies.

The best way to understand Article 46 is therefore to break it into its underlying architecture.

Where Article 46 fits within the international-transfer framework

Chapter V of the GDPR essentially creates a framework under which personal data can leave the EEA without the GDPR's protection simply disappearing once the data crosses the border.

The basic hierarchy is:

First route, Article 45: Adequacy

The Commission has already determined that the destination provides an adequate level of protection.

Example

An EU company wants to transfer customer data to a recipient in Japan and the relevant transfer falls within the scope of the EU-Japan adequacy decision. The organisation generally does not need to put an Article 46 transfer mechanism in place merely to legitimise that transfer.Second route, Article 46: Appropriate safeguards There is no applicable adequacy decision, but the organisation can establish appropriate safeguards.

The most familiar example is the use of Standard Contractual Clauses (SCCs).

Example

A German company uses a US-based service provider to process customer information. Assume the relevant transfer is not covered by an applicable adequacy mechanism. The German company may use an Article 46 mechanism, such as SCCs, subject to the other GDPR requirements.Third route, Article 49: Derogations

There is neither an applicable adequacy decision nor an appropriate-safeguard mechanism, but one of the narrowly defined derogations applies.

For example, in certain circumstances, a transfer may be necessary for the establishment, exercise or defence of legal claims.

These derogations are not supposed to become a routine substitute for Article 45 or Article 46.

The central distinction

A useful way of remembering Articles 45 and 46 is:

Article 45 = protection is considered adequate because of the destination country's legal framework.

Article 46 = protection is created or reinforced through a recognised safeguard mechanism.

But there is an important qualification:

Article 46 safeguards cannot simply contractually manufacture protection where the destination country's law makes the promised protection impossible.

That is the significance of Schrems II.

The basic purpose of Article 46

The fundamental problem addressed by Article 46 is straightforward.

Imagine that:

• an EU company has strong GDPR obligations;

• it transfers personal data to a processor in a country without an adequacy decision;

• the recipient's domestic law provides weaker protection;

• the data is now outside the direct territorial protection of EU law.

If the GDPR simply permitted that transfer without additional safeguards, the protection guaranteed inside Europe could be easily circumvented.

Article 46 therefore attempts to bridge the protection gap.

The mechanism is essentially:

No adequacy decision → impose recognised safeguards → ensure enforceable rights and effective remedies → assess whether those safeguards actually work in the destination environment.

That last part became particularly important after Schrems II.

What does “appropriate safeguards” actually mean?

This is probably the most important conceptual question under Article 46.

“Appropriate safeguards” are not simply security controls.

For example:

• encryption,

• MFA,

• firewalls,

• access controls,

• pseudonymisation,

• data-loss prevention,

are technical and organisational measures.

They may be extremely important, and in some circumstances they can constitute supplementary measures, but the concept of an Article 46 safeguard is broader.

Article 46 is concerned with a legal framework capable of ensuring that the transferred personal data continues to receive protection.

Therefore, an appropriate safeguard can be:

• SCCs;

• Binding Corporate Rules;

• approved certification mechanisms;

• approved codes of conduct;

• certain legally binding public-sector instruments;

• certain authorised contractual arrangements.

The safeguard must operate as part of the overall transfer architecture.

Article 46(1): the three essential requirements

Article 46(1) contains the core principle.

Where Article 45 does not provide the basis for the transfer, the exporter needs:

Appropriate safeguards

There must be an appropriate transfer mechanism.

Enforceable data-subject rights

The individual whose data is being transferred must have rights that can actually be enforced.

Effective legal remedies

There must be a meaningful route through which the individual can seek redress.

This third element is extremely important.

There is a major difference between:

“The contract says you have rights.”

and:

“You have a realistic legal mechanism through which those rights can be enforced.”

Article 46 requires the latter.

Why “enforceable” matters

Suppose an SCC says:

The data subject has the right to request deletion of their personal data.

That sounds good.

But imagine that:

• the importer is located thousands of kilometres away;

• the data subject cannot practically bring proceedings;

• the contractual provision gives no enforceable third-party rights;

• the importer can ignore the request without meaningful consequence.

The existence of wording on paper does not necessarily create effective protection.

This is why Article 46 focuses on enforceability.

The GDPR is concerned not merely with the formal existence of rights but with whether those rights can operate in practice.

Enforceable rights and effective remedies are different concepts

These two concepts are related but should not be collapsed into one.

Enforceable right

This concerns what the data subject is legally entitled to claim or demand.

For example:

• access;

• rectification;

• erasure;

• restriction;

• objection;

• compensation.

Effective remedy

This concerns what happens if that right is violated.

For example:

• Can the individual complain?

• Can the individual approach a supervisory authority?

• Can they go to court?

• Can they obtain an injunction?

• Can they obtain compensation?

• Can a decision actually be enforced?

Therefore:

A right without a remedy can be largely theoretical.

This is one of the deeper principles behind Article 46.

Why Schrems II fundamentally changed the way Article 46 is understood

The most important judicial development for Article 46 is the CJEU's decision in Schrems II (C-311/18).

The central lesson is that the transfer mechanism cannot be examined in isolation from the legal environment of the destination country.

Suppose an EU company and a US processor sign SCCs.

The SCC says:

“The importer will process the data only according to the exporter's instructions.”

But what if the destination country's law requires the importer to provide the data to a public authority in circumstances that conflict with that contractual obligation?

The contract cannot simply override the law of the destination country.

This creates the fundamental Schrems II question:

Can the importer actually comply with the safeguards in the destination country?

If the answer is no, signing the contract does not solve the problem.

The “essentially equivalent” standard

The transfer framework must preserve a level of protection that is essentially equivalent to that guaranteed within the EU legal order.

This does not mean:

Every foreign country must copy the GDPR word-for-word.

That would be unrealistic and is not the test.

A country can have:

• different legislation;

• different regulatory structures;

• different terminology;

• different institutional arrangements;

• different enforcement mechanisms.

What matters is whether the substantive level of protection and practical effectiveness are essentially equivalent.

A simple illustration:

Country A

Country A does not use the term “data protection impact assessment” but requires organisations to undertake a functionally equivalent risk assessment before high-risk processing.

That difference in terminology does not automatically make Country A inadequate.

Country B

Country B has a sophisticated-looking privacy statute but allows unrestricted government access to transferred data without meaningful limitations or effective judicial remedies.

That could create a serious problem despite the statute appearing comprehensive.

Thus:

Formal similarity is not the objective; effective protection is.

The transfer impact assessment concept

This is where Article 46 becomes highly operational.

Where SCCs or another Article 46 mechanism is used, the exporter needs to consider whether the law and practice of the destination country allow the safeguard to operate effectively.

This is commonly approached through a Transfer Impact Assessment (TIA).

The TIA is not simply:

“Does the country have a privacy law?”

It is much more specific.

The exporter needs to examine matters such as:

• What type of data is being transferred?

• Who receives it?

• For what purpose?

• What does the recipient do with it?

• What categories of individuals are involved?

• What laws apply to the recipient?

• Can public authorities access the data?

• Under what conditions?

• Is access targeted or broad?

• Is access necessary and proportionate?

• Are there judicial or independent oversight mechanisms?

• Can the importer legally comply with the SCCs?

• What technical or organisational measures are available?

• What happens if the importer receives a government request?

The analysis should be transfer-specific, rather than merely country-level.

Why the entire legal system of a country does not necessarily need to be analysed

An organisation does not necessarily have to conduct an exhaustive review of every statute in a country.

That would be commercially and legally unrealistic.

Instead, the analysis should focus on the areas relevant to the particular transfer.

For example:

A company transfers ordinary employee contact information to a payroll processor.

The relevant legal analysis may be very different from:

A company transfers highly sensitive health information to an AI analytics provider.

The second transfer may create substantially greater risks.

Similarly, the relevant legislation may differ depending upon whether the recipient is:

• a cloud provider;

• a telecommunications provider;

• a financial institution;

• a healthcare organisation;

• an advertising company;

• an AI service provider.

Therefore:

The question is not simply “Is Country X safe?” but “Is this particular transfer adequately protected in the legal and practical environment in Country X?”

Government access is a major Article 46 issue

One of the most difficult issues in international transfers is access by:

• intelligence agencies;

• police;

• national-security authorities;

• law-enforcement bodies;

• other public authorities.

A private contract cannot automatically bind a government.

Suppose:

Company EU → SCC → Company US.

The SCC binds the two companies.

But if US law requires Company US to disclose information to a government authority under specified circumstances, the government is not automatically bound by the SCC.

This is exactly why Schrems II required consideration of the destination country's legal system.

Four important questions concerning government access

A practical analysis should ask:

Question 1, Is government access legally permitted?

If yes, determine the statutory basis.

Question 2, How broad is the power?

Is it limited to specific circumstances, or is it potentially broad?

Question 3, Is access necessary and proportionate?

The existence of surveillance legislation is not automatically fatal.

The issue is whether the interference with fundamental rights is sufficiently constrained.

Question 4, What remedies exist?

Can the individual challenge unlawful access?

Is there independent oversight?

Can courts provide effective relief?

This last element is particularly important.

The four essential guarantees

The material you provided refers to four guarantees identified in European jurisprudence and reflected in the adequacy analysis.

They are extremely useful for understanding Article 46 as well.

Clear and accessible rules

Government access must be based on rules that are sufficiently clear and foreseeable.

An individual should not be subject to unlimited governmental discretion based on vague legal authority.

Necessity and proportionality

The interference must pursue a legitimate objective and remain within what is necessary and proportionate.

For example, a narrowly targeted investigation is legally different from indiscriminate access to enormous quantities of communications.

Independent oversight

There should be independent supervision of governmental access.

That could involve:

• courts;

• independent regulators;

• specialist oversight bodies;

• other legally independent institutions.

Effective remedies

Individuals need meaningful avenues to challenge unlawful interference.

This is particularly difficult in intelligence contexts because secrecy can make judicial challenge complicated.

Supplementary measures: why SCCs may not be enough

One of the most important practical consequences of Schrems II is the possibility that contractual safeguards may need to be supplemented.

Suppose:

EU exporter → SCCs → foreign importer.

The TIA identifies a risk that the destination country's law may permit government access inconsistent with EU fundamental-rights standards.

The organisation cannot simply say:

“We have signed SCCs, therefore everything is fine.”

It must ask whether supplementary measures can make the protection essentially equivalent.

Examples can include

• strong encryption;
• pseudonymisation;
• technical controls;
• strict access controls;

• organisational restrictions;

• transparency and notification measures where legally possible.

But supplementary measures are not a magic solution.

Encryption as a supplementary measure

Consider a company transferring encrypted customer records to a foreign cloud provider.

If:

• the exporter retains exclusive control of the encryption keys;

• the foreign provider cannot decrypt the data;

• the provider only stores ciphertext;

government access to the provider may have significantly reduced practical value.

This can strengthen the transfer arrangement.

However, the effectiveness depends on the circumstances.

If the foreign processor must decrypt the data to perform the service, encryption may provide much less protection against government access.

Therefore:

Encryption is effective only if it actually prevents the relevant threat.

Simply saying “the data is encrypted” is insufficient.

Pseudonymisation

Pseudonymisation can similarly reduce risk.

Suppose an EU company transfers:

Customer ID: 874521 Medical information: X Location: Y

but removes the direct identifying information and transfers only a pseudonymous identifier.

If the importer cannot independently identify the individual, the impact of unauthorised access may be reduced.

But again, context matters.

If the importer possesses the key needed to reverse the pseudonymisation, or can easily combine the information with other data to identify individuals, the measure may provide limited protection.

Therefore:

Pseudonymisation must be evaluated against the actual ability of the recipient or government authority to re-identify individuals.

A critical distinction: Article 46 safeguard vs supplementary measure

These terms should not be confused.

Article 46 safeguard

This is the legal transfer mechanism itself.

ExampleSCCs. Supplementary measure This is an additional protection introduced because the basic Article 46 mechanism may not, by itself, adequately address risks identified in the destination country.

ExampleEnd-to-end encryption where the importer does not possess the decryption key. Thus: SCC + encryption may be stronger than SCC alone.

But:

encryption ≠ SCC.

Encryption by itself does not necessarily satisfy Article 46.

Article 46(2): recognised safeguards

Article 46(2) provides a list of mechanisms that can be used without obtaining a specific prior authorisation from a supervisory authority.

These are important because they provide a structured legal basis for transfers.

The principal mechanisms are:

1. legally binding instruments between public authorities;

2. Binding Corporate Rules;

3. Commission-approved SCCs;

4. DPA-approved standard clauses approved by the Commission;

5. approved codes of conduct with binding commitments;

6. approved certification mechanisms with binding commitments.

The most commercially important mechanism in practice is generally the SCC framework.

Article 46(2)(a): public-authority instruments

This mechanism is primarily relevant to public bodies.

Imagine:

EU public authority ↔ foreign public authority.

They may establish a legally binding arrangement governing the exchange of personal data.

For example, a public authority in an EU Member State may need to exchange information with a corresponding public authority outside the EEA.

The instrument should not merely establish cooperation at an institutional level.

It needs to provide appropriate protection for the personal data involved.

Article 46(2)(b): Binding Corporate Rules

Binding Corporate Rules, or BCRs, are particularly relevant to multinational groups.

Imagine a multinational corporation with:

• headquarters in France;

• subsidiaries in Germany and Spain;

• shared-services centre in India;

• technology operations in the United States.

Personal data may need to move between the different group entities.

Because the entities are separate legal entities, merely saying:

“They are all part of the same corporate group”

does not eliminate the international-transfer issue.

BCRs can create a binding internal framework for transfers within the group.

Why BCRs are different from SCCs

SCCs are generally designed around a specific transfer relationship.

BCRs are more organisational in character.

They establish a broader internal data-protection framework governing transfers across the corporate group.

A useful distinction is:

==SCC = contractual transfer mechanism between relevant parties.==

==BCR = group-wide governance framework for multinational transfers.==

BCRs are therefore potentially valuable for large multinational organisations with extensive recurring intra-group transfers.

But they involve substantial compliance work and regulatory approval.

Intra-group transfer does not mean “no transfer”

This is a classic trap.

Suppose:

1. Parent company in Germany
2. Subsidiary in India

Because both companies belong to the same corporate group, an organisation may incorrectly assume that Chapter V is irrelevant.

That is not correct.

Separate group entities can be separate controllers or processors.

If the relevant conditions for a Chapter V transfer are met, the intra-group disclosure can constitute an international transfer.

This is one reason BCRs can be operationally valuable.

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

SCCs are probably the most important practical mechanism under Article 46.

They are standardised contractual provisions adopted by the European Commission.

Their attraction is obvious:

Instead of every exporter creating an entirely new international transfer agreement from scratch, the Commission provides a standardised legal framework.

But SCCs should not be understood as a “tick-box document.”

That is one of the most important lessons after Schrems II.

What SCCs actually accomplish

SCCs create contractual obligations between the exporter and importer.

Among other things, they establish obligations concerning:

• processing;

• data-subject rights;

• security;

• assistance;

• transparency;

• onward transfers;

• government access;

• handling of data-subject requests;

• cooperation with supervisory authorities;

• termination consequences.

The underlying purpose is to contractually preserve protection after the data leaves the EEA.

But what SCCs cannot do

This is crucial.

SCCs are contracts.

They cannot rewrite the sovereign law of the destination country.

Suppose the contract says:

“Importer shall never disclose the data to a public authority unless legally required under applicable EU law.”

Now assume local law requires the importer to provide the data under a legally enforceable national-security order.

The contract does not automatically invalidate the foreign law.

Therefore:

The contractual promise must be tested against the destination country's law and practice.

That is the essence of the Schrems II analysis.

The 2021 SCCs and modular structure

The current Commission SCC framework adopted in 2021 introduced a modular structure designed to accommodate different relationships.

Broadly, the modules address situations such as:

• controller → controller;

• controller → processor;

• processor → processor;

• processor → controller.

This is operationally important because the parties must select the appropriate module for the actual relationship.

An organisation should therefore not simply attach “the SCC” without determining:

• who the exporter is;

• who the importer is;

• whether each party is a controller or processor;

• what processing is actually occurring.

SCCs do not replace Article 5, Article 6 or Article 32 compliance

Another major misconception is:

“Once we execute SCCs, the transfer is compliant.”

No.

Article 46 sits within the GDPR.

The organisation must still comply with the rest of the GDPR.

For example:

• there must be a lawful basis for the underlying processing;

• purpose limitation must be respected;

• data minimisation must be considered;

• transparency obligations remain;

• security obligations remain;

• processor requirements remain where applicable;

• data-subject rights remain applicable.

The transfer mechanism addresses international transfer protection. It does not cure unrelated GDPR violations.

Example

SCCs do not legalise excessive collection Imagine a company collects:

• passport number;
• full medical history;
• family details;
• precise location;
• biometric information; for a simple newsletter subscription. It then signs SCCs with a processor outside the EEA. The SCC does not make the excessive collection lawful. The organisation may have:

1. a processing-lawfulness problem;
2. a data-minimisation problem;
3. potentially a transparency problem;
4. an international-transfer issue. Article 46 solves only the relevant transfer problem.

Article 46(2)(d): DPA-approved standard clauses

Article 46 also permits standard data-protection clauses adopted by a supervisory authority and approved through the relevant EU process.

The basic idea is similar to Commission SCCs.

Instead of the Commission itself developing the clauses, a supervisory authority may develop them, subject to the prescribed approval process.

This provides another standardised transfer mechanism.

Article 46(2)(e): approved codes of conduct

Codes of conduct are sectoral or organisational frameworks developed under Article 40.

They can provide practical rules for complying with the GDPR in particular sectors.

Article 46 allows an approved code of conduct to function as a transfer mechanism when accompanied by:

binding and enforceable commitments by the third-country controller or processor.

This last part is crucial.

Merely joining or referencing a code is not necessarily enough.

The third-country organisation must undertake binding commitments to apply the safeguards, including those concerning data-subject rights.

Why codes of conduct can be useful

Imagine an industry where many organisations have similar processing models.

For example:

• cloud computing;

• healthcare;

• advertising;

• financial services.

Instead of each company creating a completely unique transfer framework, an approved code can establish common sectoral standards.

The advantage is standardisation and sector-specificity.

The limitation is that the code must actually provide the required safeguards and binding commitments.

Article 46(2)(f): certification mechanisms

Certification is another mechanism.

The GDPR provides for certification mechanisms and data-protection seals or marks.

For Article 46 purposes, certification alone is not sufficient.

There must also be:

binding and enforceable commitments by the third-country controller or processor to apply the appropriate safeguards.

Thus:

Certification + binding commitments

is the relevant architecture.

Not simply:

==Certification badge = lawful transfer.==

Article 46(3): mechanisms requiring prior authorisation

Article 46(3) creates another category.

These safeguards can include:

A. Ad hoc contractual clauses

and

B. Provisions incorporated into administrative arrangements between public authorities.

But these require prior authorisation from the competent supervisory authority.

This distinction is important.

Standardised SCC vs ad hoc clauses

This is a common exam and operational distinction.

SCC

The Commission has already approved the framework.

Therefore, provided the organisation uses it appropriately, it does not generally require individual prior DPA authorisation merely to use the standard clauses.

Ad hoc contractual clauses

The organisation develops its own transfer clauses.

Because these are not part of the standard approved framework, the competent supervisory authority must authorise them.

So:

Standard mechanism → no individual prior authorisation merely for using the mechanism.

Custom mechanism → prior authorisation required.

Can organisations add provisions to SCCs?

Yes, but there is an important distinction between:

Supplementing the SCCs

and

Modifying the SCCs.

Recital 109 supports the possibility of adding clauses or additional safeguards provided they do not:

• contradict the SCCs;

• undermine their protective effect;

• prejudice fundamental rights and freedoms.

For example, parties could potentially add operational provisions concerning:

• additional security;

• internal procedures;

• technical controls;

• reporting;

• governance.

But they cannot modify the SCCs in a way that undermines their mandatory protection.

Why supplementary clauses are useful

Suppose the SCCs establish a baseline framework.

The parties might additionally agree that:

• all transferred data must be encrypted;

• the encryption keys remain exclusively with the EU exporter;

• the importer must maintain specified access controls;

• the importer must notify the exporter of government requests where legally permitted;

• the importer must challenge disproportionate requests where appropriate.

These provisions can strengthen the overall protection.

Thus, the SCC should often be viewed as a foundation, rather than necessarily the entire transfer compliance programme.

When does changing SCCs become a problem?

If an organisation materially changes the standard clauses, it risks moving away from the approved mechanism.

For example, suppose the standard clause gives a data subject a particular contractual right.

The parties cannot simply delete that right because:

“Our commercial agreement does not want customers bringing claims.”

That would potentially undermine the protection built into the approved framework.

The central test is:

Does the additional provision supplement the SCCs, or does it contradict or weaken them?

Article 46(3)(a): ad hoc contractual clauses

An organisation may create bespoke contractual safeguards for a particular transfer.

For example:

An EU public research institution needs to transfer a specialised category of information to a research organisation in a country for which no adequacy decision exists.

Instead of using the standard mechanism, the parties may develop bespoke contractual protection.

But this requires prior supervisory-authority authorisation.

This makes the mechanism less convenient than SCCs but potentially more flexible.

Article 46(3)(b): administrative arrangements

This is particularly relevant to public authorities.

Imagine:

EU health regulator ↔ foreign health regulator.

The authorities may need to exchange information.

They may use an administrative arrangement containing provisions designed to protect data-subject rights.

But because such arrangements may not have the same legally binding character as a treaty or other legally binding instrument, Article 46(3) requires supervisory-authority authorisation.

This creates an important distinction:

Article 46(2)(a): legally binding instrument

versus

Article 46(3)(b): administrative arrangement requiring authorisation.

The apparent paradox concerning enforceability

There is an interesting grey area here.

Article 46(3)(b) contemplates administrative arrangements that provide:

enforceable and effective data-subject rights.

But the underlying administrative arrangement itself may not necessarily have the same legal force as a legally binding international instrument.

This raises a practical question:

How can an arrangement that is not itself fully legally binding produce enforceable rights for individuals?

This is one of the conceptual difficulties identified in the commentary you supplied.

The solution has to come from the actual legal structure of the arrangement and the rights created, rather than simply relying on the label “memorandum of understanding.”

Article 46(4): consistency mechanism

Where the safeguard requires DPA authorisation under Article 46(3), the supervisory authority must apply the GDPR's consistency mechanism.

The reason is straightforward.

International transfers have consequences beyond one Member State.

If:

DPA A approves a transfer mechanism

while:

DPA B rejects an essentially identical mechanism,

the EU could end up with fragmented international-transfer standards.

The consistency mechanism therefore promotes uniformity.

Why consistency matters

Consider a multinational company operating across:

• France;

• Germany;

• Ireland;

• Spain.

Suppose each national authority independently applies Article 46 differently.

The organisation could face:

• different transfer requirements;

• conflicting decisions;

• inconsistent compliance expectations.

The consistency mechanism helps reduce that fragmentation.

This reflects one of the broader objectives of EU data-protection law:

Cross-border processing requires a degree of regulatory consistency.

Article 46 and processor arrangements

Article 46 applies to both:

• controllers;

• processors.

This is operationally important.

A processor cannot simply tell a controller:

“International transfers are your problem.”

Where the processor itself transfers data to a third country, the processor may have its own Chapter V obligations.

For example:

EU controller → EU processor → US sub-processor.

The second transfer may independently require an appropriate Chapter V mechanism.

This is why organisations need to map sub-processing and onward transfers carefully.

Onward transfers under Article 46

Suppose:

German company → Indian processor → US sub-processor.

The German company may have an Article 46 mechanism with the Indian processor.

But that does not automatically solve the next transfer.

The organisation must examine the onward transfer.

Questions include:

• Who is the next recipient?

• Where is it located?

• What role does it have?

• What transfer mechanism applies?

• Does the first transfer agreement regulate onward transfers?

• Can the original exporter maintain oversight?

• What happens to the data after the second transfer?

This is one reason SCC structures include obligations concerning onward transfers.

A practical transfer chain

A useful way to conceptualise international transfers is:

Exporter

Article 46 safeguard

1. Importer
2. Potential onward recipient
3. Further jurisdiction

Every stage can create a separate compliance issue.

Therefore, organisations should not stop their analysis at:

“We have an SCC with Vendor X.”

They should ask:

“Where will Vendor X actually send the data?”

Article 46 and cloud computing

Cloud services are a classic example.

Suppose an EU company uses a cloud provider.

The organisation needs to understand:

• where data is stored;

• where it is accessed;

• where support personnel are located;

• where backups are located;

• where disaster-recovery environments exist;

• which entities are processors or sub-processors;

• which jurisdictions can legally compel access.

A contract saying:

“Primary data centre is in the EU”

does not necessarily answer the Chapter V question.

If support personnel in a third country can access personal data remotely, the organisation may need to analyse whether that constitutes a transfer and whether Article 46 applies.

Remote access is an important operational grey area

Suppose the database is physically stored in Germany.

But a technical support team located in the United States can remotely access the database and view customer information.

The physical location of the server is therefore not necessarily the end of the analysis.

The critical question is:

Has personal data been made available to an entity in a third country?

The EDPB's transfer analysis focuses on the disclosure or making available of personal data to an importer in a third country.

Therefore:

“The data is stored in Europe” does not automatically mean “there is no international transfer.”

EU-based parent company with non-EU employees

Another example:

A French company employs staff in India through a group subsidiary.

Employee data is shared between the entities.

The fact that both companies belong to one group does not eliminate the transfer issue.

The organisation must identify:

• the controller/processor roles;

• the transfer;

• the destination;

• the appropriate Article 46 mechanism;

• employee rights;

• onward transfers;

• government-access risks.

BCRs may be particularly relevant for large groups, but SCCs may also be used depending on the structure.

Article 46 is not simply a “contract requirement”

This is perhaps the single most important operational lesson.

A weak compliance approach is:

“Vendor is outside the EEA → obtain SCC → file contract → done.”

A stronger approach is:

Step 1

Identify whether there is actually a Chapter V transfer.

Step 2

Check whether Article 45 adequacy applies.

Step 3

If not, identify the Article 46 mechanism.

Step 4

Execute the appropriate safeguard.

Step 5

Analyse the destination country's law and practice.

Step 6

Determine whether the safeguard can actually operate.

Step 7

Implement supplementary measures where required.

Step 8

Document the analysis.

Step 9

Monitor changes.

Step 10

Suspend, modify or reassess the transfer if circumstances materially change.

This is much closer to the post-Schrems II compliance model.

Article 46 and the “law and practice” of the destination country

A particularly important nuance is that the exporter should not look only at legislation.

There is a difference between:

law on the books

and

law as applied in practice.

A country may have an impressive privacy statute.

But if:

• the regulator is ineffective;

• courts rarely provide remedies;

• government agencies routinely ignore statutory limitations;

• enforcement is weak;

the practical protection may be considerably weaker.

Conversely, a country may use different legal terminology but have genuinely effective institutions.

Therefore:

The real-world operation of the legal system matters.

Why “essentially equivalent” does not mean “identical”

This distinction is extremely important for CIPP/E preparation.

Suppose the EU uses:

• GDPR;

• independent DPAs;

• specific data-subject rights;

• judicial remedies.

Country X uses:

• a different privacy statute;

• a different regulatory institution;

• different terminology;

• different enforcement mechanisms.

Country X does not automatically fail.

The question is whether the system as a whole provides a level of protection that is essentially equivalent.

Therefore, never answer an exam question by assuming:

“The country does not have GDPR → transfer impossible.”

That is wrong.

The GDPR does not require every third country to reproduce European legislation word-for-word.

But “different” does not mean “acceptable”

The reverse mistake is equally dangerous.

One cannot say:

“The GDPR doesn't require identical laws, therefore almost any foreign system is acceptable.”

No.

There are core elements that must be protected.

These include concepts such as:

• lawful and fair processing;

• purpose limitation;

• proportionality;

• data quality;

• retention;

• security;

• transparency;

• data-subject rights;

• restrictions on onward transfers;

• independent oversight;

• effective remedies.

The exact legal form may differ.

The level of protection cannot simply disappear.

Article 46 and data-subject compensation

An often overlooked aspect is compensation.

Suppose unlawful processing occurs in the destination country.

It is not enough to say:

“The data subject has theoretical rights.”

There needs to be an effective mechanism through which the individual can seek redress, including compensation where legally appropriate.

This is one reason Article 46 focuses on effective legal remedies, not merely contractual statements.

The “empty promise” problem

There is an important practical criticism here.

Suppose a consumer in France has their data transferred to a company in another country.

The contract says the individual can enforce rights.

But the individual may face:

• unfamiliar procedural rules;

• language barriers;

• high legal costs;

• jurisdictional difficulties;

• difficulties identifying the correct defendant;

• difficulties enforcing a foreign judgment.

A right that is theoretically available but practically inaccessible can become an empty promise.

This is why effectiveness matters.

Article 46 and government requests

A sophisticated transfer programme should also consider:

What happens if the importer receives a government request?

For example:

EU exporter → foreign processor

The processor receives:

“Provide this customer's data to the government.”

The organisation should have a defined process addressing:

• whether the request is legally binding;

• whether the importer must notify the exporter;

• whether notification is legally permitted;

• whether the request can be challenged;

• whether the scope can be narrowed;

• whether the importer can disclose only the minimum necessary data;

• whether encryption or pseudonymisation limits access;

• whether the exporter must be informed.

This is an important operational component of Article 46 compliance.

Why data minimisation becomes relevant to transfers

Suppose a government authority can legally compel access to data.

The risk is substantially different if the importer holds:

Dataset A

Name + email address.

versus

Dataset B

Name + passport + medical history + financial records + biometric information.

Therefore, transfer compliance should not be isolated from GDPR's broader principle of data minimisation.

Reducing the quantity and sensitivity of transferred information can reduce the impact of a potential government-access event.

The importance of pseudonymisation in transfer architecture

Imagine:

EU company retains identity information.

The foreign processor receives:

Customer 73829 Transaction information Product information

but cannot identify Customer 73829 without information retained exclusively by the EU exporter.

If the foreign authority obtains the processor's dataset, it may receive substantially less identifying information.

This is why technical measures can sometimes play a major role in making a transfer legally defensible.

But again, effectiveness must be demonstrated rather than assumed.

When supplementary measures may not save the transfer

This is another difficult area.

Suppose the importer must process data in plaintext to perform the service.

The destination country's law permits broad access to that information.

The exporter cannot technically prevent the importer from accessing the data.

Simply adding:

“We promise to protect the data.”

may not solve the problem.

Similarly, encryption is not meaningful if:

the importer must hold the decryption keys.

Therefore, there are situations where no supplementary measure can realistically eliminate the identified risk.

In such a case:

The transfer may need to be suspended or stopped.

This is one of the most consequential lessons of Schrems II.

Article 46 creates an ongoing obligation, not a one-time exercise

Another common mistake is to treat the TIA and SCC signing as a one-time event.

Imagine:

January 2026: Exporter assesses destination-country law.

March 2027: The foreign country introduces a new surveillance statute.

April 2027: The importer becomes subject to a new government-access obligation.

The original assessment may no longer accurately reflect the risk.

Therefore, international-transfer compliance needs ongoing monitoring.

This is particularly important for:

• long-term vendor arrangements;

• cloud services;

• multinational groups;

• high-risk processing;

• sensitive personal data.

Article 46 and vendor due diligence

From a practical privacy-counsel perspective, Article 46 should be integrated into vendor onboarding.

Before engaging a foreign vendor, the organisation should ask:

Corporate questions

• Where is the vendor established?

• Which legal entities will process the data?

• Are there sub-processors?

Data questions

• What categories of data are transferred?

• How sensitive is the data?

• How much data is transferred?

• For what purpose?

Technical questions

• Is data encrypted?

• Who controls the keys?

• Is pseudonymisation possible?

• Where are backups stored?

Legal questions

• What local laws apply?

• Can government authorities access the data?

• What remedies are available?

• Can the importer comply with SCC obligations?

Contractual questions

• Which SCC module applies?

• Are onward transfers controlled?

• Are additional safeguards included?

• Are termination obligations included?

This turns Article 46 into an operational compliance process.

A worked example: EU company using an Indian processor

Consider:

A French company uses an Indian IT-support company.

The Indian company receives:

• customer names;

• email addresses;

• support tickets;

• account information.

Assume there is no applicable adequacy decision covering this particular transfer.

Step 1, Identify the transfer

French company is the exporter.

Indian company is the importer.

Personal data is made available to the Indian entity.

Chapter V therefore becomes relevant.

Step 2, Select the mechanism

The parties may use an Article 46 mechanism such as SCCs.

Step 3, Contractual safeguards

The parties execute the appropriate SCC structure.

Step 4, TIA

The French company analyses relevant Indian laws and practices concerning:

• privacy;

• government access;

• law enforcement;

• intelligence;

• judicial oversight;

• remedies.

Step 5, Risk assessment

Suppose the analysis identifies some risks.

The company considers:

• encryption;

• pseudonymisation;

• restricted access;

• data minimisation.

Step 6, Operational controls

The company implements the measures.

Step 7, Monitoring

The company periodically reassesses whether the legal and factual circumstances have changed.

This is a much stronger compliance process than merely signing an SCC.

Worked example

EU parent and US subsidiary Suppose: German parent → US subsidiary. Both are part of the same corporate group. There is no assumption that the transfer is exempt merely because they are related companies. The group may consider:

• BCRs;
• SCCs;
• another applicable Article 46 mechanism. If SCCs are used, the organisation must still analyse the relevant US legal environment. The corporate relationship does not eliminate government-access concerns.

Worked example

cloud provider Suppose: Italian company → cloud provider. The company believes: “Our data is stored in the EU.” But the provider's support team in a third country can remotely access production databases. The organisation should examine whether:

• personal data is being made available to the foreign entity;
• the foreign entity qualifies as an importer;
• Chapter V applies;
• an Article 46 mechanism is required. The lesson is: Data location and data-access location are not necessarily the same thing.

Worked example

onward transfer Suppose: Netherlands controller → UK processor → US subprocessor. Even if the first transfer is properly structured, the onward transfer requires separate analysis. The controller should understand:

• whether the processor is authorised to use the US subprocessor;
• whether the relevant transfer mechanism covers that onward transfer;
• whether the US subprocessor is subject to the relevant contractual obligations;
• whether additional safeguards are needed. This is why vendor-management teams must maintain an accurate subprocessor map.

Article 46 and AI services

Article 46 is increasingly relevant to AI and SaaS arrangements.

Imagine:

EU company → AI provider outside the EEA.

The company uploads:

• customer communications;

• employee information;

• support tickets;

• documents containing personal data.

The organisation must consider:

1. Is there a Chapter V transfer?

2. Who is the importer?

3. Which legal entity receives the data?

4. Where is the data processed?

5. Where can support personnel access it?

6. Which subprocessors are involved?

7. What Article 46 mechanism applies?

8. What happens to prompts and outputs?

9. Can data be used for model training?

10. What foreign government-access laws apply?

11. Can encryption or pseudonymisation meaningfully reduce the risk?

This demonstrates why international-transfer compliance cannot be separated from modern technology procurement.

Article 46 and AI training

Suppose an EU organisation sends personal data to a third-country AI provider to train a model.

Even if SCCs are signed, the organisation must separately examine whether:

• the processing purpose is lawful;

• individuals have been appropriately informed;

• data minimisation is satisfied;

• the AI provider can use the information for training;

• retention is appropriate;

• onward transfers occur;

• government access risks are manageable.

Again:

Article 46 does not make an otherwise unlawful processing operation lawful.

Article 46 vs Article 45, the key comparison

Issue	Article 45	Article 46
Basic concept	Adequacy	Appropriate safeguards
Who establishes protection?	European Commission assesses destination	Exporter/importer establish recognised safeguards
Typical mechanism	Adequacy decision	SCCs, BCRs, etc.
Individual transfer contract	Generally unnecessary for Chapter V	Often required depending on mechanism
TIA concerns	Still relevant to overall compliance, but adequacy provides the transfer basis	Particularly important for assessing whether safeguards work
Government access	Considered in adequacy assessment	Must be considered when assessing effectiveness of safeguards
Supplementary measures	Not ordinarily the basis of the mechanism	Can be crucial where necessary
DPA authorisation	Not normally required for each transfer	Not required for standard Article 46(2) mechanisms, but required for Article 46(3) arrangements
Practical burden	Relatively lower for exporter	Generally higher

The most important conceptual distinction is:

Article 45 relies on an EU-level determination about the destination. Article 46 requires the parties to establish and maintain appropriate safeguards.

Article 46 vs Article 49

Another important exam distinction:

Article 46

Designed to provide a structured, recurring transfer mechanism.

Article 49

Provides specific derogations for exceptional situations.

For example, consent under Article 49 should not casually become the standard mechanism for routine outsourcing.

A company cannot reasonably structure a permanent global processing operation by repeatedly asking every individual:

“Please consent to us sending your data abroad.”

Where an Article 46 mechanism is appropriate and available, that is generally the more structured approach.

The “three-layer” way to analyse Article 46

For practical work, Article 46 can be reduced to three layers.

Layer 1, Legal mechanism

What Article 46 instrument are you using?

For example:

SCCs.

Layer 2, Destination-country environment

Can the importer actually comply with the safeguards?

This requires analysis of:

• laws;

• government access;

• enforcement;

• oversight;

• remedies;

• practice.

Layer 3, Additional protection

If the legal environment creates risks, what supplementary measures can reduce them?

For example:

• encryption;

• pseudonymisation;

• access controls;

• minimisation.

If the third layer cannot sufficiently address the identified risks, the transfer may need to stop.

A practical Article 46 compliance checklist

For a privacy professional, the following workflow is useful.

A. Identify

• What personal data is being transferred?

• Who is transferring it?

• Who receives it?

• Where is the recipient located?

• Is it actually a Chapter V transfer?

B. Check Article 45

• Is there an applicable adequacy decision?

• Does it cover this territory?

• Does it cover the relevant sector?

• Are there conditions or limitations?

C. Select Article 46 mechanism

• SCC?

• BCR?

• Code of conduct?

• Certification?

• Public-authority instrument?

• Authorised ad hoc clauses?

D. Assess destination country

• Relevant legislation?

• Government access?

• Law enforcement?

• Intelligence powers?

• Oversight?

• Judicial remedies?

• Practical enforcement?

E. Assess importer

• Can it comply with the safeguard?

• Has it experienced government-access requests?

• Can it notify the exporter?

• Does it use subprocessors?

• Where does it actually process data?

F. Supplement

• Encryption?

• Pseudonymisation?

• Key separation?

• Access restrictions?

• Data minimisation?

G. Document

Record:

• transfer;

• mechanism;

• assessment;

• identified risks;

• safeguards;

• supplementary measures;

• residual risk;

• monitoring process.

H. Monitor

Reassess when:

• law changes;

• vendor changes;

• processing changes;

• new subprocessors are added;

• data categories become more sensitive;

• government-access conditions change.

Important grey area: Is SCC execution enough?

No.

This is probably the most important practical answer.

SCC execution establishes an important contractual safeguard.

But after Schrems II, the exporter must consider whether the law and practice of the recipient country permit the SCCs to operate effectively.

Therefore:

SCC ≠ automatic compliance.

A better formulation is:

==SCC + appropriate assessment + effective implementation + supplementary measures where necessary = the relevant compliance architecture.==

Important grey area: Does a country need a GDPR-equivalent statute?

No.

The test is not textual duplication.

A third country can use a different legal system.

The question is whether the protection is essentially equivalent in substance and effectiveness.

Important grey area: Does every government-surveillance law prohibit transfers?

No.

The existence of surveillance or law-enforcement powers does not automatically mean that every transfer to that country is unlawful.

The analysis concerns:

• scope;

• necessity;

• proportionality;

• safeguards;

• oversight;

• remedies;

• the specific transfer;

• the ability to protect the data.

The problem arises where the overall legal environment prevents the required level of protection from being maintained.

Important grey area: Can encryption always solve the problem?

No.

Encryption is useful only if it meaningfully prevents the relevant authority or recipient from accessing intelligible personal data.

If the processor must possess the keys and process the information in readable form, encryption may provide little protection against certain forms of access.

Therefore, supplementary measures must be:

effective against the specific identified risk.

Important grey area: Does pseudonymisation automatically solve government access?

Again, no.

The analysis must ask:

• Who holds the re-identification key?

• Can the importer access it?

• Can the foreign authority obtain it?

• Can other information be combined with the dataset?

• Is re-identification reasonably possible?

Pseudonymisation is therefore a risk-reduction technique, not an automatic legal exemption.

Important grey area: Can the parties add their own clauses to SCCs?

Generally, supplementary clauses can be used provided they do not contradict or undermine the standard clauses.

But substantial modification of the standard contractual framework can create legal problems and may take the arrangement outside the approved standard mechanism.

Therefore, lawyers should distinguish between:

additional safeguards

and

substantive amendments to mandatory SCC provisions.

Important grey area: Can a processor decide the transfer mechanism alone?

Not necessarily.

The contractual and factual roles of:

• controller;

• processor;

• subprocessor;

must be understood.

Where a processor makes an onward transfer, the relevant contractual structure and Chapter V obligations must be considered.

A controller should therefore not blindly rely on:

“Our processor says it is GDPR compliant.”

It should obtain sufficient information to establish the transfer mechanism and assess the relevant risks.

Article 46 and accountability

Article 46 fits directly into the GDPR's broader accountability principle.

An organisation should be able to demonstrate:

“We identified the transfer, selected the legal mechanism, assessed the destination-country risks, implemented safeguards, and continue to monitor the arrangement.”

This is much stronger than simply producing an executed SCC when an auditor asks for evidence.

What a good TIA should demonstrate

A strong transfer assessment should answer four questions.

What is being transferred?

Data categories, individuals, purpose, volume and sensitivity.

Where is it going?

Country, recipient, subprocessors and onward destinations.

What could happen to it?

Including governmental access, legal compulsion, unauthorised access and onward disclosure.

What protects it?

SCCs/BCRs/etc. plus technical and organisational measures.

The conclusion should then explain whether those safeguards provide the required level of protection.

Why Article 46 creates a higher compliance burden than it initially appears

At first glance, Article 46 seems simple:

“No adequacy decision? Use appropriate safeguards.”

But the post-Schrems II interpretation makes it much deeper.

The organisation effectively needs to understand:

the transaction + the data + the recipient + the contract + the destination country's law + government access + remedies + technical safeguards + practical enforcement.

This is why international data transfer work is increasingly a multidisciplinary exercise involving:

• privacy lawyers;

• cybersecurity teams;

• procurement;

• vendor-management teams;

• IT;

• compliance;

• business teams.

The deeper philosophy behind Article 46

The fundamental principle is:

A geographical border should not become a loophole for reducing the protection afforded to personal data.

If a company is subject to GDPR inside Europe and sends personal data outside Europe, it should not be able to say:

“The GDPR no longer matters because the data has crossed the border.”

Article 46 attempts to prevent precisely that outcome.

At the same time, the GDPR does not prohibit global data flows.

That would be commercially unrealistic.

Therefore, Article 46 seeks a middle ground:

Allow international commerce while preventing the export of diminished fundamental-rights protection.

The relationship between contract and sovereignty

This is the deepest legal issue under Article 46.

A contract operates between private parties.

A sovereign state exercises public authority.

Therefore:

Private contractual safeguards have limits when confronted with mandatory foreign law.

SCCs can tell an importer:

“Do not disclose the data except in accordance with this agreement.”

But they cannot necessarily prevent a foreign state from imposing a legally binding disclosure obligation.

This is why the destination country's law must be assessed.

And this is why Schrems II is so important.

Article 46 after Schrems II in one sentence

If you remember only one principle, remember this:

A transfer mechanism is not sufficient merely because it exists on paper; it must be capable of providing the level of protection required by EU law in the actual legal and practical environment of the destination country.

That is the core of modern Article 46 analysis.

Article 46, exam-oriented conceptual map

For CIPP/E purposes, think of Article 46 as follows:

1. No adequacy decision?
2. Yes

Can you use an Article 46 mechanism?

Yes

Is there an appropriate safeguard?

SCC / BCR / approved code / certification / public authority instrument etc.

Are data-subject rights enforceable? Are effective legal remedies available? Can the importer actually comply with the safeguard under local law?

Yes

→ Transfer may proceed, subject to the rest of GDPR.

No / insufficient protection

→ Consider supplementary measures. If supplementary measures are insufficient:

→ Transfer may need to be suspended or prohibited.

Article 46, the biggest traps

Trap 1

“No adequacy decision means no transfer.”

Wrong.

Article 46 provides alternative mechanisms.

Trap 2

“SCCs automatically make a transfer lawful.”

Wrong.

Schrems II requires consideration of the destination-country legal environment.

Trap 3

“The third country must have exactly the GDPR.”

Wrong.

The standard is essentially equivalent protection, not identical legislation.

Trap 4

“Encryption automatically solves government-access concerns.”

Wrong.

It depends on whether encryption actually prevents the relevant access.

Trap 5

“Group companies can freely transfer data between themselves.”

Wrong.

Separate entities can still make Chapter V transfers.

Trap 6

“A contract provides rights, therefore the rights are enforceable.”

Wrong.

The rights must be practically enforceable and accompanied by effective remedies.

Trap 7

“Article 46 replaces the rest of the GDPR.”

Wrong.

The underlying processing must still comply with the GDPR.

Trap 8

“Once the SCC is signed, the assessment is finished.”

Wrong.

The legal environment and processing circumstances can change.

Article 46 and operational privacy practice

For a privacy lawyer, Article 46 is not merely a provision to cite in a privacy notice.

It appears in real-world work such as:

• drafting and negotiating SCCs;

• reviewing vendor contracts;

• conducting TIAs;

• analysing foreign surveillance laws;

• reviewing cloud arrangements;

• assessing subprocessors;

• designing encryption arrangements;

• advising procurement teams;

• handling M&A due diligence;

• designing multinational data architectures;

• responding to regulatory inquiries;

• maintaining records of international transfers.

A privacy professional who understands Article 46 therefore needs both legal and operational understanding.

The most important practical distinction: mechanism vs effectiveness

This is perhaps the best way to consolidate the entire Article.

There are two separate questions.

Question A, Do we have a valid transfer mechanism?

For example:

We have applicable SCCs.

Question B, Does that mechanism actually provide the required protection in this situation?

For example:

Can the importer comply with those SCCs despite the destination country's law?

A company can answer yes to A and still have a problem withB.

That is the essence of the post-Schrems II approach.

Final synthesis

Article 46 should therefore be understood as a risk-control architecture for international data transfers in the absence of adequacy.

It does not simply permit transfers by signing contracts.

Its logic is:

No adequacy → recognised safeguards → enforceable rights → effective remedies → examination of the destination-country environment → supplementary protection where necessary → ongoing monitoring.

The most important mechanism in everyday commercial practice is the SCC, but the SCC should be understood as the beginning of the transfer-compliance exercise rather than its automatic conclusion.

The destination country's legal system matters because a private contract cannot necessarily neutralise mandatory foreign law. This is particularly important where governments may access personal data for national-security, intelligence or law-enforcement purposes.

That is why the post-Schrems II approach asks whether the importer can actually comply with the contractual safeguards and whether the transferred data can continue to receive a level of protection essentially equivalent to that guaranteed in the EU.

Where risks exist, supplementary measures such as encryption or pseudonymisation may strengthen protection. But these measures must be assessed against the specific threat and processing context; they cannot be invoked as generic compliance labels.

At the same time, Article 46 does not require the third country to reproduce the GDPR word-for-word. The question is whether its legal and practical framework, combined with the contractual and technical safeguards applicable to the particular transfer, preserves the required level of protection.

Finally, Article 46 must be read together with Article 44, Articles 45 and 47, 49, the broader GDPR principles, and the CJEU's Schrems II jurisprudence. A transfer mechanism cannot cure an otherwise unlawful processing operation.

The simplest way to remember the provision is:

Article 45 asks whether the destination is already adequate. Article 46 asks whether adequate protection can be maintained through safeguards.

And after Schrems II, the decisive question becomes:

“Are those safeguards actually capable of protecting the data in the real-world legal environment of the destination country?”

If the answer is yes, the transfer can proceed subject to the applicable GDPR requirements. If the answer is uncertain, supplementary measures and further assessment may be necessary. If the answer is ultimately no and the protection cannot be restored, the transfer cannot simply continue because an SCC happens to have been signed.

That is the central legal and operational significance of Article 46 GDPR.