SCC Modules: Overview And Use Cases

If you pick the wrong SCC module, your data transfer paperwork may not match the parties’ GDPR roles. The 2021 SCCs have 4 modules, and each one maps to a different exporter/importer setup: controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller.

Here’s the short version: don’t choose a module based on the tool. Choose it based on who decides why and how the data is processed. If a party decides the purposes and means, it’s a controller. If it only acts on instructions, it’s a processor. That one role check decides the module.

If I had to boil the article down into a few points, it would be this:

• Module 1: controller → controller
• Module 2: controller → processor
• Module 3: processor → processor
• Module 4: processor → controller
• Each transfer leg needs its own check
• You can’t rewrite the SCC text
• Annexes must match the actual transfer
• Modules 2 and 3 include Article 28 processor terms

A few facts stand out. The 2021 SCCs replaced the old split approach with one modular set covering 4 transfer scenarios. And in many SaaS vendor chains, you won’t use just one module. You may need Module 2 for the vendor and Module 3 for the sub-processor in the same setup.

Standard Contractual Clauses (SCC) - What Are They? - Data Transfers

sbb-itb-5f36581

Quick Comparison

My takeaway: map the legal roles first, then pick the module, then complete the annexes with specific details. That is the whole job in plain English.

How the SCC Modular Structure Works

Once the roles are clear, the next step is to line them up with the SCC structure. The 2021 SCCs sort transfer rules into four role-based modules. That role match does more than point you to a form. It also sets the duties each party takes on.

General Clauses vs. Module-Specific Clauses

The SCCs work in two layers. First, there are general clauses that apply to every transfer. Then there are module-specific clauses that spell out the parties' duties based on their roles.

That distinction matters. A processor acts on instructions. A controller decides its own purposes and means.

The SCC text itself is fixed. As Mayer Brown notes:

"The SCCs have a modular approach, include general clauses applicable to all cases and four modules tailored to the capacity in which the parties will be using the personal data."

So yes, parties can choose the right module, fill in the annexes, and select from the options the SCCs allow. But they cannot rewrite the clauses.

How to Pick the Right Module

Start with the basics: identify the exporter, identify the importer, and then ask who decides the purposes and means of processing. If the importer decides the purposes and means, it is a controller. If it acts only on instructions, it is a processor. That answer tells you which module fits.

Sometimes the picture is messier. A business may handle different data flows in different roles. When that happens, more than one module can be folded into a single SCC agreement.

The annexes are where the role match turns into a working record of the transfer. Annex I.B must list the data, data subjects, transfer frequency, and retention periods. Annex II must describe the actual technical and organizational measures in specific terms.

Norton Rose Fulbright puts it plainly:

"The technical and organisational measures must be described in 'specific (and not generic) terms' and it must be clear 'which measures apply to each transfer/set of transfers'."

Table: Quick Comparison of the Four SCC Modules

The next section breaks down each module by transfer direction and use case.

The Four SCC Modules Explained

Start with the role pair. Then look at the transfer direction. That tells you which SCC module fits.

Module 1: Controller-to-Controller

Module 1 applies when both sides act as independent controllers. In plain English, each party decides for itself how the data will be used.

This module fits cross-border data sharing between independent affiliates or business partners that use the data for their own purposes. The data importer must handle rectification and erasure requests and can only pass data to other recipients if those recipients provide equivalent safeguards.

Module 2: Controller-to-Processor

This is the module most SaaS companies and many B2B teams use. It applies when an EEA controller sends personal data to a processor in a third country, and that processor acts only on the controller’s instructions.

Common examples include:

• Cloud hosting
• Payroll
• Email marketing
• Analytics

A useful detail here: the SCCs also include processor terms. Because of that, they often remove the need for a separate DPA.

If that processor brings in its own sub-processors, the next step is Module 3.

Module 3: Processor-to-Processor

Module 3 applies when an EEA processor hires a downstream sub-processor in a third country. That setup shows up all the time in SaaS delivery chains.

The sub-processor has to follow the controller’s instructions, as passed down through the exporting processor.

If the data goes back to a controller instead, use Module 4.

Module 4: Processor-to-Controller

Module 4 covers the reverse flow: an EEA processor sends data back to its controller in a third country. A common example is a service provider returning processed leads or support logs to the client that hired it.

Under this module, the exporter must flag any instructions that conflict with GDPR. So yes, the transfer direction is what decides the module.

How to Apply SCC Modules in Real Transfer Setups

Mapping Roles Across a Vendor and Sub-Processor Chain

One business relationship can call for more than one SCC module when different parts of the transfer involve different GDPR roles. The key is simple: look at each transfer leg on its own. Don’t try to cover the whole chain with one module.

In a SaaS setup, the controller-to-processor transfer uses Module 2. Then, if that processor sends the data to another processor downstream, that processor-to-processor transfer uses Module 3. After you map each leg, the annexes need to line up with the way the data actually moves.

There’s one point that trips people up all the time. If the vendor decides the purposes or means of processing, that vendor is acting as a controller. In that case, you use Module 1, not Module 2.

Completing the Annexes Accurately

Once the right module is set, the next step is filling in the annexes with the actual transfer details. Annex I.A identifies the parties and signatures. Annex I.B explains the transfer. Annex II sets out the concrete technical and organizational measures for each transfer flow.

Annex III comes into play for Modules 2 and 3 when the parties use specific prior authorization for sub-processors. In that case, it lists the named sub-processors.

Table: Practical Differences Between the Modules

Common Mistakes When Choosing an SCC Module

Even when the module seems obvious, these three mistakes still drive a lot of drafting problems.

Do Not Use the Product Type to Choose the Module

Don’t choose an SCC module based on the product or service. Choose it based on the legal role of each party.

If the importer decides the purposes or means of processing, use Module 1. If the importer acts only on instructions, use Module 2.

That same rule carries through vendor chains too. Each cross-border leg needs its own role check.

If you map the roles the wrong way, the SCCs may not fit the transfer.

Using One Module for Every Leg of a Transfer Chain

Don’t use one module for the whole transfer chain. Each leg needs to match its own role pair.

For example:

• A controller-to-processor transfer may use Module 2
• A downstream processor-to-processor transfer uses Module 3
• A processor-to-controller return uses Module 4

This is where teams often slip up. They treat the chain like one flow, when it’s often a series of separate handoffs with different legal roles.

Using Generic Annex Language

Getting the module right is only part of the job. The annexes also need to match the transfer as it happens in practice.

Generic annex language can weaken the legal validity of the transfer.

Use the actual data categories, purposes, transfer frequency, and security controls. Boilerplate that doesn’t match the transfer might look tidy on paper, but it can create problems fast.

Conclusion: Choosing the Right SCC Module for Each Data Flow

Once you’ve spotted the common mistakes, the last step is simple in theory but easy to get wrong in practice: match each transfer leg to the right SCC module.

The module you use depends on the exporter’s and importer’s roles in that specific data flow. That means each data flow needs its own module.

Use the module that fits the actual exporter/importer relationship in the transfer. A SaaS provider might act as a controller in one flow and a processor in another. So the direction of the transfer, along with who makes the decisions about the data, determines which module applies.

After the role map is set, write it down and apply the matching module. For B2B and SaaS teams, the safest path is to map each role pair, pick the matching module, and record that decision in the ROPA.

FAQs

How do I tell if a party is a controller or a processor?

Look at who decides why and how personal data gets processed. A controller decides the purpose and the way that processing happens.

A processor works with personal data on the controller’s behalf and follows documented instructions. If your organization makes its own decisions about processing, it’s a controller. If it acts only under another party’s direction, it’s a processor.

Can one vendor setup require more than one SCC module?

Yes. A single set of Standard Contractual Clauses can include more than one module.

That modular setup helps when the same parties play different roles across different data transfers. For example, they might act as a controller in one case and a processor in another.

What should I include in the SCC annexes?

Include the chosen modules, options, and any bracketed details so everything is clear.

In Annex I, identify the parties, describe the transfer, name the competent supervisory authority, and include:

• the transfer frequency
• the purpose and nature of the processing
• the data categories
• the sub-processors
• each sub-processor’s processing scope and duration
• the technical and organizational measures used to protect the data

Related Blog Posts

• Customizing SCCs for SaaS Companies
• Cross-Border Data Transfers: Privacy Shield vs. SCCs
• How SCC Clauses Protect Cross-Border Data
• New SCCs: Key Changes and Deadlines